过去几个月来，Hacker News 上关于「写更少代码，担当更多责任」的讨论引发了广泛共鸣。核心论点并非新事物：代码行数从来不是衡量产出的有效单位，恰恰相反，每一行新增代码都是一份长期负债。然而，当大语言模型将代码生成的边际成本降至几乎为零时，这一看似显而易见的道理突然获得了前所未有的现实紧迫性。本文不打算重复「思考比打字更重要」这类老生常谈，而是聚焦于一个更可操作的层面：如何量化 LLM 生成代码的冗余程度，以及如何在工程流程中设置自动化检测与重构触发阈值。

代码冗余度问题的本质

传统软件开发中，代码冗余主要来源于重复实现、硬编码和缺乏抽象。LLM 时代带来了新的维度：模型倾向于生成过度完备的解决方案，包括详尽的注释、冗余的错误处理、过度设计的类结构，以及大量模板化 boilerplate。学术研究已经观察到这一现象，有论文将其描述为「excess token prevention」问题 —— 模型在追求「正确性」的过程中，输出的 token 数量往往远超实际所需。

这种冗余并非无害。首先是直接成本：按 token 计费的 API 模式下，冗余代码直接转化为财务支出。其次是维护成本 —— 更多代码意味着更长的理解时间、更高的认知负荷和更大的 bug 引入概率。更隐蔽的是「代码质量滑坡」效应：当开发者习惯于让 LLM 代劳实现后，他们对代码库的掌握程度会逐渐下降，面对冗余或错误的输出时也难以有效审查。

可量化的冗余度指标体系

要对 LLM 生成的代码进行有效优化，首先需要建立可测量的指标体系。以下是一套经过实践验证的核心度量维度。

Token 效率比是最直观的指标，计算方式为「有意义可执行语句的 token 数」除以「总输出 token 数」。这里的关键在于区分「有意义」与「无意义」：一行 const result = await fetchData(); 显然比三行注释加四行空行更有价值。实践中，可以设置一个基线阈值 —— 例如效率比低于 0.4 时触发人工审查，低于 0.3 时强制要求优化后重试。

代码密度衡量每单位功能所需的代码量。一个 50 行却只实现了单一职责的函数，与一个 200 行实现了五个不相关功能的函数，后者的代码密度明显偏低。对于 LLM 输出，建议函数级别代码密度的健康阈值不低于 0.6，即至少 60% 的行数应该贡献实际功能，其余可以是必要的空行、类型标注或 unavoidable 的 boilerplate。

圈复杂度增量是另一个关键指标。LLM 有时会生成过度嵌套的条件判断或不必要的状态机。跟踪每次代码变更引入的额外复杂度分支尤为重要 —— 如果一次 LLM 辅助修改使圈复杂度增加超过 3 个单位，就应该触发额外审查。

代码复用率衡量生成代码中与既有代码库的重叠程度。高复用率意味着 LLM 成功利用了现有抽象，低复用率则可能意味着生成了新的重复实现或引入了不必要的外部依赖。这一指标可以通过简单的文本相似度匹配或抽象语法树比对来计算。

工程化优化策略

建立指标体系只是第一步，将这些指标嵌入开发流程才能产生实际价值。

Prompt 层面的约束是最直接的优化手段。在系统提示中明确要求「生成最小可行实现」而非「完整解决方案」，可以显著降低冗余度。具体的工程实践包括：在 prompt 中加入 token 预算限制，例如「用不超过 150 个 token 实现这个函数」；明确指定代码风格，如「使用函数式风格，避免不必要的类和中间变量」；以及要求先输出实现思路再输出代码，让模型自己先做一轮精简。

后处理自动化是第二道防线。即便 prompt 约束未能完全生效，也可以在代码进入代码库之前运行自动化剪枝。常见的做法包括：使用代码格式化工具统一风格后统计有效行数变化；运行静态分析工具标记过度复杂的函数；以及基于 AST 的轻量级重构脚本，自动提取重复模式并建议合并。

重构触发阈值的设置是整个闭环的关键。建议采用分级响应机制：第一级，当单次生成的 token 数超过同类任务历史平均值的 150% 时，系统提示用户关注；第二级，当代码密度连续两次低于 0.4 时，自动触发代码审查流程；第三级，当累计复杂度增量超过项目基线 20% 时，锁定该模块并要求人工确认。这些阈值并非一成不变，而应随着团队对 LLM 使用熟练度的提升而动态调整。

实施路线图

对于希望系统性地解决 LLM 代码冗余问题的团队，建议分三个阶段推进。第一阶段是基线测量 —— 在不做任何干预的情况下，记录 LLM 生成代码的各项指标，建立团队当前的「正常」水平。这一阶段通常会揭示惊人的数字：很多团队的 LLM 代码密度甚至低于 0.3，意味着超过七成的输出是无实质贡献的冗余内容。

第二阶段是分场景阈值设定。根据业务场景的可靠性要求，设置差异化的阈值策略。关键业务路径的代码应当采用最严格的冗余度控制 —— 代码密度阈值可以设为 0.5 以上；而实验性原型或一次性脚本则可以放宽要求，重点关注功能正确性而非代码质量。

第三阶段是流程嵌入与持续迭代。将冗余度检测集成到 CI 流程中，使其成为代码审查的自动化环节。同时，建立反馈循环 —— 如果某个 prompt 持续导致高冗余输出，就针对性地优化 prompt 模板；如果某个 LLM 模型在特定任务上表现不佳，就调整模型选择策略。

结语

LLM 确实大幅降低了代码生成的门槛，但「生成更多代码」不等于「更快交付价值」。当冗余代码的累积速度超过团队维护能力时，曾经的效率优势会迅速转化为技术债务危机。通过建立量化的冗余度指标体系，并在工程流程中嵌入检测与响应机制，团队可以在享受 LLM 生产力红利的同时，避免代码库不可逆转地膨胀。这本质上是一种防御性编程 —— 防御的不是 bug，而是效率幻觉带来的慢性侵蚀。

参考资料