规范驱动开发——企业规模化落地实践
过去一年，AI 辅助编程领域迎来了重大变革。我们已不再需要在 IDE 与聊天界面之间来回复制代码，转而使用专为 AI 打造的命令行工具与 AI 原生编辑器。 然而，即便工具持续演进，“氛围编程”（与 AI 反复迭代直至代码可运行，而非事先周密规划）的交互方式本质上仍属于指令式，一次仅能处理一个提示词，输出会作为后续步骤的上下文。 图 1：氛围编程工作流 规划模式（AI 在编写代码前先起草执行计划供人工审核）标志着 AI 编程的一次重大演进，能够及早发现意图对齐问题。它要求人类与 AI 在实现代码之前先商议并确定任务清单、相关验证机制等，拉长了独立执行的周期，最终交付更完整的结果。这是我们与 AI 的第一次“开工仪式”，它印证了：前期对话质量越高，最终结果越对齐。 然而，人类与 AI 之间的交互仍然是战术性和指令式的。由于计划通常不会在执行后保留，代码实现本身就成了后续迭代与功能新增的主要上下文。 图 2：规划模式工作流 随着 AI 模型开始具备在复杂任务上保持长时间持续专注的能力，规范驱动开发（SDD）应运而生。在连续交互的模式中，人类与 AI 之间的指令式交互并非发挥这一能力的最优方式；同时，让 AI 长时间独立运行也存在大幅偏离预期结果的风险。我们需要高效的上下文工程来确保在此场景下的意图对齐。SDD 通过构建人类与 AI 之间的共同理解来满足这一需求，规范的作用是促进人机对话，而非充当操作手册。 图 3：规范驱动开发工作流 本文探讨企业应如何采用 SDD：审视需要填补的即时工具缺口、梳理与现有工作流的集成模式（帮助团队快速体验价值），以及推动相关协作模式变革，让 SDD 能够规模化、可持续落地。 SDD 已在多个技术维度展现出明确价值。除了支持更长时间、更专注的独立执行外，它还有助于解决 Token 用量与上下文窗口管理问题，实现 AI 智能体的高效与低成本使用。 然而，SDD 最重大的影响可能是文化层面的，而非技术层面。 资深工程师协作时，沟通是对话式的，而非单向指令。我们通过对话达成共识，而这种共识决定了最终要构建的内容。SDD 在人类与 AI 智能体之间建立了同样的模式：智能体帮助我们思考方案、质疑假设，并在正式实施前细化目标意图。 图 4：规范驱动开发详细工作流 图 4 展示了 SDD 工具如何帮助构建人与 AI 之间的对话。部分工具采用独立的探索、设计与任务阶段，另一些则采用更细粒度或更灵活的流程。核心在于创造机会，通过规范与 AI 迭代表达意图。尽管新模型拥有更长的上下文窗口与更强的推理能力，但只有将 AI 视为解决方案的共同创造者，我们才能充分释放其潜力。 从概念层面看，借助规范驱动开发，团队可将功能拆解为可指导自主执行的组成模块（图 4）： 什么（发现）：定义我们所服务的用例的业务上下文是什么？ 如何（设计）：如何将该用例映射到我们的架构？需考虑模块划分、实现机制与通信方式。 任务：详细制定智能体可执行的计划，确保具备清晰的可验证性与并行执行空间。 但即便采用这种对话式方式，若仅由个人单独实践，仍会错失更大的价值。虽然 AI 可以扮演不同角色（如图 4 所示）来协助编写各类规范，但由单个开发者独立完成全流程并不合理。 团队通过跨职能协作构建规范与执行上下文远优于个人埋头优化提示词或追求更强大的模型。SDD 能将规范作为转化层，捕捉各方持续迭代的沟通内容。例如：产品定义“做什么”，架构确定“怎么做”，工程负责落地“具体任务”等。 随着开发变得更快、成本变得更低，瓶颈已经发生转移。如果我们仍将精力耗费在校验 AI 输出上，需求积压就会因缺乏新想法而加剧。简而言之，仅依靠审核的模式，在使用 AI 智能体时无法实现规模化。 正是在这种背景下，团队需要协同运作，共同构思并解决问题，以此指导可并行构建的智能体集群。掌握这一方法的组织能让人类将更多时间用于解决战略性问题，同时由智能体同步处理多个工作流。这种团队层面的统筹编排，而非单纯提升个人效率，正是 SDD 对企业而言不可或缺的核心价值所在。 鉴于这种重要的文化属性，若只是将 SDD 作为技术部署，会造成大量价值流失。SDD 的落地是一项需要长期培养的组织能力，而非一项只需安装部署的技术实践。有过企业敏捷转型经验的人都会熟悉这一规律：工具与流程很容易落地，但缺少文化转变就很容易出现“规范瀑布”——也就是敏捷里所谓的“伪敏捷”。 若不改变产品、架构、工程与 QA 各方的实际协作模式，直接推行规范驱动工作流，反而可能催生“Markdown 怪兽”——生成层层叠叠、一诞生便已过时的文档。关键在于要将规范同时作为多方协作的对话媒介与 AI 智能体的上下文引擎。 企业多层级、多利益相关方的现实暴露出当前 SDD 工具存在的诸多短板。主流工具大多存在以下一个或多个问题。 目前主流的 SDD 工具大多将使用场景限定在 Git 仓库、代码编辑器与命令行界面中。这种定位对个体开发者而言较为合理，却给跨职能协作带来了阻碍。当规范存放在代码仓库里时，产品经理与业务分析师（本应负责定义“做什么”的角色）会面临较高的参与门槛。 当前工具通常将规范与代码存放在同一仓库中。这对于简单的应用来说或许可行，但企业系统极少采用单仓库架构。现代架构横跨微服务、公共库、基础设施仓库与平台组件。当一个功能需要跨六个仓库修改时，规范应该放在哪里？如何保证这些边界之间的一致性？工具并未给出明确答案。 作为以开发者为中心的延伸，现有工具并未根据演进节奏与受众对象对产出物进行清晰区分。 架构决策（如 Schema 设计）和业务上下文（如验收标准）更偏战略层面，涉及不同的受众与审批流程。而任务列表则具有高度战术性，通常只需负责执行的工程师审核即可。 然而，大多数工具将所有内容都放在功能专属的文件夹下，导致难以提取领域级视图或跨功能跟踪技术演进。尽管智能体理论上可以汇总出整体视图，但核心问题依然存在：这些生命周期截然不同的产出物是否本就应该放在一起？ 团队应该从覆盖整个应用的产品需求文档开始，还是从现有待办事项中提取的某个具体功能开始？多数企业在 Jira、Azure DevOps 等工具中已有完善的需求清单，凝聚了数周乃至数月的梳理成果。然而，现有 SDD 工具并未与这些系统打通集成。 团队能否将现有待办事项中的功能接入 SDD 工作流？如何让需求清单与持续迭代的规范保持同步？缺乏清晰的集成方案已成为团队希望落地 SDD、却又不愿完全放弃现有工作规划与投入的主要障碍。 并非所有利益相关者都会参与全部阶段。产品团队专注于功能定义，仅需掌握高层技术认知；架构师聚焦系统设计与横切关注点；平台工程负责确保符合组织标准。但现有工具并未适配这些不同的参与模式。各方贡献应从何时开始、何时结束？如何知晓需要审核？由谁负责审批？这些协作机制的模糊之处，都会阻碍 SDD 的可持续落地。 不同 SDD 工具对规范的处理方式各不相同。多数采用 Markdown 文件，但格式可能是结构化的用户故事和验收标准（GitHub SpecKit），或则 EARS 模式（Amazon Kiro），等等。一些工具会为模式与消息负载生成机器可解析的格式（如 SpecKit 为 HTTP API 生成 OpenAPI），另一些工具则将测试直接嵌入到规范中，用以验证一致性（如 Tessl）。 规范文件的组织策略也各不相同。有的工具按功能维度组织规范（如 SpecKit、Kiro），有的维护单一可演进的规范，还有的采用混合方式，同时保留顶层规范与归档式功能规范（如 OpenSpec）。部分工具会在规范与代码工件之间建立一一对应的映射关系。不同工具所支持的规范详细程度也存在差异。 鉴于实现方式与粒度差异巨大，工具与规范风格的选择可能令人望而生畏。每种工具都自带一套会影响流程的设计理念，这对刚接触 SDD 的团队或许有帮助，但一旦工具的预设逻辑与团队实际工作方式不匹配，就会变成限制。 虽然 SDD 的最终目标是实现从意图到落地的对齐，但整个过程包含两类不同的转换： 意图到规范 规范到实现 意图到规范的对齐可通过对话与审核实现，真正显而易见却被忽视的关键问题是规范到实现的对齐。这种对齐验证已成为选择 SDD 工具或方法时的核心考量，因为每种规范风格都有其固有的可验证性特点。 无论是企业团队还是小型团队都有需要维护或添加新功能的遗留代码。在这种情况下，第一步应该是让大模型通读整个项目来生成规范，还是应该聚焦每个需要关注的领域并逐步构建规范？这其中有两个方面可能会造成障碍。 如果已有的应用规模很庞大，让大模型生成规范可能并不现实，因为会超出上下文窗口限制。即便成功生成了规范，也可能因为体量过大而难以审核。虽然通过代码反向校验规范能在一定程度上建立信心，但正如我们一直强调的，规范的核心在于捕捉意图，而意图必须经过人工审核。体量过于庞大的现有系统规范，会给审核带来极大困难。 虽然一些工具（如 OpenSpec，它采用增量方法在规范中捕捉现有信息）声称面向遗留系统场景，但在大规模环境下——上下文分散在多个仓库和项目中——这方面的模糊性可能成为采用的障碍。 尽管部分工具（如采用增量方式在规范中记录现有信息的 OpenSpec）宣称是面向遗留系统的，但在大规模环境下——上下文分散在多个仓库与项目中——这方面的模糊性仍会成为落地的障碍。 上述的不足属于战术层面的障碍，而非根本性壁垒。企业可以先将相关实践适配到现有工作流中，待价值显现后，再逐步向更贴近 AI 原生的模式演进，从而真正体现 SDD 的价值。 从头开始构建规范驱动开发工具看似诱人，但其推广成本可能很高。选择最贴近你理念、且具备扩展性的工具并进行定制会是一条更务实、能从实践中学习的路径。 以下是解决当前工具在入门阶段若干障碍的实用措施。 大多数 SDD 工具诞生于以开发者为中心的环境，因此从工程团队入手是合理的。但这不应要求产品经理去学习 Git 工作流。MCP 服务器提供了一个实用的集成层。 开发者可直接从 Jira、Linear 或 Azure DevOps 中将需求拉取到 SDD 工作流中，同时进度更新会自动回写到需求管理工具。 OpenSpec 采用三步式 SDD 工作流，变更通常会经过“提议”、“应用”和“归档”三个阶段。 图 5-a：OpenSpec 规范驱动开发工作流 在图 5-b 所示的改进工作流中，我们通过 MCP 与产品待办清单集成，采用适当的状态来对问题进行更新。这与默认通过 CLI 输入变更提议的方式不同： 从积压中选取问题进行"提议"时，将其移至"待办"状态； 当我们进入"应用"阶段实施时，问题移至"进行中"状态； 随后在"归档"时，问题移至"已完成"状态。 图 5-b：通过 MCP 与产品待办清单集成的 OpenSpec 改进版 SDD 工作流 这种简洁的集成方式充分尊重了产品团队已在需求管理上投入大量精力的现实。我们无需在新系统中重复工作，而是直接与现有系统打通。 将业务上下文与技术实现细节分离，对多仓库场景下的 SDD 编排至关重要。 以一个同时涉及前端、后端或跨越多个微服务的功能为例，需要明确仓库职责与集成模式，以便将工作拆解为合适的模块并进行跨边界协同。 图 6：通过 SDD 工作流实现产品负责人、架构师与开发者之间的协作 图 6 展示了产品负责人、架构师与开发者如何通过 SDD 工作流在三个不同阶段开展协作。 产品负责人与 AI 协作，明确功能背后的业务意图（即“做什么”与“为什么做”）。此次对话基于产品待办清单展开，业务相关方已在此场景下开展工作。 架构师与 AI 协作确定技术方案。对于涉及多个代码仓库的功能，在该阶段会将父任务拆解为各仓库对应的子问题。每个子问题均限定在单一仓库内完成，具备清晰的技术边界与依赖关系。重要的是，这些子问题会保留在待办清单中，以便产品与研发团队能够跟踪进度。 开发者在各自代码仓库中处理子问题，并与 AI 协作细化具体实现任务。技术执行细节（如模式定义、模块拆解等）均在这个阶段明确。这些产出物归属对应仓库，因为它们与待修改的代码库高度耦合。 通过这种职责分离，业务上下文在产品看板上保持可见，技术实现细节则保留在代码仓库中。 重要的是，架构师无需手动分解每个用户故事。相反，他们可以通过定义仓库边界、集成模式与架构约束为智能体搭建执行框架。在上下文的指导下，智能体能够自动将这些规范应用到新的用户故事中，为每个受影响的仓库生成对应的子问题。 当需要进行架构重构时，原始业务故事保持不变，而新的架构拆解会在不同仓库生成对应的子问题。业务意图保持不变，但技术实施策略可以持续演进。 下面是一个 Claude Code 实例基于项目级架构分解上下文，根据代码仓库职责更新 Linear 待办清单的示例。 图 7：基于架构上下文生成的前端和后端子问题 就像架构师提供架构指南一样，基础设施专家、性能专家、安全专家等其他角色也可构建各自的上下文框架，每个框架用于捕获对应领域的特定约束与模式。 关键同样在于配置智能体，将这些角色专属的指南叠加到传入的需求场景中，转化为工作项与任务。专业智能体可自动应用其领域专业知识，而非依赖人工审核，例如： 基础设施智能体添加部署约束 性能智能体标记优化需求 安全智能体识别合规要求 这为编排多个专业智能体奠定了基础，各智能体分层应用指导规则，将业务意图转化为完整、可落地的执行方案。 这可能是一个主观性较强的话题。以下从实用性与企业适用性角度，列出需要考虑的方面。 架构、代码组织、技术最佳实践等关注点属于跨功能范畴，会影响规范的细化过程，而非仅归属某一条具体规范。因此，对这类机制提供原生支持（如 SpecKit 中的 Constitution、Kiro 中的 Steering Docs）或具备实现该目标的可扩展能力至关重要。 能够提取或随时查看与当前应用状态高度一致的规范工件有助于开展验证工作。 虽然实现对齐很重要，但生成与实际代码高度一致的工件的工具可能是一把双刃剑。从审核负担角度看，让规范在规模上保持“可人工审核”至关重要，数量过于庞大将会让详细审核变得难以开展。 更务实的做法是优先采用能促进有效沟通的规范风格，以便在与 AI 协作时更好地交流思路、探讨方案。验证固然重要，但不应以引发抵触的方式影响规范风格，进而阻碍这一核心目标。 与其追溯性地为整个系统编写规范，不如采用增量式探索，这种方式更为实用。采用 SDD 的核心原因之一是通过向编码智能体精准提供其在特定工作领域所需的信息来降低上下文负担。规范只需在变更区域附近保持最细粒度，这种粒度同样能减轻前面章节中强调的审核负担。 这种方法与我们在测试驱动开发中重构遗留代码时所用的技术并无区别。我们会尽可能覆盖变更区域周边的现有逻辑，一旦具备足够信心，便对该区域进行有效隔离，帮助编码智能体专注于目标区域，而不是用过多细节污染上下文窗口。 随着时间推移，规范覆盖范围会在每次修改中逐步完善。错误修复、功能新增、重构工作，都可以成为为相关代码补充规范的契机。这种渐进式的方式能自然形成规模合理、便于人工审核的上下文，聚焦于活跃开发区域，避免了对整个遗留系统全面“编写规范”的不切实际做法，也减轻了由此带来的审核负担。 至此，我们已探讨了如何将 SDD 适配到现有组织模式，且不破坏已验证的工作流。一旦团队看到价值，问题就会转变为：组织应如何向更 AI 原生的交付模式演进？答案在于，将规范视为非静态工件，通过反馈循环持续优化的动态指南。 SDD 早期落地阶段的一个常见问题是：对于微小变更或错误修复，我们是否还需要遵循规范流程？难道不能直接修改代码吗？随着组织向规范原生开发转型，这个问题会变得愈发关键。 答案决定了规范是作为次要文档存在，还是作为一等工程界面。在成熟的 SDD 实践中，每一次变更——无论是主要功能还是微小错误修复——都必须经过规范。这与其说是遵守流程，不如说是认识到规范是指导智能体执行的核心界面。这也是我们向 AI 原生 SDLC 转型时流程层面的一个重大转变。 以往，我们会禁止直接修改服务器上的代码，因为这类直接变更会在下次部署发布时被覆盖。通过关闭服务器直接修改权限，团队必须在唯一可信源（版本控制中的代码）中进行修复，并通过规范的发布流程重新部署。这种限制确保了修复内容能在后续版本中持续生效。 同理，对于 AI 生成的代码，代码问题本质是规范缺口导致的结果。直接在代码层面修改反而会进一步扩大这一缺口。受 AI 生成的非确定性影响，每次基于该规范重新生成代码时，这类缺口都会以不同形式反复出现。持续手动修补代码难以规模化，尤其在 AI 短时间内生成大量代码的情况下更是如此。相比之下，将问题反馈至规范层面、闭合缺口，才是更可持续的方式。 因此，我们需要让“做正确的事”变得简单，即在规范层面而非代码层面开展工作。例如，尽管代码依然是我们进行版本控制和审核的产物，但编写代码的工作可仅限于 AI 编码智能体。 在 InfoQ 文章“规范驱动开发：当架构变得可执行”中，Leigh 和 Ray 引入了 SpecOps 概念，确立了规范编写作为一等工程界面的地位。 当规范成为需求进入系统的主要途径时，理应对它们采用与生产代码相同的质量规范、版本控制、审核流程和持续改进机制。 这一转变具有深远影响。如果智能体依据规范执行，那么规范的质量将直接决定最终实现的质量。缺陷不再只是代码问题，更是优化生成该代码的规范与框架的机会。这正是反馈循环发挥关键作用的地方。 当错误出现时，理解其根源至关重要。 规范本身清晰，但实现出现了偏差。这类问题需要强化任务完成验证机制，避免类似缺口再次出现；框架也需要更完善的验证智能体或更明确的实现约束。 商议过程中遗漏了用例细节，导致规范本身并不完整。这类问题需要通过向框架补充问题模式、调研步骤或分析框架来优化规范引导流程，确保后续需求在前期就能捕捉到这些细节。 这些问题不只是简单的错误分类，更是上下文框架的质量指标。每一个缺口都揭示了框架需要完善的地方。质量工程的角色也从验证实现结果演变为验证并改进指导智能体执行的框架。 图 8：框架反馈循环 图 8 展示了这一持续改进循环。当验证智能体发现规范与实现之间的缺口时，这些洞察会反馈到框架的优化中。随着时间推移，框架会沉淀更多领域知识、预见更多边界场景，并生成更完整的规范。系统并非通过修补实现来从错误中学习，而是通过完善指导未来实现的上下文来实现自我进化。 通过将规范编写视作一套包含反馈循环、质量指标与持续改进的运营体系，单个功能所需的人工细化工作会大幅减少，框架也能将积累的经验持续传承下去。 有人质疑，在意图、规范与实现无法完全对齐的情况下，SDD 是否仍有价值，这种质疑是合理的。虽然我们可以设计验证机制，基于规范独立测试实现，但可达到的对齐程度会随规范类型而变化。如果从一开始就追求完美对齐，可能会导致规范过于细碎，进而引发审核疲劳，阻碍落地推广。 从实践层面来看，即使在人类团队成员之间也同样需要面临对齐问题。在人工协作场景中，我们会通过机制修复问题，减少后续误解。同理，回顾式反馈循环有助于逐步提升对齐效果。每一个被发现的缺口都会强化框架，让后续的规范更完整、实现更一致。 这一转变标志着智能体编排开发中质量工作的根本性转变。质量专家不再审核最终实现，而是验证上下文框架、框架所承载的约束，以及这些验证机制能否及早发现偏差。其工作重心也从实现质量转向框架质量。 随着 AI 智能体具备持续自主执行能力，软件交付的瓶颈已经发生转移。核心不再是我们能多快编写代码，而是我们能多高效地表达意图。正如 Adrian Cockcroft 在旧金山 QCon 大会上所阐述的，我们正在学习指挥智能体集群。这种构建方式是一种与传统人员管理截然不同的组织能力。 SDD 为这一转变提供了可能，但前提是我们要认清其背后真正的变革是什么。产品团队需以足够清晰的方式阐明业务上下文，确保智能体能够理解用户价值与验收标准；架构师则必须将技术约束和集成模式编码为可复用的框架。工程师的角色将从编写实现，转变为验证智能体生成的代码是否与规范对齐；而质量专家也不再测试已完成的实现，转而保障上下文框架本身的健壮性。 有了 SDD，对话不再仅仅发生在人与人之间。规范成为产品、架构、工程与质量团队的协作界面，他们共同构建执行上下文，并由 AI 智能体转化为具体行动。而规范编写中的反馈循环，正是这类协作落地的核心环节。 将 SDD 作为技术进行推广的人将获得技术方面的收益，如更好的 Token 利用率、更持久的智能体运行时长、更少的幻觉现象。而将其视为组织变革的人将真正具备高效指挥智能体集群的能力，释放人类创造力用于解决战略性问题，同时由智能体完成多工作流的落地实现。 对于已经准备好转型的组织而言，这一转变并非遥不可及的未来，而是当下即可实现的能力。 原文链接： https://www.infoq.com/articles/enterprise-spec-driven-development/意图表达的演进：从指令到对话
氛围编程（Vibe Coding）——指令式交互
规划模式（Plan Mode）——更好的准备
规范驱动开发（Spec-Driven Development）——人机对话
企业落地：为何至关重要，且绝非单纯的技术部署
对话优于指令
协作上下文优于更智能的模型
“规范瀑布”（SpecFall）/ “Markdown 怪兽”的风险
SDD 规模化落地的挑战
以开发者为中心的工具
单仓库聚焦
缺乏关注点分离
起点不明确
协作模式未定义
规范的风格与粒度多种多样
规范到实现的对齐
遗留系统的落地路径不清晰
在不推倒重来的前提下落地 SDD
对接现有产品需求清单
产品待办清单集成示例
多仓库编排
发现阶段
设计阶段
任务阶段
角色特定贡献
规范风格与验证
顶层引导能力
顶层规范视图
合理的粒度
在遗留系统环境中采用 SDD
长期方向
框架治理
规范到实现的缺口
意图到规范的缺口
实现对齐的务实路径
结语