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

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

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

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

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

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

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

不是 compute。便宜 compute 很早就有了。

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

真正的 bottleneck 是一种很难并行化的 expertise。

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

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

所以很多“good on paper”的方法最后只留在 aerospace、finance、formal methods research，或者极其自律的 infrastructure teams 里。方法有效，staffing model 不成立。

AI 改变了什么

AI 不是拿走 engineering judgment，而是改变 judgment 花在哪里。

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

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

旧工作流是 author-heavy，新工作流变成 review-heavy。

这意味着:

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

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

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

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

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

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

在 AI 之前，大多数团队连其中一个策略都很难 justify。AI 之后，同时组合几层开始变得现实，而且不必把 reliability work 做成全职 specialist program。

这不是魔法

当然也有错误做法。

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

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

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

AI 在这里的价值，是补上 expertise gap，而不是充当最终裁判。

为什么现在尤其重要

今天很多团队已经在用 AI 压缩 implementation time。真正的风险是，delivery speed 的增长速度，超过 verification depth 的增长速度。

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

真正的机会，是用同样加速生成的模型，把过去太贵而无法持续的 reliability practices 重新带回来。这样，速度才不会直接变成 operational debt。

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

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