FeatureLoop 附录：协议、指标与完整结果

附录 D 实验细节与协议实现

D.1 被评估的模型

我们评估 12 个模型：在三种工作流的每一种之下，对 61 项任务各给出一个结果，合计为 2,196 次模型–任务–工作流运行。表 16 记录了用来界定这一 2026 年 7 月至 9 月队列的发布版本或重大更新，并链接到相应的提供方文档。

表 16：被评估的模型及其发布或更新日期。日期采用年–月–日或年–月。所链接的页面用来标识该模型。DeepSeek V4 的日期指的是早先预览版之后的更新。

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

D.2 工具框架与运行时配置

智能体接口会影响仓库任务上的表现（Yang 等人，2024a）。因此，我们对全部 2,196 次模型–任务–场景运行，都使用 Claude Code 2.1.74 作为共享的编码工具框架。工作区在各次模型–任务–协议运行之间相互隔离。在每一次渐进式运行内部，可写仓库与对话在整个开发过程中一直保留。活动上下文窗口为 200,000 个词元，并在模型路由所支持的地方采用高推理力度。采样使用每一个提供方的默认温度与 top-p。表 17 记录了这一共享配置。

表 17：执行设置。一次回应可以包含多次模型调用与多次工具交互。

一次完整运行包含反复的模型调用以及上下文的复用。上下文上限适用于一次调用的活动上下文；智能体词元把该次运行中每一次调用所报告的输入词元与输出词元累加起来。

反馈质量与修订所用的计算量会影响代码修复的结果（Olausson 等人，2024）。为使这些方面标准化，完成反馈由一个固定的 Hy4-Preview 模型生成，采用高推理力度，生成上限为 20,000 个词元。它的输入包含当前的公开检查状态，以及该任务从失败检查到可观察问题的预定义映射。它至多选择两条观察，并把它们表述成一份自然语言报告。这一上限使每份报告中的信息量在各模型之间保持可比，并把下一次修订集中到一小集具体问题之上。两次修订这一上限另行约束每个阶段上的重复干预。可执行检查决定正确性；生成器把由此产生的证据向智能体表达出来。

D.3 协议执行

图 15：完整协议的信息流。绿色路径承载需求披露；橙色路径承载对已观察到的失败所作的报告。跳过分支绕过已经实现的行为。

三种工作流都以同一个最终需求集合 $Q_{K}$ 为目标，并从同一个任务检查点出发，但每一次都是独立的执行。它们的信息日程以及采取行动的机会并不相同。

控制器在开篇请求中供给完整的最终规格说明。智能体在一次编码会话之内探索、编辑并测试该仓库。评估器随后检查最终工作区。这一工作流衡量的是在事先信息完整的条件下所作出的实现。

控制器首先供给 $u_{0}$。在智能体作出回应之后，它对照下一个需求状态来评估那个持久的工作区。已经满足的需求不必再作披露。否则，它供给相应的演化消息，并让智能体修改同一个工作区。该过程沿着固定的状态序列继续下去。先前已经陈述的行为若失败，并不会产生完成消息，但那些需求在此后全部累积检查中仍然处于有效状态。

这一协议加入了状态内部的纠正。一次回应之后，评估器检查当前有效的累积需求。当它获得可归因的失败证据时，反馈生成器把至多两条预定义观察表达成一条面向用户的消息。智能体在该状态上至多可以把工作区修订两次。然后控制器继续向前推进，即便需求仍然未被满足。更早的失败在智能体的工作区里仍然是有效的义务。

控制器执行下列步骤：

• 1. 交付初始请求，并取得一次编码智能体的回应。
• 2. 执行当前的累积检查。在演化加完成中，一次被观察到的失败可以触发一条完成消息以及另一次回应，直至两次修订的上限。
• 3. 在每一次后续披露之前，检查当前工作区。跳过已经满足的行为；否则披露该状态所缺少的需求信息。
• 4. 取得智能体的回应，应用该协议的状态内检查与纠正规则，并前进到下一个状态。
• 5. 在最终状态及其被允许的修订之后，评估每一个有效的需求组以及仓库基线。

生成器使用预定义观察来描述公开行为，例如一条命令返回了错误结果，或者一个界面在某个指定动作之后失败。隐藏的测试标识符、断言、参考代码与未来需求都停留在消息上下文之外。经过两次纠正性修订之后，控制器进入下一个需求阶段，并在累积检查中保留全部更早的需求。

D.4 信息与回应机会

表 18：信息与回应机会。在所有协议中，更早的需求仍然是最终的验收义务。

每一次比较都跨独立执行的工作流匹配同一模型与同一任务。配对变化概括完整的开发过程；直接恢复衡量的是在一次执行之内被修复的失败状态。

D.5 观察可得性与反馈事件核算

交互账本与恢复所用的分母描述的是不同的单位。这 732 次演化加完成运行包含 2,484 条状态记录，以及 1,723 条已交付的完成消息。在这些状态之中，有 733 个具有被观察到的首次回应失败，因而有资格成为恢复机会。一个机会可以收到一条消息，也可以收到两条消息。表 19 把这些计数核对到一起。

表 19：演化加完成的汇总反馈事件核算。恢复资格要求存在被观察到的首次回应失败；消息计数记录的是交付本身，不论是否具备资格。

这 187 个带有反馈、但首次回应观察不可得的状态，贡献了 352 条消息。控制器为这些状态记录分类型的执行结果，或套件是否可得的结果。消息核算保留已经交付的交互，而恢复分析使用的是那 733 次被观察到的失败。终局评分使用每一次运行的最终执行结果。

特定于指标的投影选出每一个定义所要求的那些观察。反馈折损智能体完成度使用 2,390 个具有可用评分观察的状态。状态结果摘要包含 151 条未观察记录和 140 个延迟解决；恢复另外还要求存在被观察到的首次回应失败，从而选出 113 次修复。附录 E.6 定义恢复的单位，附录 E.3 给出反馈折损智能体完成度的覆盖规则。

附录 E 指标与统计分析

全部指标都使用冻结的任务定义以及所记录的轨迹。一次模型–任务–协议运行是终局评估的单位。一个需求状态是控制器交互与直接恢复的单位。需求组是局部正确性与语义分析的单位。这 207 个状态包含 209 个组，而这 146 个后续状态包含 147 个后续组。

E.1 最终任务完成

对于模型 $m$、任务 $\tau$ 与协议 $p$，令 $W_{T}$ 为最终工作区，$b(W_{T})$ 为其基线结果，$Z_{g}(W_{T})$ 为需求组 $g$ 的结果。于是

$$ \operatorname{StrictPass}_{m,p}(\tau)=\mathbf{1}\!\left[b(W_{T})=1\ \land\ \bigwedge_{g\in Q_{K}}Z_{g}(W_{T})=1\right]. \tag{7} $$

该模型的严格通过率是在 61 项任务上的均值。部分完成是

$$ \operatorname{NodeCredit}_{m,p}(\tau)=\frac{1}{|Q_{K}|}\sum_{g\in Q_{K}}Z_{g}(W_{T}). \tag{8} $$

节点得分给予每一项任务相等的权重，并保留部分需求完成。严格通过还要求每一个组以及仓库基线都通过。

译注：本块以公式为主，汉字集中在说明而不在符号本身。式（7）的严格通过要求最终工作区的基线结果为通过，并且最终需求集合中的每一个需求组结果都为通过，指示函数在两个条件同时成立时取一、否则取零。式（8）的节点得分把各需求组的结果相加后，再除以需求组的个数，因此每一项任务权重相同，未全部通过的任务仍保留部分得分。符号依次表示模型、任务、协议、最终工作区、基线结果、需求组结果与最终需求集合。

E.2 初始交付

初始交付的结果使用那些带有渐进式请求、并且没有纠正性反馈的运行。令 $\operatorname{precheck}_{i}$ 表示某个状态在披露前检查时通过，令 $\operatorname{firstpass}_{i}$ 表示它在该状态上、于智能体的首次回应之后通过。初始可用交付是

$$ \operatorname{IUD}(\tau)=\mathbf{1}[\operatorname{precheck}_{1}\lor\operatorname{firstpass}_{1}]. \tag{9} $$

它衡量的是初始评估窗口之内的可用性，其中包括预先已经存在的行为。初始完整交付还要求每一个后续状态都在其自身被披露之前即已通过：

$$ \operatorname{ICD}(\tau)=\operatorname{StrictPass}(\tau)\,\operatorname{IUD}(\tau)\prod_{i=2}^{K}\mathbf{1}[\operatorname{precheck}_{i}]. \tag{10} $$

初始完整交付衡量的是：初始交付是否已经满足该任务被冻结下来的最终需求。主动覆盖使用附录 C.6 中的先验信息队列另行分析。

E.3 反馈折损的智能体完成度

反馈折损智能体完成度衡量完整交付，同时对那些在额外跟进之后才完成的需求赋予较少的得分。令 $I_{\tau}$ 包含其所需观察为可用的那些状态。对于 $i\in I_{\tau}$，定义

$$ q_{i}= \begin{cases} 1, & \text{披露前通过，或初始状态的首次回应通过},\\ 0.5, & \text{后续状态在披露之后立即通过},\\ 0.5\times 0.4^{r}, & \text{在完成修订 }r\in\{1,2\}\text{ 之后通过},\\ 0, & \text{在该状态被允许的回应之内没有通过}. \end{cases} \tag{11} $$

任务得分是

$$ \operatorname{FDAC}(\tau)=\operatorname{StrictPass}(\tau)\left(\prod_{i\in I_{\tau}}q_{i}\right)^{1/|I_{\tau}|}. \tag{12} $$

几何平均防止一项长任务仅仅因为乘上了更多因子就被折损，但仍然使任何一个未解决的可用状态具有决定作用。模型层面的反馈折损智能体完成度对任务得分取平均。状态的划分在评估之前就已经固定。

状态权重编码了该基准的这样一种偏好，即更早完成、并且跟进更少：在后续披露之前或在初始回应之后为 1，在后续披露之后为 0.5，并且每一次纠正性修订再附加一个 0.4 的因子。同一修订规则使一个在第一次修订上被修复的初始状态获得 0.2 的权重。一个在其局部预算内未能解决的状态保持权重为零，即便后来的工作修复了它。因此，反馈折损智能体完成度既纳入及时的中间交付，也纳入最终正确性。

对于一条成功的三状态轨迹，$q=(1,0.5,0.5)$ 给出反馈折损智能体完成度 $0.25^{1/3}\approx 0.630$。在第二状态上作一次纠正，会把它变为 $q=(1,0.2,0.5)$，反馈折损智能体完成度为 $0.1^{1/3}\approx 0.464$。若错过该状态的预算，则得到 $q=(1,0,0.5)$，得分为零。

在同时具有两类反馈的 732 次运行中，2,484 个状态里有 2,390 个具有反馈折损智能体完成度所要求的观察。几何平均使用这些状态，并且每一次运行里至少有一个可用状态。表 20 报告逐模型的覆盖。

表 20：反馈折损智能体完成度的状态覆盖。每一个模型都有 207 个可能的需求状态。

反馈折损智能体完成度的软版本用节点得分替换严格的最终成功，并使用算术平均：

$$ \operatorname{FDAC\text{-}soft}(\tau)=\operatorname{NodeCredit}(\tau)\frac{1}{|I_{\tau}|}\sum_{i\in I_{\tau}}q_{i}. \tag{13} $$

这一部分得分诊断把节点得分与状态权重的算术平均结合起来。

E.4 配对协议转换

对于两种协议，按模型与任务来匹配运行。一对结果为双方都通过、一次挽救（仅第二种协议通过）、一次损失（仅第一种通过），或双方都失败。净率差为

$$ \Delta_{b-a}=\frac{n_{\mathrm{rescue}}-n_{\mathrm{loss}}}{N_{\mathrm{paired}}}. \tag{14} $$

该对照在匹配的模型–任务对上比较独立执行的工作流。直接修复与代码回退根据运行内部的执行记录另行测量。

E.5 单项需求完成与累积正确性

对于在状态 $i$ 被激活的后续组 $g$，局部成功是 $Z_{g}(W)$，累积成功是同一工作区上的 $P_{i}(W)=\mathbf{1}[\forall h\in Q_{i},Z_{h}(W)=1]$。事件 $Z_{g}(W)=1,\ P_{i}(W)=0$ 标识的是当前需求已经完成，同时至少还有另一项已陈述需求尚未完成。完整交付还要求基线得到保持：$C_{i}(W)=b(W)\,P_{i}(W)$。

披露前覆盖检查某个组在其请求之前是否已经通过。首次回应完成在智能体的首次回应之后评估已经披露的组。局部修复@2 与前缀闭合@2 使用同样的 455 个失败的后续组实例：该组在首次回应之后失败，并且它所在的阶段收到了完成反馈。局部修复@2 计入该组在两次修订之内随后通过的情形。前缀闭合@2 要求迄今已经引入的每一个组都在同一窗口之内通过。被选中的反馈观察针对的是该阶段；单个失败的组可能仍然未被提及。

这 147 个后续组映射到 146 个状态。Slidev 的 Q002 引入两个组，因此它的执行结果向每个组贡献一条观察。消息计数、词元总量与状态恢复对这一共享状态只计数一次。每一个指标都使用其定义所要求的、带有观察的记录。

E.6 反馈恢复与需求保持

一个状态层面的恢复机会，要求在该状态上存在被观察到的首次回应失败，以及完成反馈。恢复@$r$ 是此类机会中、其被记录的累积状态检查在 $r$ 次修订之内通过所占的比例。恢复@1 与恢复@2 共用分母 733，其中包括在预算之内未能恢复的机会。已交付消息的完整集合更大，并且包含没有可归因的首次回应观察的回退事件（附录 D.5）。

回归测试检查变更是否保持既有行为（Yoo 与 Harman，2012）。观察到的保持使用那些至少通过一次、并且在更后的需求阶段上有检查的组。当一个组在每一次此类观察上以及在最终检查点上都仍然通过时，该组计为被保持。

状态演化可靠性@ $r$ 沿着 685 条在每一个后续状态上都具有可用结果的轨迹，衡量累积状态的完成。当每一个累积状态都在至多 $r$ 次修订之后、于其被记录的检查点通过时，该次运行被计入。三个检查点复用同一条轨迹。停滞的回应在累积检查之下不增加进展；回退事件记录的是早先通过的行为在后来一次回应之后失败。

E.7 条件性主动覆盖

主动契约覆盖把披露前的精确覆盖限制于满足 $N\geq 2$、$X\geq 2$ 且 $C\leq 1$ 的组：对需求本身与精确行为有充分的先验支持，同时过早承诺的风险有限。标签使用每个组被披露之前紧接可得的信息。微观主动契约覆盖把可用的模型–组观察汇总到一起；宏观主动契约覆盖对组内比率取平均。严格队列由 14 项任务中的 16 个组组成。

E.8 交互与词元成本

$N_{E}$ 与 $N_{C}$ 计数初始请求之后已交付的演化消息与完成消息。智能体词元把被评估智能体在各次模型调用上所报告的输入词元与输出词元相加。缓存输入的用量被分开记录，以避免重复计数。这些测量刻画的是开发路径上的交互，以及求解器一侧的词元成本。

令 $\mathcal{R}_{p}$ 为协议 $p$ 下具有已报告遥测的运行，$T_{\tau}$ 为它们的词元总数。我们报告

$$ \operatorname{MeanTokens}_{p}=\frac{\sum_{\tau\in\mathcal{R}_{p}}T_{\tau}}{|\mathcal{R}_{p}|},\qquad\operatorname{TokensPerSuccess}_{p}=\frac{\sum_{\tau\in\mathcal{R}_{p}}T_{\tau}}{\sum_{\tau\in\mathcal{R}_{p}}\operatorname{StrictPass}(\tau)}. \tag{15} $$

每次成功的词元包含失败运行的成本。已报告遥测的子集包含：事先规格说明 726/732 次运行，渐进式需求 732/732 次运行，以及带纠正的渐进式需求 731/732 次运行；它们的成功分母分别为 295、378 与 468。平均词元的比较使用这些已报告子集。因此，47.2% 这一增幅衡量的是每次运行已报告智能体词元之均值的变化。

E.9 不确定性与舍入

逐模型的任务完成区间使用 95% 威尔逊区间（Wilson，1927）。汇总比率与工作流差异使用 10,000 个按仓库聚类的自助样本，种子为 20260923。重抽样保留属于被选中仓库的全部任务与模型结果，用以衡量对仓库样本的敏感程度。语义子组的敏感度另行报告。百分比与差值由整数计数或未舍入得分计算得出，然后再为展示而舍入。

附录 F 完整结果与模型层面分析

正文按实现难度、模型差异与资源使用对结果进行分组。本附录保留相应的事件计数、完整分布、条件总体以及不确定性估计。表 21 提供一张从各项主要发现通向其计数单位的直接映射。

表 21：主要发现背后的观察总体。一个需求组可以出现在若干次模型运行之中；一个状态可以包含若干个组。每一行都使用它自己被显式定义的观察集合。

F.1 最终任务完成

最终任务完成以及通向该结果的路径，揭示出不同的模型画像（表 22）。GPT-6 Astra 录得最高的完成率与经过反馈折损的得分。GPT-5.6 Sol、Kimi K3、DeepSeek V4 Flash 与 DeepSeek V4.1 Flash 各完成 43 项任务，而它们的路径得分把沿途所需要的指导区分开来。

表 22：完整结果，按反馈折损智能体完成度排序。模型的严格通过单元格给出成功数/61 以及百分比（汇总分母为 732）；节点得分、反馈折损智能体完成度及其软版本为百分比。每一列中观察到的最佳模型值以粗体标出。

表 23 给出逐模型的 95% 威尔逊区间。汇总最终完成的、按仓库聚类的区间为：事先规格说明 $[29.9,\ 50.1]$，渐进式需求 $[41.0,\ 61.5]$，以及带纠正的渐进式需求 $[53.8,\ 72.8]$。

表 23：严格通过（%）的逐模型 95% 威尔逊区间。

部分完成也把在最终成功上打成平手的模型区分开来。在全部任务上取平均，DeepSeek V4.1 Flash 满足最终需求组的 86.5%，Kimi K3 满足 84.6%，相比之下 GPT-6 Astra 为 82.2%。Hy3 达到 50.1%。这些数值保留了那些达不到完整交付的运行上的进展。

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

F.2 失败归因协议

我们审阅了同时具有两类反馈的工作流中全部 263 次最终失败。审阅使用了请求、反馈、可见的智能体动作、工作区变更、回应层面的得分，以及最终执行证据。在一次穷尽的取证遍历中，每一次失败都接受一个主标签，用以标出能够解释后续结果的、最早得到支持的那一错误。独立得到支持的验证问题与修复问题接受次级标签。表 24 给出判定标准；证据记录把每一项决定链接到它的轨迹。

表 24：最终失败归因的主因分类。

次级标签捕捉的是：针对公开路径之替代物的验证、被继续携带向前的已知失败，以及在已经损坏的工作区上所作的进一步修补。赋值使用实现证据与执行证据，并借助工具调用与智能体回应，在轨迹中定位相关决定。

F.3 是什么导致最终失败

表 25 给出完整的主因分布。行为或应用编程接口不匹配、构建或运行时失败，以及没有到达面向用户路径的代码，合计占 196/263 次失败（74.5%）。构建、类型或运行时失败尤其严重：69 次之中有 65 次对最终需求组无一满足，而 70 次行为或应用编程接口不匹配之中有 58 次、57 次用户路径失败之中有 44 次保留了部分得分。

表 25：演化加完成之下、全部最终失败的主因。

次级标签把反复出现的修复障碍定位出来：263 次失败之中有 198 次省略了相关的公开路径检查，或者验证的是一个替代物；140 次把一个已知问题继续带向后面；59 次在恢复一个可工作版本之前继续打补丁。这些轨迹暴露出：一次运行可以继续对反馈作出回应，同时却让用户那个失败的行为保持不变。

按是否有任一模型解出这些任务来加以分开，可以把共同的局限与模型特有的局限区分开（表 26）。由部分模型解出的 38 项任务贡献 155 次失败，其中 147 次对所指派的原因具有直接的执行证据。没有任何模型解出的九项任务贡献 108 次失败；由于没有成功的同类运行可供使用，它们的归因依赖于请求、实现以及观察到的失败路径。表 27 表明这一区分为何重要：不一致的共享状态集中于没有任何模型解出的任务，而行为不匹配与构建失败更经常地把各个模型区分开。

表 26：演化加完成之下的任务分组。

表 27：按任务组划分的详细主因计数。

F.4 模型层面的失败画像

GPT-5.6 Sol、Kimi K3、DeepSeek V4 Flash 与 DeepSeek V4.1 Flash 各自在 61 项任务中的 43 项上成功。把它们最终失败任务的集合相交，剩下 10 项任务被这四个模型全部失败，因此它们成功任务集合的并集包含 $61-10=51$ 项任务。任务结果上的两两不一致范围是 6 到 14 项任务。这些计数由那张 263 行的最终失败标注表重新计算，每一次失败运行对应一条模型–任务条目。它们描述的是那些已经存在、被独立记录的运行之间的互补覆盖。

相等的最终成功率掩盖了彼此不同的失败集合。在完成 43/61 项任务的四个模型之中，在至少被一个模型解出的任务上，两两失败重叠从 12.5% 到 50.0%，中位数为 20.0%。图 7 与表 28 显示，是哪些实现问题构成了每个模型剩余的失败。

表 28：按模型分组的主因计数。“无 / 有”把没有任何模型解出的任务上的失败，与至少有一个模型解出的任务上的失败分开。

下列画像把表 28 与表 35 中的数值比较，连接到失败运行里所发现的实现路径。

剩余的失败涉及公开入口点的集成、精确的输入表示，以及不一致的共享状态。该模型具有最高的最终完成，并在其具备保持资格的子集中保全每一项需求。更广的事件记录中仍然包含两次回退，落在那个更窄的保持总体之外。因此，它剩余的失败涉及特定的端到端路径，而不是总体上没有能力实现所请求的行为。

若干不成功的轨迹考察了相关代码，却没有产生连接到公开接口的、可编译的实现。较强的最终得分，与一个阶段一旦失败之后较低的、被观察到的修复比例并存。这一画像把注意力引向从定位相关代码到验证一项可工作修复的过渡，而不是仅仅停留在仓库探索。

剩余的差距常常位于能够工作的内部逻辑，与暴露给用户的图表、输出表示或更早格式之间。它的 18 次最终失败之中有 15 次保留了部分需求得分。这些轨迹把不完整的公开行为，与一项完全不成功的实现区分开来。

失败轨迹包括对内部合并组件所作的检查，而当时线上端点仍在使用旧行为，也包括从未到达渲染的配置变更。尽管代码的其他地方有所进展，此类检查仍使公开失败保持原样。问题在于智能体验证的是哪一条执行路径，而不只是它是否调用了测试工具。

失败轨迹常常检查自定义示例、被显式注册的组件或辅助函数，而不是默认渲染器、命令或所要求的输出。频繁的工具使用因而产生的是关于一条替代执行路径的证据。这一模式与该模型在被观察到的失败阶段之中相对较高的恢复比例并存。

遗留的调用形式、时序界限、输出表示，以及对更早行为的变更，构成了剩余的兼容性差距。它的 18 次最终失败之中有 17 次保留部分得分，并且没有一次把构建或运行时失败作为主标签。它的画像不同于那些其变更经常使仓库无法执行的模型。

在有代表性的轨迹中，次序、更新时序、错误文本、命名与边界计算在反馈之后仍然不正确。行为或应用编程接口不匹配占它 21 次最终失败之中的十次。未解决的工作，位于原本相关的实现之内的那些精确公开需求。

有些运行在工作区已经停止工作之后，仍继续使用未经验证的接口，或继续添加功能。构建/运行时失败与断开的公开路径实现，各占八次最终失败。那些运行之中的持续活动，并没有解决阻碍所请求行为的那个问题。

轨迹包括部分的数据结构迁移，以及被猜出来的签名，其后是未能解决的编译器错误。23 次最终失败之中有 14 次没有满足任何一个最终需求组。因此，一次不完整的接口变更可以同时影响当前需求与后续开发，而不是停留为一处局部缺陷。

该模型相对较高的修复比例，与它对已经能够工作的需求所作的薄弱保持并存。附录 F.5 中的 NextChat 轨迹说明了这一对照：一次早期修复之后出现运行时错误，而该错误在后来的能力被添加之时仍然持续。对某些纠正作出有效回应，并不能保证被修复的实现在后来的编辑之中仍然可用。

有些运行在更早的命令、接口、计数或构建问题仍未解决之时添加新功能。自定义检查错过了实际的执行路径，使后续需求上的进展可以与一项尚未完成的更早义务并存。即使最新的变更看起来合理，累积起来的任务仍然不完整。

剩余的失败集中在：使用既有的仓库接口、维持一个可执行的工作区，以及经由预定的入口点把实现暴露出来。构建/运行时错误与公开路径的集成失败，占它 39 次失败运行之中的 27 次。反复的纠正常常在更精细的行为需求能够被验证之前，就遇到这些执行层面的障碍。

跨各个模型来看，这些轨迹区分出低干预开发的四项障碍：精确行为被留待未完成、功能与公开接口断开、修复在后来的编辑中丢失，以及损坏的执行路径被带入后续工作。这些障碍解释了为何终局完成、直接修复与保持，对同一个开发过程提供了彼此互补的视角。

F.5 随时间展开的失败案例

在 Qwen 3.8 Flash 的 1Panel 运行中，初始端点依赖于一个只由服务器引导过程初始化的全局验证器，因此在直接路由器的使用方式下失败。一次完成反馈修订把绑定与验证移入处理函数，恢复了第一状态，并使第二状态在其首次回应上即为正确；这项修复在最终检查点仍然有效。

GPT-6 Astra 把一个 Socket.IO 工作器对象当作进程标识符。该实现因此返回并比较了错误的公开数据模型，两项需求只完成一项，并且在两条完成反馈消息之后仍然未获解决。另外 11 个模型中有八个通过这项任务，表明在同一评估之下，这项任务可以被同类模型解出。执行轨迹把这次失败定位到公开表示的不匹配。

图 16：Grok 4.6 的 NextChat 轨迹。各列顺着相继的需求阶段排列；下方的轨道记录运行时状态。

Grok 4.6 在反馈之后恢复了第一个 NextChat 状态，随后在修订第二状态时引入了 message.content is not iterable。该错误在其余四个状态中一直持续，与此同时该次运行继续添加个人资料、启动、状态与主题路径，产生 15 次回退，最终得分为 1/6（图 16）。这条轨迹表明，持续的功能工作如何能够掩盖这样一个事实：面向用户的路径在早若干个状态之前就已经停止工作。

F.6 初始交付

初始可用性，以及与被冻结的最终需求之间的兼容性，是不同的结果。这些初始交付结果使用的是渐进式需求工作流。表 29 给出精确计数：按模型来看，初始状态在首次评估窗口内可用的运行占 63.9%–80.3%，而没有任何模型在超过 3.3% 的运行上已经满足最终功能。全部 14 次初始完整交付成功发生在两项任务上（ECharts 上九次模型成功，Typst 上五次）。至少包含一个后续信息组的任务，占 0/540 次初始完整交付成功。附录 C.6 刻画每一项后续需求可得的先验信息。

表 29：演化之下的初始可用交付与初始完整交付。每个模型有 61 次运行。

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

F.7 局部采纳与累积闭合

图 17：局部成功与完整的需求状态成功。新请求总体包含对后续信息组的 927 次首次回应；纠正总体包含 455 个失败的后续组机会。这两个总体并不相同，而每一行都把它自己的观察划分成互斥的结果。

表 30 把需求标签与执行结果结合起来。披露前通过检查某个后续组在其请求之前是否已经能够工作。首次回应的局部成功在该次回应之后检查那个组；累积成功检查迄今已经引入的全部分组。局部修复@2 计数的是：在一个收到完成反馈的阶段上，失败的组于两次修订之内被修复。前缀闭合@2 还要求此前引入的全部分组都通过。每一个比率都使用为其特定检查可得的观察。

这 147 个组映射到 146 个披露状态：Slidev 的 Q002 在一个状态中包含两个相关的组。每一个 Slidev 行指的是同一个被观察到的状态之内的不同需求组。

表 30：演化加完成之下，按语义队列划分的早期覆盖与首次回应结果。条目为成功数/机会数（百分比）。

表 31：两次修订之内的局部修复与累积闭合。两列在每一个队列内部使用同样的、被观察到的失败组机会。

先验信息把两类早期覆盖分开：严格主动队列中有 44/179 次评估通过，而后续信息队列中为 1/956。一旦一项需求被披露，仅仅实现它仍然可能让更早的工作停留在未完成。这种情况出现在后续信息队列里 717 次局部成功的首次回应中的 76 次，以及全部分组的 1,078 次中的 136 次。与此类似，91 次成功的单项修复中有 19 次在同一修订窗口内留下另一项已陈述需求未获满足。这些不完整的实现既包括从未通过的需求，也包括被后来的编辑所破坏的行为。

F.8 匹配的协议转换

图 18：在每一次比较的 732 个匹配模型–任务对上，最终结果的变化。条形区分新变为成功的运行与新变为不成功的运行；区间对仓库进行重抽样。每一次比较都使用这些完整工作流的独立执行。

完整到演化的工作流对照，对 DeepSeek V4 Flash 给出最大的净变化，对 Hy4-Preview 给出最小的净变化。演化到演化加完成的对照把这一模式在 Hy4-Preview 上反过来，并把自身最大的变化给到 Grok 4.6，而对 GPT-6 Astra 与 Hy3 改变很少。表 32 给出匹配计数；图 19 与图 20 展示完整的模型层面分解。

表 32：按模型划分的匹配协议转换。挽救/损失给出同样 61 项任务上的计数；净变化以百分点计。

在汇总层面上，以渐进式功能开发替换一次性的完整契约工作流，给出 $+11.3$ 个百分点的净变化，按仓库聚类的 95% 自助区间为 $[+6.1,\ +18.6]$。启用完成反馈工作流，其中包括失败证据与有限次修订，给出 $+12.4$ 个百分点的净变化，区间为 $[+8.3,\ +17.1]$（图 18）。

图 19：每个模型在 61 项任务上的配对完整 → 演化转换。条形计数失去的成功与被挽救的失败；右侧一列给出净百分点增益。

图 20：每个模型在 61 项任务上的配对演化 → 演化加完成转换。条形计数失去的成功与被挽救的失败；右侧一列给出净百分点增益。

在两条被独立执行的渐进式工作流之间被挽救的 119 个模型–任务对里，有 57 个在成功的那次运行中没有收到完成消息，有 54 个包含一次被观察到的同一状态恢复。配对表记录的是最终结果的变化；运行内部的恢复计数标识的是跟随失败反馈之后的修复。

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

F.9 按实现语言与软件形态划分的结果

表 33 报告主要的描述性分层：五个单语言切片，以及五个软件形态，后者至少有七项任务，并且至少来自三个仓库。每一次匹配的演化到演化加完成变化的点估计都为正，但 TypeScript 与浏览器的区间触及零。恢复、稳定性与词元使用有很大差异（表 34）。图 21 显示，服务具有最大的主要匹配增益，而浏览器最小。按仓库聚类的区间描述对所抽样的仓库混合构成的敏感度。

表 33：按主要语言与软件形态划分的最终完成。$n$ 是任务数，$r$ 是仓库数，每种协议的分母是 $12n$ 次运行。$\Delta$ 是配对的演化到演化加完成变化，以百分点计，并带有按仓库聚类的 95% 区间。

表 34：同一批主要分层在演化加完成下的诊断。恢复与状态演化可靠性的单元格给出成功数/合格机会数。词元是每次已报告运行的百万数；遥测报告的是可用次数/总运行次数。每个分层按一种属性对所抽样的任务分组。

那一项混合的 Go/TypeScript 任务、两项框架任务，以及一项嵌入式任务，以描述方式加以报告。它们的匹配变化分别为 $+66.7$、$0.0$ 与 $+41.7$ 个百分点，不附带推断区间。语言与形态的构成是稀疏的：42 个可能单元格中有 25 个为空，Rust 几乎全部是命令行，TypeScript 集中在浏览器与框架任务。这些分层描述的是所观察到的仓库、语言、软件形态与任务跨度的组合。

图 21：按实现语言与软件形态划分的、匹配的演化 → 演化加完成变化。区间使用按仓库聚类的自助样本；仅作描述的稀疏分层与主要切片分开列出。

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

F.10 完成反馈之后的恢复

恢复从一次失败的首次回应出发，并追问当前需求状态是否在它的两次纠正性修订之内通过。保持只在单项需求已经通过之后才开始，并追问它在后来被观察到的阶段以及最终检查上是否仍然正确。跨各个模型，有 642 个需求组实例既有一次通过观察，又有一次后续阶段观察。其中 569 个保持成功，73 个随后失败。因此，$569/642=88.6\%$ 是观察到的保持，$73/642=11.4\%$ 是与之互补的丢失率。这些实例是在模型运行中被评估的需求，而不是 642 项彼此不同的基准需求。

图 22：一次失败的首次回应之后的恢复。区段按第一次成功的修订来划分这 733 个被观察到的失败状态，未解决的状态单独显示。

图 23 显示，直接恢复在各模型之间有很大差异；表 35 既报告反馈转化，也报告分开的、组层面上的保持度量。Grok 4.6 与 DeepSeek V4 Flash 具有最高的恢复@2，而 GPT-5.6 Sol 尽管最终完成很强，其观察到的恢复比例却较低。每一个恢复率都使用该模型所遇到的失败状态。第二次修订为 Grok 4.6、DeepSeek V4 Flash 与 DeepSeek V4 Pro 各增加三次恢复，但对 Hy3、Qwen 3.8 Flash 或 GPT-6 Astra 一次也没有增加。

表 35：按模型划分的完成反馈转化与观察到的需求保持。恢复@1 与恢复@2 以反馈机会作为分母。保持只使用先前已经满足、并且至少有一次后续状态观察的需求组。

按仓库聚类的 95% 自助区间，恢复@1 为 $[7.5,\ 20.0]$，恢复@2 为 $[9.2,\ 23.5]$。

图 23：按模型划分的完成反馈恢复。条形显示第一次修订之后获得的修复，以及由第二次修订追加的修复；右侧各列给出恢复@2 与机会计数。

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

F.11 状态结果与用户反馈负担

在有渐进式请求、且没有纠正时，2,484 个需求状态中有 56.3% 在首次回应之后通过，3.5% 在披露之前已经满足，34.7% 仍然未解决，5.4% 在所记录的轨迹中未被观察。在有纠正性反馈时，59.5% 在首次回应上通过，5.6% 在一次修订之后通过，3.5% 已经满足，25.3% 仍然未解决，6.1% 未被观察。图 24 与图 25 显示这些结果如何随模型而变化。

图 24：演化之下的状态结果，每个模型有 207 个可能状态；汇总把全部 12 个模型聚合在一起。斜线阴影表示未观察记录。

图 25：演化加完成之下的状态结果，每个模型有 207 个可能状态；汇总把全部 12 个模型聚合在一起。“反馈之后”表示延迟解决；斜线阴影表示未观察记录。

表 36：演化加完成之下的反馈与路径诊断。$N_{E}$ 与 $N_{C}$ 是每项任务已交付消息的均值。被触发的运行收到完成反馈；成功是它们最终的严格通过率。停滞是没有观察到累积进展的回应所占的百分比；回退是事件，而不是彼此不同的任务。

演化反馈的计数变化很小，因为各模型遵循相同的任务状态，而完成反馈的负担取决于当前工作区（表 36）。Hy3 每项任务收到 4.03 条完成反馈消息，并在 67.1% 的回应上没有可观察的进展。GPT-5.6 Sol 与 Kimi K3 每项任务收到的完成消息少于 1.9 条，而 DeepSeek V4 Flash 在那些触发完成反馈的任务之中具有最高的最终成功率。Grok 4.6 把较大的协议之间净增益，与 35 次运行内部的回退事件结合在一起。

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

F.12 区分模型的任务

在三种被独立执行的工作流之中，被全部模型失败的任务数量下降，而被部分、但并非全部模型解出的任务数量上升（表 37）。当两类反馈都可用时，有 38 项任务被部分、但并非全部模型解出，有九项仍然未被全部 12 个模型解出。

表 37：在每种协议之下，有多少任务被全部模型、部分模型或没有任何模型解出。

F.13 在后续状态中保持行为

表 38 在每个阶段内部的三个时点上检查同样这 685 次合格运行：首次回应之后、第一次纠正之后，以及第二次之后。在每一个检查点上，轨迹可靠性都要求全部累积阶段都已经在它们各自的修订序列中、于该时点之前通过。GPT-5.6 Sol 与 GPT-6 Astra 具有最高的、被观察到的状态演化可靠性@0。Hy4-Preview 获得最大的第一次修订增益，而 DeepSeek V4 Pro、GLM 5.3 Flash 与 GPT-5.6 Sol 从第二次修订中获得的增益最多。图 26 使第二次修订那一份很小、且依赖于模型的贡献变得可见。

表 38：同一些运行在首次回应、第一次修订与第二次修订检查点上的轨迹可靠性。“运行数”计数的是在每一个后续状态上都有可用结果的轨迹。

图 26：当两类反馈都可用时，按模型划分的轨迹可靠性。区段给出合格运行中这样一部分所占的比例：它们在该阶段之内，于首次回应、第一次纠正性修订或第二次纠正性修订之前，完成每一个累积阶段。

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

F.14 词元成本

表 39 报告每次已报告运行的平均词元，以及每次成功的最终交付所用的词元。GPT-6 Astra 与 Grok 4.6 在每次成功交付上使用的词元，显著少于其余模型。当两类反馈都可用时，GLM 5.3 的词元成本最高，而 Hy3 较低的平均运行成本被它较低的完成率所抵消。Grok 4.6 与 GLM 5.3 的状态演化可靠性@2 相近（67.9% 与 67.2%），然而 GLM 5.3 在每次成功交付上消耗的词元大约是前者的七倍（图 27）。

表 39：词元消耗以百万为单位，只使用具有已报告遥测的运行。每种协议都把每次已报告运行的平均词元，与每一次已报告的严格通过成功所对应的已报告词元总量分开，其中包含花在失败上的词元。覆盖情况为：完整协议 726/732，演化协议 732/732，演化加完成协议 731/732。每一列之内所报告的最低词元成本以粗体标出。

图 27：全部模型上，状态演化可靠性@2 相对于每次成功最终交付的已报告词元。成本包含来自已报告失败运行的词元；虚线标出观察到的帕累托前沿。

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

F.15 条件性主动覆盖与模型画像

在严格的合格队列上，微观主动契约覆盖为 44/179（24.6%）。先在 16 个组的每一组内部取平均，得到宏观主动契约覆盖 22.9%。排除混合语义的条目之后，微观结果变为 24/131（18.3%），宏观主动契约覆盖变为 16.7%。因此，这一诊断对队列的构成是敏感的。重实现子集所覆盖的，是需求与仓库的一种规模不大、且彼此有别的混合。

表 40 以实际分母报告完整的模型画像。每个模型只有 14 至 16 个可用的严格主动机会。这些画像把早期实现，与新信息到来之后的完成、单项修复，以及对全部已陈述需求的成功完成区分开来。修复的分母由每个模型所失败的那些组构成。

表 40：演化加完成之下的条件模型画像。每个条目都是成功数/机会数。采纳使用后续信息队列；修复与闭合使用全部合格的、失败的后续组。百分比可以直接由所显示的计数恢复出来。

宏观主动契约覆盖分析给出按组自助的区间：严格队列为 22.9%［8.9，38.5］，不含混合条目时为 16.7%［5.6，29.9］。这些区间概括的是对所抽样需求组的敏感度。重抽样的单位是需求组，使用的是已经最终确定的标签。

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