思路一直是对的，问题在于不划算

软件工程里有很多方法，你一读就会觉得“这当然应该这么做”。

当然应该用 contracts 明确 function 能接收什么、必须返回什么。当然 tests 不该只写几个人工挑选的例子，而应该验证 properties。当然团队不该把 coverage 当成质量代理，而应该真的去判断 tests 能不能抓到 faults。也当然，架构决策应该和代码保持同步，而不是写完就烂在文档目录里。

这些想法本身从来不离谱。问题一直是经济性。它们贵的不是算力，也不是工具许可证，而是最难扩张的资源: 持续性的专业注意力。

过去很多强工程策略都死在同一个循环里。团队兴冲冲地引入，质量也真的提升了，然后维护成本开始出现。contracts 开始漂移，property tests 跟不上 schema 变化，surviving mutants 越积越多却没人分流判断，架构文档逐渐变成虚构文本。它们不是因为“理论错了”才失败，而是因为它们要求的持续专业能力远超大多数产品团队能稳定投入的水平。

这才是当前 AI 时刻真正重要的地方。关键变化不只是模型能更快写 code，而是模型开始能接住过去最贵的那部分 specification 与 verification 工作。

真正把这些策略困在小众里的是什么

不是算力。便宜算力很早就有了。

也不只是工具。不少方法早就有成熟工具，但工具仍然默认有人知道该怎么写 invariants、generators、contracts、boundary rules。

真正的瓶颈是一种很难并行化的专业能力。

  • Design by contract 需要有人能写出在 refactor 之后仍然有意义的 preconditions、postconditions、invariants。
  • Property-based testing 需要有人看到一个 function 时，会自然想到 round trip、idempotence、error behavior、algebraic properties，而不只是几个 examples。
  • Mutation testing 需要有人能分流判断 survivors，判断它们暴露的是真空缺还是无害的 equivalent mutants。
  • Type-level correctness 需要团队理解 branded types、phantom types、typestates，甚至 formal verification 工具。
  • Living specifications 需要持续把人的决策翻译成可执行的 architecture rules。

每一种策略都有自己的维护税。把它们组合起来会更贵，因为你还得写中间那层胶水。

所以很多“纸面上看起来很好”的方法最后只留在航天、金融、形式化方法研究，或者极其自律的基础设施团队里。方法有效，人员配置模式不成立。

AI 改变了什么

AI 不是拿走工程判断，而是改变判断花在哪里。

以前资深工程师得手写大部分脚手架。现在模型可以先起草 contract、建议 properties、搭出 schema、把自然语言决策转成 architecture rule，甚至顺手给 surviving mutant 写一个 regression test 初稿。人类工程师不再从空白页开始，而是把精力放在领域正确性审查上。

这个变化比表面看起来大得多。

旧工作流是重撰写，新工作流变成重审查。

这意味着:

  • contracts 的引入成本下降了
  • property-based testing 变得更现实了
  • mutation testing 终于更可运营了
  • architecture constraints 更容易真正落地到 CI

真正的经济性突破就在这里。不是“用模型替代工程师”，而是让过去需要专家撰写的策略，变成普通产品团队也能承受的东西。

更关键的一点: 这些策略组合起来才更强

最有价值的变化，不是某一个技术单点变便宜了。

真正有意思的是，AI 让整套 stack 的组合成本下降了。

一个 contract 可以变成 property test 的来源。一个 property test 可以再交给 mutation testing 去衡量强度。一个 schema 可以定义 runtime boundary。一个 ADR 可以变成 architecture rule。一个 branded type 可以在 runtime checks 之前先收紧 surface area。价值不只在每一层本身，更在这些层之间的胶水。

在 AI 之前，大多数团队连其中一个策略都很难证明值得做。AI 之后，同时组合几层开始变得现实，而且不必把可靠性工作做成全职专家项目。

这不是魔法

当然也有错误做法。

如果你只是让 AI 生成 code、contracts、tests，却没有 deterministic enforcement，那你得到的只是一大堆看起来很像那么回事的文本。目标不是让模型“批准”你的 codebase。目标是让模型帮助你产出可以被低成本、重复验证的 artifacts。

所以真正有效的模式依然很朴素:

  • 用 AI 生成
  • 用 deterministic tools 验证
  • 在 specification level 做 review
  • 一旦规则被破坏，就让 CI 立即失败

AI 在这里的价值，是补上专业能力缺口，而不是充当最终裁判。

为什么现在尤其重要

今天很多团队已经在用 AI 压缩实现时间。真正的风险是，交付速度的增长速度，超过验证深度的增长速度。

如果发生这种失衡，你得到的不会是一个更高效的工程组织，而只是一个更快滑向脆弱系统的路径。

真正的机会，是用同样加速生成的模型，把过去太贵而无法持续的可靠性实践重新带回来。这样，速度才不会直接变成运营债务。

未来几年，真正占优的会是那些早早意识到这一点的团队。AI-assisted coding 本身不是策略。AI-assisted verification and enforcement 才是。

这也是为什么那么多老工程策略突然重新重要起来: 不是因为它们突然变得更正确，而是因为它们终于变得经济上可行了。