演示永远能跑通
每个 AI 编程演示都遵循相同的套路。有人向模型发出提示。一个能工作的应用凭空出现。观众印象深刻。
他们理应如此。速度是真实的。能力是真实的。有 AI 参与时，第一版确实发布得更快。
问题在于，第一版从来不是难点。
成本实际集中在哪里
软件工程的成本不集中在初始创建阶段。它集中在第四、第五、第六次迭代：
- 认证提供商需要更换，因为定价变了。
- 数据分析需要迁移，因为供应商被收购了。
- 需要添加一个功能，它涉及初始生成从未预见到的三个页面。
- 样式系统需要替换，因为设计师改变了方向。
- 支付集成需要切换，因为产品扩展到了新市场。
这些都不是初始生成的失败。它们都是正常的产品开发。问题在于 codebase 使这些变更是廉价的还是昂贵的。
变更压力下的 AI 生成 Codebase
大多数 AI 生成的 codebase 能很好地应对第一次变更。第二次变更开始不舒服了。到第四次变更时，团队开始报告相同的症状：
- “我们让 AI 切换认证提供商，但它触及了 14 个文件。”
- “refactor 破坏了本应无关的 module 中的测试。”
- “我们无法分辨系统的哪些部分依赖于数据分析 SDK。”
- “每次变更都需要重新理解整个 codebase。”
这些症状不是模型的失败，而是架构的失败。模型生成了一个没有边界的系统，现在每次变更都有不可预测的影响范围。
为什么 AI Codebase 退化更快
传统 codebase 也会退化。但 AI 生成的 codebase 因为特定原因退化得更快：
没有共享的心智模型。 人类团队经过数月建立结构性直觉。AI 生成代码时对之前决策的原因没有记忆。
针对当前提示的优化。 模型解决的是当前请求。它们不会为接下来的五个请求进行优化。每次生成都做出局部正确但全局不协调的决策。
代码量放大耦合。 AI 更快地生成更多代码。更多缺乏边界的代码意味着更快的耦合累积。速度优势变成了退化加速器。
Refactor 需要全局上下文。 模型难以处理跨越整个 codebase 的 refactor，因为上下文窗口是有限的，而架构意图是隐式的。
真正的工程挑战
AI-native 开发中真正的工程挑战不是”我如何生成更好的代码？”
而是”我如何组织系统结构，使 AI 生成的部分可以独立变更？”
这意味着：
- 使影响范围可预测的边界。
- 将变化的部分与不变的部分解耦的 interface。
- 使依赖图显式化的 composition root。
- 在不需要完整系统的情况下验证集成点的 contract tests。
- 能够删除并重新生成任何 module 而不引发级联失败的能力。
长期维护是一个结构问题
再好的提示也无法修复一个每个 module 都深入其他 module 的 codebase。你无法通过提示来摆脱架构耦合。
长期 AI codebase 维护需要一直以来都需要的同样纪律：边界、contracts 和隔离。不同之处在于，AI 的速度使缺乏这些纪律的后果更快显现。一个本来需要两年才能创建出不可维护的单体应用的团队，现在两个月就能做到。
速度既是馈赠也是陷阱。没有结构，它只是意味着你更早到达维护危机。
与 AI-Native 架构的关联
这是我在斯坦福 CS146S 对 AI 编程的判断是对的——缺失的主题是架构中提出的核心论点：没有架构纪律的工具熟练度，产出的 codebase 创建快速但维护昂贵。
现代软件开发者两者都需要。用 AI 工具快速发布的能力，以及在第一版之后仍能保持快速发布的架构纪律。
第一版从来不是问题。问题在于第五版是否仍然成本低廉。
常见问题
为什么 AI 生成的 codebase 会变得难以维护？
AI 模型针对当前提示进行优化，而非为未来变更优化。这产生了能工作但缺乏独立修改所需边界的代码。没有显式的架构约束，耦合的累积速度比手写 codebase 更快，因为 AI 生成了更多代码、更快。
如何防止 AI codebase 随时间退化？
三个结构性实践：用应用自有的 interface 执行 module 边界、在 composition root 中集中依赖项连接、运行独立验证集成点的 contract tests。这些使变更成本可预测，无论代码是如何生成的。
AI 生成的代码比人写的代码更难 refactor 吗？
并非天生如此。但 AI 生成的代码更可能缺乏使 refactor 安全的结构边界，因为模型不会自发地为未来变更进行优化。修正方法是在生成之前施加这些边界，而非寄希望于模型自行产生它们。
AI 编程对长期项目最大的风险是什么？
最大的风险是速度陷阱：在早期阶段发布得太快，以至于架构债务在团队注意到之前就已累积。等到维护变得昂贵时，codebase 已经耦合得无法增量修复了。