代码行数饼图：一场荒诞管理要求的回忆How Many Tokens Did You Burn Today

职业生涯早期，我曾在一家大公司任职时，一位经理提出的要求荒诞得令人难忘。我回到团队复述他的要求，还没说完就忍不住笑了起来。他要求我为每位开发人员每周的代码行数制作一个饼图。

我们都乐不可支。首席开发人员问这位经理的眼睛是否看起来有些呆滞。我们笑得更加厉害。没错，确实如此。他总是处于亢奋状态。

那是二十年前的事了。我无数次讲述这个故事，每次讨论软件团队与管理层之间的脱节时，总能引发阵阵笑声。任何软件工程师都能感同身受。我们都知道代码行数毫无意义。初级程序员可能写出上千行的“面条式”代码，而资深专家只需四十行优雅代码就能解决同样的问题。

但上周，我的名字却出现在排行榜顶端。

我的雇主一直在探索生产力工具，试用了一款他们认为有用的产品。试用结束后，他们报价每年50万美元。该工具跟踪开发者的生产力，并与Atlassian产品、微软及其他许多我们使用的服务集成。价格过高，于是被放弃。几个月后，同一家公司再次回来，提供了折扣价——同样的工具，仅需每年5万美元。我的雇主毫不犹豫地接受了这个机会。

今天你用了多少字节？

我现在正查看这个仪表盘，发现我的名字赫然排在排行榜首位。我点击小部件，随即出现了一个饼图。这里清晰地展示了我团队使用AI生成的总代码行数的个人细分情况。

这并非仅限于我的雇主。每家公司都在构建某种方式来追踪AI使用情况以证明投资价值。如今我们不再按项目完成度考核，而是统计每位开发者用AI生成的代码行数。讽刺的是，现在没人再发笑了。整个行业都在鼓掌并鼓励员工更多地使用它。

我并非因拥有什么智能工作流而成为冠军。完全是意外之举。在使用LLM时，我误对已规划好的请求选择了“规划模式”，代理运行了几分钟，消耗了代币去解决根本不存在的难题。就这样，我轻松登顶，甚至没写过一行代码。

若将此小部件视为真实指标，开发者很快会故意利用它。只需让代理通宵运行，你的雇主就能宣称生产力提升了十倍。

过去我们不用代码行数作为生产力指标，因为它毫无意义。重构代码时，我们常得到比初始更少的结果。事实上，修改AI生成代码的大部分时间花在删除它创建的多余内容上。难道要统计负代码行数？编程水平越高，数据反而越差。我们竟用代码行数评估开发者！

我曾见过AI布道者提问：“今天消耗了多少代币？”他们试图说服听众，生产力与代币用量成正比。这让我想起从纸质文档转向计算机的过渡。那个时代的电脑布道者或许会问：“今天用了多少字节？”

代码行数、字节数、令牌计数，这些都与实际工作效率毫无关系。度量标准往往与其本意完全脱节。我曾见过一些公司仅依赖故事点（story points），结果员工却将所有工单都标得尽可能高。若以代码行为指标，代码行数自然会增加；奖励最高产的开发者，到下次绩效评估时，所有人的产出量可能翻倍甚至三倍。

这种度量标准虽荒谬，但有其用途——只是未必适合你。AI 公司推广令牌使用量并将其与效率挂钩，正因他们直接从中获益。想象一家按字节收费的互联网服务提供商，他们会如何建议提升效率？“多用些字节！”

我认识的最优秀工程师写的代码更少，而非更多。他们删减冗余、简化逻辑，深知目标从来不是代码本身。他们解决问题、构建可靠系统、服务用户。用产出量（无论是代码行、提交次数还是令牌）衡量开发者，就像把尾气误认为引擎动力。

每个工具时代都会催生一类新度量标准，将活动等同于价值。电子表格并未让会计师更高效，只因他们能填满更多单元格；AI 也不会让开发者更高效，只因它能生成更多代码。

我们甚至未跟踪是否解决了正确的问题，且解决得是否妥善。若效率仪表盘无法回答这个问题，那它根本不是在衡量效率，而是在衡量订阅费用。