在工程师最关心的“AI 代码到底能不能托底”这个困境里，很多人都会问：为什么大模型能写出跑得通的代码，却没人敢把它直接丢进生产系统？知乎上有人回答过：生产系统不看“能不能跑”，只看“坏的时候谁背锅、多久恢复、怎么复盘”。今天我就结合软件工程的经典思想、运维的真实案例和最新的 AI 实践，聊聊可靠性才是硬通货的关键。

人们对 AI 代码的第一印象往往是惊艳。你随便提一个需求，它能啪地吐出一段能跑的函数，甚至附带注释，看上去专业而高效。但问题是，代码的世界讲究的是确定性，而大模型的本性是非确定性的。正如《The Mythical Man-Month》（《人月神话》，Frederick P. Brooks, 1975）里说过的一句话：“编程本质上是精确的艺术，模糊的地方往往是灾难的开始。”换句话说，工程师要的不是“差不多能跑”，而是“在最糟糕的时候也要能预测它会坏在哪里”。AI 的“似是而非”输出，天然和这个文化冲突。这就是为什么可靠性必须要靠测试和形式化手段兜底。

说到测试，很多人以为 AI 写代码就能帮我们少测一些，其实刚好相反。你会发现，真正的主业已经从“写代码”变成了“写测试与规约”。正如《Test-Driven Development: By Example》（Kent Beck, 2002）里强调的：好的软件不是写出来的，而是测出来的。现在我们更需要属性测试（property-based testing）、契约测试（contract testing）、规约测试（specification testing）、模型检查（model checking）来确保 AI 的产物和预期一致。举个例子，早期有个团队用 Copilot 自动生成单元测试，结果发现覆盖率很高，但很多断言都是错的——它只是在“模仿”测试，却没有理解需求。最后人类工程师不得不重新设计测试规约，才能把 AI 写的代码拉回到轨道上。所以，如果你要做一件事，请先写清楚“代码应该满足什么条件”，再去看 AI 的输出，而不是盲目相信它。

可靠性不仅仅是技术问题，它更是组织能力。Google 的《Site Reliability Engineering》（Beyer et al., 2016）中提出了一个核心观点：“希望系统稳定运行，不是靠天才，而是靠制度。”你需要值班制度（on-call rotation）、故障演练（chaos engineering）、回滚与开关管理（feature flag & rollback），这些是 AI 替你写不出来的。Netflix 曾经搞过著名的“Chaos Monkey”，就是在生产环境里随机杀掉服务，逼迫团队提升抗风险能力。想象一下，如果把这交给 AI，它最多能生成一些实验脚本，却没法替你设计值班体系和复盘文化。没有这些，哪怕 AI 帮你写出一万行代码，出了事故也没人知道谁来背锅，谁来拉闸。

落地时，你该盯哪些指标？经典的《Accelerate》（Forsgren, Humble, Kim, 2018）提出了四大研发效能指标，其中三个和这里直接相关：缺陷密度（Defect Density）、变更失败率（Change Failure Rate）、平均恢复时间（MTTR）。如果你想评估 AI 带来的真实价值，就要比较“AI+人”和“纯人”的差别。比如，一个团队让 AI 写接口，工程师只负责写契约和回滚逻辑，结果发现缺陷密度下降，MTTR 也缩短，因为回滚开关到位。但另一个团队完全照单全收，直接把 AI 代码推上生产，结果变更失败率飙升，平均一次事故恢复要 6 小时以上。可靠性，从来都不是“AI 行不行”，而是“AI+人有没有形成闭环”。

当然，有人会说，这种方法是不是就放之四海皆准？答案是否定的。比如在科研原型、黑客马拉松、教学场景下，你的目标是快速试错，而不是 SLA（服务等级协议）。这时候过度追求可靠性，反而是负担。正如《Lean Startup》（Eric Ries, 2011）里强调的，“在不确定性最高的时候，关键是快速学习，而不是完美”。所以，要看清楚场景。高风险生产系统，可靠性是红线；低风险探索场景，速度和迭代才是王道。

如果只做一件事，请先给 AI 代码加上契约测试，把输入输出边界写清楚；想更进一步，就建立一套回滚和开关机制，让坏的时候能迅速止损；再往上走，就要在组织层面建立制度，把值班、复盘、演练纳入日常。这样一来，AI 不是你的“风险”，而是你可靠性的加速器。

你有没有遇到过这样的情况：AI 写的代码跑得挺顺，但一上生产就爆雷？你又是怎么处理的？欢迎在评论里分享，因为我们都在摸索，如何让 AI 真正变成可靠的伙伴。

合十，如夜话，至此。