卖Token的公司，正在给你的编程效率打分

一段流传于开发者社区的对话，把一个越来越普遍的现象摆上了台面。

对话里，一个工程师被AI编程助手的"用量限制"拦住了，系统提示他"效率需要提升"。另一个同事问他昨天用这个工具做了什么，他说"主要是说不"——AI想把整个支付服务重写一遍，他只让它改了一行。结果在效率和节省工时的排行榜上，他排在末尾。而榜首那位，每天早上让AI把整个应用从头重建一遍，系统显示他每天节省40小时。

最后一句才是重点：这个排行榜的评分规则，是卖Token的公司自己写的。

从"助手"到"监工"：评分机制如何运转

AI编程代理（coding agent）近年来迅速普及，工具提供商在订阅套餐中引入用量限制并不罕见。但把"效率"做成一个量化指标、再做成排行榜，性质就变了。

根据对话中的描述，这套评分逻辑的核心指标是"每花费一美元节省的工程小时数"。也就是说，你越是让AI大量生成代码、消耗越多Token，系统越倾向于认定你"效率高"。反过来，你越谨慎地控制AI的输出范围、只让它做最小改动，评分反而越低。

这就产生了一个方向性的激励偏差：评分奖励的是AI的使用量，而不是工程判断力。那位只改一行的工程师，实际上避免了一次高风险的大规模重写——在支付系统这种场景里，最小改动往往才是正确的工程决策。但在排行榜上，他成了效率垫底的人。

AI编程代理（coding agent） 是指能够自主规划并执行多步编码任务的AI系统，区别于传统的代码补全工具（如早期Copilot的逐行建议）。典型代表包括Claude Code、Cursor的Agent模式、Devin等。其工作方式通常是：接收自然语言目标后，自行读取代码库、修改多个文件、运行测试，并在失败时迭代修正。由于一次任务可能涉及数十次模型调用和大量上下文读取，Token消耗远高于单次补全，这正是提供商需要引入用量限制的原因。也正因为消耗量与“任务规模”强相关，用Token折算效率的评分体系会天然偏向鼓励更大规模的任务委派。

顶部与底部：两种截然不同的"高效"

对话中描述了排行榜的两端。垫底的人：被AI要求重写支付服务，他只批准了一行改动。榜首的人：每天早上让AI把整个应用重建一遍，系统显示他每天节省40小时。

一天只有24小时。"每天节省40小时"这个数字本身就已经暴露了指标的问题——它衡量的不是真实节省的时间，而是AI生成的代码量折算出的假设工时。重写整个应用听起来产出巨大，但如果没有对应的验证、测试和审查，这些代码的实际价值是存疑的。

换句话说，排行榜顶部的"高效"，很可能只是高消耗的同义词。而底部的"低效"，恰恰来自对AI输出的审慎把关。

Token 是大型语言模型处理文本的基本计量单位，大致相当于一个词或词的一部分。API按输入和输出Token分别计费，因此“消耗多少Token”直接对应“花多少钱”。在编程代理场景中，一次任务会反复把代码库片段、对话历史和工具返回结果送入模型，输入Token往往占大头。所谓“每花费一美元节省的工程小时数”，本质是把Token账单换算成金额，再除以一个假设的“AI生成代码量对应的人工工时”系数。这个系数并无统一标准，由平台自行设定，因此指标的分母和分子都带有主观性——这也是“每天节省40小时”这类数字得以出现的原因。

谁来定义效率：利益冲突的核心

这段对话最具洞察力的一句是：评分规则由卖Token的公司制定。

这不是说工具提供商一定有恶意，而是结构性的利益冲突客观存在。Token消耗是这类公司的收入来源，一个奖励"多用AI"的评分体系，天然与收入增长方向一致。问题在于，它同时被包装成了对开发者工程能力的客观评价。

当评分标准由利益相关方单方面制定，排行榜就不再是中立的反馈工具，而是一种行为引导。它引导用户多生成、少筛选，多消耗、少判断——这恰好与优秀工程实践的方向相反。

利益冲突（conflict of interest） 在专业伦理中指的是：当评价方的判断可能受其自身利益影响时，评价的中立性就不可靠。经典处理原则是“利益回避”——例如审计师不得审计自己持股的公司。AI工具商的处境类似：它既是评分规则的制定者，又是Token销售的收入方，还是被评分对象所使用产品的提供方。三者合一，使得任何“效率”指标都难以被视为第三方认证。识别这类冲突的关键不在于认定主观恶意，而在于承认：即使规则制定者完全善意，只要激励方向与用户利益不完全一致，指标就会在长期演化中向对平台有利的方向漂移。

开发者该如何看待这类指标

对话中的工程师用"说不"来回应AI的重写提议，这本身是一种被低估的能力。在AI编程工具能力越来越强的当下，知道什么时候不该用AI、该把AI的输出限制在多小的范围内，可能比让AI写更多代码更重要。

面对平台给出的效率评分，有几个判断值得保留：

• 评分反映的是平台希望你如何使用产品，不一定是你的真实工程效率。
• 节省工时的估算值需要审视其计算口径，尤其是当数值超过物理可能性时。
• 在支付、安全等高风险模块，最小改动原则的优先级应高于任何排行榜。
• 如果评分体系与产品收入直接挂钩，应将其视为营销信号而非能力认证。

这段对话之所以在开发者中引起共鸣，是因为它用极短的篇幅说清了一件事：当工具开始给你打分，先看清楚打分的人靠什么赚钱。

最小改动原则 在软件工程中由来已久，与外科手术式修改（surgical change）和“先让它失败”的测试驱动思路一脉相承。其核心假设是：每次改动都引入风险，改动范围越大，需要验证的路径越多，回归缺陷的潜在面积越大。在支付、认证、账务等模块，一次全量重写意味着整个信任边界需要重新审计，而一行修复的影响面可以精确圈定。这一原则与AI代理的“倾向”存在结构性张力：生成式模型天然倾向于产出完整、连贯的实现，而非最小补丁。因此使用AI时，约束输出范围往往需要开发者主动施加，而这种约束恰恰不会被以产出量计分的系统所识别。