AI 写代码越快: 越要盯住架构质量

AI 带来的一个明显变化，是代码生成速度变快了。以前可能要花半小时写一段逻辑，现在几分钟就能生成一版；以前懒得补的分支、接口和测试，也可以快速铺出来。

但代码变多不等于项目变好。速度提升以后，另一个风险也会被放大：项目可能在不知不觉中变得更难维护。

AI 常见的架构副作用

AI 很擅长完成当前任务，却不会天然知道项目的长期边界。没有额外约束时，它可能会：

• 重复实现项目里已经存在的函数
• 为小需求引入不必要的依赖
• 把业务逻辑塞进 UI 层
• 绕过已有 service 或 repository
• 让单个文件继续膨胀
• 在多个模块里复制相似逻辑
• 为了通过测试而削弱断言

这些问题单独看都可能不严重，但 AI 编程通常频率高、速度快。如果每次改动都积累一点结构债，项目会在很短时间内变得难维护。

为什么 AI 容易写出能跑但不健康的代码

一个人类工程师处理需求时，通常会同时考虑：这段逻辑应该放在哪一层、项目里有没有已有实现、新依赖是否值得引入、旧功能会不会受影响，以及下次维护的人能不能看懂。

AI 也可以被要求考虑这些问题，但它最直接的倾向仍然是完成当前任务。如果它不知道项目地图、历史设计和模块边界，就会选择一条局部最容易完成的路径。

所以架构质量不能只靠模型自觉，也不能等到项目明显失控以后再大规模重构。更实际的方式是把检查放进每次 AI 改动之后。

先看 diff，再看边界和测试

每次 AI 完成一项改动，我会先问三个问题：

 复制代码1. 这次 diff 是否只包含和任务相关的文件？
2. 新逻辑是否遵守既有模块边界？
3. 新行为和旧行为是否都有足够测试？

如果一个小需求跨了很多不相关模块，要警惕。如果它绕过了项目已有抽象，要警惕。如果它只改实现、不补测试，也要警惕。

这不是要求所有改动都必须重构得完美，而是要及时识别那些会增加长期维护成本的选择。

一个具体反例

需求是：在交易列表里显示分类名称。

不健康的实现可能是直接在前端组件里写一份分类映射；没有分类时再临时给默认值；另一个页面需要时继续复制同一段逻辑。

这份代码可能马上就能跑，但分类名称一旦变化，多个页面就会出现不一致。

更合理的路径是先找到已有分类模型和数据流，在数据层或统一的 service 中补充分类信息，前端只负责展示，并为有分类、无分类和未知分类补测试。

这就是“能跑”和“架构合理”的差别：前者只证明当前页面出现了文字，后者还考虑了数据来源、复用边界和未来变更。

让 AI 参与架构检查

AI 不只能生成代码，也可以在提交前做一轮结构化检查：

 复制代码请检查这次 diff：1. 是否违反项目既有模块边界？
2. 是否重复实现已有逻辑？
3. 是否引入不必要依赖？
4. 是否让某个文件或模块继续膨胀？
5. 是否有更小的实现方式？
6. 哪些地方需要人类重点 review？

为了让结果有用，最好同时提供仓库地图、相关模块说明、任务目标和测试结果。只给 AI 一段孤立 diff，它很难判断某种写法是否违反了项目的历史约束。

一份 AI 改动后的架构检查表

 复制代码## AI 改动后的架构检查- 是否只改了和任务相关的文件
- 是否出现跨层调用
- 是否重复已有函数或组件
- 是否新增不必要依赖
- 是否让单个文件继续膨胀
- 是否缺少边界测试
- 是否改变旧行为
- 是否有更小的实现方案

这份清单不应该取代人工判断。它的作用是让 review 有一个稳定的起点，帮助人类更快把注意力放到模块边界、业务副作用和长期维护成本上。

速度越快，质量检查越要靠近改动

AI 编程不要求我们拒绝快速生成代码，而是要求快速生成以后，立刻进行小范围验证和结构检查。改动越小，问题越容易定位；反馈越及时，返工成本越低。

如果等到很多功能堆在一起才检查架构，任何一个局部决定都可能已经和其他模块纠缠在一起。那时再修，成本远高于每次多看几分钟 diff。

用一个小改动演示架构检查

继续看交易列表显示分类名称这个需求。让 AI 实现后，我会要求它输出一份改动说明，而不是直接看“功能能不能跑”：

 复制代码请根据本次 diff 回答：1. 分类名称的真实数据来源是什么？
2. 为什么修改点放在这一层，而不是页面组件？
3. 项目中是否已经存在可复用的分类查询或序列化逻辑？
4. 哪些旧接口和页面会受到影响？
5. 有分类、无分类、未知分类分别怎么验证？
6. 如果未来分类改名，是否需要修改多个地方？

如果 AI 无法回答第 1、2、3 个问题，说明它可能只是完成了表面展示，还没有理解项目的数据流。这时先不要继续扩功能，而是让它补读模型、service 和已有测试。

用简单指标发现结构债

不一定要一开始引入复杂的架构分析平台。对于频繁使用 AI 的项目，可以先在 PR 中观察几项简单信号：

• 一个小需求是否跨越过多目录
• 单个文件是否持续出现在不同 PR 中
• 相似逻辑是否在多个模块重复出现
• 新增依赖是否超过任务本身的必要范围
• 测试是否只覆盖新增 happy path
• 业务逻辑是否越来越集中在页面或 controller

这些不是绝对阈值，而是提醒 reviewer 追问“为什么”。如果一个改动确实需要跨模块，也应该在 PR 描述中解释原因，而不是让 reviewer 自己猜。

把检查做成 AI 的提交前步骤

可以把下面这段放进项目 Skill 或 PR 自动化流程：

 复制代码在提交前检查本次 AI 改动：- 用一句话说明业务目标
- 列出实际修改文件，并解释每个文件为什么需要改
- 查找是否有重复实现
- 查找是否绕过已有抽象
- 检查是否新增依赖
- 列出新旧行为差异
- 列出必须由人类确认的风险如果发现更小的实现方案，先提出方案，不要自行扩大范围。

这一步的重点不是让 AI 代替架构师，而是迫使它把局部实现放回项目结构里解释。解释不清楚的地方，正是人类最应该看的地方。

什么时候应该接受架构债

并不是所有临时实现都必须马上重构。有些项目处在验证阶段，先用简单方案验证需求是合理的；关键是把它明确记录为技术债，并写清触发重构的条件。

例如：先在 service 中使用一个简单映射可以接受，但要注明分类自定义开放后必须统一迁移到分类 repository；先用浏览器语音识别可以接受，但要注明正式服务接入前需要补超时、失败回退和成本控制。

架构质量守护不是追求零债务，而是避免临时方案在没人意识到的情况下变成永久结构。

最后

AI 让代码生成速度变快，但架构质量不会自动变好。越是高频使用 AI 编程，越要把 review、测试和架构检查放进流程里。