内容
职业生涯早期，我曾在一家大型公司工作，有位经理提出了一个荒唐到让我至今都记忆犹新的要求。我回到团队，把他的要求复述了一遍，故事都没讲完就忍不住笑了出来。他想让我做一个饼图，按开发者、按周统计代码行数。
我们全都笑疯了。我们的首席开发工程师还问，那位经理的眼睛是不是看起来有点发直。我们笑得更厉害了。因为是的，没错，确实如此。他一直都嗨着。
那是二十年前的事了。我无数次讲起这个故事，每次都会引来一阵轻笑，因为大家都在讨论软件团队和管理层之间的脱节。任何软件工程师都能感同身受。我们都知道，代码行数是一个毫无意义的指标。初级开发者可以写出一千行乱七八糟的“意大利面”代码；资深开发者则可能只用四十行优雅的代码就解决同一个问题。
但就在上周，我发现自己的名字出现在了排行榜最上方。
我的雇主一直在研究生产力工具，并试用了一款他们认为会有用的产品。试用结束后，对方报出的价格是每年 50 万美元。这个工具会追踪开发者生产力，并与 Atlassian 产品、微软以及我们使用的许多其他服务集成。价格太高，于是就被搁置了。几个月后，同一家公司又带着折扣方案回来了。同样的工具，一年只要 5 万美元。我的雇主立刻抓住了这个机会。
你今天用了多少字节？
我现在正看着这个仪表板，看到自己的名字排在排行榜第一。点开这个小组件后，一个饼图弹了出来。看吧：这是我所在团队借助 AI 产出的总代码行数，按个人拆分的明细。
这并不只发生在我的雇主那里。每家公司都在搭建一些东西，用来追踪 AI 使用情况，并为这笔投资找到理由。我们不再追踪项目是否完成，而是在追踪每个开发者借助 AI 生成了多少代码行。讽刺的是，笑不出来的人是我，因为根本没人觉得这好笑。整个行业都在鼓掌，还在鼓励员工多用一点。
我并不是因为有什么精巧的智能体工作流才成了冠军。纯粹是意外。我在使用 LLM 时，不小心把一个已经规划好的请求切到了“规划模式”。这个智能体运行了好几分钟，白白烧掉了一堆 token 去解决一个根本不存在的问题。就这样，我什么代码都没写，就登上了榜首。
如果这个小组件被当真看待，用不了多久，开发者就会开始故意刷数据。只要让智能体通宵运行，你的雇主就能宣称生产力提升了 10 倍。
过去我们之所以不把代码行数当作生产力指标，是因为这根本说不通。每次重构代码时，我们通常都会把代码量减少。实际上，我花在修改 AI 生成代码上的很多时间，都是在删除它凭空造出来的不必要内容。那是不是该统计“负代码行数”？你越擅长编程，数据反而越难看。我们竟然在用代码行数来衡量开发者。
我见过 AI 布道者问“你今天烧了多少 token？”他们想说服听众：生产力和 token 消耗量成正比。这让我想起从纸张过渡到计算机的时代。那个时代的一位计算机布道者也许会问：“你今天用了多少字节？”
token 数、代码行数、字节数，这些都和真实生产力没有任何关系。指标往往和它们试图衡量的东西完全脱节。我见过公司依赖故事点，结果员工把每张工单都尽量估得高高的。把代码行数作为指标，代码行数就会增加。奖励最高贡献者，等着看下一次绩效评估前，所有人的产出翻倍甚至三倍。
这确实是个愚蠢的指标，但它确实有作用，只是不是对你有用。AI 公司鼓励 token 消耗，并把它和生产力绑定，因为他们能直接从中受益。想象一家按字节收费的互联网服务提供商。他们会怎么建议提升生产力？“多用字节！”
我所见过最优秀的工程师写的代码都更少，而不是更多。他们会删东西，会简化。他们明白，目标从来都不是代码本身。他们解决问题，让系统可靠，并服务用户。用输出量来衡量开发者，不管是代码行数、提交次数还是 token 数，都只是把排气管当成了发动机。
每一代工具都会带来一种新的指标，把“活动”误当成“价值”。电子表格并没有因为会计能填更多单元格，就让他们更高效。AI 也不会因为能生成更多代码，就让开发者更高效。
我们甚至连问题有没有被正确地解决、有没有被很好地解决都没在追踪。如果生产力仪表板回答不了这一点，那它衡量的就不是生产力，而是订阅费。