如何让 Agent 不把代码库写烂

AI Agent 最大的风险，不是它不会写代码，而是它太会写代码了。它可以在很短时间内生成大量实现、抽象、工具函数、适配层和测试代码。问题是，代码越多不代表系统越好，很多时候只是技术债增长得更快。

Mario 在访谈里反复强调一个点：Agent 会倾向于把简单问题复杂化。一个本来只需要内联三行逻辑的修复，它可能会抽出一个函数；一个只有一个调用点的逻辑，它可能会包装成通用 helper；一个局部 bug，它可能会顺手重构一片区域。短期看很勤奋，长期看就是复杂度膨胀。

要避免代码库被写烂，第一条原则是：不要把架构判断外包给 Agent。Agent 可以填充实现，但系统边界、模块划分、依赖方向、API 形状，仍然应该由人主导。因为这些判断依赖长期维护经验、业务理解和代码库上下文，而这些并不是模型最擅长的部分。

第二条原则是：把 Agent 的输出放进确定性约束里。Agents.md、prompt、口头规则都只是软约束，模型可能记得，也可能忘记。真正可靠的是 lint、typecheck、test、pre-commit、CI、依赖锁定、安全扫描这些确定性工具。规则写在文档里只是提醒，规则写进检查流程里才是约束。

第三条原则是：对复杂度保持敌意。Review Agent 代码时，不只看它有没有通过测试，还要看它有没有引入不必要的层级。很多坏代码并不是功能错了，而是结构变重了。函数是否只有一个调用点？抽象是否真的复用？有没有复制粘贴相似逻辑？有没有因为“看起来专业”而引入未来维护成本？这些都需要人来判断。

第四条原则是：按风险分级使用 Agent。内部脚本、一次性工具、非关键后台页面，可以让 Agent 更自由地发挥。核心交易链路、安全逻辑、权限模型、数据一致性代码，则必须保持更高审查标准。不是所有代码都需要同样严格，但关键代码必须有人负责。

第五条原则是：任务要小，反馈要快。Agent 最怕在巨大上下文中长时间自由发挥。越大的任务，越容易错过上下文，越容易生成自洽但不符合项目约束的方案。把任务切小，让每一步都有 diff、检查和人类反馈，反而更稳定。

如果用一句话总结：不要让 Agent 在黑箱里连续写三个月。让它每走一小步都经过测试、diff、review 和架构判断。Agent 可以加速工程交付，但如果没有治理，它也会加速架构腐化。

相关：Mario 的日常 AI 编程工作流、Agents、AI 编程时代的软件工程原则