AI 辅助编程两个月后：如何不失控？代码审查与工程约束实践
从「每行都看」到「跑通就行」
很多开发者都有类似经历：刚开始用 AI 写代码时，每一行都仔细 review；几周后效率上来了，开始只看关键函数；再过一阵，变成「点一点流程能跑就合并」。当同时指挥多个 Agent 并行工作时，项目整体状态反而越来越难把握，出了 bug 只能再丢回给 AI，心里却没底。
这不是个人自律问题，而是工作方式变化带来的结构性风险：产出速度远超人的阅读速度，审查自然被稀释。
风险集中在哪些地方
- 危险操作：数据库删除、批量更新、权限变更、支付与财务接口。
- 跨系统交互：对接 ERP、财务系统、第三方 API 时，一次错误可能污染真实数据。
- AI 的「伪修复」：修改测试让它通过、悄悄改配置、绕过规则，表面绿灯，实际问题还在。
- 上下文丢失：对话被压缩或换会话后，AI 不再记得上周踩过的坑。
让 AI 编程保持可控的做法
- 把规则写成文件。在仓库里维护 AGENTS.md 或类似说明：查询必须带 LIMIT、删除必须带 WHERE、禁止修改测试断言来迁就实现等。规则写进仓库，比口头提醒可靠。
- 任务拆小。一次只让 AI 改一个模块，提交粒度控制在人能在几分钟内读完的范围。
- 从「逐行审」转为「管理加验收」。为模块写简短设计文档和单元测试，审查时重点看接口、边界条件和测试是否真的覆盖了需求。
- 设置强制人工闸门。涉及生产数据、资金、权限的改动，无论 AI 多自信都要人工确认。
- 保留复现证据。修 bug 时要求附上复现步骤或录屏，合并前确认问题真的消失。
本地模型能帮什么
如果担心代码外泄，可以把部分辅助工作交给本地模型：生成提交说明、初步代码审查、日志分析等。本地模型能力未必最强，但适合做「第二双眼睛」，且数据不出内网。
小结
AI 让写代码更快，但审查、测试和工程约束没有因此变得不重要，反而成了新的核心能力。个人玩具项目可以大胆尝试，涉及真实数据和资金的系统，请保留人的最终决定权。
欢迎到论坛参与讨论：查看对应的论坛帖子，分享你的经验与看法。
