第一性原理：動手前先質疑前提

定義：第一性原理（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 檔搬到雲端倉庫後為何無法線上預覽——本文那三種修法的技術細節版
• 臨時簽章連結（SAS）是暫時的公開連結：交給第三方的信任邊界——第二種修法為何不可接受
• 絞殺榕式搬家：系統換底不重寫——這次繞路發生在資料層遷移的脈絡裡
• 找出未知：四象限框架與反向面試、盲點掃描——同樣是「動手前先把前提問清楚」的方法
• SDD：規格先行的開發流程——第一性原理要越過規格問到人，兩者互補