第一部「喊停的成本要看可不可逆」、第二部「意圖對齊分兩層」、第三部「完成需要共同定義」——這三個收斂看起來是三件不同的事,但今天要做的,是把它們疊在同一個框架下看,找出貫穿全系列的那一條共通模式。
| 部別 | 摩擦類型 | 缺的是什麼 | 補救方式 |
|---|---|---|---|
| 第一部 | 提前喊停、判斷丟回來 | 重試門檻、驗證責任沒有預設值 | 把門檻跟驗證方式寫成前提條件 |
| 第二部 | 動手前沒對齊意圖 | 目標架構、意圖分類只存在腦中 | 複述確認、明講唯讀 |
| 第三部 | 宣稱完成沒有證明 | 完成標準只存在腦中 | 要求證據、限制外顯化 |
三行放在一起看,會發現一個共通的句型:「XXX 只存在授權者腦中,沒有被講清楚,執行者只能憑一般理解去猜,猜錯了就變成摩擦」。三部處理的其實是同一個問題在協作的不同階段(動手前、動手中、動手後)分別造成的表現。
如果只停留在「三部各自的規則」,下次遇到一個新的摩擦類型時,還是得從頭重新分析一次;但如果掌握了這個共通模式,遇到任何新的摩擦,都可以先問同一個問題:「這次摩擦,是不是因為某個標準只存在我腦中,卻沒有被講清楚?」 這個問題本身,就是一個可以套用到任何協作情境的診斷起點,不限於這個系列處理過的三類摩擦。
值得補一句:這個共通模式不是這個特定工具才有的現象,換成任何 AI coding 工具、甚至換成人跟人之間的協作,同樣的結構都存在——執行方能依據的,永遠只有被明講出來的資訊,隱性的標準無論多麼理所當然,都不會自動傳遞過去。
回想這個系列講過的所有案例,你覺得哪一個「只存在腦中卻沒講清楚」的標準,是你自己最常忽略、沒有意識到需要明講的?
明天是系列總結:把每一次「不對!」,變成寫進專案文件裡的一句話。