AI的“使用”并不等同于“采纳”

文章指出，许多工程组织混淆了AI使用率与AI采纳度。单纯的令牌消耗和工具调用只是表象，真正的采纳需要改变工作流程和规范。企业应通过淘汰繁琐工作、建立团队协作规范及量化实际成果，而非仅依赖使用指标，来推动AI在研发中的实质性应用。

译自：AI adoption isn’t the same as AI usage^[1]

作者：Harshal Shah

今年，我接触过的每一家工程组织都有着大同小异的图表：席位激活数在攀升，Token（令牌）消耗量在增加，某人的演示文稿里写着80%的周活跃率。但当你坐在该团队的规划会议上时，会发现他们的软件构建方式没有任何改变。

这种差距才是真正的问题所在，而我们衡量AI采纳度的方式，大多在无意中掩盖了这一点。

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

Token消耗量只能告诉你有人在对话框里输入了内容；Pull Request（合并请求）数量只能告诉你代码提交了；“AI编写的代码百分比”只能告诉你自动补全被采纳了。这些指标都无法证明工作质量得到了提升。

这就是古德哈特定律（Goodhart’s Law）：当一个数字成为目标时，它就不再描述现实，而是开始描述激励。

“当一个数字成为目标时，它就不再描述现实，而是开始描述激励。”

这种失败最明显的例子甚至与AI无关。每个工程师都见过一个团队通过编写断言为真的测试来通过覆盖率门禁，例如 expect(true).toBe(true)。代码行数被覆盖了，指标变绿了，但实际上什么都没测试。指标被满足了，目标被抛弃了，而仪表盘无法区分这种差异。

AI使用指标也是如此。如果我告诉团队使用率是绩效信号，那么不到一周使用率就会上升，但我除了学到他们能读懂激励机制外，一无所获。这我早就知道了。

更好的问题是：如果明天删除了这些工具，什么会瘫痪？不是指人们会抱怨什么，而是什么会真的瘫痪。如果老实的回答是“没什么，人们只是会感到有点烦恼”，那么你并没有实现采纳，你只是在购买订阅。

三种被称为“采纳”的事物，只有一种能持久

当我深入探究特定团队所说的“我们已经采纳了AI”到底意味着什么时，通常是以下三种情况之一，它们的价值大相径庭。

一是有人改变了自己的工作习惯。他们用它写提交信息，或者用它在不熟悉的代码库中理清思路。这很真实、有用，但几乎完全不可持续。一旦遇到紧迫的截止日期，他们就会回到自己已知可行的方式上。这不是纪律问题，在压力下，人们会选择确定性最高的路径，而新的工作流程本身就意味着高不确定性。

二是有人永久性地移交了一项重复性工作。不是“我今天用了AI”，而是“我不再做这个了，由工作流来完成，我只负责检查输出”。这能经受住期限的考验，因为回到过去意味着要给自己找麻烦。当这个人离开时，这个流程也会随之消失。

三是团队有意改变了做事方式。有人决定流程中的某个步骤现在以特定方式运行，并将其记录下来，无论个人是否对此感到热衷，它都会持续下去。只有第三种情况能在人员流动和糟糕的季度中存续。

大多数组织庆祝第一种，偶尔达到第二种，却从未达到第三种。因为第三种不是工具问题。购买许可证是预算对话，而改变规范意味着大声说出旧方式更糟糕，并在新方式在第三周出现问题时勇于承担责任。

“改变规范意味着大声说出旧方式更糟糕，并在新方式在第三周出现问题时勇于承担责任。”

在 Webflow^[2]，我们坚持下来的是将提示词（prompts）视为共享的版本化资产，而不是个人财产。过去，人们把它们保存在草稿文件中，私下微调数周，下次换机器时就弄丢了。现在，好的提示词会像其他任何代码一样，存在于存储库中，有所有者，有使用说明，并有变更审查。它在工具层面没有任何成本，所需要的只是确定这一类事物值得维护。

它之所以能维持，是因为它不依赖任何人的热情。新工程师继承的是优化版本，而不是 花一个月时间^[3] 去重新发现它。当有人发现改进方案时，每个人都能从中受益，而不是一个人默默地提升工作能力。

智能体（Agent）工作起步快，但收尾难

这是一种在团队达到第三阶段之前就会扼杀采纳的模式。

杠杆作用集中在任务的开始阶段：从空白页面到像样的草稿，速度比过去快得多。但从草稿到正确且可交付的产品，速度并没有变快，而后半部分工作依然由你负责。

因此，工程师发现他们可以同时开始五件事，一股脑发出去，并在处理这些事时感到高效。然后，五件事返回时都需要审查，而审查是单线程地在一个人脑子里进行的，处理的是他们没写过、必须从头重新理解的工作。他们并没有实现并行，他们是在自己的注意力上进行了串行化，其队列深度是没人会刻意选择的。

他们结束那周时比前一周更忙碌、更不确定，这是一种极其糟糕的体验。很多人尝试过一次智能体工作流，有了这种感觉，就悄悄停止了。几周后，这表现为使用率下降，并被诊断为培训不足。

“委托给智能体与委托给人的上限相同：即保持问责制的人的审查能力。”

事实并非如此。这是一个工作形态问题。委托给智能体^[4] 与委托给人的上限相同：即保持问责制的人的审查能力。那些从中获得真正价值的团队，明确了哪些工作可以轻度检查后移交，哪些则不能，而不是将所有工作一视同仁。

你无法管理采纳，也无法量化得分

如果你无法对产出进行评分，那么关于 工作流是否有效^[5] 的所有争论都是基于“氛围”的争论。而基于氛围的争论往往由房间里最自信的人获胜，这对于运营工程团队来说是灾难性的。

评分并不意味着基准测试（Benchmarks）。基准测试只能告诉你模型在一般情况下是否表现良好。你需要知道这个工作流在你团队从事的具体工作上是否表现良好，而没有任何基准测试能覆盖这一点。从你自己的领域中提取几十个真实案例，对照你写下的准则进行评估，并在每次有人更改提示词或更换模型时重新运行。规模小点没关系。关键不在于精确度，而在于拥有一个因你理解的原因而波动的数字。

没有它，你就无法区分一个改进的工作流和一个故障变得更频繁的工作流。在演示中，它们看起来一模一样。

我会怎么做

• • 为每人永久性地干掉一项重复性的手工工作。不是“尝试用AI做”，而是将其从他们的周计划中剔除，并让工作流成为记录的所有者。一项彻底消灭的工作胜过十个实验。
• • 本季度正式以书面形式确立一项团队规范。只有一项。小到你真的会去执行它，具体到有人能违反它。
• • 停止向上汇报使用率。汇报使用率原本应该产生的成果，即便在数据看起来比单纯看使用率更难看的季度也要如实汇报。

这些都不需要新工具，这正是重点所在。工具是其中最便宜的部分，却占据了最多的注意力。昂贵的部分在于你是否愿意公开地、明确地改变团队的工作方式，并愿意为其后果负责。

本文最初于2026年8月5日发布在 webflow.com^[6]。

引用链接

[1] AI adoption isn’t the same as AI usage: https://thenewstack.io/ai-adoption-versus-usage/[2] Webflow: https://webflow.com/[3] 花一个月时间: https://thenewstack.io/serpapi-google-search-api/[4] 委托给智能体: https://thenewstack.io/microsoft-build-scout/[5] 工作流是否有效: https://thenewstack.io/anthropic-claude-design-overhaul/[6] webflow.com: https://webflow.com/blog/ai-adoption-vs-usage-engineering-teams