這是協作問題，不是技術問題
這個場景在各個團隊反覆上演：有人打開了 Agent，看著它做事，然後某一天發現唯讀開關不見了，或者在你還在看第一個 diff 的時候它還繼續在改。一小時後分支上有四十個改動，一半跟任務無關，沒人說得清 src/legacy/ 為什麼被動過。
接下來的抱怨總是同一句：我已經不認識這份程式碼了。
嚴格說，這不是 Agent 的 bug，而是一條從來沒被寫下來的規則，正在被一次次事故發現。
寫一段更長的提示詞沒有用
第一反應通常是寫更長的 prompt：「不要改無關檔案、不要刪測試、不要動部署設定」。它能撐過這個 session，然後就消失了。
提示詞是「每個 session、每個人」的；放在專案裡的檔案會被每一次 session、每一位同事、每一個你換用的 Agent 讀到——更關鍵的是，它可以像程式碼一樣被審查。團隊只需要在一個 PR 裡吵一次，而不是每次被 Agent 嚇到才吵。
四道護欄，按收益順序
1. 規則檔。 AGENTS.md（或 CLAUDE.md，或你的 Agent 從專案根目錄讀取的那個檔案）定義什麼叫「做完」：哪些指令才算驗證、哪些路徑不能碰、哪些事絕對不能自作主張。短到人也會願意讀。
2. 權限清單。 三份清單，結構比語法重要：
| 清單 | 放什麼 | 例子 |
|---|---|---|
| allow | 唯讀操作，加上專案本來就會跑的 test / lint / build | Bash(pnpm test:*) |
| ask | 會改寫歷史、安裝套件、連網的行為 | Bash(git push:*) |
| deny | 機密檔案、正式環境設定、部署流程、破壞性指令 | Read(./.env) |
沒有列到的一律回到「問人」。真正要避免的失敗模式是：權限寬到沒有人願意讀。
3. 保護路徑。 機密檔案、正式環境設定、資料庫 migration、CI 定義都要被明確點名，規則檔與 .gitignore 裡各寫一份。這一步把「判斷題」變成「機械檢查」——而只有機械檢查能扛得住截止日期。
4. 合併前的審查清單。 護欄判斷不了設計好壞，所以清單負責補位：diff 是不是超出這個任務該有的規模、有沒有刪掉或放寬測試、有沒有把錯誤悄悄吞掉、總結裡的數字是否都能對應到某次指令輸出。
護欄產生器 可以用一份短表單產出上面這四份檔案——指令、允許路徑、保護路徑、要強制的規則——並且跟著頁面語言切換中英文。
護欄做不到什麼
把邊界講清楚比誇大宣傳重要，因為誇大最容易讓團隊信錯東西：
- 不做設計審查。 一個改動可以完全在範圍內、測試全綠，但把架構搞得更糟。
- 不能讓 Agent 變誠實，只能讓它受限。 一個不能 push 的 Agent，照樣能在本地寫出錯誤的東西。
- 不能取代 git 紀律。 分支保護與小的提交粒度仍然是真正的回滾手段。
- 擋不住執意要繞的人。 總會有人為了解封去改 deny 清單——這正是權限設定本身值得被審查的原因。
把它當成爆炸半徑控制：目標是讓一個錯誤只值一次 revert，而不是一個週末。
讓它變成習慣
最有用的儀式很無聊：每次 Agent 做出讓你意外的改動之後，往規則檔加一行、往 deny 清單加一條。一個月後，這份檔案描述的就是你們團隊真實的協作方式，新換的 Agent 直接繼承。
兩個配套習慣：要過程不要只要結論（「列出你改了哪些檔案、為什麼」），以及開會前核而不是會後核——幾分鐘的檢查，勝過幾個小時的更正信。
如果你們的報表裡還有 Agent 生成的數字，AI 數字核驗器 處理的是同一個問題的另一半：看起來對、卻沒有出處的數字。