這篇算是近期系列文章的補充篇／支線任務。它不太適合直接放進主文，所以我單獨發表。這在 [《軟體工廠為何失敗》](https://x.com/dexhorthy/status/2080697380379427275) 第二部分 [《重新點亮燈光》](https://x.com/dexhorthy/status/2081058573556306030) 中略有提及。
尋找槓桿點
早在 AI 出現之前，開發一個功能所需的時間，只有 25-50% 是花在寫程式碼本身。其餘的時間都用在對齊需求／規劃、程式碼審查／重工，以及測試／驗證解決方案上。
如果你只靠 AI 來寫程式碼，那你只是把 2-4 小時的編碼時間縮短到 10-20 分鐘，但其他環節完全沒有加速。
但如果你用 AI 來協助規劃和對齊需求，那麼你實際上可以達到接近 2-3 倍的速度提升。
AI 編碼的 80/20 法則
假設你隨意地將一個兩句話的提示丟進你的工廠，那麼你獲得一個完全可合併結果的機率大約是 50%，而有 50% 的機率需要重工。
現在，假設你是一位擁有 10 年經驗的首席工程師。你已經將橫跨 100 個儲存庫的整個程式碼庫都記在腦中。於是你花了一個下午，親手撰寫了一份完美且詳盡的規格。這樣一來，你的成功率提升了，但可能仍有約 10% 的機率，你需要重做某個重要的部分。
而極端的情況是：自己動手寫每一行程式碼。這樣 Agent 就沒有任何出錯的空間，重工的機率則降為零。
注意： 在這個例子中，我會把
「你需要修改某事的機率」乘以「修改的麻煩程度」
模糊成一個單一的百分比數字，但顯然它們是兩個不同的變數。如果模型有 50% 的機率弄錯按鈕樣式，但修正方法就是一個簡單的提示，那麼我們整體的「預期痛苦」就會很低。
預期痛苦 = 你需要修改的機率 × 修改的麻煩程度
如果你把這個關係畫出來，就會發現前期投入的努力與預期痛苦之間存在反比關係。
你不想做的事情是，為了一個任務花費 6 小時規劃，但你其實可以在前 10 分鐘內就消除 80% 的預期痛苦。
你需要在不鑽牛角尖於那些無法在不深入細節的情況下回答的問題來做到這一點。例如，如果你已經在「產品」層級做了一些工作，但尚未解答所有懸而未決的問題，那麼你可能需要先停下來，深入技術細節層級，以了解什麼是可行的。這方面沒有完美的流程。
這就是我們所說的槓桿 - 而這需要務實的態度。如果你正在進行多階段的規劃，從五萬英尺的高空視角一路縮小到一萬英尺的視角，你希望在每個階段都進行一點微調，以確保你盡可能地消除最多的預期痛苦。
祝好運。
