需求编译: 让需求从文档走向“源代码”

前言：

如果需求 DSL 是”源代码”，那么 ARC 可以视为一个面向需求 DSL 的编译器。一个传统编译器通常包含前端、中端和后端三个部分：前端负责解析源代码并生成中间表示（IR），中端负责程序优化，后端负责将 IR 翻译为目标代码。ARC 借鉴了其中前端与后端的职责划分，但处理对象从程序代码变成了需求规格。

具体来说，ARC 采用深度优先搜索（DFS）遍历需求图，自顶向下地进行接口设计与测试生成，当一个节点没有任何子节点/依赖或子节点/依赖都已实现时，进入“实现”阶段。以下演示说明了这一过程：

演示1：需求“编译”流程

在传统编译器中，前端负责将源代码解析为结构化的程序表示（如 AST），为后续分析与代码生成奠定基础；而在 ARC 中，”前端”则负责将需求解析为结构化的软件表示，包括接口设计、约束生成和测试生成。具体来说，针对每个需求节点按需设计不同类型的接口：比如UI、API、FUNC、DB。这里的接口类型并非特定技术实现，而是一种抽象的职责划分，即用户交互接口、模块间能力边界、业务逻辑单元、数据持久化能力。它们并不要求必须采用某种 API 协议或使用数据库实现，而是用于描述系统的逻辑结构。Web 应用天然契合这种划分方式，但这一抽象模型同样适用于桌面应用、移动应用、嵌入式系统等其他软件形态。基于这些接口，ARC 会进一步自动生成功能约束和调用关系。

随后的任务是在业务代码落地之前，依据接口功能、需求场景中的 Given/When/Then 生成完整的测试套件：

• 单元测试：验证每个独立接口的逻辑正确性

• 集成测试：验证模块之间的协作正确性

• 端到端测试：验证端到端的用户旅程正确性（如 Playwright脚本）

这回应了文章开头的核心观点：在 AI 时代，写测试或许不再只是一种繁琐的后验验证，而可以是一种前验的约束建模。 如果需求描述得足够详细，场景步骤就有可能自动转换为测试用例。在理想情况下，写代码的过程从”先写后测”的串行流程，转变为一个”在大量测试的约束下，尝试通过尽可能多已有测试”的逐步优化问题。

当沿着深度优先的顺序触底之后，生成了接口、测试，ARC沿着需求树的叶子向上推进，开始真正的代码实现。实现阶段的本质是一个带约束的测试驱动开发（TDD）循环：

1. 生成代码 → 产出候选实现

2. 执行测试 → 运行预先定义好的单元/集成/E2E 测试

3. 获取反馈 → 如果测试失败，将编译错误和断言失败作为提示传回智能体

4. 修复迭代 → 智能体基于反馈修改代码，直到测试通过（或达到预算上限）

每一个需求节点的实现都受到对应测试套件的约束：测试不通过，就意味着实现尚未达到预期的功能要求。 这套机制将 LLM 的创造性输出纳入了测试的反馈闭环中——代码可以有不同的实现方式，但需要满足已定义的接口和测试合约。

在整个过程中，叶子节点更多扮演”功能点”的角色，而非”完整模块”；而非叶子节点的父节点则负责将子节点的功能组合起来，形成完整的模块或系统。

为了使得AI生成的代码具有可追溯性，在处理每个需求点时，都有相应的资产记录。例如，设计阶段，产生的接口、测试单元的元数据将被记录入库；在实现阶段，也会相应追踪和更细接口的实现情况、测试的通过情况。

同时，每一份设计和实现都会产生一次 Git 提交，提交记录精确到 <节点, 阶段> 级别，例如：”REQ-1-1 (design): 用户注册接口设计”。

演示2：可追溯性记录示例

这种可追溯性记录带来几个方面的好处：

• 智能复用：处理新节点时，ARC 首先查询祖先节点已有的接口和测试，判断是否可以适配复用，而非从零开始生成

• 非回归保障：测试驱动 + 节点隔离的架构，尽可能减少修改一个需求意外破坏已实现功能的情况

• 人工可理解：开发者拿到 ARC 生成的系统后，可以通过 traceability 记录反向理解”为什么这里有这段代码”，降低维护门槛

• Git 就是时间机器：遇到问题时，”git checkout” 到任意中间版本，对比设计前后的差异，迅速定位问题

在 AI 时代，代码的可追溯性可能与代码本身同等重要。 当一个系统由智能体自动生成时，traceability 和 git 的结合，是开发人员理解和审查这套系统的一种重要手段。

1. 深度基准（Depth-oriented）： 选取了 6 个成熟且大规模使用的 Web 系统，每个系统的需求文档包含 50~200 个功能：

1. 广度基准（Breadth-oriented）：选取数据集 AppForge， 包含 101 个 移动应用生成任务，每个 app 涉及不到 10 个功能点，覆盖广泛的实现挑战。

我们与四类代表性的先进方案进行了比较：

• MetaGPT：角色扮演式多智能体框架（模拟产品经理、架构师、程序员等角色）

• OpenHands：基于事件流的反应式智能体框架

• Cursor Agent Mode：单智能体 IDE 交互模式

• GitHub Copilot Agent Mode：单智能体 IDE 交互模式

在 Web 系统 Benchmark 上，ARC 在测试通过率上相较基线有显著提升：

• GUI 测试通过率平均高出 50.6%，在部分系统上提升高达 108.1%

• 随着系统复杂度增加（从 BookStack 到 Ctrip），基线的性能急剧下降（OpenHands 从 55.6% 跌至 15.0%），而 ARC 仍稳定保持 75.4% 的通过率

• 方差可接受（标准差 ≤ 7.6%），而基线普遍呈现高波动（如 Cursor std 26.9%）

在 AppForge 上，ARC 也取得了较为积极的初步结果：

– 100% 编译成功率

– 在选取的基线中，ARC 取得了最高的测试用例平均通过率 68.3%

我们分析了基线方法在面对大规模需求文档时的表现，发现一个共性问题：需求缺乏显式拆解。

现有的智能体方案（无论是 MetaGPT 的 SOP 驱动、OpenHands 的事件流还是 Cursor/Copilot 的 Agent Mode）大多将整份需求文档作为一长段自然语言上下文输入模型。当需求文档包含上百个场景时，这种”全文灌输”的方式面临两个困境：

1. 注意力分散：LLM 的注意力机制在超长上下文中天然存在不均匀分布——模型可能对文档开头和结尾的内容分配更多注意力，而中段的需求点被相对弱化。反映在生成结果上，就是部分功能被遗漏或简化。

2. 上下文损耗：我们观察到，长需求文档直接输入模型时，更容易出现需求遗漏、细节弱化和边界条件丢失。一个可能原因是，大规模需求在单一上下文中缺乏显式调度，模型需要同时完成理解、拆解、排序和实现，导致部分需求点没有获得充分处理。

换句话说，基线依赖模型自身的能力来”读懂”并”拆解”需求文档，但面对大规模需求时，这种隐式的拆解是不可靠的。需求越复杂，遗漏和偏差就越严重。

ARC 的思路与此不同。我们将需求拆解从”模型的认知任务”转变为”系统的显式调度”：

• 显式拆解：DSL 将需求文档预先建模为 DAG，每个功能点都是一个独立的节点。ARC 不依赖模型去”自己理解应该先做什么后做什么”，而是由调度器依据 DAG 的依赖边逐个分发节点，每个节点获得独立的处理会话和资源预算。

• 测试先行约束：每个节点在被实现之前，必须先通过 TestGenerator 将场景步骤转化为可执行的测试套件。这些测试充当了该节点的”规格契约”——无论模型在实现时如何发挥，最终必须通过测试才算完成。这从机制上保障了每个需求节点获得对等的注意力投入，而非被淹没在长文档的中段。

简而言之，ARC 用显式的图结构调度和测试门控，替代了基线中隐式的、依赖模型注意力分配的”全文理解”。这种差异在大规模需求场景下尤为关键

为了让更多人直观感受”需求编译”的过程，我们搭建了一个在线平台arc-bench.com，希望形成一个融合教学、比赛和研究的平台。该平台对ARC框架做了以下支持：

平台收录了6 个 Web 系统的完整 DSL 需求文档（我们正在扩充更多的系统），可以逐一查看每个系统的需求树结构、场景细节。同时也准备了大量端到端GUI测试用例，来验证需求编译的效果。同时，我们也期待未来更优秀的需求编译智能体能通过更多的测试。

用户上传ARC代码或指定框架下编写的agent至平台，可以动态回放每个需求节点的编译过程：

• 需求树展示：以可视化 DAG 的形式呈现需求的层级结构和依赖关系

• DFS 编译轨迹：按时间顺序展示每个节点的 DESIGN → IMPLEMENT 过程，清晰呈现自顶向下设计、自底向上实现的完整流水线

• 在需求-接口-测试三维关联视图中，追踪任意一条需求对应生成了哪些接口、哪些测试

• 查看接口间的调用图（Call Graph），理解模块之间的调用关系

• 浏览完整的 Git 提交历史，查看每一个需求设计和实现时的代码变更，同时可以回溯到处理某个需求点时的状态 

网站地址：arc-bench.com

结语：