AI 能几分钟生成一个功能，但代码库会不会因此变成没人敢碰的“意大利面”？作者以自己的项目 Mole 为例，给出了一个明确判断：清晰的架构和分层，在 AI 时代不是过时了，而是更基础了。没有预先定义好模块边界和交互方式，AI 写得越快，后期越难扩展和维护。

先把架构图固定下来，再让 AI 动手

他的做法是在项目初期与 AI 共建架构图，并用文档固定下来，作为后续开发的基准。这样 AI 每次生成代码时，都有明确的边界可以参照，而不是自由发挥。架构文档解决的是“代码该放在哪里、模块之间怎么通信”的问题，避免后期出现牵一发动全身的混乱。

自动化测试是唯一可靠的验收方式

AI 生成的代码分支太多，人手工验证不过来。作者分享了一个关键数据：项目测试覆盖率从 56 个提升到 3347 个。这个变化让他修复 bug 时更有底气，因为系统会确保问题不会在别处重现。他坚持一个观点：AI 写的代码应该 AI 来测试，而非人，把人引入这个环节反而会拖慢整体进度。

尤其在修 bug 时，他会多留一些东西下来：除了把问题修复，还会加一个让旧代码失败的回归测试。这样每一次修复都变成对系统的加固，而不是单纯打补丁。

规则文档补上测试解释不了的背景

测试能记录什么是对的，但无法解释为什么有些设计看起来是错的、其实是对的。规则文档（Rules）就是用来记录这些设计决策的背景信息。它的作用是让 AI 在未来的迭代中，不会因为缺乏上下文而推翻之前的优化。换句话说，测试守住“正确”，规则文档守住“为什么正确”。

少做功能，比多做功能更重要

AI 让添加实验性功能变得非常容易，几分钟就能写一个设置项、兼容分支或者后台监听。但这些功能留下的状态和维护成本，反而是代码腐化的最大原因。作者的建议是坚持“如无必要，勿增实体”，重点关注用户真正需要的功能，避免系统随着时间推移变得臃肿。

发布前用流程卡点拦住最后一刻的错误

代码在本地运行正常，不代表在生产环境也正常。作者利用 GitHub Actions 做综合验证，确保在实际发布之前，所有环境中的依赖和配置文件都保持一致，避免部署错误的二进制文件。这个流程卡点的价值在于：它不依赖人的细心，而是把一致性检查变成自动化的固定动作。

从架构文档到自动化测试，再到规则记录和发布检查，这套组合的核心逻辑是：AI 负责生成，系统负责验证。人不再逐行盯代码，而是把精力放在定义边界、记录决策和设计流程上。这样 AI 带来的速度，才不会变成维护上的债务。