性能盲区：AI代理编写低效代码

代码通过了所有测试。代码检查工具没有报错。类型检查器表示满意。代码审查也通过了。然而，这个函数比它应有的速度慢了446倍。¹

Codeflash是一款代码性能优化工具，他们分析了完全由Claude Code生成的两个拉取请求：涵盖一个Java语言支持模块和一个React框架集成，共76,000行代码。¹他们发现了118个存在严重性能问题的函数。性能下降幅度从3倍到446倍不等。最严重的案例是：一个类型提取函数在每次调用时都重新扫描整个AST，而不是缓存遍历结果。行为完全正确，但性能灾难性地低下。

这一发现并非个例。SWE-fficiency是一个包含498个优化任务的基准测试，覆盖了NumPy、Pandas和SciPy等代码库，结果发现表现最好的LLM代理在相同任务上仅达到专家开发者加速效果的不到0.15倍。²另一项独立研究测试了Claude 3.5、OpenAI o1和Llama 3.2在26个高性能计算代码上的表现，发现Claude 3.5在串行优化上仅实现了1.02倍的加速（实质上零改进），同时在30%的案例中生成了错误代码。³Codeflash自身对100,000个开源函数的分析发现，90%的AI建议优化要么不正确，要么没有可测量的收益，而在正确的优化中，73%的收益低于5%。⁴

性能是AI编码工具看不到的维度。每一个标准质量关卡（代码检查工具、类型检查器、测试套件、代码审查）都在验证正确性，没有一个在验证效率。结果是：AI生成的每一行代码都通过了所有检查，却对它进入的每一个系统施加了一种隐形税。

摘要

AI代理编写的代码正确但缓慢。Codeflash在76,000行Claude Code输出中发现了118个性能问题，性能下降幅度从3倍到446倍。¹学术基准测试证实了这一模式：LLM在优化任务上仅达到专家加速效果的不到0.15倍。²原因是结构性的：训练数据奖励正确性，而标准质量关卡不衡量性能。突破这一瓶颈需要性能基础设施：将基准测试与单元测试并列、在钩子中使用基于AST的模式检测，以及将性能分析作为标准工作流步骤。

核心要点

对于个人开发者。 在每个AI生成的热路径函数之后的验证步骤中，添加time或性能分析器。那个446倍的性能下降通过了所有测试和所有代码检查工具。唯一能捕获它的关卡是基准测试。将”它能运行”视为必要但不充分条件。将”它运行得有多快？”作为标准后续问题。

对于团队负责人。 性能回退是够好就行高原的隐形形式。通过所有功能测试的AI生成代码会制造一种虚假的完成感。在CI中将性能基准测试与单元测试并列添加。Faros AI的数据显示，AI辅助团队完成的任务多21%，同时每个开发者多产生9%的缺陷。⁵性能缺陷不计入那9%，因为没有人在衡量它们。

对于平台工程师。 构建缺失的关卡。代码检查工具检查风格。类型检查器检查契约。测试套件检查行为。在标准CI流水线中，没有任何工具检查算法复杂度或运行时特征。基于AST的模式检测（Semgrep规则、ast-grep模式或自定义钩子）可以捕获最常见的性能反模式：冗余遍历、缺失的记忆化和不必要的拷贝。

118个缺陷的真实面貌

Codeflash对两个Claude Code PR的分析提供了目前公开的关于AI生成性能问题的最细粒度数据集。¹两个PR共计76,000行：52,000行用于Java语言支持，24,000行用于React框架支持。两者在功能上都正常运行，都通过了测试套件，但都包含在真实负载下会性能退化的代码。

根本原因聚集为四个类别：

低效算法。 这是最主要的类别。一个将字节偏移转换为行位置的函数使用了O(n)扫描，而非使用预计算查找表的O(log n)二分查找。代码可读性良好，变量命名清晰，逻辑正确。但复杂度类别是错误的。

冗余计算。 函数重复解析、重复遍历或重复计算本可缓存的值。辅助函数查找器在每次调用时都重新解析同一源文件。一个记忆化装饰器就能将74倍的开销在首次调用后降为零。

缺失缓存和记忆化。 与冗余计算密切相关，但区别在于数据在更广泛的作用域中是可用的。类型定义提取器每次都遍历完整的AST，而非在首次访问时构建索引。模式是：代理在编写每个函数时相互隔离，不考虑该函数在循环中被调用的情况。

次优数据结构。 在集合或字典可提供O(1)查找的场景中使用列表扫描。导出检查器通过迭代列表来测试成员关系。转换为集合就能完全消除9倍的开销。

为什么代理会生成低效代码

性能盲区不是某个特定模型的缺陷。原因是结构性的，作用于三个层面：训练数据、评估标准和工作流假设。

训练数据奖励可读性

LLM从训练数据中的代码分布中学习。任何算法最常见的实现都是朴素实现。教程代码优先考虑清晰度。Stack Overflow的回答优先考虑正确性。开源代码中确实包含性能优化版本，但它们在数量上被直接了当的实现远远超过。

这一模式不仅限于性能领域。斯坦福大学发现，在五项安全任务中的四项中，AI辅助开发者编写不安全代码的频率更高，而且这些开发者更倾向于相信自己的代码是安全的。⁸这种信心差距同样适用于性能：代码看起来整洁、读起来流畅、输出结果正确，因此开发者信任它。SWE-fficiency的研究人员发现，代理难以定位优化机会并跨函数推理执行过程。²LLM倾向于做小型的、针对特定输入的编辑，而非算法层面的改进。当被要求优化时，模型会选择最近的正确变换（添加缓存、内联函数），而非重新思考算法方案。结果是在根本性低效的结构之上叠加微观优化。

没有评估关卡衡量性能

标准质量关卡验证的是它们被设计用来验证的内容：

行业已标准化的每一个关卡都作用于正确性。性能测试确实存在（性能分析器、基准测试框架、负载测试工具），但它们属于独立的工作流，大多数团队并未将其集成到CI流水线中，而AI代理从不会主动调用它们。

解释10%生产力墙的验证真空比功能正确性更为深远。这个真空不仅仅是”代码能否运行？”，还包括”代码性能如何？”——而没有任何标准关卡会问第二个问题。

代理编写的是函数，而非系统

最深层的原因是架构性的。AI代理每次生成一个函数、一个文件、一个任务的代码。每次生成的范围是当前的即时需求。性能问题出现在边界处：当为单次调用编写的函数被放入循环中调用时，当为小输入编写的解析器接收大文件时，当为正确性编写的查找在每个请求上都被命中时。

来自代理故障分类法的隧道视野故障模式在功能层面描述了这一模式：代理完善一个组件却不检查集成点。性能盲区就是隧道视野应用于运行时特征的表现。函数在隔离环境中是完美的。系统退化是因为函数的性能特征从未在上下文中被评估。

隐形税

如果AI生成的代码仅占生产系统的一小部分，性能盲区只是一个小问题。但当前的数据使其成为系统性风险。

DX测量显示AI编写的代码占已合并生产代码的26.9%，且仍在增长。⁶Faros AI（一家DevOps分析供应商）发现，AI辅助团队合并的PR比AI前基线大154%，完成的任务多21%，每个开发者多产生9%的缺陷。⁵那9%的数字统计的是功能缺陷。性能回退完全不在指标中，因为大多数团队根本没有可以回退对照的性能基线。

复利效应不容忽视。METR的随机对照试验发现，有经验的开发者使用AI工具后耗时反而多了19%，但他们自己认为AI使他们加快了20%。⁹如果开发者自身都无法准确评估影响，性能债务就会在不知不觉中累积。当26.9%的已合并代码可能携带性能债务，而组织又没有性能关卡时，债务在每个迭代周期都在复利增长。DORA 2025报告发现，AI采用与交付不稳定性的增加相关，即使吞吐量有所提升。⁷报告并未将不稳定性明确归因于性能，但机制是吻合的：更多代码、更快合并，而性能特征从未被衡量。

接受Codeflash调查的工程领导者中，52%报告说AI使用量的增加导致其代码库出现性能问题。⁴这一数据是自报告的，且来自一家供应商（Codeflash销售性能优化工具），但方向与每一个独立数据集一致。更多AI生成的代码通过标准质量关卡合并，产生的系统功能正确但运行缓慢。

10%生产力墙有一个原始数据未能揭示的性能维度。如果AI将代码生成加速了10%，但生成的代码携带的性能债务在数周或数月后以生产事故的形式浮现，那么净生产力收益将进一步缩水。这堵墙不仅仅是”AI没有让开发者更快”，还包括”AI让代码变慢了，而且没有人在衡量这一点”。

检测方案

对AI生成代码的性能检测需要大多数组织尚不具备的基础设施。工具是现成的，缺的是集成。

CI中的基准测试关卡

最直接的解决方案：对关键路径进行基准测试，在出现回退时使构建失败。每种主要语言都有框架：Python的pytest-benchmark、Java的JMH、Rust的criterion、JavaScript的benchmark.js。挑战不在于工具，而在于实践。基准测试需要基线，而基线需要有人在AI生成代码能够回退之前编写初始基准测试。

最小可行实现：识别热路径中的10-20个函数，为这些函数编写基准测试，并将其添加到CI中。Codeflash发现的118个缺陷集中在解析器和AST遍历函数中：即计算核心，而非胶水代码。性能问题每次都集中在相同的位置。

基于AST的模式检测

静态分析可以在不运行代码的情况下捕获最严重的模式。Semgrep和ast-grep支持自定义规则来检测：

• 嵌套循环中内部集合不变的列表推导或循环（缓存候选）
• 对列表执行.index()或in检查，而列表可以转换为集合
• 循环内的文件I/O或网络调用且未进行批处理
• 使用相同参数重复调用函数（记忆化候选）

这些规则不能替代性能分析。它们捕获的是构成118个缺陷中大多数的模式：冗余计算、缺失缓存、错误的数据结构。

基于钩子的性能感知

对于Claude Code用户，PreToolUse钩子可以将性能感知注入代理的工作流中。该方法与用于正确性的证据关卡模式类似：

check_performance_patterns() {
    local file_path="$1"
    local ext="${file_path##*.}"

    case "$ext" in
        py)
            # Detect nested loops with repeated computation
            if grep -Pn 'for .+ in .+:\n.*for .+ in .+:' "$file_path" 2>/dev/null; then
                echo "WARNING: Nested loops detected in $file_path"
                echo "Verify inner loop does not recompute invariant values."
            fi
            # Detect list membership checks that should be sets
            if grep -n '\bin\b.*\[' "$file_path" 2>/dev/null | grep -v '#'; then
                echo "WARNING: List membership check in $file_path"
                echo "Consider converting to a set for O(1) lookup."
            fi
            ;;
        js|ts)
            # Detect Array.includes or indexOf in loops
            if grep -n '\.includes\|\.indexOf' "$file_path" 2>/dev/null; then
                echo "NOTE: Array search detected in $file_path"
                echo "If called in a loop, consider a Set or Map."
            fi
            ;;
    esac
}

钩子不是性能分析器。它的作用是提升意识。目标与其他所有质量关卡相同：让不可见的变为可见，以便开发者（或在后续迭代中的代理）能在代码上线前解决问题。

缺失的基础设施

每一个数据点所指向的模式，与解释10%生产力墙和七种故障模式的模式相同：AI放大一切现有的基础设施，包括基础设施的缺失。

拥有CI性能基准测试的组织将以捕获人工生成性能回退的同样方式捕获AI生成的性能回退。没有这些基准测试的组织将隐形地累积性能债务。DORA的”放大器”发现直接适用于此：AI并没有创造性能盲区，AI只是将其放大了。⁷

三项最低限度的投资可以弥合差距：

1. 在AI围绕关键路径生成代码之前，先为其建立基准测试。 基准测试就是基线。没有基线，就无法检测到任何回退。识别占大部分计算时间的10-20个函数，首先为这些函数编写基准测试。

2. 将基于AST的性能检查添加到CI流水线中。 使用Semgrep或ast-grep规则标记四种主要反模式（冗余计算、缺失缓存、错误数据结构、不必要的复杂度）。这些规则轻量且可与现有的代码检查步骤组合。

3. 将性能感知注入代理工作流。 对于Claude Code：使用钩子在修改的文件中标记与性能相关的模式。对于其他工具：在提示中包含”验证算法复杂度”作为标准指令。目标不是自动优化，而是意识提升：在当前不会提出”这够快吗？”这个问题的工作流中，让这个问题浮出水面。

盲区不在AI本身。盲区在于性能基础设施的缺失。行业已构建的每一个标准质量关卡都验证正确性，没有一个验证效率。这一差距在AI之前就存在。AI将其变成了一个占生产代码26.9%的问题。

来源