你花了一周时间搞重构，理由是“让下一次改动更便宜”。测试条全绿，代码合并入主分支，然后所有人就把这事抛在脑后了。没人回头去查下一次改动是不是真的变便宜了。绿色进度条告诉你：这段代码符合它的规格说明。所有人读到这条信息后就觉得活儿干完了，而你当初投入精力的那件事从头到尾没人测量过。

CI系统显示绿色，测试断言里写着验证响应码等于200，它通过了。它没验证的是：你刚上线的缓存层有没有把99分位延迟压下来，重写过的注册引导步骤有没有拉升用户激活率，提示词的改动有没有让智能体更经常遵从指令。绿色进度条替你回答了一个你从来没提的问题。

打开网易新闻 查看精彩图片

你真正应该关注的延迟、激活率和指令遵从度，都属于“效果”。CI管线不测量效果。它测量的是“符合性”——输入能不能映射到被断言的输出，契约是否成立，有没有你写过测试的东西退化了。这叫“正确性”。它是实打实的，也是必要的。但它告诉不了你系统有没有变得更好。你因为进度条绿了才发布，而这个进度条从一开始就没打算测量你发布时真正想改变的东西。然后我们所有人看着绿色通过信号，就好像它同时回答了那另一个问题似的。

整个行业里弥漫着一个沉默的假设：大家默认“通过”和“更好”是同一条轴上的刻度，好像一个改动只要正确了，就自动变成了改进。事实不是这样的。一段完全正确的改动可能反而把系统变得更糟，也可能让所有指标纹丝不动——两种情况下测试套件都一路绿灯。绿色递进条对于“更好”来说是必要条件，但远远够不上充分条件，而几乎所有工程团队都没有给这两者之间的温差装上仪表。更关键的是：这个行业已经把这件事掰成了两半，给它们各自取好了名字，还把这两半设定成了对手。

这两种做法的名字一个叫“规范驱动开发”，另一个叫“假设驱动开发”。先说前一个。规范驱动开发的逻辑极其清晰——先写出规格，再照着它构建，最后证明构建物符合规格。整套测试套件就是规格的可执行副本。正确性等于全部游戏内容。它规矩、可审计，也是大多数工程组织实际运转的方式。把它当成一条流水线来看的话，它的终结点就是进度条变绿的那一瞬间。注意看它停在了哪里：停在“正确”这里。这条环线里面的任何一步，都从来没问过你发布的那个改动有没有在任何一项业务指标上带来改进。

假设驱动开发，问的恰好是规范驱动不问的那个问题。当年ThoughtWorks把这种方式归纳成一个三段式：我们相信做了某个动作A，会带来结果B；当我们看到可测量的信号C出现时，才能确认原来的判断是对的。这套框架里，进步的单位不是一次构建的通过，而是“经过验证的认知”。你先把效果预测出来，再把改动推上线，然后实际去测量，测量结果回头告诉你——你之前想对了吗？项目管理领域关于期望管理的文献从另一个房间说了同样的事：一个期望就是一件被管理起来的对象——它有明确的负责人和到期日，要持续跟踪、尽早暴露，而不是等到最后才发现。把它当成一条流水线的话，它的起点恰好是规范驱动开发的终点，也就是“做出预测”这一步，并且它的流程会一直跑到发布之后。