Hacker News 中文摘要

RSS订阅

代码行数卷土重来（情况比以往更糟） -- Lines of Code Are Back (and It's Worse Than Before)

原文链接 | HN讨论 | 2026-02-13 05:37:18

文章摘要

文章指出，软件行业曾长期认为"代码行数"是糟糕的生产力指标，但AI的出现让这一过时标准重新流行，且情况比以往更糟。多位技术先驱如Dijkstra、比尔·盖茨等早批评该指标会鼓励编写低质量代码，但如今行业又倒退使用这一错误衡量方式。

文章总结

标题：代码行数指标卷土重来（且情况比以往更糟）

行业共识的崩塌

软件行业长期认为代码行数（LOC）是糟糕的衡量标准。Dijkstra批评其"鼓励编写乏味代码"，比尔·盖茨类比为"用飞机重量衡量制造进度"。2009年，提出"无法测量就无法控制"的Tom DeMarco公开撤回这一观点，认为软件开发的本质是实验性探索。到2023年，Kent Beck将LOC归为"最无用的输入指标"。

AI时代的指标倒退

随着AI代码生成工具的兴起，科技巨头开始竞相吹嘘AI编写代码的占比： - 谷歌CEO称2024年25%新代码由AI生成，2025年升至30% - 微软CEO表示20%-30%代码由AI编写 - Meta CEO预测一年内AI将承担半数开发任务 - Anthropic CEO甚至宣称其90%代码由AI完成（后修正为70%-90%）

这些数据被包装成技术突破，却无人报告AI代码的缺陷率、重构率或实际部署效果。工具厂商也推波助澜，GitHub Copilot等平台将"建议/采纳代码行数"作为核心指标，2024年全球AI生成代码达2560亿行。

指标异化的三重危机

  1. 人为操纵的恶化：过去开发者可能刻意编写冗长代码，但存在人力限制；AI则能在瞬间生成数万行无意义代码，彻底打破平衡
  2. 古德哈特定律的二次方：当无限游戏能力的AI遇上已被证伪的指标，结果完全失真
  3. 理解力危机：Andrej Karpathy提出的"氛围编程"（不关注代码逻辑）导致开发者对系统理解度下降，Greptile数据显示人均代码量增长76%的同时，代码质量显著恶化

触目惊心的数据证据

  • GitClear分析2.11亿行代码发现：2024年复制粘贴代码（12.3%）首次超过重构代码（9.5%）
  • 新代码两周内修改率从3.1%升至5.7%
  • METR实验显示：使用AI的开发者耗时增加19%，却自认为提速20%
  • Stack Overflow调查：66%开发者表示修复AI"近似正确"代码的时间超过节省的编写时间
  • Veracode报告：45%的AI代码存在安全漏洞

替代指标的探索

建议转向四个结果导向的指标： 1. 价值实现时间：从需求识别到生产环境部署的全周期 2. 代码半衰期：代码存活时间反映健康度（AI代码平均14天即需修改） 3. 缺陷溯源率：区分AI/人工代码的缺陷比例 4. 系统理解度：团队对关键路径的掌握程度

核心洞见

软件开发的瓶颈从来不是编码速度，而是系统理解、设计能力和工程判断。当AI使代码生产成本趋近于零时，衡量产出数量已毫无意义。真正的挑战在于回答： - 如果禁用AI工具，团队是开发变慢还是仅仅减少代码量？ - 代码库中有多少比例能被团队成员完整解释？ - 我们究竟需要多少代码存在？

正如作者在实践中所坚持的：应该测量难以量化的价值指标，而非精确统计无意义的代码行数——因为前者至少指向正确的方向。

评论总结

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

支持代码行数（LoC）作为指标的观点

  1. 初学者适用性：认为LoC对初学者是有效的进步衡量标准，能直观展示从零开始的成长。

    • "LOC is great because productivity measures are for beginners and people who don't understand code."（评论1）
    • "even lines of code are good enough to see progress from a blank slate"（评论1）

  2. 项目复杂度参考：LoC可作为项目整体复杂度的参考指标，而非个人生产力。

    • "LoC never went away for estimating the overall level of complexity of a project"（评论3）
    • "There's generally a valid distinction between an app that has 1K, 10K, 100K, or 1M lines of code."（评论3）

反对LoC作为核心指标的观点

  1. 质量与效率矛盾：更多代码可能意味着冗余、低效或未优化的AI生成内容。

    • "AI code is more repetitive and needs refactoring... a larger surface for bugs"（评论3）
    • "It will write code that's already available... end up with tons of extra lines"（评论6）

  2. 可被操控性：LoC易被人为操纵，无法反映真实价值。

    • "Lines of code changed are a very bad measure for humans because they can be gamed"（评论8）
    • "Management... commented them out [instead of deleting] to meet line count goals"（评论18）

替代性建议

  1. 反向指标：应追求更少但更高效的代码。

    • "Lines of code are bad, and you should target fewer lines of code"（评论12）
    • "LoC is a good code quality metric, only it has to be inverted"（评论7）

  2. 结果导向：关注客户满意度、团队成长等实际成果。

    • "Is the client happy? Are the team members growing? Were we able to make a profit?"（评论5）
    • "Focusing on capabilities instead of shipping code provides a better measure"（评论17）

  3. 技术替代方案：建议采用词法标记或AST边数等更精确的度量方式。

    • "We could count (lexer) tokens of code instead of lines"（评论14）

关于AI生成代码的特殊性

  1. 重复与维护问题：AI易生成重复代码且缺乏自我清理机制。

    • "AI often fails to clean up after itself... leaves behind unused code"（评论6）
    • "The code written by AI in most cases is throwaway code"（评论2）

  2. 管理挑战：需警惕自动化带来的审查惰性。

    • "Human mind resists thoroughly scrutinizing automation which is usually right"（评论15）

关键争议点总结：LoC作为历史性指标虽具直观性，但在AI时代更暴露其局限性；支持者强调其入门价值，反对者则指出其与代码质量、管理目标的根本冲突。替代方案多聚焦于结果价值或更精细的技术度量。