> ## Content Index
> Fetch the complete content index at: http://localhost:2368/llms.txt
> Use this file to discover other available public pages before exploring further.

# 第一性原理：動手前先質疑前提
- URL: http://localhost:2368/first-principles-questioning-premises/
- Published: 2026-07-09T06:07:52.000Z
- Updated: 2026-08-23T13:54:26.000Z
- Description: 第一性原理是把問題拆回最底層事實再重推，而非沿用「別人都這樣做」的類比。以一次真實繞路為例：在既有前提內找了三種愈修愈重的解法，最後退回去問「這件事本來就該做嗎」，問題自然消失。並記下轉彎是被人的一連串提問逼出來的——提問品質決定人機協作的天花板。附可帶走的三問。
- Author: yuchang23
- Tags: #wiki, #wiki-concept

> **定義**：第一性原理（First Principles）是把一件事拆回「最根本、無法再往下拆、也不需要靠別的東西證明的基礎前提」，再從這些事實重新往上推——相對於「別人都這樣做，所以我也這樣做」的類比推理。落到日常，就是動手之前先質疑你正準備接受的那個前提。

*一篇寫給自己的覆盤。記錄一次資料遷移時，我跟 AI 怎麼一起在一個小問題上繞了三圈，最後靠「追問」才發現「根本不該那樣做」——並藉這個過程，把第一性原理講清楚。特別想留下的，是人機協作裡「AI 提解法、我追問前提」這個分工的真實樣子。*

## 先說結論

那次我遇到的問題是：**一批 Excel 檔案搬到 新的儲存體Azure Blob（雲端純檔案倉庫）之後，沒辦法線上預覽了。**

我把問題丟給 AI，請它想辦法「讓它能預覽」。AI 很快給了三種修法——全都是在「檔案已經在新的儲存體」這個前提底下打轉的解。我追問了好幾個問題，直到這一句才發現關鍵：

> 「等一下——這些檔案，本來就該被搬到新的儲存體嗎？」

原來這套系統的本質是**核准與參照**，檔案的真正來源是另一套進料檢驗系統。我根本不該複製一份檔案過來自己存，只要**參照**檢驗系統那邊的原始檔就好。

這一問，同時消滅了三個問題：預覽問題、重複上傳問題、還有法規上「同一份檔案存兩份、哪份為準」的疑慮。

**重點在於問「這個問題本來就該存在嗎」，而不是「這個問題怎麼解」。**後者是在既有框架裡埋頭找解法，前者是回到第一性原理。

## 什麼是第一性原理

「第一性原理」（First Principles）這個詞來自亞里斯多德，意思是：一件事情最根本、無法再往下拆、也不需要靠別的東西來證明的基礎前提。

推理的方式有兩種，剛好是對照：

| 類比推理（大多數人的預設）        | 第一性原理                   |
| -------------------- | ----------------------- |
| 「別人／過去都這樣做，所以我也這樣做」  | 「把事情拆到最底層的事實，再從事實重新往上推」 |
| 接受現有框架，在框架**內**找更好的解 | 質疑框架本身，問這個框架**本來就該存在嗎** |
| 快、省力、大多數時候夠用         | 慢、費神，但能看穿「其實不必要」的問題     |

一個常被引用的例子，是 SpaceX 執行長伊隆·馬斯克顛覆航太產業的核心思維：如果用類比推理，你會問「別人的火箭多少錢，我怎麼買便宜一點」；用第一性原理，你會問「火箭是由哪些原料組成的？這些原料本身值多少錢？」——結果發現原料成本只佔售價的一小部分，於是「自己造」這個原本荒謬的選項忽然變得合理。

重點不在火箭，而在那個**動作**：把問題拆回「最底層的事實」，而不是停在「別人怎麼做」或「現在的框架長怎樣」。

## 我這次是怎麼繞路的

把過程攤開來看，會很清楚地看到「類比推理」和「第一性原理」的分岔口在哪。

### 第 0 步：一個看似單純的症狀

系統要把附件從 SharePoint 搬到 Azure Blob（這是資料層遷移的一部分）。搬完之後發現：PDF 還能預覽，但 **Excel 檔沒辦法在瀏覽器裡線上打開了**。

### 第 1～3 步：AI 在框架內提解法、人在框架內追問（類比推理）

我把問題丟給 AI 的時候，我們其實共用了同一個心智模式：「檔案已經在新的儲存體了，這是既定事實，任務是讓它能預覽。」在這個前提底下，**AI 一路往下給方法，我也順著同一個框架一種一種追問**——注意，這三種修法都是 AI 提的，我的角色是追問細節、然後一個個否決：

1. **AI 先提微軟的 Office Online Viewer**——它需要一個「公開可讀的網址」，我一追問「那我們的檔案安全嗎」才發現：新的儲存體是靠 限時簽章（SAS）授權、不對外公開，兩者不合。
2. **AI 再提產生臨時公開連結**——技術上做得到，但我追問「這不就把檢驗檔案短暫暴露到公開網路了？」——在一家做精密製造、重視稽核的公司裡，這是不能接受的。
3. **AI 又提自己接一套線上文件轉檔／檢視引擎**（Collabora／OnlyOffice 之類）——除了 AI 給的這三個方法，我還想知道有沒有其他更好的建議，但為了「預覽一個 Excel」多養一個服務、多一份維運成本，這明顯太過沉重。

> **這就是類比推理的陷阱：我跟 AI 都沒質疑過最上游那個前提，於是只會愈修愈深。**

### 第 4 步：終於追問了那一句

後來換個方向追問：「為什麼 SharePoint 上就能預覽，新的儲存體上就不行？」

答案是：**SharePoint 內建了 Office 的線上算圖引擎，新的儲存體只是純粹的檔案倉庫，它本來就不負責「打開」檔案。**

這個事實一浮出來，下一個問題就自然接上了：「那……我為什麼要把檔案從一個『會預覽』的地方，搬到一個『不會預覽』的地方？」

### 第 5 步：回到最上游，問「根本需求是什麼」

再往上一層，我問了真正該最先問的問題：「這套核准系統，跟檔案的關係到底是什麼？」把它拆到底層事實：

- 公司有**兩套系統**。一套是**進料檢驗系統**，品管人員在那裡上傳檢驗檔案——那是檔案的**原始來源**。
- 另一套是這個**核准系統**，它在幾個核准關卡需要「看到」那些檢驗檔案，好做核准判斷。
- 使用者真正想要的是：**品管只在檢驗系統上傳一次，核准系統這邊直接引用，不要再傳第二次。**

於是本質浮現了：**這套核准系統，本質是一層「純核准／參照層」。它需要的是「指向原始檔案的參照」，而不是「自己保管一份副本」。**

一旦這樣定義，前面所有的糾結全部解散：

- 不用煩惱新的儲存體怎麼預覽——因為檔案本來就該留在會預覽的檢驗系統／SharePoint。
- 不用煩惱重複上傳——因為只有一個上傳入口。
- 不用煩惱「兩份哪份為準」——因為只有一份，單一事實來源。

那個 Excel 預覽問題，不是被「解決」的，是被**問到不存在了**。

## 轉彎，是被「問」出來的

前面那個「終於退一步」的動作，不是 AI 自己想通的，是**我一連串的提問**讓它重新思考，才把它引導出來的。這是跟 AI 協作做的事，值得把真實的提問順序留下來——關鍵不在答案，在**問題問對了沒**。

把當時問的問題照順序排出來，就看得到「還在框架內」和「跳出框架」的分界：

1. 「檔案搬到新的儲存體之後，為什麼沒辦法線上預覽？」——症狀提問，完全在框架內：預設「檔案搬過來」是對的，只想知道怎麼修。
2. 「有沒有現成的線上檢視服務？會有臨時的公開連結嗎？」——探索解法，仍在框架內，只是把選項攤開比。這兩問對應到前面第 1、2 種修法。
3. 「有沒有更好的解法？我想繼續討論。」——**第一個轉折點**。重點不是找第四種修法，而是**不接受目前這些勉強的解**。當一個人願意說「這些都不夠好，再想想」，就是他開始不信任這個框架了。
4. 「那我回到最一開始，為什麼要這樣做？我們其實有兩套系統——一套讓人上傳原始檔案，另一套只是要在流程中看到那些檔案。我想要只上傳一次，另一邊直接引用。你有沒有更好的建議？」——**真正的第一性提問**。注意結構：先「回到最一開始」，再把**真實場景和真正意圖**攤開。問題被這樣重述後，答案（參照，而非複製）幾乎自己浮出來。**這一問才是整條繞路的出口。**
5. 「這一連串的討論，有回歸到第一性原理嗎？」——事後的**後設反思**。它檢查的不是題目，是**自己的思考方式**；正是這一問，讓「動手前先質疑前提」從偶然變成刻意留下的原則。

規律很清楚：**問題 1、2 是「怎麼做」，問題 3、4、5 是「為什麼做／該不該做」。**前者讓協作往框架深處鑽，後者才把它拉回地面。

給人機協作的提醒：**AI 很擅長、也很樂意在你給的框架裡把事情做到最好，它預設會相信你給的前提。所以「質疑前提」往往得由人來介入。**你問「怎麼修」，AI 就一路幫你修；你問「這本來就該做嗎」，它才會跟你一起回頭。提問的品質，決定協作的天花板。

## 為什麼會繞路——這才是要記住的部分

繞路不丟臉，繞路是常態。要記住的是「為什麼會繞」，才有辦法下次早點轉彎。

1. **接受了一個沒被檢驗的前提——而且是雙方一起接受的。**我把「檔案要搬到新的儲存體」當成不可動搖的起點，AI 也預設它成立，於是雙方所有力氣都花在「搬過去之後」。但那個前提本身，才是問題的根源。這也點出人機協作的一個盲點：**AI 不會替你質疑你給它的前提，它預設你是對的。**
2. **眼前的問題會把注意力往下拉，不會往上拉。**「不能預覽」是一個很具體的症狀，具體到你會立刻想動手修它。愈具體的症狀，愈容易讓人跳過「這問題該不該存在」這一層。
3. **每個局部修法「看起來」都在前進。**但這種「假前進」最危險——它讓你更捨不得回頭，因為回頭等於承認前面白走。
4. **真正的需求藏在使用者那邊，不在規格書裡。**規格寫的是「搬檔案到新的儲存體」，但使用者要的是「只上傳一次」。規格是別人對需求的**一次轉譯**，而轉譯可能就已經轉錯了。第一性原理要越過規格，問到人。

## 可以帶走的做法

把這次的教訓變成一個下次真的用得上的動作，而不是一句口號，讓AI建一個Skill。

**在「實作／遷移／大改架構」之前，先問三個問題：**

1. **這個問題的根本需求是什麼？**（越過症狀、也越過規格，問到使用者真正要的結果）
2. **現在這個框架／前提，本來就該存在嗎？**（把「既定事實」拿出來質疑一次）
3. **如果從一張白紙重來，我還會這樣設計嗎？**（用第一性重推，而不是沿用類比）

**什麼時候該用、什麼時候不必：**

- **該用**：要動架構、要搬資料、要引入新服務、發現自己「愈修愈複雜」的時候。「愈修愈複雜」幾乎總是一個訊號——你可能在錯的前提上努力。
- **不必**：改個錯字、調個樣式、明確的小修補。對瑣碎的事盤問前提，只是拖慢自己。第一性原理是拿來對付「大方向」的，不是拿來折磨每一行程式碼的。

**一個判斷訣竅：**

> 當你發現某個解法「愈想愈勉強、愈修愈重」，先別找第四種解法——停下來，回頭問那個最上游的前提。

## 尾聲

這次的檔案預覽問題，最後不是靠一個聰明的技術方案收尾的，是靠**退回去問一句最笨的問題**收尾的：「這件事本來就該做嗎？」

第一性原理聽起來很高深，但它落到日常，其實就是這個習慣：**動手之前，先花三十秒質疑你正準備接受的那個前提。**大部分時候前提沒問題，你三十秒後照樣動手。但只要偶爾有一次，那個前提是錯的——你就省下了一整條繞路。這一次，就是那一次。

## 相關條目

- [Office 檔搬到雲端倉庫後為何無法線上預覽](https://yuchang23.com/office-preview-needs-render-engine/?ref=localhost)——本文那三種修法的技術細節版
- [臨時簽章連結（SAS）是暫時的公開連結：交給第三方的信任邊界](https://yuchang23.com/sas-link-trust-boundary/?ref=localhost)——第二種修法為何不可接受
- [絞殺榕式搬家：系統換底不重寫](https://yuchang23.com/strangler-fig-migration/?ref=localhost)——這次繞路發生在資料層遷移的脈絡裡
- [找出未知：四象限框架與反向面試、盲點掃描](https://yuchang23.com/finding-unknowns/?ref=localhost)——同樣是「動手前先把前提問清楚」的方法
- [SDD：規格先行的開發流程](https://yuchang23.com/spec-driven-development/?ref=localhost)——第一性原理要越過規格問到人，兩者互補