端到端研发自动化，为什么不能只靠 Workflow 或 SDD

本文是《别让 Skill 变成新的文档债：从经验沉淀到行为回归》的下一篇。

上一篇讨论的是：当 Skill 开始影响 Agent 行为之后，它就不能只作为经验文档存在，而必须进入测试、回归和评估体系。

这篇继续往前推一层：如果 Skill、Prompt、Tool、项目知识、执行轨迹、验证结果和回归样本都需要被统一管理，那么端到端研发自动化就不能只停留在 Workflow 或 SDD 的视角里。

过去一段时间，AI Coding 的讨论正在发生一个变化：重点不再只是模型能不能写代码，而是 Agent 能不能在真实研发流程里稳定完成任务。

这个变化背后，有两类信号很明显。一类是以规格为中心的开发工具链开始出现。GitHub Spec Kit 把自己定位为帮助团队开始 Spec-driven Development 的工具包，围绕 specification、plan、tasks 等产物组织开发过程；Kiro 的 Specs 也强调在写代码之前先完成 requirements gathering、technical design 和 implementation planning。它们共同说明一个趋势：AI Coding 不能只靠即时对话，而是需要更稳定的规格、计划和任务表示。

另一类信号是，Coding Agent 开始从一次性对话走向长时运行。Claude Code、Codex、Cursor、GitHub Copilot 这些产品都在补执行环境、任务会话、上下文保持、工具调用、失败恢复和过程可观察能力。如果只看前一个变化，我们很容易得出一个结论：端到端研发自动化的关键，是把 Spec 写清楚。如果只看后一个变化，我们又容易得出另一个结论：端到端研发自动化的关键，是把 Workflow 串起来，让 Agent 按步骤执行。

但真实研发任务往往没有这么简单。一个需求从提出到上线，不只是经过几个步骤，也不只是生成一份规格。它会涉及分散在不同系统里的输入材料、不断变化的产品现场、复杂的代码仓库上下文、多轮执行失败、工程验证、业务验收、人工确认，以及任务结束后的经验沉淀。

所以问题不是 Workflow 有没有用，也不是 SDD 有没有用。它们都很重要。但如果我们希望 Agent 真正进入研发交付链路，就还需要多问一层：当规格写完、流程画好之后，Agent 到底运行在哪里？它如何拿到正确上下文？如何处理失败？如何留下证据？如何被人接管？又如何把这次执行变成下一次可复用的经验？

这才是端到端研发自动化不能只靠 Workflow 或 SDD 完成的原因。

Workflow 的价值，是让流程可见。

一个需求从提出到上线，中间会经过很多环节：需求澄清、范围确认、设计对齐、接口确认、任务拆解、开发实现、测试验证、代码评审、灰度发布、线上观察。过去这些动作经常散落在会议、聊天、文档和项目管理工具里，依赖人的主动推进。

Workflow 至少让这些动作有了可见路径。

这对 Agent 进入研发流程尤其重要。因为 Agent 不可能在完全无结构的环境里稳定工作。它需要知道当前任务处于哪个阶段，下一步应该做什么，哪些步骤已经完成，哪些步骤还在等待确认。

从这个角度看，Workflow 是必要的。没有 Workflow，研发自动化很容易变成一串临时脚本或者一堆松散的 Agent 调用。看起来每一步都能自动化，但整体没有过程感，也没有状态管理。

SDD 的价值，是让任务可表达。

很多 Agent 执行失败，并不是因为模型不会写代码，而是因为输入本身就不完整：目标不清、范围不明、接口字段缺失、设计稿和 PRD 不一致、验收标准模糊。所以，把需求、设计、接口、约束、验收标准前置表达清楚，是端到端研发自动化必须补的一步。

这也是为什么以规格为中心的开发工具链开始出现。它们试图把一句需求描述，逐步组织成规格、计划、任务，再交给 Agent 执行。这个方向是对的，因为 AI Coding 不能只靠即时对话，必须有更稳定的任务表示。

Workflow 和 SDD 的价值都成立，但它们解决的是端到端研发自动化里的两个关键局部，而不是完整闭环。

Workflow 解决的是“流程怎么组织”，但不等于“执行如何可靠”。

流程图上可以写：生成代码、运行测试、修复失败、提交 PR。但 Agent 真实执行时，问题不会这么整齐地出现。它可能在需求理解阶段就遗漏了关键约束；可能在读代码时找错了相似实现；可能在修改文件时扩大了影响范围；可能在测试失败后误判原因；也可能在 build 通过之后误以为需求已经完成。

这些问题不是多加几个流程节点就能完全解决的。因为真正困难的地方不在于“下一步是什么”，而在于“当前这一步做得对不对，以及失败后如何继续”。

SDD 解决的是“任务怎么表达”，但不等于“交付如何验证”。

规格里写了“支持批量审批”，并不等于系统已经证明了批量选择、取消选择、部分失败、权限不足、接口异常、空状态、加载状态和回归影响都符合预期。规格里写了“按设计稿实现”，也不等于 Agent 已经理解了所有交互状态、组件约束、响应式边界和历史页面兼容问题。

更现实的问题是，真实研发任务里的信息经常并不在同一个地方。PRD 可能是一份文档，设计稿在另一个工具里，接口字段在接口平台里，历史逻辑在代码仓库里，线上表现又在真实页面里。Agent 拿到一份规格，并不等于它拿到了完成任务所需的全部上下文。

所以，Workflow 和 SDD 之后，仍然有几个断点没有被完整解决：输入如何从分散材料变成可执行上下文；Agent 如何在真实仓库中选择、读取和使用上下文；执行过程如何被观察、约束和接管；验证结果如何变成证据，而不是一句“已完成”；失败、修正和人工判断如何沉淀成后续可复用经验。

这才是端到端研发自动化继续往前走时必须面对的问题。

如果把 Workflow 看成流程层，把 SDD 看成规格层，那么端到端研发自动化还需要第三层：研发运行承载能力。

这里不一定要把它理解成某个具体平台，也不是要创造一个新名词。更准确地说，它是一组让 Agent 能在真实研发链路中稳定运行的系统能力。

它至少包括六件事。

第一，输入如何进入任务对象。PRD、会议纪要、设计稿、接口、仓库上下文、历史需求、线上页面、测试用例，不能只是散落在不同地方，而要被组织成一个可执行的任务上下文。

第二，任务如何被表示。Agent 不应该直接面对一堆原始材料就开始写代码，而要先形成目标、范围、非目标、影响面、约束、验收标准、不确定项和人工确认点。

第三，Agent 如何执行。它使用什么模型，在哪个环境里运行，能调用哪些工具，能改哪些文件，什么时候需要权限确认，什么时候允许自动继续，什么时候必须停下来。

第四，执行过程如何被观察。系统需要记录 Agent 读了什么、改了什么、调用了什么工具、遇到了什么失败、如何修复、验证结果是什么，而不是只留下一个最终 PR。

第五，验证如何形成闭环。lint、typecheck、build、unit test、端到端测试、视觉校验、回归测试、人工验收，不应该是“写完之后看情况跑一下”，而应该成为任务执行链路里的分层证据。

第六，经验如何回到系统。一次失败不能只停留在聊天记录里，而要变成新的测试样本、回归用例、项目知识、Skill 修改或 Eval Gate 规则。

这也是为什么现在一些产品和工程实践开始反复提到 harness、agent session、long-running agent、execution trace 这些词。VS Code 团队在介绍 GitHub Copilot 的实现时，直接把模型之外负责 context、tool calling、agent loops、terminal execution、memory 等能力的部分称为 coding harness；Anthropic 在长时运行应用开发的文章里，也把 harness design 放在长时 Agent 能否稳定推进任务的核心位置。

这些词背后的共同点，并不是又换了一套新概念，而是大家都在补同一类能力：让 Agent 不只是在对话框里回答问题，而是在一个可承载、可观察、可恢复、可验证的工程环境里执行任务。

Workflow 让过程可见。SDD 让任务可表达。研发运行承载能力要解决的是：任务如何被执行、被观察、被验证、被接管，并在一次次执行后持续收敛。

端到端研发自动化听起来很大，但落地时不应该从“大一统平台”开始。更现实的起点，是选择一个真实交付项，把它做成可回放样本。

这个交付项可以是一个新增页面、一次业务流程改造、一个表单能力升级、一个跨端组件调整，或者一次已有页面的体验优化。它不再只是项目管理工具里的一条任务，而是一个贯穿产品、设计、工程和验证的工作对象。

所谓可回放，不是把聊天记录保存下来，而是把一次研发任务里的关键证据保存下来：输入材料是什么，任务如何被表示，Agent 读了什么、改了什么、调用了什么工具，哪些验证通过，哪些验证失败，人工在哪里介入，最后哪些经验进入了回归样本或 Skill。

只有做到可回放，端到端研发自动化才不是一次演示，而是可以比较、可以复盘、可以改进的系统能力。

围绕这个交付项，最小闭环至少要组织四件事。

第一，输入要能收敛。PRD、会议纪要、设计稿、接口文档、历史页面、线上截图、相似需求和代码仓库上下文，不能只是散落在不同工具里。系统需要帮助人和 Agent 一起识别：目标是什么，范围是什么，非目标是什么，哪些信息缺失，哪些地方存在冲突，哪些点必须人工确认。

第二，产品现场要能被看见。很多研发任务并不是从一段文本开始，而是发生在页面、状态、流程和交互细节里。一个按钮什么时候出现，一个列表空状态如何展示，一个弹窗失败后如何恢复，一个批量操作如何处理部分成功，这些都不是纯文本规格能完全表达的。所以端到端研发自动化不能只面对文档，还需要面对真实产品现场：当前页面是什么，新页面是什么，涉及哪些状态，设计稿和现有实现有什么差异，哪些交互路径需要验收。

第三，任务要能变成 Agent 可执行对象。当输入和产品现场被收敛之后，系统不能直接把原始材料扔给 Agent，而要生成一个面向执行的任务对象。这个任务对象至少包括：目标、范围、非目标、影响面、相关文件线索、接口约束、状态清单、验收标准、风险点、验证计划和人工门禁。它不是传统 PRD，也不是简单 Prompt，而是连接产品意图和工程执行的中间表示。

第四，执行和验证要能形成闭环。Agent 执行时，系统需要记录它读了什么、改了什么、调用了哪些工具、遇到了什么错误、如何修复、跑了哪些验证、哪些验证失败、哪些地方需要人确认。最终产物也不应该只有一个 PR，而应该同时包含：代码改动、执行轨迹、验证结果、人工验收项、回归样本和可复用经验。

这样，一个交付项才形成最小闭环：输入材料被收敛，产品现场被看见，任务被结构化，Agent 执行被承载，验证证据被保留，失败经验被沉淀。

这比单纯搭一个 Workflow 更具体，也比单纯写一份 Spec 更接近真实研发现场。端到端研发自动化的最小可行形态，不是一个自动写代码的 Agent，也不是一个自动生成需求文档的工具，而是一个围绕真实交付项运转的研发任务工作台。

它把产品、设计、工程、Agent Session 和验证证据放到同一个工作对象里，让每一次需求推进都能留下可执行、可观察、可验证、可回归的结构化证据。

这篇文章并不是要否定 Workflow 或 SDD。相反，它们都应该成为端到端研发自动化里的关键组成。

Workflow 负责把流程显性化，让研发任务不再完全依赖人的临场组织。SDD 负责把规格结构化，让 Agent 不再只面对模糊文本和碎片化输入。但它们都需要进入一个更大的运行系统里。

在这个系统里，Workflow 不只是静态流程，而是和执行状态、验证结果、人工门禁、失败重试绑定在一起。Spec 不只是文档，而是会被拆解成任务表示、上下文选择、验收断言和验证计划。Skill 不只是经验沉淀，而是会被测试、回归和持续演化。Agent 不只是代码生成器，而是运行在受控环境里的执行单元。PR 不只是最终产物，而是带着上下文、轨迹、验证证据和回归样本的交付结果。

这才是端到端研发自动化真正要走向的形态。

过去我们讨论 AI Coding，常常把重点放在模型能不能写代码。后来我们发现，模型能写代码不代表需求能交付，于是开始讨论验证链路。再后来，我们发现，验证链路也不能只靠单次执行，于是开始讨论 Skill、Benchmark、Trace 和 Regression。

现在问题继续往前走：如果这些东西都要进入真实研发流程，那么我们就不能只停留在 Workflow 或 SDD 的视角。Workflow 让流程可见，SDD 让任务可表达，但端到端研发自动化真正要解决的是：任务如何被执行、被观察、被验证、被接管，并在一次次执行之后持续收敛。

所以我越来越觉得，端到端研发自动化的核心，不是一张更完整的流程图，也不是一份更标准的规格文档，而是一套面向真实研发现场的运行承载能力。它让 Agent 不只是“能做事”，而是能在工程系统里稳定做事。

这可能也是 AI Coding 从工具走向系统之后，真正的分水岭。