库克把2万行代码删成-2000，40年后硅谷又栽进同一个坑

1982年，苹果工程师比尔·阿特金森（Bill Atkinson）在周报上填了个负数：-2000。他刚花几周重构区域计算引擎，把臃肿的原始算法换成更优雅、更快、更短的版本。管理层推行"代码行数"（LOC）作为生产力指标，他用这个负数表达态度。

40年后，Y Combinator CEO加里·谭（Garry Tan）在推特晒出一张仪表盘：每天37000行代码，作为"智能体工程"（agentic engineering）提速的证据。历史没重复，但押韵押得刺耳。

LOC幽灵复活：从-2000到+37000

阿特金森是QuickDraw架构师、Apple Lisa核心设计师。他写的-2000不是恶作剧，是对度量衡本身的质疑。代码行数能衡量什么？只能衡量你生产了多少需要维护的债务。

谭的推文引发连锁反应。Slack频道、技术论坛、董事会会议室里，一种信念正在扩散：AI"解决"了软件工程，因为生成代码变得毫不费力。这不是边缘观点，这是硅谷最高层领导层的判断。

作者纳撒尼尔·菲舍尔（Nathaniel Fishel）的批评很直接：我们在把token消耗错当成价值创造，把攻击面扩张和维护负担爆炸庆祝为进步。仪表盘上的虚荣指标永远不会告诉你创造了多少价值，只会告诉你融资了多少技术债务。

代码本身值多少钱？微软开源Windows的假想实验

菲舍尔抛出一个思想实验：如果微软明天开源整个Windows，用户会立刻涌向一家卖同样代码的创业公司吗？

答案显然是否定的。用户为Windows付费，不是因为那几千万行源代码，而是因为开机就能工作的结果。他们买的是分发渠道、技术支持、品牌信任——是"工作"被"完成"（Job to be Done）。

这个区分很关键。源代码的 intrinsic value（内在价值）为零。没有用户的软件，按定义毫无价值。AI代理生成十万行代码，不会有客户因此多付一分钱。如果这些代码没有缩短用户的"愉悦时间"（Time to Joy），你创造的价值就是零。

三条替代指标：从代码量到价值量

菲舍尔提出三个衡量维度，替代LOC这种有毒指标。

第一，价值实现时间（TTV）与反馈循环。用户从接触到获得价值需要多久？这个指标倒逼团队缩短路径，而非堆砌功能。

第二，效用与维护成本之比。软件的价值是用户获得的效用，除以维护它所需的持续投入。AI生成的代码如果难以调试、难以测试，分母会迅速膨胀，比值可能为负。

第三，用户结果导向。回归"工作完成"框架。用户不关心你用了多少智能体，关心的是问题是否解决、解决得多快、解决得多可靠。

这三条都指向同一个方向：把度量衡从工程师的产出，转移到用户的收获。

智能体工程的幻觉：更快≠更好

谭的仪表盘有个隐含假设：速度就是一切。每天37000行代码，比每天3700行快10倍，所以效率提升10倍。

这个等式漏掉了分母。代码不是资产，是负债——直到它被验证、被部署、被用户实际使用。生成速度越快，待验证的负债堆积越高。AI编码工具的真正风险不是取代工程师，而是让组织误以为"写代码"等于"交付价值"。

菲舍尔在文末留了道开放性提问：如果LOC是毒药，什么指标能让领导层真正"后退一步"，看清仪表盘背后的真相？

阿特金森的-2000行，和谭的+37000行，中间隔着40年。两代技术革命，同一个认知陷阱。区别在于，1982年的错误只影响一个团队，2025年的错误可能通过AI放大到整个行业的技术债务规模。

用户会为"每天多写3万行代码"买单吗？还是说，他们只会为"问题被解决"付费——无论那需要-2000行，还是+37行？