AI激活率≠实际使用率：企业落地为何徒有其表

今年我聊过的每个工程团队，都有一版相同的图表。席位激活数在涨。Token 消耗在涨。有人 PPT 里写着 80% 周活跃用户。然后你坐到他们的规划会里，发现他们构建软件的方式没有任何改变。

这个差距才是真正的问题，而且我们大部分衡量 AI 采纳的方式，无意间恰恰是为了掩盖它。

你所测量的一切都是使用指标

Token 消耗只能告诉你有人在框里打了字。Pull request 数量只能告诉你提交落了地。「AI 生成的代码占比」只能告诉你一个自动补全被接受了。这些都告诉不了你工作变好了。

古德哈特定律如期而至。一旦一个数字成为目标，它就不再描述现实，而开始描述激励。

「一旦一个数字成为目标，它就不再描述现实，而开始描述激励。」

这种失败最清晰的样子甚至和 AI 无关。每个工程师都见过一个团队用什么都不断言的测试通过了覆盖率门禁。expect(true).toBe(true)。行覆盖了，数字绿了，什么都没测。指标被满足了，目标被放弃了，而仪表盘没有办法区分这两者。

AI 使用指标有着同样的结构。如果我告诉团队使用量是性能信号，一周之内使用量就会涨，而我除了知道他们能读懂激励之外什么都没学到。这一点我早就知道了。

更好的问题是：如果你明天把这些工具撤走，什么会出问题？不是人们会抱怨什么，是什么会出问题。如果诚实的答案是「没什么，人们会有点烦」，那你就不是有采纳，你只是有个订阅。

三件事被叫做采纳，但只有一件能持久。

当我深入去看「我们已经采纳了 AI」在一个具体团队里意味着什么，它往往是三件事之一，而它们的价值天差地别。

有人改变了自己的循环。他们用它来写 commit 信息，或者用它来在不熟悉的代码里找方向。真实的、有用的、几乎完全不可持续的。第一个紧迫的 deadline 一到，他们就退回自己已经知道可行的方式。这不是纪律问题。在压力下，人们会选择不确定性最低的路径，而新工作流本质上就是高不确定性的那个。

有人永久地把一个循环任务交给了出去。不是「我今天用了 AI」，而是「我不做这个了，一个工作流在做，我检查输出」。这能扛过 deadline，因为退回意味着给自己制造工作。它也会随人离开。

或者团队有意地改变了做某件事的方式。有人决定过程中的某一步现在以某种方式运行，写了下来，而且无论任何个人情绪如何它都能维持。只有第三种能扛过人员流动和糟糕的季度。

大多数组织在庆祝第一种，偶尔能达到第二种，从来没到过第三种。因为第三种不是工具问题。购买许可证是预算对话。改变规范意味着公开承认旧的方式更差，然后在新的方式在第三周搞砸某件事时承担后果。

「改变规范意味着公开承认旧的方式更差，然后在新的方式在第三周搞砸某件事时承担后果。」

在 Webflow，对我们来说真正持久的那件事，是把 prompt 作为共享的、有版本控制的产物来对待，而不是个人财产。人们以前把它们放在临时文件里，私下调优几周，下次换机器就丢失了。现在好的那些和代码一起放在仓库里，有负责人、有使用说明、有变更 review。工具上没花什么钱。花的力气是决定这类东西值得维护。

它之所以持久，是因为它不依赖任何人的热情。新工程师继承好的版本，而不是花一个月重新发现。当有人找到改进，所有人都能受益，而不是只有一个人悄无声息地把工作做得更好。

Agent 开局很好，但收尾很差

有一种模式会在团队还没达到第三层之前就扼杀采纳。

杠杆集中在任务的开头。从空白页到可信草稿比以前快得多。从可信草稿到正确可发布并没有更快，那一半还是你的。

所以一个工程师算出来可以同时启动五件事，把它们全发出去，然后感觉很有成就感。然后五件事都回来了需要 review，而 review 在一个人脑子里单线程运行，对他没写过的代码要从头重建。他没有并行化，他在自己的注意力上串行化了，而且队列深度是没人会故意选择的。

他们那周结束比上周更忙、更不确定，这是一个确实更差的体验。足够多的人尝试了一次 agentic 工作流，感觉就是这样，然后悄悄放弃了。几周后这表现为使用量下降，被诊断为培训缺口。

「把工作委托给 agent 和委托给人有同样的上限：保持负责的那个人，他的 review 容量。」

不是的。这是一个工作形态问题。把工作委托给 agent 和委托给人有同样的上限：保持负责的那个人，他的 review 容量。那些从这个领域获得真正价值的团队，对哪些工作可以轻量检查就安全交出去、哪些不行，变得非常具体，而不是把所有东西都当作同等可委托的。

你没法管理采纳；你没法打分

如果你没法给输出打分，关于一个工作流是否有效的每个争论都是凭感觉的争论。而凭感觉的争论是由屋里最自信的人赢的，这是运行工程的不良方式。

打分不等于基准测试。基准测试告诉你一个模型总体上好不好。你需要知道这个工作流在你团队所做的特定事情上好不好，而没有任何基准测试覆盖这个。你需要几十个你自己领域里的真实案例，用你写下来的评分标准打分，每次有人改了 prompt 或换了模型就重新跑。小规模没关系。重点不是精确，而是有一个数字会因为你理解的原因变动。

没有它，你分不清一个变好了的工作流和一个失败变得更流畅的工作流。在演示里，它们看起来一模一样。

每个人永久干掉一个循环手工任务。不是「在这上面试试 AI」。把它从他们的周工作里拿掉，让工作流成为记录在案的责任人。一件保持死的任务胜过十次实验。

这个季度把一个团队规范正式写下来。一个。足够小以至于你真的会执行，足够具体以至于有人能打破它。

不要再向上报使用量了。报告那些使用量本来要产生的结果，包括那些这个数字看起来比使用量更差的季度。

这些都不需要新工具，这是要点的大部分。工具是这里面最便宜的部分，却吸收了最多的注意力。贵的那部分是愿意故意改变团队的工作方式，公开地、以你的名字担责地。

This article was originally published on August 5, 2026, on webflow.com.