FeatureLoop：在演化需求下评测编码智能体

FeatureLoop：在演化需求下评测编码智能体

使用编码智能体进行软件开发时，过程常常始于一条粗略的请求，用户在试用实现之后再加以细化。只看最终正确性，并不能刻画这一过程所需要的反复指导。我们提出 FeatureLoop，这是一项包含 61 个经人工审阅的任务的基准，任务来自 34 个仓库，覆盖五种主要编程语言和七种软件形态。每项任务都在一个持久工作区中遵循同一个开发目标，并经历演化反馈与完成反馈：演化反馈会新增或澄清需求，完成反馈则报告已陈述需求的失败。累积的可执行检查跟踪新行为、修复，以及对更早功能的保持。我们评测了 12 个前沿模型，发现最强的模型在同时具备两类反馈时完成 72.1% 的任务。然而跨模型来看，所观察到的失败阶段中，只有 15.4% 能在两次纠正性修订之内恢复。进一步的分析揭示了不完整的修复、回归，以及各模型在反馈使用和词元效率上的特定差异，从而指出通向可靠、低干预开发的障碍。

1 引言

编码智能体把仓库检查和代码编辑（Yang 等人，2024a）与沙箱环境中的命令执行（Wang 等人，2025）结合起来。真实用户的记录显示出持续的开发，其中伴随反复的纠正和失败报告（Baumann 等人，2026）。初始请求也可能省略实现所需要的信息（Vijayvargiya 等人，2026）。因此，把开篇请求委托出去，仍然给用户留下进一步的工作：试用实现、解释额外需求，以及报告错误。把这些报告变成可以工作的代码，仍然是另一项挑战，因为修复能否成功取决于反馈的质量（Olausson 等人，2024）。实践中的问题是：一个智能体需要多少反复指导，才能把一条初始请求变成完整且可以工作的实现？

图 1：一段 Excalidraw 交互摘录。画布展示相继出现的实现；褪色的形状标出拖动之前的位置。

图 1 说明了回到编码智能体面前的两个理由。在 Grow 菜单能够创建相互连接的形状之后，用户要求连接器在拖动期间重新布线。这改变了软件应当做的事情。一旦已经提出重新布线的请求，一份“连接器仍停在旧位置”的报告所指出的，便是尚未完成的实现工作。我们把第一种干预称为演化反馈，把第二种称为完成反馈。在这两者之中，进展都必须累积：如果下一次编辑破坏了子形状的创建，或丢失了它的绑定，那么仅仅造出一条正确的连接器是不够的。在变更之后重新检查更早的行为，正是回归测试的目的（Yoo 与 Harman，2012）。

已有基准确立了这一评测的若干部分。可执行任务覆盖仓库议题解决（Jimenez 等人，2024）、复杂功能实现（Zhou 等人，2026）、技术性终端工作流（Merrill 等人，2026），以及漏洞复现（Wang 等人，2026b）。交互式评测衡量对用户请求和纠正的响应（Wu 等人，2026），而顺序评测则在持续修改之后检查更早的需求（Shen 等人，2026）。对话式代码生成进一步表明，解决更多问题与用更少轮次解决问题是彼此不同的结果（Han 等人，2025）。我们关注的是这些要求如何相互作用：当用户增加需求或报告失败时，下一次修订是否改善了完整实现，以及还需要多少进一步的指导？

我们提出 FeatureLoop，以使这条开发路径变得可以度量。每项任务都从一个面向用户的开发目标出发，自初始请求起，对同一仓库实现作相继的细化。后续请求规定它的能力、约束和交互，而每一次修订都必须保留已经确立的需求。可执行检查判定哪些后续需求仍然需要被请求，哪些已陈述需求需要纠正，以及更早的功能是否仍然正确。由此得到的记录，把对最新请求的成功与对迄今所请求的一切的成功分开。它也把最终交付，与一条反复把不完整或已损坏的实现留给用户的开发路径分开。

FeatureLoop 包含来自 34 个仓库的 61 项任务，覆盖五种主要编程语言和七种软件形态。它的构建把公开的开发请求连接到分阶段的、可执行的验收标准。测试与参考实现由彼此独立的人员编写，每个阶段都同时检查新增行为以及对更早需求的保持，人工审阅者在智能体试运行之前和之后都检查任务质量。由此得到的任务具有明确的用户目标、可行的实现，以及需求级别的证据，范围涵盖命令行工具、服务、交互式应用和库。因此，同一个反馈循环可以在广泛的软件工程设置中接受评测。

我们用三种方式评测 12 个前沿模型：预先给出全部需求、只有渐进式请求，以及渐进式请求再加上纠正性反馈。结果暴露出三种相互补充的弱点。第一，模型的最终成功率并不能说明它需要多少纠正。第二，失败报告很少产生完整的修复：所观察到的失败状态中，只有 15.4% 在两次修订之内恢复。第三，局部成功并不能保证可靠的累积进展；即便是成功的单项修复，也有 20.9% 的情形仍使其他已陈述需求停留在未完成状态。模型级分析进一步把对纠正的响应能力、对可用行为的保持以及资源使用区分开来。这些差异指出，持续的用户干预在哪些地方仍然必要。

我们的贡献有三项：

• 我们提出一种对迭代式仓库开发的可执行评测，它把需求演化与纠正性反馈连接到累积正确性和用户指导。

• 我们构建了 FeatureLoop，这是一套经过质量审阅的基准，包含来自 34 个仓库的 61 项多阶段任务，覆盖五种主要编程语言和七种软件形态，并在整个开发过程中保留验收检查。

• 我们评测了 12 个前沿模型，指出在完整修复和面向用户的验证上的共同缺口，以及在保持、失败模式和词元效率上的模型特定差异。

2 FeatureLoop

译注：本节标题保留基准专名 FeatureLoop，不另作意译。

2.1 任务表述

一项 FeatureLoop 任务在一个既有仓库之内开发一个面向用户的目标。初始请求确立方向；后续请求规定进一步的能力、约束和交互，从而细化目标软件。所有阶段都建立在同一份实现之上，每一次修订都必须满足迄今已经累积的需求。

设 \(W_{0}\) 为初始仓库。一个需求组把放在一起评测的相关行为收集起来，例如创建一个子形状并绑定它的连接器。这些组构成一个有向无环图（DAG），其中一条边 \(g\to h\) 表示 \(h\) 依赖于 \(g\)。我们把该图展开为一条固定的阶段序列，这条序列尊重图中的依赖关系。在阶段 \(i\)，新引入的组是 \(A_{i}\)，需求状态 \(Q_{i}\) 包含迄今已经引入的全部分组：

| | Q 1 = A 1 , Q i + 1 = Q i ∪ A i + 1 , Q 1 ⊂ ⋯ ⊂ Q K . Q_{1}=A_{1},\qquad Q_{i+1}=Q_{i}\cup A_{i+1},\qquad Q_{1}\subset\cdots\subset Q_{K}. | | (1) |

| --- | --- | --- | --- |

译注：式（1）表示，第一阶段的需求状态等于第一批需求组；此后每一阶段都把新引入的需求组并入已有状态；因此需求状态从第一阶段起严格扩张，直到最终阶段。

每个阶段都至少增加一个组。每一个更早的组都会一直作为任务的一部分保留下来，直到最终阶段 \(K\)。

设 \(Z_{g}(W)\) 表示工作区 \(W\) 中的实现是否通过组 \(g\) 的检查。设 \(b(W)\) 表示它是否通过基线测试套件，该套件检查的是任务开始之前原本可以工作的仓库行为。我们把所请求的功能与基线分开评测：

| | P i ( W ) = 𝟏 [ ∀ g ∈ Q i , Z g ( W ) = 1 ] , C i ( W ) = b ( W ) P i ( W ) . P_{i}(W)=\mathbf{1}[\forall g\in Q_{i},\ Z_{g}(W)=1],\qquad C_{i}(W)=b(W)P_{i}(W). | | (2) |

| --- | --- | --- | --- |

译注：式（2）表示，若需求状态中的每一个组都通过检查，则请求功能指标取一；完整指标还要再乘上基线是否通过。

这里，\(P_{i}=1\) 表示迄今引入的全部需求都通过；\(C_{i}=1\) 还要求原有的仓库行为通过。例如，若创建其绑定子形状仍然失败，那么把一条连接器正确地重新布线就只是局部进展。回归测试检查修改是否保持了已经确立的行为（Yoo 与 Harman，2012）。在这里，被保留下来的义务既包括原始基线，也包括任务期间引入的每一项需求。

演化反馈从下一批需求组 \(A_{i+1}\) 中引入尚缺的行为。完成反馈报告已经处于 \(Q_{i}\) 之中的需求的某一次失败，并要求智能体修复其实现。在发送一条更晚的请求之前，评测器检查相应行为是否已经可以工作，并略去已经满足的部分。修订随后更新现有的工作区。这使得反馈依赖于智能体的进展，同时使开发目标保持固定。

最终的任务成功要求每一项被请求的行为以及基线都通过：

| | Success ⁡ ( W T ) = C K ​ ( W T ) , \operatorname{Success}(W_{T})=C_{K}(W_{T}), | | (3) |

| --- | --- | --- | --- |

译注：式（3）表示，最终工作区上的任务成功，等于最终阶段那个同时包含全部需求与基线的指标。

其中 \(W_{T}\) 是最终工作区。中间检查识别出立即完成的需求、在反馈之后得到修复的需求、被留下未完成的需求，或被更晚的编辑破坏的需求。附录 B.1 定义了所存储的任务组成部分以及修订的索引方式。完整的六阶段 Excalidraw 走查出现在附录 B.2。

2.2 三种开发场景

图 2：三种开发场景。绿色：新请求；橙色：纠正。

我们比较用户可以用来委托同一项开发任务的三种方式（图 2）。它们的差别在于用户何时提供需求，以及用户是否返回来报告实现上的问题。

用户在一开始就规定整个目标，并要求智能体在一次编码会话中把它交付出来。智能体检查仓库、编辑代码，并使用自己的工具检查结果。该场景评测的是：当用户已经描述了所需要的一切时，实现做得如何。

用户从一条初始请求开始，并随着开发的推进引入进一步的需求。每一条新请求都给智能体另一次机会去扩展现有实现。用户提供额外的需求，但把调试留给智能体。该场景评测智能体能否借助它自己的验证来整合每一条请求，并保持更早的功能。

用户还会报告在当前实现中遇到的问题。智能体可以在收到下一条需求之前回应这些报告。这是主要的评测场景：用户继续细化任务并检查已经交付的软件，而基准衡量智能体使用两类反馈的有效程度。

为了使任务保持可比，所有场景都从同一个仓库检查点出发，并使用相同的最终需求和验收检查。两个渐进式场景还共享需求的顺序。在该顺序之内，当前实现决定哪些请求仍然需要，以及哪些失败可以被报告。附录 D.3 中的图 15 给出完整的协议图，其中包括披露检查和纠正性反馈的路径。

2.3 基准构建

图 3：构建阶段及其产出的制品。

构建必须把一个现实的开发目标，连接到可运行的阶段，以及忠实测试所请求行为的验收检查。更强的测试能够暴露较弱评测套件所遗漏的错误（Liu 等人，2023），这促使我们既检查新行为，也检查它与更早需求的交互。我们的流水线把智能体辅助的编写、可执行验证和人工审阅结合起来。图 3 给出一幅简化的概览；完整的作者—批评者工作流，包括信息边界和修订路径，出现在附录 B.3 的图 10 中。

每个候选都从一个精确的仓库检查点开始，并至少有两个完整的公开议题支持同一个面向用户的方向。这些议题锚定动机和初始范围；仓库中的证据支持与之兼容的扩展。我们把这个共享目标组织成需求组的依赖有向无环图，然后选择一条阶段序列，这条序列尊重该图，并顺着那些促使细节进一步展开的使用场景前进。一份行为规格为每个组记录动作或输入、预期结果、被保持的行为，以及公开的观察点。相应的用户请求按顺序引入该行为。附录 B.3.1 至附录 B.3.5 描述来源选择、需求规划、环境搭建和请求编写。

为了在不同实现之间评测功能，测试编写者从行为规格导出可执行检查。这些检查覆盖每一个需求组、每个阶段所累积的需求，以及仓库基线。在构建参考解之前，我们在此后的公开仓库历史上运行已经冻结的检查，并移除那些完整目标已经被实现的候选。这样做针对的是公开可得的解，同时保留原始的仓库上下文。公开解的可得性是评测污染的一个来源（Badertdinov 等人，2025）；筛查此后的历史，就所记录的仓库窗口处理了这一顾虑。附录 B.3.6 与附录 B.3.7 规定测试的构建以及所检索的历史。

一位独立的参考实现编写者实现同一份规格，为每个阶段产生一个可以工作的检查点 \(W_{i}^{}\)。测试编写者与参考实现编写者使用分开的工作区和审阅会话，因此这些测试评估的是共享规格，而不是从一份参考补丁抄录而来。对于每一个新组 \(g\in A_{i}\)，它的检查必须在 \(W_{i-1}^{}\) 上失败，并在 \(W_{i}^{*}\) 以及所有更晚的检查点上通过。每一个检查点还必须通过基线和更早的需求。这些检查既确立一个有意义的增量，也确立它与累积实现的持续兼容。被选中的候选还额外使用有效的替代实现，以及故意构造的错误变体，以检查验收和失败检测。附录 B.3.8 与附录 B.3.9 给出构建规则和验证规则。

人工审阅者首先检查需求和请求，运行每一个参考阶段，并核实测试所强制执行的是预期的、用户可见的行为。通过这一审阅的候选，随后由四个编码模型来实现。审阅者检查由此产生的对话、编辑和执行证据，以识别出参考解之外的实现所暴露的任务缺陷。缺陷被退回到负责的构建阶段，以便纠正并重新验证。最终验收保留 61 项任务。附录 B.3.10 规定人工审阅，附录 C.1 记录候选数量、试运行模型以及选择结果。

2.4 数据集特征

这 61 项任务覆盖 34 个仓库和五种主要编程语言：Go、Rust、JavaScript、TypeScript 和 Python。它们包括命令行工具、终端界面、浏览器应用、服务、库、框架和嵌入式软件（图 4（a））。这一覆盖包括后端服务、开发者工具、交互式软件和可复用组件，每一类都通过其公开命令、应用程序接口或用户界面来评测。附录 C.2 与附录 C.5 给出完整的构成。

（a）

（b）

图 4：数据集构成与累积的实现规模。（a）按编程语言和软件形态统计的任务数量，其中包括一项 Go 与 TypeScript 混合的任务。（b）累积测试组数、非空白测试行数，以及参考代码新增行数加删除行数的均值和四分位距。阶段 \(i\) 计入能够到达该阶段的任务；最后一列计入全部 61 项任务。

任务包含二到八个阶段。每个阶段都增加行为，而这些行为必须在实现发生变化时继续可以工作。在全部 61 项任务中，活动测试组的平均数量从第一阶段的 1.15 增长到最终阶段的 4.11（图 4（b））。因此，每一个新阶段都扩大了必须在同一份实现中一起工作的行为集合。附录 C.4 报告阶段数量、测试规模和参考编辑量；附录 C.3 定义计数单位。

这 61 项任务包含 147 个后续需求组。其中有 42 个沿着更早请求所支持的方向延续。对这 42 个组中的 16 个而言，更早的信息还约束了确切的预期行为，并且提早实现它所带来的风险有限。另有 85 个依赖于新的用户信息，或依赖于更早交互中无法获得的某项发现。规格不足的请求可能省略那些会实质改变正确实现的信息（Vijayvargiya 等人，2026）。因此我们区分两种能力：在还需要另一条请求之前，就完成已有充分支持的行为；以及一旦用户把新需求提供出来，就正确地把它们纳入实现。语义标注流程、示例和全部标签见附录 C.6。

3 实验设置与评测

我们在三种开发场景之下，于全部 61 项任务上评测 12 个前沿模型，共得到 2,196 次运行。所有模型都使用 Claude Code 作为共享的编码驾驭框架。渐进式运行保留工作区和对话；纠正场景使用一个固定的反馈生成器，并允许每个阶段至多有两次纠正性修订。每一次修订都是一次完整的编码智能体响应，并带有它自己的工具调用。附录 D 给出模型、运行时配置和执行规则。

StrictPass 衡量全部需求以及仓库基线的最终完成情况。我们报告新需求消息数和纠正消息数（\(N_{E}\)、\(N_{C}\)），以及反馈折减的智能体完成度（FDAC）。FDAC 按照中间状态在何时变为正确，对成功交付进行折减；若某个状态在其响应预算之内仍然没有完成，则记为零。中间检查把新需求的接纳、完整的修复，以及对更早成功的保持区分开来。Agent Tokens 衡量所报告的输入词元和输出词元。除非另有说明，轨迹分析同时使用两类反馈。附录 E 提供指标定义、观察窗口、词元核算以及不确定性估计。

4 结果

译注：本块数字、模型名、仓库名与原文表逐行对应，不删行。列名按表13：N为需要是否可预见，X为确切行为是否已决定，G为先前交付有多不完整，W为新工作流有多远，D为是什么揭示了该需要，B为实现工作量，C为猜测风险，T为演化类型。演化类型中契约补全、接口扩展、工作流扩展、组合、兼容、稳健性、状态生命周期、错误可观测性、策略偏好、正交能力分别对应 CC、IE、WE、CO、CP、RO、SL、EO、PP、OC。置信度高、中、低对应 H、M、L。

4.1 干预改变的是模型之间的比较，而不只是平均分数

在一开始就提供整份规格，并不会产生最高的完成率。跨模型来看，最终成功率从预先给出规格（Full）时的 40.3%，上升到渐进式请求（Evo）时的 51.6%，再上升到渐进式请求加上纠正（Evo+Comp）时的 64.1%。目标与最终检查是相同的，但得以专注于一条新需求、或回看一次失败的机会并不相同。因此，完整规格下的表现并不能充分刻画迭代式开发。

表 1：主要结果，按 Evo+Comp 路径上的 FDAC 排序。StrictPass 与 FDAC 都是百分数；\(N_{E}\) 与 \(N_{C}\) 是每项任务的平均消息数，其中包括失败的运行。每个模型都在相同的 61 项任务上接受评测。所观察到的最佳结果数值，以及最低的纠正次数，以粗体标出。

译注：表中 Full、Evo 与 Evo+Comp 是三种开发场景的原文简称。StrictPass 是最终严格通过率，FDAC 是反馈折减的智能体完成度。\(N_{E}\) 是演化消息的平均条数，\(N_{C}\) 是完成反馈消息的平均条数。向上的箭头表示数值越高越好。Pooled 一行是十二个模型合并之后的结果，并不是另一个模型的名称。粗体沿用原文对最佳观测值和最低纠正次数的标示，提取文本时粗体格式可能已经丢失，数值本身保持原表。

启用纠正之后，GPT-6 Astra 与 Hy3 各自只提高 3.3 个百分点。对 GPT-6 Astra 而言，这是因为在没有纠正时成功率已经很高；对 Hy3 而言，这伴随着两种设置下都很低的成功率（表 1）。工作流上的一点点增益本身，并不能把“对干预的需要有限”与“尽管给予了干预却未能取得有用进展”区分开来。模型对干预类型的响应也不相同：DeepSeek V4 Flash 从分阶段请求中获益最多，而 Grok 4.6 从启用了纠正的工作流中获益最多。附录 F.8 把这些结果上的变化，与单次运行内部的直接修复分开。

共享的需求序列使各模型产生的新请求数量彼此相近，而纠正消息则从每项任务不到两条，到大约四条不等。即便是并列达到 43 次成功交付的那四个模型，所得到的反馈折减分数也不相同。因此，最终成功彼此吻合，并不意味着用户的参与程度或中间完成的及时性也彼此吻合。附录 F.11 在报告消息条数的同时，也报告停滞的状态和发生回归的状态。

4.2 局部进展常常无法产生完整且持久的修复

我们首先考察那些引入了任务更早时候无法获得之信息的需求。在所观察到的情形中，智能体有 77.3% 在第一次响应时就实现了新请求的行为。然而，其中一些局部成功的响应，仍然把更早的需求留在未完成状态。困难并不只是理解最新的那条请求：新行为必须与用户已经要求过的一切共存。附录 F.7 把局部成功与完整的需求状态成功分开。

我们接下来跟随那些在第一次响应之后未通过检查、并且收到了纠正性反馈的阶段。其中只有 15.4% 在两次被允许的修订之内变为完全正确。此外，修好单独的一项需求并不总是足够：在成功的单项修复中，有 20.9% 仍然使另一项已经陈述的需求未能满足。更早的工作可能一直没有完成，或者被随后的一次编辑破坏。因此，相关的停止条件是活动需求的完整集合，而不是最新症状的消失。附录 F.10 给出状态一级的恢复，附录 F.7 给出单项修复的分解。

为了考察保持情况，我们继续检查那些已经通过、并且在更晚的阶段中再次被观察到的需求。在这些先前可以工作的需求中，有 11.4% 在随后的某次检查中失败。在 NextChat 的例子里，一次早期修复之后出现了运行时错误，而这一错误在进一步的能力被添加进来时仍然持续存在。因此，持续的功能开发可能把一条已经损坏的执行路径掩盖起来，而不是把它修复。该案例出现在附录 F.5；完整的留存计数和观察条件见表 35。合在一起，这些发现为智能体定位出三项彼此分开的要求：实现新的行为，恢复全部已经陈述的行为，并在进一步的编辑之中保持该结果。

4.3 相近的最终分数掩盖了不同的恢复与保持画像

图 5：两类反馈之下的模型级恢复与留存。恢复使用的是失败状态；留存使用的是先前已经通过、并且此后仍有观察的需求。

两个 DeepSeek Flash 模型具有相同的最终完成率，但 V4 所修复的失败状态比例，大约是 V4.1 所修复比例的两倍。与之相对，V4.1 保持了更大一部分它先前可以工作的需求（图 5）。Grok 4.6 呈现出另一种不平衡：它拥有最大的、由启用纠正所带来的工作流增益，以及最高的、被观察到的直接恢复比例，然而被观察到的留存却是最低的。这些画像解释了，为什么只看最终成功，并不能揭示一个模型是经由稳定的进展、还是经由反复的修复才到达它的结果。每一个条件比率都跟随该模型实际遇到的失败，或实际遇到的先前通过的需求；附录 F.10 提供完整的模型级计数。

各自完成 43 项任务的四个模型合在一起覆盖 51 项任务。这意味着，尽管它们的汇总结果彼此并列，一项任务仍可能对其中一个模型失败，而对另一个模型成功。这一并集衡量的是它们各自独立记录的运行所覆盖的范围。它们的失败画像识别出不同的障碍：与 Kimi K3 相比，GPT-5.6 Sol 更经常留下构建失败或运行时失败；而 DeepSeek V4.1 Flash 剩余的失败集中在行为兼容性上，而不是集中在损坏的构建上。附录 F.4 报告任务重叠的计算以及全部模型画像。因此，要改进迭代式编码，就需要识别对某一个模型而言究竟是实现的哪一个阶段失败了，而不是把排行榜上的一个分数当成均匀划一的能力。

4.4 验证常常错过用户的实际执行路径

图 6：每一个任务集合的最终失败内部的首要诊断。“其他”把其余的诊断归并在一起。

我们检查每一次以不成功告终的运行中的请求、编辑、动作和执行证据。在这些失败之中，有 75.3% 是智能体要么省略了一次相关的用户路径检查，要么改为去验证一个辅助例程、一个桩或一个代理。例如，一个内部合并例程可以通过一项定制测试，而那个正在运行的端点却继续使用旧的行为。这解释了表面上合理的代码和反复的工具使用，如何能够与一份尚未解决的用户报告并存：智能体所作的检查，并没有去行使正在被评测的那个行为。附录 F.2 记录了这一编码流程，附录 F.5 追溯了有代表性的例子。

在没有任何一个受评模型能够完成的任务上，组件之间的状态不一致占最终失败的 32.4%；相比之下，在有部分模型能够解决的任务上，这一比例是 2.6%（图 6）。这些轨迹涉及注册表、存储、解析器、渲染器或生命周期处理器，它们对同一个状态并不能取得一致。一个局部补丁即使它自己的辅助例程可以工作，也可能把那种不一致原样留在那里。因此，共同的困难比写下某一个缺失的函数更广：变更必须到达公开的入口点，并且在消费这一变更的各个组件之间保持一致。

图 7：每一个模型的最终失败内部的首要诊断；单元格中的数值是百分数。

构建问题和运行时问题构成 Hy3 与 Grok 4.6 的失败中的很大份额，而 GLM 5.3 更经常产生一份可以运行、但行为或应用程序接口细节并不正确的实现（图 7）。DeepSeek V4.1 Flash 没有任何一次最终失败被主要归因于损坏的构建，但它仍然错过遗留的调用形式、时序界限或输出表示。这些是不同的验证需要：恢复可执行性，检查确切的公开行为，以及保持兼容性。附录 F.4 中的模型级案例指出了相应的命令、接口和状态迁移。附录 F.9 报告这些模式如何分布在所抽样的语言和软件形态之上。

4.5 相近的交付质量可能伴随非常不同的词元成本

图 8：两类反馈之下的模型级完成情况与词元开销。开销包括花费在失败运行上的词元。

启用纠正使每次运行平均报告的词元增加 47.2%。因此，更为成功的最终交付，伴随着开发期间显著更大的词元支出。为了在已经交付的结果这一层面上比较模型，我们把全部已经记录的运行，包括失败的运行，都记到它们的成功交付之上。Grok 4.6 与 GLM 5.3 达到相近的最终完成率，但后者在每一次成功交付上所使用的词元大约是前者的 7.1 倍（图 8）。相近的结果质量因而可能出现在非常不同的资源支出上。

这一成本差异必须与开发画像放在一起阅读。Grok 较低的词元使用，与它对更早行为较弱的保持同时存在；GLM 5.3 更大的支出，在若干轨迹中仍然留下确切的接口需求没有解决。较低的词元总量，或较高的最终分数，各自都不能单独描述可靠的、低干预的开发。附录 F.14 提供完整的词元核算，附录 F.13 则报告整条中间轨迹的可靠性。

5 范围与局限

FeatureLoop 聚焦于既有仓库之中那些累积的、可执行的需求，并且每项任务只有一条预先定义的延续。我们使用固定的反馈策略，并且每个阶段至多两次纠正性修订。这些发现所刻画的，是在这些交互设置之下被抽样的任务；人类之间的协作可能涉及不同的需求变化和不同的反馈模式。正确性通过可执行检查来评估，而这些检查的覆盖范围以已经规定的行为为界。

6 结论

我们提出了 FeatureLoop，它是一个面向演化需求下迭代软件开发的基准。每项任务都在一个持久工作区中遵循一个开发目标，把新的请求和纠正性反馈与累积的可执行检查结合起来。我们对 12 个前沿模型的评测表明，交互式工作流提高了最终完成情况，而不完整的修复和回归仍然是反复出现的障碍。最终成功率相近的模型，在它们对纠正的依赖、对可以工作的功能的保持，以及词元支出上，也彼此不同。通过同时评测最终结果和跨越各次修订的进展，FeatureLoop 提供了一个试验台，用以推进那些需要更少反复用户指导的可靠编码智能体。

参考文献

• Badertdinov 等人（2025）。作者姓名按原文保留：I. Badertdinov, A. Golubev, M. Nekrashevich, A. Shevtsov, S. Karasik, A. Andriushchenko, M. Trofimova, D. Litvintseva, and B. Yangel。中文题名：SWE-rebench：一条用于任务收集、并对软件工程智能体作去污染评测的自动化流水线。外部链接：2505.20411，链接。被正文引用的位置：§A.1节、§2.3节。

• Baumann 等人（2026）。作者姓名按原文保留：J. Baumann, V. Padmakumar, X. Li, J. Yang, D. Yang, and S. Koyejo。中文题名：SWE-chat：来自真实用户、处于野外环境中的编码智能体交互。外部链接：2604.20779，链接。被正文引用的位置：§1节。

• Chen 等人（2023）。作者姓名按原文保留：X. Chen, M. Lin, N. Schärli, and D. Zhou。中文题名：教导大语言模型进行自我调试。外部链接：2304.05128，链接。被正文引用的位置：§A.3节。

• Han 等人（2025）。作者姓名按原文保留：H. Han, S. Hwang, R. Samdani, and Y. He。中文题名：ConvCodeWorld：在可复现的反馈环境中评测对话式代码生成。外部链接：2502.19852，链接。被正文引用的位置：§A.2节、§1节。

• Jain 等人（2025）。作者姓名按原文保留：N. Jain, J. Singh, M. Shetty, L. Zheng, K. Sen, and I. Stoica。中文题名：R2E-Gym：为扩展开源权重的软件工程智能体而设的过程化环境与混合验证器。外部链接：2504.07164，链接。被正文引用的位置：§A.1节。

• Jimenez 等人（2024）。作者姓名按原文保留：C. E. Jimenez, J. Yang, A. Wettig, S. Yao, K. Pei, O. Press, and K. Narasimhan。中文题名：SWE-bench：语言模型能否解决真实世界中的 GitHub 议题。外部链接：2310.06770，链接。被正文引用的位置：§A.1节、§1节。

• Le 等人（2026）。作者姓名按原文保留：T. Le, M. V. T. Thai, D. N. Manh, H. P. Nhat, and N. D. Q. Bui。中文题名：SWE-EVO：在长程软件演化场景中评测编码智能体。外部链接：2512.18470，链接。被正文引用的位置：§A.2节。

• Li 等人（2026）。作者姓名按原文保留：H. Li, Z. Fang, R. Feng, Y. Zhao, J. Liu, P. Gao, H. Ye, D. Lin, Q. Lin, S. Rajmohan, and D. Zhang。中文题名：LoopsBench：编码智能体评测中从驾驭工程走向循环工程。外部链接：2608.00267，链接。被正文引用的位置：§A.2节。

• Liu 等人（2023）。作者姓名按原文保留：J. Liu, C. S. Xia, Y. Wang, and L. Zhang。中文题名：由 ChatGPT 生成的代码真的正确吗？对大语言模型代码生成的严格评测。外部链接：2305.01210，链接。被正文引用的位置：§A.1节、§B.3.9节、§2.3节。

• Madaan 等人（2023）。作者姓名按原文保留：A. Madaan, N. Tandon, P. Gupta, S. Hallinan, L. Gao, S. Wiegreffe, U. Alon, N. Dziri, S. Prabhumoye, Y. Yang, S. Gupta, B. P. Majumder, K. Hermann, S. Welleck, A. Yazdanbakhsh, and P. Clark。中文题名：Self-Refine：借助自我反馈进行的迭代精炼。外部链接：2303.17651，链接。被正文引用的位置：§A.3节。

• Merrill 等人（2026）。作者姓名按原文保留：M. A. Merrill, A. G. Shaw, N. Carlini, B. Li, H. Raj, I. Bercovich, L. Shi, J. Y. Shin, T. Walshe, E. K. Buchanan, J. Shen, G. Ye, H. Lin, J. Poulos, M. Wang, M. Nezhurina, J. Jitsev, D. Lu, O. M. Mastromichalakis, Z. Xu, Z. Chen, Y. Liu, R. Zhang, L. L. Chen, A. Kashyap, J. Uslu, J. Li, J. Wu, M. Yan, S. Bian, V. Sharma, K. Sun, S. Dillmann, A. Anand, A. Lanpouthakoun, B. Koopah, C. Hu, E. Guha, G. H. S. Dreiman, J. Zhu, K. Krauth, L. Zhong, N. Muennighoff, R. Amanfu, S. Tan, S. Pimpalgaonkar, T. Aggarwal, X. Lin, X. Lan, X. Zhao, Y. Liang, Y. Wang, Z. Wang, C. Zhou, D. Heineman, H. Liu, H. Trivedi, J. Yang, J. Lin, M. Shetty, M. Yang, N. Omi, N. Raoof, S. Li, T. Y. Zhuo, W. Lin, Y. Dai, Y. Wang, W. Chai, S. Zhou, D. Wahdany, Z. She, J. Hu, Z. Dong, Y. Zhu, S. Cui, A. Saiyed, A. Kolbeinsson, J. Hu, C. M. Rytting, R. Marten, Y. Wang, A. Dimakis, A. Konwinski, and L. Schmidt。中文题名：Terminal-Bench：在命令行界面中困难且现实的任务上评测智能体。外部链接：2601.11868，链接。被正文引用的位置：§A.1节、§1节。

• Miserendino 等人（2025）。作者姓名按原文保留：S. Miserendino, M. Wang, T. Patwardhan, and J. Heidecke。中文题名：SWE-Lancer：前沿大语言模型能否从真实世界的自由职业软件工程中赚取一百万美元。外部链接：2502.12115，链接。被正文引用的位置：§A.1节。

• Mündler 等人（2025）。作者姓名按原文保留：N. Mündler, M. N. Müller, J. He, and M. Vechev。中文题名：SWT-Bench：用代码智能体测试并验证真实世界中的缺陷修复。外部链接：2406.12952，链接。被正文引用的位置：§A.1节、§B.3.9节。

• Olausson 等人（2024）。作者姓名按原文保留：T. X. Olausson, J. P. Inala, C. Wang, J. Gao, and A. Solar-Lezama。中文题名：自我修复是代码生成的一颗银弹吗？外部链接：2306.09896，链接。被正文引用的位置：§A.3节、§D.2节、§1节。

• Orlanski 等人（2026）。作者姓名按原文保留：G. Orlanski, D. Roy, A. Yun, C. Shin, A. Gu, A. Ge, D. Adila, N. Roberts, F. Sala, and A. Albarghouthi。中文题名：SlopCodeBench：评测编码智能体在长程迭代任务中如何退化。外部链接：2603.24755，链接。被正文引用的位置：§A.2节。

• Pan 等人（2025）。作者姓名按原文保留：J. Pan, X. Wang, G. Neubig, N. Jaitly, H. Ji, A. Suhr, and Y. Zhang。中文题名：借助 SWE-Gym 训练软件工程智能体与验证器。外部链接：2412.21139，链接。被正文引用的位置：§A.1节。

• Peng 等人（2026）。作者姓名按原文保留：Z. Peng, D. Huang, C. Zhang, C. Xu, C. Xiao, S. Hong, D. Lo, L. Qiu, X. Cao, J. He, and Y. Cao。中文题名：ICAE-Bench：把编码智能体作为交互式项目构建者来加以评测。外部链接：2607.21217，链接。被正文引用的位置：§A.2节。

• Raghavendra 等人（2026）。作者姓名按原文保留：M. Raghavendra, A. Gunjal, A. Sabharwal, and Y. He。中文题名：SWE-INTERACT：把软件工程基准重新设想为用户驱动的长程编码会话。外部链接：2606.30573，链接。被正文引用的位置：§A.2节。

• Rashid 等人（2025）。作者姓名按原文保留：M. S. Rashid, C. Bock, Y. Zhuang, A. Buchholz, T. Esler, S. Valentin, L. Franceschi, M. Wistuba, P. T. Sivaprasad, W. J. Kim, A. Deoras, G. Zappella, and L. Callot。中文题名：SWE-PolyBench：面向编码智能体仓库级评测的多语言基准。外部链接：2504.08703，链接。被正文引用的位置：§A.1节。

• Segura 等人（2016）。作者姓名按原文保留：S. Segura, G. Fraser, A. B. Sanchez, and A. Ruiz-Cortés。中文题名：一项关于蜕变测试的综述。载体为《电气与电子工程师学会软件工程汇刊》第 42 卷第 9 期，第 805–824 页。外部链接：文档。被正文引用的位置：§B.5节。

• Shen 等人（2026）。作者姓名按原文保留：H. Shen, X. Chen, W. Xu, Y. Ma, L. Chen, and K. Li。中文题名：EvoCode-Bench：在多轮迭代交互中评测编码智能体。外部链接：2605.24110，链接。被正文引用的位置：§A.2节、§1节。

• Shinn 等人（2023）。作者姓名按原文保留：N. Shinn, F. Cassano, E. Berman, A. Gopinath, K. Narasimhan, and S. Yao。中文题名：Reflexion：带有言语强化学习的语言智能体。外部链接：2303.11366，链接。被正文引用的位置：§A.3节。

• Vijayvargiya 等人（2026）。作者姓名按原文保留：S. Vijayvargiya, X. Zhou, A. Yerukola, M. Sap, and G. Neubig。中文题名：Ambig-SWE：用以克服软件工程中规格不足问题的交互式智能体。外部链接：2502.13069，链接。被正文引用的位置：§A.2节、§1节、§2.4节。

• Wang 等人（2026a）。作者姓名按原文保留：X. Wang, L. Sun, Y. Zhu, S. Zhou, J. Liu, F. Chen, L. Qiu, X. Cao, X. Cai, L. Zhang, and Z. Mao。中文题名：Asuka-Bench：在规格不足的用户意图与多轮精炼上评测代码智能体。外部链接：2606.05920，链接。被正文引用的位置：§A.2节。

• Wang 等人（2025）。作者姓名按原文保留：X. Wang, B. Li, Y. Song, F. F. Xu, X. Tang, M. Zhuge, J. Pan, Y. Song, B. Li, J. Singh, H. H. Tran, F. Li, R. Ma, M. Zheng, B. Qian, Y. Shao, N. Muennighoff, Y. Zhang, B. Hui, J. Lin, R. Brennan, H. Peng, H. Ji, and G. Neubig。中文题名：OpenHands：一个面向作为通用智能体的人工智能软件开发者的开放平台。外部链接：2407.16741，链接。被正文引用的位置：§1节。

• Wang 等人（2026b）。作者姓名按原文保留：Z. Wang, T. Shi, J. He, M. Cai, J. Zhang, and D. Song。中文题名：CyberGym：大规模评测人工智能智能体的真实世界网络安全能力。外部链接：2506.02548，链接。被正文引用的位置：§A.1节、§1节。

• Wilson（1927）。作者姓名按原文保留：E. B. Wilson。中文题名：或然推断、继位律与统计推断。载体为《美国统计学会会刊》第 22 卷第 158 期，第 209–212 页。外部链接：文档，链接。被正文引用的位置：§E.9节。

• Wu 等人（2026）。作者姓名按原文保留：Y. Wu, Z. Zhao, S. Li, H. H. Lee, J. Zhu, S. Wu, T. Yu, S. Li, L. Zhang, X. Fan, and S. Li。中文题名：SWE-Together：在交互式用户会话中评测编码智能体。外部链接：2606.29957，链接。被正文引用的位置：§A.2节、§1节。

• Yan 等人（2026）。作者姓名按原文保留：L. Yan, X. Chen, and X. Zhang。中文题名：当规格逐渐浮现：评测长程编码智能体中的忠实性损失。外部链接：2603.17104，链接。被正文引用的位置：§A.2节。

• Yang 等人（2024a）。作者姓名按原文保留：J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press。中文题名：SWE-agent：智能体与计算机的接口使自动化软件工程成为可能。外部链接：2405.15793，链接。被正文引用的位置：§D.2节、§1节。

• Yang 等人（2024b）。作者姓名按原文保留：J. Yang, C. E. Jimenez, A. L. Zhang, K. Lieret, J. Yang, X. Wu, O. Press, N. Muennighoff, G. Synnaeve, K. R. Narasimhan, D. Yang, S. I. Wang, and O. Press。中文题名：SWE-bench Multimodal：人工智能系统能否泛化到可视化的软件领域。外部链接：2410.03859，链接。被正文引用的位置：§A.1节。

• Yang 等人（2025）。作者姓名按原文保留：J. Yang, K. Lieret, C. E. Jimenez, A. Wettig, K. Khandpur, Y. Zhang, B. Hui, O. Press, L. Schmidt, and D. Yang。中文题名：SWE-smith：为软件工程智能体扩大数据规模。外部链接：2504.21798，链接。被正文引用的位置：§A.1节。

• Yoo 与 Harman（2012）。作者姓名按原文保留：S. Yoo and M. Harman。中文题名：回归测试的最小化、选择与优先级排序：一项综述。载体为《软件测试、验证与可靠性》第 22 卷第 2 期，第 67–120 页，原文注明为英文。外部链接：文档，国际标准连续出版物号 ISSN 0960-0833。被正文引用的位置：§E.6节、§1节、§2.1节。

• Zan 等人（2025）。作者姓名按原文保留：D. Zan, Z. Huang, W. Liu, H. Chen, L. Zhang, S. Xin, L. Chen, Q. Liu, X. Zhong, A. Li, S. Liu, Y. Xiao, L. Chen, Y. Zhang, J. Su, T. Liu, R. Long, K. Shen, and L. Xiang。中文题名：Multi-SWE-bench：一个面向议题解决的多语言基准。外部链接：2504.02605，链接。被正文引用的位置：§A.1节。

• Zhan 等人（2026）。作者姓名按原文保留：Z. Zhan, S. Gao, R. Hu, and C. Gao。中文题名：SR-Eval：在需求逐步精炼的条件下评测大语言模型的代码生成。外部链接：2509.18808，链接。被正文引用的位置：§A.2节。

• Zhang 等人（2025a）。作者姓名按原文保留：L. Zhang, J. Yang, M. Yang, J. Yang, M. Chen, J. Zhang, Z. Cui, B. Hui, and J. Lin。中文题名：SWE-Flow：以测试驱动的方式合成软件工程数据。外部链接：2506.09003，链接。被正文引用的位置：§A.1节。

• Zhang 等人（2025b）。作者姓名按原文保留：L. Zhang, S. He, C. Zhang, Y. Kang, B. Li, C. Xie, J. Wang, M. Wang, Y. Huang, S. Fu, E. Nallipogu, Q. Lin, Y. Dang, S. Rajmohan, and D. Zhang。中文题名：SWE-bench 走向实况运行。外部链接：2505.23419，链接。被正文引用的位置：§A.1节。

• Zhou 等人（2026）。作者姓名按原文保留：Q. Zhou, J. Zhang, H. Wang, R. Hao, J. Wang, M. Han, Y. Yang, S. Wu, F. Pan, L. Fan, D. Tu, and Z. Zhang。中文题名：FeatureBench：面向复杂功能开发的智能体式编码评测。外部链接：2602.10975，链接。被正文引用的位置：§A.1节、§1节。