验收驱动开发，在 Harness + Loop Engineering 时代为什么更重要

1. 这套方式到底叫什么

你描述的不是一个孤立方法论，而是几套成熟实践在 AI coding 时代的重新组合。传统软件工程里，它靠需求分析、验收标准、ATDD 和 BDD 支撑；AI agent 工程里，它继续向 Harness、Eval、Trace、Human-in-the-loop 和自动修复循环延伸。

概念谱系从业务变化到可运行反馈

As-Is 先理解当前业务流程、状态流、角色、异常路径和系统边界。

To-Be 描述改完后的目标流程，尤其是新状态、新规则和用户可观察变化。

Gap 对比改动前后，抽出必须变更的代码、数据、接口和权限点。

Acceptance 把“算完成”的条件写成验收清单、场景和可执行检查。

Harness + Loop 让 Agent 按验收信号反复实现、测试、修正、报告和沉淀。

术语	对应你描述的哪一段	工程含义
As-Is / To-Be Analysis	梳理原逻辑流程和改完后流程	不是直接改代码，而是先建立当前态和目标态的业务地图。
Gap Analysis	对比改动前后，确定要改什么	把流程差异转成系统差异，包括领域规则、接口、数据迁移和 UI 行为。
Acceptance Criteria	罗列验收列表	Atlassian 将验收标准定义为工作完成前必须满足的条件，这正好是 Loop 的停止依据。
ATDD	先写验收再开发	Acceptance Test-Driven Development 强调团队先澄清验收测试，再实现代码。
BDD	用场景表达业务行为	Cucumber / Gherkin 常用 Given / When / Then 把需求转成可讨论、可自动化的行为规格。
Spec-driven Development	规格、计划、任务、实现、验证	GitHub Spec Kit 把规格先行变成 AI coding 的结构化流程。

如果要给这套 AI 时代的组合方法取一个实用名字，我会叫它：验收驱动的 Loop Engineering。它的关键不是“文档更多”，而是让文档变成可执行、可验证、可反馈的工程信号。

2. 为什么现在更有价值

传统开发里，验收列表主要服务人类协作。到了 AI coding，它还承担另一个角色：约束一个会调用工具、会修改文件、会多轮尝试的系统。没有验收标准，Agent Loop 只能凭语言自信收敛；有了验收标准，Loop 才有明确的评分器和退出条件。

生成不等于完成

AI 很擅长生成 plausible code，但业务正确性常常藏在状态、边界条件和历史数据里。验收标准把“看起来合理”推进到“业务上成立”。

Harness 需要信号

Anthropic 关于 long-running agents 的文章强调，长任务需要环境、工具、观察、日志和评估。验收清单就是 Harness 的输入之一。

Loop 需要停止条件

Agent 能反复计划、执行和修正，但没有明确停止条件就会变成消耗 token 的循环。验收通过、风险升高、预算耗尽都应被明确定义。

弱验收模式

用户说一个模糊需求。
Agent 直接改代码。
测试能跑就报告完成。
业务方验收时发现流程不对。
重新解释需求，重新返工。

验收驱动 Loop 模式

先写 As-Is 和 To-Be。
把差异拆成变更点。
将验收条件写成清单和测试。
Agent 只围绕验收目标改动。
Harness 验证失败就回到下一轮修正。

深度搜索后的判断：“loop engineering”还不是像 TDD、BDD 那样稳定的标准术语，但 Anthropic 的 evaluator-optimizer workflow、long-running agent harness、SWE-bench harness、LangGraph 的状态图和 human-in-the-loop、GitHub Spec Kit 的规格先行，都在指向同一个工程趋势：把 AI 产出放进可观察、可评估、可迭代的闭环。

3. 一个可落地的核心流程模型

这套模式最重要的是把“理解业务”和“验证实现”放到同一条链路里。不要只写需求，也不要只跑测试，而是把业务流程、差异、任务、代码和验收反馈串起来。

验收驱动开发闭环业务分析到回归沉淀

Acceptance
Harness
Loop

业务理解 As-Is、角色、状态、异常、系统边界。

规格与任务 To-Be、Gap、验收清单、任务拆解。

实现与观察 修改代码、运行测试、记录 trace。

验收与沉淀 通过则交付，失败则补样例并进入下一轮。

输入工件 业务流程图、接口契约、数据库约束、用户故事、生产事故样例、历史 PR、埋点和日志。

输出工件 变更规格、验收列表、任务包、测试用例、实现 diff、验收报告、失败样例和回归集。

控制工件 权限边界、预算上限、停止条件、人工审批点、回滚策略、风险分级和发布门禁。

流程前后对比清楚 可以回答“原来怎么走、改完怎么走、哪一步发生变化”。

验收项可被验证 每条验收不是愿望句，而是能通过测试、截图、接口响应、日志或人工检查证明。

任务拆分对应 Gap 每个开发任务都能追溯到某个流程差异或验收项。

失败反馈能进入下一轮 验收失败不是一句“没通过”，而是带有失败证据、复现路径和下一步修正方向。

4. Harness 怎样承接验收

Harness 可以理解为“让 Agent 在受控环境里完成任务并接受验证的试验台”。它不只是跑单测，还包括环境准备、样例数据、工具权限、评估脚本、日志、trace、成本统计、回放和人工验收入口。

层次	内容	对应验收驱动开发
Environment	依赖、数据库、fixture、mock 服务、浏览器环境、权限沙箱	让“原流程”和“新流程”能被稳定复现。
Task	任务说明、输入资料、约束、禁止事项、交付格式	把 Gap Analysis 变成 Agent 可执行的任务包。
Evaluator	单测、集成测试、BDD 场景、截图比对、静态检查、评分器	把验收清单变成机器可运行的判断。
Observer	工具调用记录、日志、trace、费用、耗时、失败分类	验收失败时能定位原因，而不是只说“模型没做好”。
Supervisor	人工审批、风险门禁、预算限制、回滚策略、停止条件	避免 Agent 为了通过局部测试而越权、破坏架构或扩大风险。

acceptance:
  - id: AC-01
    title: 未支付订单可以取消
    given: 用户有一笔 pending 订单
    when: 调用取消订单接口
    then:
      - 订单状态变为 cancelled
      - 库存释放记录存在
      - 支付系统没有退款请求
    evidence:
      - api_test: tests/orders/cancel_pending.spec.ts
      - db_check: sql/assert_inventory_released.sql

  - id: AC-02
    title: 已发货订单不能取消
    given: 用户有一笔 shipped 订单
    when: 调用取消订单接口
    then:
      - 返回业务错误 ORDER_ALREADY_SHIPPED
      - 订单状态保持 shipped
      - 写入审计日志
    evidence:
      - api_test: tests/orders/cancel_shipped.spec.ts
      - log_check: scripts/assert_audit_event.js

Harness 的关键不是一次性“跑绿”，而是让失败样例沉淀下来。每次验收失败都应该补充到回归集、文档、Skill 或任务模板里，否则 Loop 只是重复犯错。

5. Loop 怎样持续收敛

Anthropic 的 Building Effective Agents 把 evaluator-optimizer 描述为一种让模型生成、评估、再改进的工作流。把它放进软件开发，就是：Agent 改代码，Harness 评价，失败信号回到上下文，Agent 再改，直到通过验收或触发停止条件。

Agent Loop 的四个关键控制点没有控制点就不是工程闭环

目标函数

验收标准、测试、业务规则、截图要求、性能阈值和安全约束共同定义“什么叫更好”。

观察信号

测试输出、trace、日志、用户反馈、diff review、截图和运行时指标让失败可被定位。

修正策略

失败分类、最小改动、回滚点、补充上下文、调用专用 Skill 或切换人工接管。

停止条件

验收通过、预算耗尽、风险升高、权限不足、需求不明确或连续失败达到上限。

记忆沉淀

把失败原因、修复方式和新测试沉淀为回归集、知识库、runbook 或 Codex Skill。

人类监督

涉及产品判断、安全边界、架构权衡和线上发布时，人类不应只在最后验收。

while budget.available:
    spec = load_change_spec()
    context = collect_relevant_context(spec)
    plan = agent.plan(context, acceptance_criteria=spec.acceptance)

    diff = agent.implement(plan)
    result = harness.run(diff, checks=spec.acceptance)

    if result.passed:
        return handoff(diff, result.evidence)

    if result.risk_high or result.needs_human:
        return request_review(diff, result.failure_report)

    agent_memory.add(result.failure_report)
    spec = refine_spec_with_evidence(spec, result)

这段伪代码背后的工程含义是：Agent 的下一轮输入不应该只是“继续修”，而应该包含上一轮失败证据、失败分类、受影响文件、未通过验收项和被禁止的错误方向。

6. 目前有哪些平台或 Skill 支持

目前没有一个主流平台把你描述的完整链路作为单一标准产品完全包起来，但很多工具已经覆盖其中一段。真正可用的方案通常是“需求协作平台 + 规格工具 + 自动化验收 + Agent Harness + 人工审查”组合。

类别	代表工具	支持方式
需求与任务	Jira / Confluence / Linear / GitHub Issues	承载用户故事、验收标准、任务拆解、状态流和 review 记录。
BDD / ATDD	Cucumber / Gherkin / Robot Framework / pytest-bdd	把 Given / When / Then 或关键字测试写成可执行业务验收。
前端验收	Playwright / Cypress / Storybook test runner	验证页面状态、交互路径、截图、可访问性和回归行为。
规格驱动	GitHub Spec Kit	用 spec、plan、tasks 把需求先结构化，再进入实现。
Agent 工作流	LangGraph / OpenAI Agents SDK / AutoGen	支持多步工具调用、状态流、trace、人工接管和可组合 agent。
Eval / Harness	SWE-bench / Inspect AI / LangSmith Evals / 自建 Harness	提供数据集、执行环境、评估器、失败分析和回放能力。
Codex Skills	skill-creator / github:* / build-web-apps:* / product-design:*	可以把“先梳理流程、列验收、再执行、再验证”的工作流封装成团队专用 Skill。

在 Codex 里怎么组合

你当前环境里已经有一些可组合的 Skill：`skill-creator` 可以把这个流程封装成新 Skill；`product-design:get-context` 和 `product-design:audit` 适合梳理产品流程；`build-web-apps:frontend-testing-debugging` 适合前端验收；`github:gh-fix-ci` 和 `github:gh-address-comments` 适合把失败检查或 review feedback 纳入修复循环。

最值得做的下一步：把这套流程封装成一个 `acceptance-loop-development` Skill。它不需要绑定某个业务领域，只要强制每次变更都产出 As-Is、To-Be、Gap、Acceptance Checklist、Task Plan、Verification Report 和 Regression Notes。

7. 一个团队可直接采用的落地模板

下面这个模板可以放进 issue、PRD、Codex Skill 或仓库里的 `.agent/change-spec.md`。它的目的不是增加仪式感，而是让 Agent 和人类在同一套验收语言里工作。

# Change Spec: <变更名称>

## 1. Business Context
- 业务目标：
- 相关角色：
- 相关系统：
- 非目标范围：

## 2. As-Is Flow
1. 当前步骤 A：
2. 当前步骤 B：
3. 当前异常路径：

## 3. To-Be Flow
1. 目标步骤 A：
2. 目标步骤 B：
3. 目标异常路径：

## 4. Gap Analysis
| Gap | 类型 | 影响文件/模块 | 风险 |
| --- | --- | --- | --- |
| G-01 | 领域规则 | order/domain | 高 |
| G-02 | API 响应 | order/controller | 中 |

## 5. Acceptance Criteria
- AC-01: Given ..., When ..., Then ...
- AC-02: Given ..., When ..., Then ...
- AC-03: 性能、权限、审计、兼容性要求

## 6. Task Dispatch
- T-01: 修改领域模型，对应 G-01 / AC-01
- T-02: 增加接口测试，对应 AC-02
- T-03: 更新文档和回归样例

## 7. Verification Report
- 运行命令：
- 通过证据：
- 未覆盖风险：
- 需要人工验收的项：

## 8. Regression Notes
- 新增测试：
- 新增失败样例：
- 可沉淀到 Skill / runbook 的经验：

小变更也保留验收项 哪怕只有 3 条，也比“看起来没问题”可靠。

复杂变更必须有前后流程图 尤其是订单、审批、计费、权限、库存、合约等状态密集领域。

每条验收都绑定证据 证据可以是测试、截图、日志、SQL 检查、接口响应或人工确认。

失败样例进入回归集 否则下一次 Loop 仍然可能在同一个地方犯错。

8. 风险与反模式

验收驱动不是把所有事情都流程化到迟缓。它真正要防的是另一种极端：Agent 很快、代码很多、反馈很自信，但业务目标没有被验证。

反模式	表现	应对
验收项写成愿望	“体验更好”“逻辑正确”“性能正常”	改写成可观察结果、阈值和证据类型。
只验 happy path	主流程通过，但异常路径、权限、并发和历史数据遗漏	As-Is / To-Be 必须包含异常流和不可变约束。
Harness 过窄	只跑单测，却声明业务验收通过	根据需求范围加入集成、端到端、日志、截图或人工检查。
Loop 投机	为了过测试硬编码、删除断言、扩大 mock	增加 diff review、禁止项、架构约束和人工门禁。
反馈不沉淀	这次修好了，下次类似问题又发生	把失败样例写入回归集、Skill、runbook 或模板。

最后的判断：在 harness + loop engineering 时代，验收驱动开发不是传统流程的复古，而是 AI coding 规模化的必要控制面。它把业务目标、工程执行和反馈学习连成一条闭环。

9. 参考资料

以下资料用于交叉验证本文的术语、趋势和平台能力。检索重点覆盖 ATDD / BDD、验收标准、agent harness、eval、spec-driven development、agent loop 和 human-in-the-loop。

HarnessAnthropic, Effective harnesses for long-running agents.
EvalsAnthropic, Demystifying evals for AI agents.
AgentsAnthropic, Building Effective AI Agents.
HarnessSWE-bench, The Harness.
SpecGitHub, Spec Kit.
BDDCucumber, Gherkin Reference.
ATDDAgile Alliance, Acceptance Test-Driven Development.
AcceptanceAtlassian, Acceptance Criteria.
WorkflowLangGraph, Overview and Human-in-the-loop.
EvalLangSmith, Evaluation.
OpenAIOpenAI, Evals guide and Agents SDK tracing.
CodexOpenAI Developers, Codex Skills.
TestingPlaywright, Playwright testing documentation.
TestingRobot Framework, Robot Framework User Guide.