砍完之後該加什麼：AI 翻遍程式碼也猜不到的事

先砍掉一半那篇把常駐檔砍到剩骨架。這一篇做相反的事：加。

但加的不是你剛砍掉的那些。要加的是一種特定的東西，AI 翻遍整個程式庫也絕對猜不到的規則。這類東西有個名字叫默會知識（tacit knowledge）：早就內化成你的直覺、平常連你自己都沒意識到的潛規則。它有一個討厭的特性——你不會主動想起它，它只在 AI 把事情搞砸的那一刻才浮上來。

所以加法的困難不在寫，在挖。

砍完的骨架
   +
商業死規定        法規、政策，程式碼裡完全沒有
固定的非技術流程  先改試算表再同步，不是直接改程式
改 A 要連動 B     改會員價→首頁、結帳頁、通知信都要動
什麼算做完        電腦版與手機版都看過、下一筆測試單
不懂去哪找        品牌語氣看 docs/voice.md，退款看政策書

五個問題，把腦子裡的直覺逼出來

動手寫之前，對自己問這五題。每一題我附一個電商的例子，你換成自己的行業。

有沒有「絕對不能犯、一出錯就完蛋」的死規定？例如法規要求對客顯示的價格必須含稅。AI 看程式碼看不出這條，它很可能在新頁面顯示未稅價。看起來只是數字，實際是客訴和法律風險。

有沒有「固定的、非技術性的處理路徑」？例如公司規定價格要先在 Google Sheet 改，再由腳本同步到資料庫；直接改程式碼，下次同步就被蓋掉。這種流程是人定的，程式碼裡沒有它的痕跡。

改完一個地方，還有哪些地方要被迫連動？改了會員價，首頁 Banner、結帳提示、FAQ、寄給客戶的通知信範本都要跟著改。「改 A 忘 B」是 AI 最常漏的一類，它只看得到你叫它改的那個檔案。

做到什麼程度才算真的做完？改完畫面要在電腦版和手機版都看過，改完購買流程要實際下一筆一元測試訂單確認金流。這是任務說明書裡「完成定義」那一格的常駐版本。

它不懂的時候，該去哪裡找答案？寫對外文案看 docs/voice.md，碰到退款看退款政策。這一條讓常駐檔保持短，細節不用寫進來，指路就好。

我的經驗是第三題最值錢，也最難一次答完。多數連動關係是在 AI 漏掉一次之後才被加進去的。這不丟臉，這就是默會知識的挖法：撞一次，加一條。

用 MUST／SHOULD／MAY 寫清楚強度

挖出來之後怎麼寫？我借用網路協定文件（RFC 2119）的用字：MUST、SHOULD、MAY。這三個字在協定文件裡有嚴格定義，拿來當強度標籤剛好：

「請盡量……」這種溫和寫法，AI 很容易當成建議略過。標了 MUST，它至少知道這條沒有妥協空間。

不過有一件事要講清楚：寫 MUST 不會讓它變成強制。常駐檔仍然是「被讀、不被強制」的便條，MUST 的作用是讓 AI 分得出輕重，不是保證。真正沒有例外的事——不能提交金鑰、不能刪除測試——要靠 hook 和權限設定，hook 擋金鑰那篇講做法。

最後在檔案結尾加一段 ## 交付前檢查，把第四題的答案列成清單。它交卷前會對照一次。不保證每次都對照，但比沒有好得多。

動手做

常駐檔剛砍完、不知道加什麼的，開新對話貼這段，讓它問你五題，再幫你寫成規則：

請用五個問題拷問我，把我腦中關於這個專案的潛規則逼出來。一次問一題，等我回答再問下一題，我答不出來就先跳過：
1. 有沒有絕對不能犯、一出錯就完蛋的死規定？（法規、公司政策）
2. 有沒有固定的、非技術性的處理路徑？（先改哪裡、再同步哪裡）
3. 改完某個地方，還有哪些地方要被迫連動修改？
4. 做到什麼程度才算真的做完？（要在哪些地方檢查）
5. 你不懂的時候，該去哪裡找答案？（哪份文件、問誰）
問完之後，把答案整理成常駐規則：每一條標 MUST／SHOULD／MAY，最後附一段「交付前檢查」清單。不確定強度的標 SHOULD 並問我。
專案是：（一句話）

想從老同事腦中挖規則的，找方法有AI 老師傅經驗萃取。

只想先加最重要的一條？想一件 AI 最近替你改壞、而你當下說「它怎麼會不知道」的事。那句「它怎麼會不知道」，就是一條默會知識。寫下來，標 MUST 或 SHOULD，加進去。一條就好。

加對了的樣子：每一條你都能說出「這是 AI 從程式碼看不出來的」；五題裡第三題（連動）至少有一條；沒有一條是「請盡量」，每條都有強度標籤；AI 下次改 A 的時候，主動提到了 B。

砍完加的是「AI 翻遍程式碼也猜不到的事」：死規定、固定路徑、連動關係、什麼算做完、不懂去哪找。撞一次，加一條，默會知識只能這樣挖。MUST 讓它分得出輕重，但強制要靠 hook 和權限。

站內延伸

• 完成定義的原型 → 五格 Brief
• 真正的硬性防線 → hook 擋金鑰
• 想從老同事腦中挖規則 → 找方法AI 老師傅經驗萃取

來源： RFC 2119：Key words for use in RFCs to Indicate Requirement Levels（MUST／SHOULD／MAY 的原始定義）；「便條不是保險」的依據是 Claude Code memory 文件的「context, not enforced configuration」。五個問題與電商例子是我自己的整理。