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