采用即证据

"你怎么证明这个团队让开发者变快了？"这听起来是个测量问题。往前再站一步。

一个背着真实交付压力、工作多到做不完的团队，不需要被说服去用一个真有用的工具。它会自己扑上来。而一个没用的工具，它会悄悄放下——不管发布公告写得多漂亮。

所以，真实压力下的采用，本身就是证据。新鲜感过去之后他们还回来，说明有些东西在起作用。而如果没人来——那也是一个答案，而且比问卷便宜。

这成立的前提是："更好"是事先共同定义的。把验收测试和将来要用的人一起写出来，提速团队就不是在给自己批作业，结论也不靠任何一方的数字自说自话。（这一点我另有一条笔记：验收测试驱动开发，以及为什么每条 eval 结果都必须可审计。）

但采用有个坎。它只发生在人们真的能上得了手的时候——而用户对一个新工具笨拙得惊人。这很公平。凭什么人家要在我的产品上聪明呢？

所以那些不光鲜的工作和机器本身一样重要：产品内一步一步的引导，和展示真实用法的视频。我甚至得学视频的节奏，让注意力不要在中途散掉。

我最喜欢的版本是自动化的。一个 agent 读 Git 历史，把提交串成一个功能，端到端地跑一遍，截好图和片段，生成一条功能视频。团队看视频，挑出不对的地方，改进就喂回来。更新日志不再是没人看的文字，而是人们能对其作出反应的东西。

从哪里开始，也遵循同一条证据规则。挑最愿意合作的团队。第一印象决定推广成败：如果平台团队给人的感觉是"我们比你更懂你的工作"，阻力就会永久化。所以要找一个有真实问题、解决路径有希望的团队——而且解决之后能成为一个好故事，因为把下一批团队带进来的，正是这个故事。

这一切底下，压着一条纪律。挑一个团队本来就在产出的数字——从动手改一处代码到这次改动抵达生产的时间。上线前测一次，上线后测一次。没有基线，就没有证明。

变快不是一种感觉，也不是上线那周的曲线。它是背着压力的人们一周又一周地选择这个工具，和一个诚实的数字在动。