这是协作问题，不是技术问题
这个场景在各个团队反复上演：有人打开了 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 是不是超出了这个任务该有的规模、有没有删掉或放宽测试、有没有把错误悄悄吞掉、总结里的数据是否都能对应到某次命令输出。
护栏生成器 可以用一份短表单产出上面这四份文件——命令、允许路径、保护路径、要强制的规则——并且跟随页面语言切换中英文。
护栏做不到什么
说清楚边界比夸大宣传重要，因为夸大最容易让团队信错东西：
- 不做设计审查。 一个改动可以完全在范围内、测试全绿，但把架构搞得更糟。
- 不能让 Agent 变诚实，只能让它受限。 一个不能 push 的 Agent，照样能在本地写出错误的东西。
- 不能替代 git 纪律。 分支保护和小的提交粒度仍然是真正的回滚手段。
- 挡不住执意要绕的人。 总会有人为了解封去改 deny 清单——这正是权限配置本身值得被 review 的原因。
把它当成爆炸半径控制：目标是让一个错误只值一次 revert，而不是一个周末。
让它变成习惯
最有用的仪式很无聊：每次 Agent 做出让你意外的改动之后，往规则文件加一行、往 deny 清单加一条。一个月后，这份文件描述的就是你们团队真实的协作方式，新换的 Agent 直接继承。
两个配套习惯：要过程不要只要结论（「列出你改了哪些文件、为什么」），以及开会前核而不是会后核——几分钟的检查，胜过几个小时的更正邮件。
如果你们的报告里还有 Agent 生成的数字，AI 数字核验器 处理的是同一个问题的另一半：看起来对、却没有出处的数字。