AI 编码 Agent 需要的是护栏，不是更多信任
这是协作问题，不是技术问题 这个场景在各个团队反复上演：有人打开了 Agent，看着它干活，然后某一天发现只读开关不见了，或者在你还在看第一个 diff 的时候它还在继续改。一小时后分支上有四十个改动，一半跟任务无关，没人说得清 src/legacy/ 为什么被动过。 接下来的抱怨总是同一句：我已经不认识这份代码了。 严格说，这不是 Agent 的 bug，而是一条从没被写下来的规则，正在被一次次事故发现。 写一段更长的提示词解决不了 第一反应通常是写更长的 prompt：「不要改无关文件、不要删测试、不要动部署配置」。它能撑过这个 session，然后就消失了。 提示词是「每个 session、每个人」的；放在仓库里的文件会被每一次 session、每一位同事、每一个你换用的 Agent 读到——更关键的是，它可以像代码一样被 review。团队只需要在一个 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 是不是超出了这个任务该有的规模、有没有删掉或放宽测试、有没有把错误悄悄吞掉、总结里的数据是否都能对应到某次命令输出。 护栏生成器 可以用一份短表单产出上面这四份文件——命令、允许路径、保护路径、要强制的规则——并且跟随页面语言切换中英文。 护栏做不到什么 说清楚边界比夸大宣传重要，因为夸大最容易让团队信错东西： ...