你的代码智能体消耗的能源比你手写代码多得多——但值得吗？

41 Wh。 这是一次中等规模的 Claude Code 会话的能耗——数据来自研究者 Simon P. Couch 于 2026 年 1 月的直接测量。

这相当于 136 次普通文本查询。或者一个 LED 灯泡亮 四个小时。或者你笔记本电脑一整天工作能耗的 12%。

而这还只是中等规模会话。一次复杂会话——智能体全天活跃运行——可以达到 50-200 Wh。

问题不在于能耗是否高。而在于是否值得。

什么是代码智能体，为什么它消耗这么多能源

代码助手和代码智能体之间有着根本区别。

经典的自动补全——最初的 GitHub Copilot、智能代码片段——每次建议只调用一次模型。成本小且是一次性的：每个工作会话 0.5-2 Wh。

智能体则完全不同。它不等你去写代码：它主动行动。它接收一个自然语言任务（“实现 OAuth 认证”、“将这些测试迁移到新 API”、“找到并修复 checkout 的性能 bug”），然后自主执行。

为完成这项任务，智能体会：

• 读取项目文件——有时数十个
• 在动手写代码之前规划和分解任务
• 编写代码，在沙箱环境中执行并读取输出
• 解读错误并决定如何修复
• 如果结果没有通过测试，重新开始

一个”简单任务”可能触发 20-50 次模型调用。复杂任务可达数百次。而且每次调用都包含累积的上下文——所有已读取的文件、完整的历史记录——这意味着每次调用的 token 数量也会随时间增长。

结果是：能耗并非随任务复杂度线性增长。它呈超线性增长。

数据：逐工具分析

以下是主要代码智能体的能耗范围记录，以及相对于单次文本查询（参考值 0.3 Wh）的倍数：

关于这张表的一些观察：

Aider 是正面异类。 这个开源智能体在同等任务中消耗的 token 比 Claude Code 少 x4 倍。高效率并非商业解决方案的专利。

Devin 2.0 是最不可预测的。 10-60 Wh 的范围反映了巨大的方差：其完全自主模式的能耗可以与使用 Opus 的 Claude Code 长时间会话相当。

GPT-5.3-Codex 比前代翻了一倍。 从 x20-x67 跃升至 x40-x133，这一版本间的差距说明了趋势：集成推理能力的模型成本更高，但能力也更强。

Claude Code 案例：唯一具有公开方法论的数据

在上述所有工具中，只有一项分析具有详细的公开方法论：Simon P. Couch 于 2026 年 1 月发表的研究。

Couch 分析了自己数周的 Claude Code 工作会话，记录了以下数据：

• 中等会话： 24 次交互对话中产生 592,000 个 token
• 中等会话能耗： 41 Wh
• 等价于： 136 次普通文本查询
• 高强度使用会话（多实例，全天）：50-200 Wh

“一个开发者每天使用代码智能体 8 小时，消耗的能源相当于一台冰箱运行 24 小时。” — Simon P. Couch，Claude Code 能耗分析，2026 年 1 月

这项分析的价值不仅在于数字本身：更在于没有其他人发布过类似数据。Anthropic 没有，OpenAI 没有，GitHub 没有，Cursor 也没有。销售这些工具的公司不公布每项任务的 Wh 数据。它们只公布每个 token 的价格——这是能耗的代理变量，但在实际使用场景中并不等同于真实能耗。

生产力悖论

接下来是分析中令人不安的部分：如果生产力提升是真实的，那么高能耗成本可能是合理的。

GitHub 的内部数据表明，在范围明确的任务中使用 Copilot Agent 可以提速 +55%。采用完整代码智能体的团队报告称，某些类型的任务可以将 3-4 天的工作量压缩到一天。

如果这是真的——方法论确实存在我们将要讨论的局限性——即使考虑能源消耗，ROI 也可能是正面的。

但这些数据存在一个问题：

生产力基准测试由这些公司自己制作。 GitHub 衡量 Copilot 的影响。Anthropic 衡量 Claude Code 的影响。没有任何独立研究同时测量过：

1. 开发速度
2. 总能耗
3. 生成代码的质量
4. 长期可维护性
5. 产生的技术债务

反弹效应是真实存在的，在其他技术领域已有记录：当某件事变得更快时，人们会更多地使用它。采用代码智能体的团队不仅仅是更快地完成同样的工作——他们还会生成更多代码、更多迭代、更多审查、更多 PR。总开支更多？很可能是的。

没有人在回答的问题是：那些额外的代码是在创造价值，还是只是在积累技术债务？

哪些情况下能源成本是值得的？

并非所有使用场景都一样。以下是代码智能体的能源成本能获得明确回报的情况：

具有明确模式的迁移和重构。 从一个 API 版本迁移到另一个、更新依赖项、将测试从一个框架转换到另一个。智能体了解模式，能以一致的方式将其应用到数百个文件。人类需要数天；智能体只需数小时。这个时间差具有真实的商业价值。

时间上市速度至关重要的快速原型开发。 在有真实截止日期的探索阶段——投资人演示、验证假设的 MVP——速度带来的价值可以远远超过能源成本。

理解大型代码库。 让智能体解释一个 200,000 行项目的架构、追踪一个函数的调用流程或识别某个 API 的所有使用点。在这种场景下，智能体读取多于编写，价值在于综合分析。

回归测试和覆盖率。 为文档完善的现有代码生成测试是可预测的，智能体做得很好。释放出的人力时间可以投入到更高认知价值的任务中。

哪些情况下不值得？

开放式探索。 “用这些数据做点有意思的事。""提升应用性能。""重构得更整洁。“没有明确的成功标准，智能体会不断迭代却无法收敛。大量模型调用、结果不确定，最终仍然不可避免地需要人工审查。

模型不擅长的领域。 如果智能体不熟悉该领域——一个非常特定的库、一种小众语言、没有文档的业务逻辑——它会犯错并需要多次迭代来纠正。高能耗，平庸的结果。

速度不重要的任务。 如果没有截止日期，如果生成的代码无论如何都需要详尽审查，如果团队花在审查智能体产出的时间比自己写代码还长：ROI 是负的。

当生成的代码制造的技术债务多于解决的。 智能体是针对完成指定任务的优化器。它们没有自己的业务上下文，不了解团队的隐性约定，不知道代码的哪些部分更为关键。它们生成的代码可能能运行，但六个月后可能成为问题。

度量偏差

在评估代码智能体影响方面存在一个结构性问题：

生产力研究由销售生产力工具的人资助。 关于 Copilot 影响的最常被引用的研究来自 GitHub，GitHub 属于 Microsoft，而 Microsoft 销售 Copilot。关于 Claude Code 最有利的分析来自 Anthropic。这并不能否定数据的有效性，但确实需要以批判性思维来解读。

成功指标偏向于容易衡量的东西。 完成一个范围明确任务的速度：可衡量。六个月后的代码质量：在三周的研究中无法衡量。累积的技术债务：同样无法衡量。对开发者维护和理解自己代码能力的影响：几乎无法隔离测量。

没有任何提供商公布每项任务的能耗指标。 每个 token 的价格是公开的。每项任务的 Wh 却不是。对家用电器要求的能源透明度，对消耗远超任何洗衣机能源量级的软件工具却没有要求。

AISHA 在此提出一个具体呼吁：代码智能体提供商应当公布每项任务的 Wh 指标，就像它们公布每个 token 的价格和生成速度一样。对于能够访问自身系统的人来说，这并非难以计算的信息。这是用户和工程团队做出明智决策所需的信息。

代码智能体并不比人类开发者更好。它是不同的：在某些类型的任务上更快、能耗更高、没有自己的业务上下文。正确使用它的决策需要你确切了解手头任务的类型。

我能做什么？

• 如果你是开发者： 在调用智能体之前先区分任务类型。有明确标准的重复性任务 → 智能体。开放式探索 → 先自己写。对于不需要最大自主性的任务，考虑使用 Aider：能耗降低 x4 倍，结果相当。

• 如果你管理工程团队： 制定使用策略，而不仅仅是访问权限策略。衡量完整周期时间——包括审查和修正生成代码的时间——而不仅仅是生成时间。定义哪些类型的任务适合使用完整智能体，哪些只需要简单辅助。

• 如果你是 CTO 或技术负责人： 一个 20 人的工程团队每天使用代码智能体 6 小时，能耗相当于数百台冰箱全天候运行。这对 ESG 报告和按用量付费的运营成本来说是一个重要数据。

• 如果你从事技术可持续性工作： 要求开发工具提供商在其仪表板中包含每项任务的 Wh 指标。每个 token 的成本已经公开。Wh 成本也应该公开——技术上并不困难，这是一个透明度的决策。