前言：為什麼想寫這個系列

這個系列的起點，是一份把過去 14 個工作階段、646 則訊息、339 小時協作紀錄整理成模式跟數據的報告。第一次看到這份報告時，本能反應是想反駁——那些摩擦都有各自的情境，不能一概而論。但整理成文章寫下來之後才發現，同一類摩擦反覆出現，這件事本身就是最有力的證據：這些不是各自獨立的意外，是一直沒有被講清楚的規則，在不同情境下用不同的樣貌重複出現。

三部內容回顧

第一部（Day 1-10）：提前喊停，把判斷丟回來。 從連線失敗就下結論、驗證工作丟回來問，講到缺乏預設政策、偽尊重這兩個根因，一路走到真實案例跟兩條規則。收斂：喊停的成本要看這件事可不可逆。

第二部（Day 11-19）：動手前沒對齊意圖，路線就走偏。 從先動手才發現理解錯架構、提問被誤判成請求，講到目標架構隱性、問題與請求語法模糊這兩個根因，走到複述確認機制跟唯讀模式宣告兩條規則。收斂：路線走偏不是能力問題，是意圖沒對齊，而且對齊分成「該不該做」跟「該怎麼做」兩層。

第三部（Day 20-28）：宣稱完成，但沒有證明。 從宣稱完成卻有殘留、本機綠燈換環境卻失效，講到主觀認為完成跟有證據的完成之間的落差、完成標準的隱性，走到證據優先跟限制外顯化兩條規則。收斂：高標準不是壓力來源，是讓「完成」有共同定義。

個人心得：一份報告逼我承認的事

老實說，第一次看到這份報告整理出來的摩擦類別時，心裡的第一反應是防衛性的——覺得每一次的糾正都有它的特殊情境，用數據把它們歸類成幾種固定模式，好像抹殺了每個情境的個別性。但寫完這 30 天回頭看，我承認自己錯了：正因為這些摩擦在完全不同的情境下反覆出現同樣的結構，才更值得認真對待——如果只發生過一次，可以當成意外；反覆發生，代表背後有一條一直沒被講清楚的規則在起作用。

寫這個系列的過程也讓我意識到一件更基本的事：我對「授權」這件事的理解，可能一直太粗略了。以為授權就是講清楚「要做什麼」，卻很少花力氣講清楚「怎麼驗證」「該做到什麼程度」——這些沒講清楚的部分，最後都變成了協作中的摩擦，要靠當下的糾正一次次補回來，而不是一開始就講好。

給讀者的具體建議

如果你也想用類似的方式檢視自己跟 AI 的協作模式，一個可行的第一步不是「把所有規則一次寫進專案文件」——而是先回想你最近一個月最常說出口的糾正句是哪一句，把它拆解成「現象、根因、規則」三段，寫成一句具體的前提條件。走完一次之後，你會發現這個拆解方法可以套用到下一句糾正，逐步把「事後靠糾正對齊」的協作模式，變成「事先講清楚」的協作模式。

語言/工具可遷移性

貫穿全系列的核心模式——某個標準只存在授權者腦中、執行者只能憑一般理解猜測——跟用哪個 AI 工具、甚至跟是不是 AI 都無關，換成任何形式的委派協作都成立。具體的機制（例如把規則寫進 CLAUDE.md、透過 hooks 在動作發生時自動檢查）是 Claude Code 這個工具的實現方式；換成其他 AI coding 工具，原則一樣適用，但落地成具體規則的地方要換成對應工具的等效機制。

結語

Day 01 立的主題句，這裡再說一次：跟 AI 協作時反覆出現的摩擦，幾乎都不是能力問題，是某條規則當下沒有講清楚——把每一次摩擦，變成一條寫進專案文件裡的具體規則，摩擦才會真的減少，而不是下次繼續靠當場糾正。 這句話最早只是為了整理這一份使用報告寫的，但寫完這 30 天回頭看，它其實適用在任何一段長期、高頻率的協作關係上——不管協作對象是 AI，還是任何一個需要被授權、需要被講清楚規則的人。