如何理解 SDD，以及规格驱动的开发流程？

SDD 是规格驱动开发：先把需求写成明确、可验证的行为规格，再据此设计、实现和验收。在 AI 编程中，规格让人和 Agent 对目标、边界与完成条件有共同依据，减少只靠对话逐轮猜需求。

常见流程是：澄清需求，写明输入输出、业务规则、异常和验收场景；形成必要的技术设计与任务；分步实现；按规格检查代码和实际行为；需求变化时同步更新规格、实现和测试。具体文件名和阶段划分随工具不同，并不存在所有项目必须采用的固定模板。

“实现订单导出”只是目标；有效规格还要说明导出哪些订单、谁有权限、字段与时间口径、空结果如何处理、数据量过大怎么办，以及如何判断完成。

例如：“门店经理只能导出所辖门店；日期采用业务约定时区；金额口径与页面一致；无记录时仍输出表头。”这些条件可以转为权限、边界和内容检查。技术方案再决定同步还是异步、如何分页等。规格要清楚，但不必把所有底层代码提前用自然语言写一遍。

需求中的每个关键行为，对应到实现任务和验收用例。AI 先读取相关代码与约束，再实施当前任务；验证发现缺口时，判断是实现偏离、规格含糊还是需求变化，更新正确的那一层。

规格需要随功能演进。只在开工前生成很长文档，之后不再核对，无法形成规格驱动；代码和测试都出自同一个错误理解，也不会因多了一份规格就自动正确。

TDD 以失败测试推动实现，再重构，侧重开发反馈循环；SDD 侧重把行为、约束与验收作为实现依据。两者可以结合：从规格中的场景形成测试，再小步实现。

Harness 则提供 Agent 的执行环境、工具、任务状态与检查反馈。规格说明要做成什么，Harness 让 Agent 能读取材料、修改代码并运行检查；写了规格，不等于系统已经具备这些执行能力。

跨模块、规则多、多人协作或需要长期维护的变更，较完整的规格能减少理解分歧。局部低风险修改，只需把必要行为和验收写清，不必额外生成整套文档。规格本身也有编写和维护成本，应按风险选择粒度。

不能保证。还要检查规格是否正确、相关约束是否被加载，以及真实行为是否通过验证。业务权限等硬约束应由执行层强制实施，不能只写在规格里。

先标明变更了哪些规则和验收，再找受影响的任务、代码与测试；已完成的部分按影响回归。保留变更依据，避免新旧规格同时指导不同模块。

国内：华为云：SDD开发模式标准工作流与斜杠命令实践：参考规格、设计、任务与实现的阶段分工，解释常见流程而不将产品命令当通用标准。
国内：民生银行信息科技部及民生科技作者；阿里系统软件技术发布：SDD在银行私域研发体系的落地探索：借鉴企业、领域、项目规格分层和轻量切入，解释维护成本与适用粒度。
国内：Snailclimb：Harness 是什么？Harness Engineering 六层架构与 Agent 工程实践：采用模型外执行、状态与验证机制的分工，解释SDD和Harness的关系。
国内：adongwanai：Coding Agent：仓库级任务、工具与验证：采用仓库级任务的上下文、变更范围及多种验证，说明规格如何落到执行。
国外：GitHub：Specification-Driven Development：采用规格作为持续演进依据、验收场景关联实现与测试的方法，说明规格不是一次性文档。
国外：Anthropic：Best practices for Claude Code：参考对照规格审阅并实际运行检查的做法，解释SDD不能自动保证实现正确。