FeatureLoop 附录：相关工作与 Excalidraw 构建

附录 A 相关工作

A.1 可执行基准与任务构建

SWE-bench（Jimenez et al., 2024）评测现有仓库中针对问题的补丁。Multi-SWE-bench（Zan et al., 2025）与 SWE-PolyBench（Rashid et al., 2025）把仓库级评测扩展到多种语言，而 FeatureBench（Zhou et al., 2026）针对复杂功能实现。SWE-bench Multimodal（Yang et al., 2024b）纳入可视化软件领域，SWE-Lancer（Miserendino et al., 2025）把任务建立在付费自由职业工作之上。Terminal-Bench（Merrill et al., 2026）把评测拓宽到命令行环境中的困难技术任务。CyberGym（Wang et al., 2026b）通过执行所生成的概念验证输入来验证漏洞复现。这些基准把现实工作连接到可检查的结果。FeatureLoop 度量的是需求不断累积时通向某一结果的路径，并保留中间的实现、修正与保持证据。

SWE-Gym（Pan et al., 2025）为训练智能体与验证器提供可执行环境。R2E-Gym（Jain et al., 2025）把过程化环境与混合验证结合起来；SWE-smith（Yang et al., 2025）扩展基于仓库的训练任务；SWE-Flow（Zhang et al., 2025a）通过测试驱动的构建来合成任务。EvalPlus（Liu et al., 2023）展示了更强测试覆盖对代码评测的影响，而 SWT-Bench（Mündler et al., 2025）评测那些复现缺陷并验证修复的测试。FeatureLoop 独立构建测试与参考检查点，在相邻状态以及更后的状态上检查每一项新行为，并把可执行证据与人工评审结合起来。它的历史筛选补充了 SWE-bench-Live（Zhang et al., 2025b）与 SWE-rebench（Badertdinov et al., 2025）所使用的新任务收集。

A.2 交互与持续开发

表 2：密切相关基准中的交互与评测机制。累积检查把更早的需求保留为仍然有效的正确性义务。

表 2 对照各基准如何获得后续信息、如何检查不断演化的实现，以及如何度量交互。下面的定义区分信息获取、纠正性反馈与持续正确性。

澄清提供关于一个既定目标的缺失信息。新请求增加或改变所期望的行为。修正消息报告已经陈述的行为发生了失败。当面向用户的消息派生自对当前实现的行为检查时，我们称该反馈为以执行为依据的。这标识的是供给智能体的证据，与其最终输出是否由执行来评测相互分开。

累积评测把更早的、仍然有效的需求作为正确性义务继续向前携带。在 FeatureLoop 中，需求集合单调增长，因此每一个被引入的行为都保持有效。局部检查识别最新行为是否可用；累积检查要求所有有效组一起可用；基线套件另外检查被保留的仓库行为。

Ambig-SWE（Vijayvargiya et al., 2026）从仓库问题中移除信息，并让智能体向用户代理请求澄清。ICAE-Bench（Peng et al., 2026）从规格不足的产品请求出发，使用一个受约束的路由器，从一份固定的产品契约中揭示信息。二者都使信息获取成为智能体任务的一部分。在 FeatureLoop 中，控制器遍历一个固定的状态序列，并依照当前工作区中仍然缺失的行为来披露需求。

SWE-Interact（Raghavendra et al., 2026）使用一个能够检查仓库内容与变更的模拟器，从基准任务创建由用户驱动的会话。SWE-Together（Wu et al., 2026）根据真实会话证据与当前轨迹来为干预设置条件。它区分新请求与修正，报告 User Correction，并使用特定于任务的最终量规，配以一个能够收集执行证据的智能体裁判。FeatureLoop 把每一个需求组绑定到固定的可执行检查。这些检查既决定要披露的缺失信息，也决定要报告的有效失败；中间评测则记录单项需求的完成、全部已陈述需求的完成，以及仓库基线。

Asuka-Bench（Wang et al., 2026a）从一条规格不足的网页开发请求开始，通过浏览器交互检查所得界面，并把发现转换成供另一次修订使用的反馈。重复评测度量交互过程中的改进与修复。FeatureLoop 把评测设定扩展到现有仓库与多种软件形态，带有显式的累积需求状态，以及每个需求阶段内部的修正性修订。这些状态把每一条消息连接到新被请求的行为，或仍然未完成的行为。

EvoCode-Bench（Shen et al., 2026）在一个持久工作区中呈现扩展、修正、冲突与取代。它的验证器保留仍然有效的需求，它的参考前驱比较把单轮实现与持久执行分开。LoopsBench（Li et al., 2026）把工作组织成相互依赖的开发单元，其被激活的测试仍然是回归义务。FeatureLoop 把持续开发耦合到依赖于工作区的用户干预：已经实现的后续行为跳过披露，而失败的有效行为可以收到完成反馈。由此产生的轨迹记录直接修复，以及对更早成功的保持。

SR-Eval（Zhan et al., 2026）研究逐步的需求精炼。SlopCodeBench（Orlanski et al., 2026）考察迭代开发过程中的代码退化，而 SLUMP（Yan et al., 2026）研究规格逐渐浮现时的忠实性。SWE-EVO（Le et al., 2026）从项目发行说明构建多步骤、多文件的任务。在程序层面，ConvCodeWorld（Han et al., 2025）比较可复现的反馈环境，并把会话效率与总体任务完成区分开来。FeatureLoop 把一条不断累积的需求序列连接到依赖于状态的披露与修正，记录每一次响应是否完成有效需求，并保持更早的成功。

我们的预先工作流、渐进工作流与修正工作流，从同一个检查点瞄准同一份最终契约。每一个模型与任务的配对，都在全部三种工作流下独立执行。成对比较度量这些完整工作流之间最终结果的变化；直接恢复则在收到失败报告的那条轨迹内部单独度量。FDAC 在固定的折扣日程下汇总最终完成与中间及时性，而消息计数报告实际送达的干预次数。

A.3 反馈驱动的改进与修复

Self-Refine（Madaan et al., 2023）使用模型生成的反馈，迭代修订输出。Reflexion（Shinn et al., 2023）存储言语反馈，用以指导后来的尝试；Self-Debugging（Chen et al., 2023）把执行结果与对所生成代码的解释结合起来。Olausson et al.（2024）发现，自我修复的收益取决于反馈质量，以及为获得这些反馈所花费的计算。这些方法促使人们把反馈的使用当作一种可度量的能力。在 FeatureLoop 中，修复目标是累积的仓库状态：一次修正只有在其局部检查、累积检查或包含基线的检查所指定的层面上，才算成功。先前已经满足的行为，在后来的开发全程都保持可测试。

附录 B 构建细节与 Excalidraw 案例研究

B.1 从任务表述到所存储的任务记录

我们扩展第 2.1 节中的记号，用以标识每一次个别修订。令 W i , 0 W_{i,0} 为需求状态 i i 上第一个被评测的工作区：它或者是一个在披露之前就已经通过的工作区，或者是第一次响应的结果。令 W i , r W_{i,r} 为纠正性修订 r r 之后的工作区。任务记录固定完整的需求序列，评测器依照当前实现来投递请求与反馈。表 3 把形式对象映射到所存储的组成部分。

表 3：把任务表述映射到评测期间使用的、所存储的任务组成部分。

对于 i < K i<K ，令 A i + 1 A_{i+1} 表示由下一状态首次激活的那些组。冻结的任务记录允许控制器判定：在当前工作区中，两种用户干预是否仍然需要：

第一个指示符标识有效需求的失败，以及用于完成反馈的证据。第二个指示符标识仍然需要披露的后续组。控制器应用该协议的修订预算，并在保留更早义务的同时沿状态序列前进。已经实现的行为被跳过，部分满足的组则产生一条覆盖剩余行为的消息。因此，同一个开发目标可以随着智能体取得不同进展而需要不同的消息。附录 D.5 规定对不可用观察的处理。

B.2 完整的 Excalidraw 任务

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

#### B.2.1 来源与完整目标

图 1 中的案例是一项 FeatureLoop 任务，题为 Grow and restyle connected Excalidraw shapes。它锚定在公开的 Excalidraw 仓库、检查点 a2ec2889babf7d2295469c6d90ebe77fae57df84 以及任务修订 R003。它的来源记录汇合五条公开请求：更快地创建节点与树（#11508）、转换已有形状（#11585）、改进的箭头（#11283）、模糊效果（#11228），以及把形状用作裁剪蒙版（#11349）。

该情景把这些公开请求组合成一条图形编辑工作流：创建相互连接的节点，改变它们的类型与关系，并准备结果以便分享。完整目标是：从所选形状创建一个被绑定的子形状，在拖拽期间保持其连接器处于绑定状态并重新布线，就地转换形状并保留文本、样式与连接，以及在画布上和标准导出中组合模糊与裁剪。

图 9：完整的六阶段 Excalidraw 案例：相继的用户请求、说明性的代码编辑，以及累积的画布行为。

#### B.2.2 六个累积状态

这六个状态建立在同一份不断演化的实现之上（图 9）。表 4 列出每个状态上的新行为与累积义务。

表 4：Excalidraw 任务中的六个累积状态。

#### B.2.3 反馈与需求依赖

序列从 Grow 菜单（Q 1 Q_{1}）开始，随后是通过其动作创建的父子关系（Q 2 Q_{2}）。拖拽任一端点，使布线成为 Q 3 Q_{3} 中一项持续的几何义务。就地转换（Q 4 Q_{4}）保留标签、样式与绑定。模糊（Q 5 Q_{5}）与裁剪（Q 6 Q_{6}）增加取自来源请求的产品能力，序列化、导出与组合被纳入它们的验收需求。

这些转移只有在新揭示的行为仍然缺失时才产生演化反馈。完成反馈则停留在当前状态之内。例如，它可以报告：在 Q 2 Q_{2} 中一个子项只有一个被绑定的箭头端点，在 Q 3 Q_{3} 中拖拽之后布线仍留在旧位置，或者在 Q 5 Q_{5} 中模糊出现在画布上但没有出现在 SVG 导出中。该消息描述用户能够观察到的事项，而不暴露隐藏的测试标识符、内部函数或 Reference 实现。

在本案例中，每个状态恰好引入一个需求组；若把 G i G_{i} 写作在状态 i i 首次引入的组，则语义依赖形成下面的有向无环图，而六个用户可见阶段遵循一个尊重依赖的披露顺序：

直接边标识先决能力。即使没有直接边，保持义务也把更早的每一项有效行为向前携带。因此，尽管裁剪直接与子项创建及模糊相组合，Q 6 Q_{6} 上的成功也要求被保留的重新布线、转换以及基线行为。

#### B.2.4 可执行的行为证据

可执行检查覆盖用户可见工作流的六个部分：

• 1. 界面与可达性：Grow、子项与转换选项、效果以及裁剪控件，在适当的选择下出现，同时已有的菜单与属性面板行为仍然可用。

• 2. 场景状态：元素数量、类型、有限几何、图层顺序、被绑定的文本、箭头绑定、模糊属性以及裁剪蒙版状态，通过公开的场景表示来检查。

• 3. 交互：父项与子项的拖拽、方向改变、转换以及图层重排，行使随后的连接器、选择与蒙版行为。

• 4. 持久化：序列化再恢复的检查保留新属性与关系，而不含这些属性与关系的旧场景保留其先前语义。

• 5. 渲染与导出：交互画布、SVG 导出与画布导出行使布线、模糊、感知轮廓的裁剪，以及它们的组合。

• 6. 基线：已有的上下文菜单动作、手工创建的箭头、旧场景、框架裁剪，以及禁用效果时的渲染，仍然有效。

这些检查合在一起实现 Z g ​ ( W ) Z_{g}(W) 与 b ⁡ ( W ) b(W)，并把当前行为中的失败，与更早需求中的回归或初始仓库基线中的回归区分开来。

B.3 构建过程

图 10：完整的作者与批评者工作流。实线路径连接构建产物与执行阶段；虚线路径把评审发现返回以供修订。Test 视图与 Reference 视图标明它们各自分开的信息访问。

#### B.3.1 仓库来源

为把每一项任务锚定在真实的开发需要上，Source Author 在一个精确的仓库检查点上，选择至少两个支持同一面向用户方向的、完整的公开问题。来源记录保留问题文本、用户动机、相关的公开接口，以及支持性的仓库证据。一名独立评审者检查这些来源是否支持所提出的目标及其范围。后来的任务组成部分保留指向已被接受的来源的链接；附录 C.6 中的语义分析刻画每一个增量与更早工作的密切程度。

#### B.3.2 功能规格

为了给各个构建角色一个共享的开发目标，Feature Author 陈述完整的用户结果、验收需求、范围排除，以及由已被接受的来源与仓库所支持的精炼。一项需求可以直接来自一条公开请求，可以经由仓库证据沿同一方向得出，也可以描述已有的公开能力必须如何在同一条工作流中一起工作。这份规格固定该任务的完整目标；对话决定每一部分何时被揭示，而测试则分开编写。

#### B.3.3 需求序列

为把开发目标变成可执行的阶段，Trajectory Author 把相关行为分组为有向无环依赖图的节点。一条边记录组与组之间的先决关系。作者随后选择一条从 Q 1 Q_{1} 到 Q K Q_{K} 的、尊重这些依赖的阶段序列。每个状态记录在该处引入的组、仍然有效的全部组、直接依赖、必须保持正确的更早行为，以及暴露下一个缺口的使用情景。来源证据告知一种说得通的开发顺序；冻结的任务记录固定评测中实际使用的需求与披露序列。

#### B.3.4 可执行环境

为使每一个阶段都可复现，Environment Author 依据依赖锁定、构建配置以及仓库的持续集成记录，重建一个隔离环境。验证包括独立的干净运行、原始基线、公开入口点、离线执行、资源限制以及工作区完整性。这些运行使用同一份环境定义，但使用全新的可写工作区。这份定义决定任务如何可复现地执行，而冻结的来源与契约决定它的需求与行为。

#### B.3.5 冻结契约与反馈消息

Contract Author 把已被接受的来源、开发目标、需求序列与环境，合并成一份带版本的行为规格，称为契约 Γ \Gamma。这份规格对齐请求、测试与参考实现。每个组记录用户动作或输入、期望结果与禁止结果、必须保持正确的更早行为、允许的实现自由，以及一项可运行的检查。一名独立的 Contract Reviewer 检查该契约是否遵循来源、是否尊重状态依赖、能否通过公开接口被观察、是否把实现选择留开，以及能否在该环境中运行；确定性验证检查模式以及每一个被引用的文件或检查。

在 Γ \Gamma 被冻结之后，一名 Dialogue Author 产出 u 0 u_{0} 以及候选的演化消息。评审核验每一条消息只揭示其对应的状态，与其被记录的使用情景一致，并且不含组标识符、隐藏测试的措辞、Reference 信息或未来需求。完成反馈并不创建新的契约状态；它在运行时从当前有效组上失败的、用户可见的检查生成。

#### B.3.6 隔离的测试构建

为了独立于某个解来评测所规定的行为，Test Author 在一个分开的工作区中，依据冻结契约、初始仓库、环境以及完整状态图开展工作。它构建组检查与累积状态检查、最终套件、基线检查以及转移检查。一名 Test Critic 评审它们的行为覆盖、执行稳定性以及对公开接口的使用。Reference 代码与执行结果处于这两个角色的访问之外。

#### B.3.7 历史实现筛选

为排除已经发表过完整解的目标，我们在其检查点之后、所记录的截止之前，针对公开仓库历史筛选每一个候选。筛选使用冻结的 Test 包，并且先于 Reference 构建。冻结的行为检查在后来的提交或树上被重放：廉价的确定性检查穷尽覆盖相关历史，而浏览器执行这类昂贵检查则使用所记录的定向覆盖。其后来的公开历史通过了完整的、被记录的行为集合的候选被移除。筛选记录保留检查点、截止、被搜索的历史、所执行的检查、覆盖以及决定；评审者个别检查部分匹配与环境不兼容，以判定历史版本实现了哪些行为。

#### B.3.8 隔离的参考实现构建

为在每一个阶段确立一种可行实现，Reference Author 在一个隔离工作区中接收冻结契约、初始仓库、环境以及状态图。测试、夹具、断言以及 Test 结果处于其访问之外。从基线 W 0 ∗ = W 0 W_{0}^{}=W_{0} 出发，它在一个持久工作区中构建 W 1 ∗ , … , W K ∗ W_{1}^{},\ldots,W_{K}^{*}，每个检查点加入当前需求，同时保持更早的行为。一名具有同样受限信息的 Reference Critic 评审契约覆盖、仓库一致性、被保留的行为，以及检查点之间的边界。

#### B.3.9 跨状态验证

为核验每一个增量都在其预定阶段被实现，并在此后被保持，控制器针对 Reference 检查点运行冻结的 Test 套件。对于每一个 g ∈ A i g\in A_{i}，它要求

每个检查点 W i ∗ W_{i}^{*} 也必须通过完整的有效套件与仓库基线，并且每一个更后的检查点都必须保持该行为。被选中的候选接受两种额外探测：契约有效的替代方案测试对不同实现的接受，定向的故障变体测试对特定行为缺陷的拒绝。控制器执行所构建的变体，并把它们的结果与所要求的逐状态检查一并记录。额外检查可以揭示原始测试套件遗漏的缺陷（Liu et al., 2023）；把一项测试同时对着故障版本与已修正版本运行，也评估它是否区分预期行为（Mündler et al., 2025）。两类探测检查互补的错误：拒绝有效行为，以及接受带有已知缺陷的实现。

#### B.3.10 人工评审与任务接受

对于每一项被接受的任务，人工评审从任务语义开始。评审者检查 Contract 是否连贯、是否以来源为依据、能否通过公开接口观察，以及是否允许不同的有效实现，然后核验其 Summary 与 Evidence 记录表示的是同一行为。他们接着逐轮模拟评测。在每一轮，他们检查展示给智能体的对话，在对应的 Reference 检查点上运行项目，执行当前测试与被保留的测试，并沿公开观察点确认 Reference 行为与预期的用户语义相符。他们还检查相邻检查点上的 Test 断言，以核验每一条断言都遵循所要求的公开行为。

评审者记录最终的接受、修订或丢弃决定，并把发现绑定到负责的构建阶段。一项被请求的更改返回到该阶段，并重新运行每一个受影响的下游检查。每一项被接受的任务修订记录确切的 Source、Environment、Contract、Summary、Evidence、Dialogue、Test、历史筛选、Reference、Cross 以及人工评审产物，并保留更早的修订以便追溯。

B.4 角色与信息边界

表 5 分开每个构建角色可用的证据。关键边界在 Test 与 Reference 之间：二者接收相同的、已批准的任务语义与环境，但任何一方都不能检查另一方的私有实现或执行结果。

表 5：构建角色及其信息边界。

构建智能体把一个基础模型与一个工作区驾驭结合起来，该驾驭提供仓库搜索、文件编辑、终端执行、测试以及结构化输出。我们使用 Claude Code、Codex 与 CodeBuddy 驾驭。模型与驾驭的组合遵循每个阶段的角色与兼容性要求；仓库视图、工具权限与执行环境强制这些信息边界。

表 6 列出共享的模型池。路由使用该阶段的输出、任务难度、评审发现以及修订历史，来选择一名 Author 或一名 Critic。

表 6：用于智能体辅助的基准构建的模型池。

强模型与旗舰模型处理困难的语义评审，而低延迟模型处理有界的生成与自动化检查。需要更广推理的发现被升级到更强的模型或一名人工评审者。确定性检查管辖模式、产物链接、环境执行、状态矩阵以及结果格式化。

在各个语义阶段，Author 依据已批准的上游证据产出该阶段的完整输出，而 Critic 在独立上下文中工作，并返回关于来源忠实性、可观察性、需求完整性、实现自由以及执行证据的结构化发现。负责的 Author 修订该输出，此后该阶段以及每一个受影响的后来检查都被重新运行。Test 与 Reference 使用分开的编写会话与评审会话，并且默认使用不同的模型族。分开的仓库视图与工具权限，为工作区、对话历史以及执行结果强制这一边界。

人工评审者仍然负责功能方向、范围、交互的自然程度以及测试的公平性。他们把 Contract 与其 Summary 及 Evidence 一起审计，在对应的 Reference 检查点重放每一轮对话，运行项目与测试，把所观察到的公开行为与观察映射相比较，并核验 Test 强制的是预期语义。人工请求的更改返回到负责的阶段，并经历每一个受影响的下游检查。由此产生的审计支持最终决定：接受、修订或丢弃该任务。

B.5 质量证据

任务接受把可行性、行为判别、保持、历史筛选以及语义评审结合起来。表 7 规定支持每个组成部分的证据。

表 7：构建证据的验证作用。

接受证据来自可执行观察，例如单元测试或集成测试、CLI 或 PTY 交互、服务调用、浏览器自动化、生命周期事件、重启以及持久化。有些需求通过多次执行之间的关系来检查，例如导出与导入、保存后重启再加载、编码与解码、幂等、守恒或单调性。这些是蜕变检查（Segura et al., 2016）。与一份独立参考的比较提供额外证据。当几何、DOM 或公开状态、像素关系或协议统计能够从固定输入重新计算时，浏览器任务、TUI 任务与视觉任务仍然可以程序化地检查。每一项被接受的任务都记录每一项需求所使用的证据。

B.6 修订与失效规则

一次任务修订重新运行每一个其结论可能已经改变的检查。表 8 使这一依赖变得明确：仅措辞的编辑需要对话评审以及一份更新后的评测器映射，而对需求、环境、测试或 Reference 检查点的更改，则使对应的可执行证据失效。

表 8：实质性修订之后必须更新的任务组成部分。

在修订一个任务组成部分之前，评审者识别一次失败的 Test 与 Reference 执行的来源。Test 缺陷只更改 Test 一侧的文件；Reference 缺陷重建该检查点以及后来的 Reference 状态；含糊的需求，或无法被分开的状态，创建一次新的 Contract 修订；环境失败在证据被重新运行之前先被纠正。

B.7 带版本的任务记录

每一项被接受的任务都有一份带版本的清单，记录其仓库与精确检查点，以及来源、Contract、Dialogue、环境、冻结的 Test 包、历史筛选的截止、覆盖与结果、Reference 检查点、最终的 Cross 证据，以及人工评审决定。对需求或可执行结论的更新创建一次新修订，并重新生成受影响的下游证据；先前的修订保持不变。FeatureLoop 的 Excalidraw 记录链接其任务修订、环境、Test 包、Reference 序列以及 Cross 证据，使表 4 中的每一个状态都能追溯到对应的任务记录。