當你秉持著「減法原則」，將 slash init 自動生成的客觀事實與贅字全部砍乾淨之後，你手邊會得到一份極為乾淨、輕量的骨架。這時候，我們就要開始進行難度最高、但最具價值的核心動作——「加法原則」。
我們要將那些 AI 翻遍整個代碼庫（Codebase）也絕對猜不到的「隱性知識（Tacit Knowledge，或稱默會知識）」精準地寫入檔案中。默會知識指的是那些早已內化成你大腦直覺、平常連你自己都沒意識到的「潛規則」，它們通常只有在 AI 撞牆出錯、把事情搞砸的那一刻，才會突然浮上水面。
[ 隱性知識的加法地圖 ] | +---------------------+---------------------+ | | v v [ 商業死規定 (RFC2119 強度) ] [ 隱性聯動關係 ] - 代碼庫裡完全沒有的商業限制 - 改動 A 必須強制更新 B - 範例：價格對外顯示必須含稅 - 範例：改會員價必須改首頁與信件
實戰步驟一：利用五個黃金提問，強迫逼出你腦中的隱性直覺
為了將你腦中豐富的經驗和專案特質完美取出，並化為 AI 看得懂的規格，請在動手前，對自己進行以下五個問題的深度盤點：
這個專案有沒有「絕對不能犯、一出錯就完蛋」的死規定？
實戰案例：如果你正在開發一個電商系統，依照當地法規「所有對客戶顯示的商品價格都必須含稅」。AI 翻遍程式碼絕對找不到這條法條，如果沒寫，它極可能在設計新網頁時顯示了未稅價，直接導致嚴重的法律和客訴風險。
有沒有什麼事情「存在一套固定的、非技術性的處理路徑」？
實戰案例：公司規定「商品價格的調整，必須先在 Google Sheet 試算表中修改，再透過自動化腳本同步到網站資料庫；直接在網頁代碼上修改，下次同步時會被覆蓋」。這類非技術人員制定的固定流程，必須明文規定。
改完一個地方之後，還有哪些外觀或檔案要「被迫連動修改」？
實戰案例：只要調整了「會員價格」，首頁的 Banner、結帳頁面的提示、常見問題（FAQ）文件、以及寄給客戶的通知信件模板，都必須同步更新。這種「改 A 忘 B」的隱性聯動關係，是 AI 最容易漏掉的死角。
做到什麼程度，才算這項任務「真正完工（DoD, Definition of Done）」？
實戰案例：改完網站畫面的 code 之後，必須同時在「電腦版」與「手機版」瀏覽器上檢查排版；修改完購買流程後，必須實際去下一筆「一元測試訂單」確認金流串接。
如果 AI 遇到不懂、不知道的事情，應該指引它去哪裡找答案？
實戰案例：寫對外行銷文案就去看 docs 資料夾底下的品牌語氣指南；碰到退款問題就去看退款政策說明書。
實戰步驟二：使用 RFC2119 規範，將默會知識化為嚴格的行為規範
將上述五個問題的答案整理出來後，請套用以下工程級格式寫入 CLAUDE.md：
使用 RFC2119 網路協定字眼（Must / Should / May）：AI 對於「請盡量...」這種溫和的提示詞很容易裝死。請在 CLAUDE.md 中強制使用具備法律效力般的字眼：「修改價格 Must 從 Google Sheet 試算表開始」、「在濕度大於 70% 時 Should 自動啟動烘乾機」。這能讓 AI 瞬間判斷出哪些規則是毫無妥協餘地的死線。
定義結構化的驗收清單（DoD Checkpoint）：在檔案結尾設定一個 ## Definition of Done 區塊，規定 AI 在交付前必須自我檢查。這能強制約束 AI 在每一次交卷前，都像個幾十年經驗的老手一樣進行高標準的自我審查。