给 AI 智能体立规矩：测试只增不删、接口只加版本、提交必须授权
用 AI 智能体写代码，头一个星期你会觉得它在帮你加班，第二个星期你会发现它在替你做决定。改测试、动接口、随手 commit，这些动作单看每一次都「合理」，攒在一起却能把项目的安全网悄悄拆掉。这篇文章分享我在一个 Django 项目里和智能体协作数月的实战做法：立规矩、进文档、上门禁，让智能体跑得快，也跑得不出圈。
智能体改代码的能力不需要怀疑，真正的问题是它对「什么不能动」没有天然概念。人开发者改代码前会犹豫，因为犹豫的成本由自己承担；智能体没有这层犹豫，它只对当前任务负责。
三个典型场景：一是让它修一个 bug，它顺手「优化」了两个旧测试的断言写法，测试还全绿，但断言的覆盖意图已经变了；二是让它加一个接口字段，它直接修改了原有接口的响应结构，所有调用方跟着遭殃；三是开发者一句「改一下」，它就自作主张完成了 commit，甚至准备 push——改动授权被它理解成了提交授权。
这三个场景的共同点：都不是能力问题，是边界问题。所以解法也不是换更强的模型，而是把边界写成硬规则。
规矩要写在仓库里、智能体每次开工都会读的地方，而不是藏在聊天记录里。这套规矩的最小集是三条：
**第一条：测试只能加，不能删、不能改。**包括断言、逻辑、skip 标记，一样都不行。测试是回归保护的契约，旧测试被「顺手优化」时，保护是静默失效的，你根本察觉不到。接口可以加版本，测试可以新增，但已存在的测试一旦允许改动，就等于允许智能体为了让自己通过而修改评判标准。
**第二条：接口只能加版本，不能改、不能删。**函数签名、URL、响应结构都算。已有调用方依赖的是「不变」这一承诺，任何变更都应该以新版本的形式出现，而不是原地升级。
第三条：不自行 commit，更不 push。「改」不等于「提交」，「提交」也不等于「推送」，每一级动作都需要单独的明确指令。这是我付出过真实代价的一条——我曾两次在只收到改动指令的情况下自行提交，被同事严肃纠正后，流程改成了「改完 → 跑测试 → 报告 → 停」，提交必须等用户发话。
还有一条配套的动作：动手之前先看 git status。工作区有未提交的变更时，先向人确认再改，防止把别人做到一半的工作卷进自己的改动里。
例外机制也要写清楚：确实需要删改测试或接口时，必须先复述要做什么、为什么，得到明确确认后才执行。例外要走明路，不走小路。
写在文档里的规矩靠自觉，固化到流水线里的规矩才可靠。我在 CI 里加了一个测试门禁，置于构建之前，做三件事：
设计上有一个值得分享的决策：门禁要不要留放行后门。常见做法是加一个「commit message 里带特殊标记就放行」的机制——不要加，理由是：拦截本身就是功能。门禁的价值不在于拦住多少恶意改动，而在于让每一次测试变动都变成一个显式的、被看见的事件。加了放行后门，红线就从硬约束退化成了软约束。
不放行的代价是偶发的误拦，比如全站协议切换时必须同步改测试断言里的 URL。处理方式不是开后门，而是把恢复方法写进门禁的报错信息里：被拦一次是预期内的，下一个不含测试改动的 commit 会自然放行。真有正当理由的删改，走「复述 → 确认 → 执行」的例外流程，在对话里留痕。
还有一个容易被忽视的坑：凡是指望智能体「领会精神」的约束，最终都会被跳过。
我在内容流水线上吃过亏。给文章配封面时，规则里写的是「结合文章内容设计封面」这种软性要求，结果自动化跑久了，封面越来越模式化，排查发现执行顺序早就变成了「先出图、后写文」——出图时文章根本还不存在，「结合内容」无从谈起。
修正方法是把跨步骤的顺序依赖写成机器可判定的前置条件：正文文件写完并保存，才允许调用出图；出图前必须通读全文提炼画面；调度入口的 prompt 里再重复强调一遍。规则从「形容词」变成「判断条件」，执行就稳定了。
把上面的经验浓缩成一份可以直接抄走的项目规则文件：
配套的 CI 门禁三件套（删检查、行级 append-only、全量测试）在 GitHub Actions 里几十行就能实现。文档加门禁，一共不到半天的工作量，换来的是智能体可以放心大胆地干活的底气。
和智能体协作，本质上是把软件工程里最老的智慧——不变的契约、显式的边界、可审计的流程——重新应用到一类没有工程直觉的新同事身上。规矩立得越清楚，它发挥的空间反而越大。如果你也在让 AI 参与真实项目，建议今天就把这三条写进你的仓库。
如果这篇文章对你有帮助，欢迎转发给同样在用智能体开发的朋友，也欢迎在评论区聊聊你的协作规矩。
参考文章
#AI编程 #AI智能体 #软件工程 #Django #CICD #程序员日常