編碼 Agent

這是協作問題，不是技術問題 這個場景在各個團隊反覆上演：有人打開了 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 是不是超出這個任務該有的規模、有沒有刪掉或放寬測試、有沒有把錯誤悄悄吞掉、總結裡的數字是否都能對應到某次指令輸出。 護欄產生器 可以用一份短表單產出上面這四份檔案——指令、允許路徑、保護路徑、要強制的規則——並且跟著頁面語言切換中英文。 護欄做不到什麼 把邊界講清楚比誇大宣傳重要，因為誇大最容易讓團隊信錯東西： ...