目录核心反转规格从“写完就丢的脚手架”变为“可执行的真相来源”标准工作流四个阶段每个阶段都有验证闸门SDD的严谨度谱系不是非此即彼与你上一轮问题的关联SDD如何改变团队协作的“验证”逻辑SDDSpecification-Driven Development规格驱动开发可以理解为在AI深度参与编码的背景下将“规格”而非“代码”重新确立为软件开发的单一事实来源让代码成为从规格派生的、可再生成、可验证的次级产物。它回应的是上一轮讨论中隐含的一个问题当AI能够快速生成代码时如果“意图”仍然散落在模糊的提示词、口头沟通和头脑中的假设里AI的高速产出反而会放大偏差。SDD的本质是把意图的精确表达变成开发流程中真正的“第一等公民”。核心反转规格从“写完就丢的脚手架”变为“可执行的真相来源”传统开发中需求文档往往写完就过时代码才是实际上的权威——想知道系统到底做什么只能“读代码”。SDD 颠倒了这一关系规格是权威描述代码是从规格生成或据其验证的派生输出。GitHub Spec Kit 对此的表述很直接规格不再是指导实现的“脚手架”而是变得可执行直接生成可运行的实现。维护软件也就变成了维护规格。这一反转之所以在AI时代获得新的紧迫性是因为大语言模型“擅长模式补全但不擅长读心”。一句“给我的应用加个照片分享功能”AI必须猜测格式、权限、存储、压缩等数十个未言明的假设产出的代码看似合理却可能处处偏离意图。SDD用一份无歧义、可验证的规格替代松散提示让AI在明确的约束下工作。标准工作流四个阶段每个阶段都有验证闸门SDD 的典型流程被划分为四个顺序推进的阶段每个阶段都产出明确的制品并在进入下一阶段前设置验证检查点阶段核心问题产出物指定Specify软件应该做什么、为什么做规格文档需求、验收标准、约束规划Plan从技术上如何实现技术计划架构、技术栈、需求与策略的映射任务Tasks如何拆成可独立执行的小块有序的可执行任务清单实施Implement按规格、计划和任务写出代码经过验证、符合原始需求的代码关键不在于阶段划分本身而在于闸门机制规划前必须确认规格完整生成任务前必须验证计划可行实施前必须检查任务覆盖代码必须对照规格验证后才算完成。这使得“规格是否被忠实实现”成为一个可以在每个节点上被明确回答的问题而不是等到交付时才暴露偏差。SDD的严谨度谱系不是非此即彼SDD 并非要求所有场景都用同一种强度。研究与实践收敛出三个递进层级团队可以根据模块的关键程度选择适用级别规格优先Spec-first实现前先写规格功能完成后规格可以丢弃代码仍是权威来源。这是2025年最常见的形态适合探索性较强或生命周期较短的功能。规格锚定Spec-anchored规格在整个演进过程中被持续维护代码和规格双向对齐。规格是活的制品变更先改规格再重新生成或调整代码。适合需要长期维护的核心模块。规格即来源Spec-as-source规格是唯一的手动编辑对象代码完全自动生成人类只编辑规格绝不直接修改代码。这要求规格本身具备足够的形式化程度和工具链支撑目前适用于对确定性要求极高的领域。Marc BrookerAWS VP/Distinguished Engineer还提出了一个务实的补充原则规格深度可以分层——核心领域用“规格锚定”辅助功能用“规格优先”一次性脚本完全可以跳过SDD。把SDD理解为“每个需求都必须写一份详尽规格”是对它最常见的误解。与你上一轮问题的关联SDD如何改变团队协作的“验证”逻辑上一轮讨论的结论是端到端负责的团队需要保留独立验证的专业能力以对冲AI的“认知同源”风险。SDD 在方法论层面为这一原则提供了落地机制。在传统分工中独立验证主要依赖测试角色的人工判断在SDD中验证的锚点被前移并客观化了——规格本身就是一份事先写定的、与实现路径解耦的契约。AI可以生成代码也可以生成测试但“代码是否满足规格”这一判断依据的是人或独立验证角色事先定义的规格条款而不是AI对自己产出的自我评估。这并不意味着测试角色失去价值而是其重心从“执行测试”转向定义规格中的可验证约束、审查规格的完整性与无歧义性、以及判断AI生成的验证是否真正覆盖了意图。SDD 也与TDD/BDD有本质区别TDD/BDD以测试作为驱动SDD以规格作为驱动测试是从规格正向推导的产出物之一而非驱动开发的起点。它不属于传统测试驱动方法论的延伸序列而是AI原生开发条件下的一种独立范式。一句话概括SDD 是AI时代对“意图必须精确到可被机器执行和验证”这一要求的工程化回应。它把软件开发的锚点从易变的代码移回到可审计、可演进、可作为人与AI共同契约的规格上而团队的分工也随之从“谁写哪段代码”转向“谁对规格的完整性与验证的独立性负责”。