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、测试和架构检查放进流程里。AI 可以替你加快实现但不会自动替你守住项目边界。真正成熟的 AI 编程既要追求交付速度也要持续检查下一次修改会不会因此变得更难。