SDD 深度讲解：从规约驱动开发到数字员工的底层方法
关键词追踪「{‘type’: ‘keyword’, ‘name’: ‘数字员工’}」 原文链接: https://mp.weixin.qq.com/s?src=11×tamp=1785625265&ver=6879&signature=CSabWow*1jD1-gATg1U5hOru1hKKQUaxq6SjnI6AWvkCa6lV7G3C*wQJsLtnS-9qPaEoObcMQZI-MEnq69FBcMbT1WarBljWwM2b0g8uJw9asIc6WVr-Sepm0wESqeum&new=1 发布时间: 2026-08-01 03:45 监控类型: 关键词追踪
核心观点
-
不积跬步无以至千里，欢迎来到AI时代的编码实战课
-
传统软件开发里，代码通常是事实源。
-
需求文档会过期，设计文档会失真，接口文档会落后，测试用例也可能不完整。最后系统到底做了什么，往往只能去读代码、跑系统、查数据。
-
它希望团队维护一套结构化、无歧义、可验证、可被机器理解的规约文档。系统的业务意图、边界条件、验收标准、关键约束，都沉淀在 Spec 中。AI 或工程系统再根据 Spec 生成代码、测试、配置、文档甚至部署流程。
-
理想状态下，链路应该是：
-
描述系统意图的完整 Spec → AI / 自动化系统 → 可运行软件在这个链路里，Spec 不是附属说明，而是系统的主资产。代码只是某个时间点、某种技术栈下的实现投影。
全文
不积跬步无以至千里，欢迎来到AI时代的编码实战课
传统软件开发里，代码通常是事实源。
需求文档会过期，设计文档会失真，接口文档会落后，测试用例也可能不完整。最后系统到底做了什么，往往只能去读代码、跑系统、查数据。
SDD 想反过来。
它希望团队维护一套结构化、无歧义、可验证、可被机器理解的规约文档。系统的业务意图、边界条件、验收标准、关键约束，都沉淀在 Spec 中。AI 或工程系统再根据 Spec 生成代码、测试、配置、文档甚至部署流程。
理想状态下，链路应该是：
描述系统意图的完整 Spec → AI / 自动化系统 → 可运行软件在这个链路里，Spec 不是附属说明，而是系统的主资产。代码只是某个时间点、某种技术栈下的实现投影。
这背后的吸引力非常大。
因为如果 Spec 真能成为唯一事实源，很多软件工程的老问题都会被重新改写：
所以，SDD 的真正野心不是“让 AI 写代码更准一点”，而是重建软件生产中的事实源秩序。
今天很多讨论里，大家会把 SDD 和 SDD 框架混在一起。但这两者要分开看。
SDD 是一种开发范式。它回答的是：软件系统的事实源应该放在哪里？是代码，还是规约？
SDD 框架是一套执行系统。它回答的是：在今天的大模型能力、上下文限制、工具链限制和生产环境约束下，如何让 Agent 尽量稳定地围绕规约完成任务？
SDD：规约是本体，代码是产物。SDD 框架：用工程化流程约束 AI，让它尽量按规约完成任务。这一区分非常重要。
因为从愿景上说，SDD 想要的是：
描述意图的完整文档集 → AI → 产出软件但今天大多数场景实际做不到。于是 SDD 框架要在中间填坑，链路变成：
描述意图的文档集 → SDD 框架 → AI / Agent → 产出软件再往真实生产环境里走一步，又会继续降级：
描述局部意图的增量文档 → SDD 框架 → AI / Agent → 功能迭代这就是今天大多数 SDD 实践的真实形态。
它不是在维护一个覆盖全系统终态的 Spec，也不是让 AI 根据完整规约重建软件，而是在一个具体需求、一个局部变更、一次功能迭代中，用一套阶段化工作流约束 AI：先澄清，再计划，再拆任务，再实现，再验证。
这个过程当然有价值，但它已经不是最理想形态的 SDD，而是“面向 Agent 执行控制的 SDD 框架”。
SDD 的想法看似美好，但一落到日常迭代，马上会遇到一地鸡毛。
真实研发很少每天从零生成一个系统。大多数工作都是增量迭代：增加一点能力，减少一点逻辑，改一个字段，补一个权限，修一个边界条件。
如果这时要求团队维护一份表达系统全量终态的 Spec，成本会非常高。很多团队最后会自然退化成：每次需求写一份“增量 Spec”。
但问题在于，增量需求文档很难成为唯一事实源。
唯一事实源更像是一份终态、静态、可被查询和验证的系统规约；而过程中的增量需求，本质上是一组变化记录。它能解释“这次为什么改”，却不一定能回答“系统现在完整是什么样”。
如果 Spec 只是增量意图文档集，它就很难承担“项目唯一真理之源”的角色。
很多人记住了“Spec 要结构化、要 AI 友好”，但没有认真定义 Spec 到底应该包含什么。
结果 Spec 很容易变成大杂烩：
这些内容都重要，但不应该全都混在同一个层次里。
如果不分层，Spec 会越来越臃肿，AI 读起来也越来越容易偏移。它看似“上下文很完整”，实际却是目标、约束、设计、实现细节、历史过程全部搅在一起。
即使我们真有一套很大的系统规约，也会撞上大模型的现实限制。
一方面，上下文窗口有限，不可能每次任务都把全量系统知识塞进去；另一方面，长上下文下指令会偏移，模型会遗忘前面的关键约束，也会被后面的局部信息污染。
所以，把一个巨大的“描述意图的文档集”直接丢给 AI，让它稳定产出正确软件，在今天并不现实。
这也是为什么所有 SDD 框架最后都会不约而同地回到一件事：
用工程化阶段约束，提高 AI 生成质量。
常见流程是：
头脑风暴 / 澄清 → Plan → 拆 Task → 实现 → 验证这和提示词时代的 RIPER-5 本质上没有太大区别：都是用阶段化、门禁化、文件化的方式，约束 AI 不要在一个长上下文里自由发挥。
也就是说，SDD 的宏大愿景今天还很难完全实现，但 SDD 框架作为“驾驭 Agent 的工程系统”，已经有明确价值。
如果说 SDD 的目标是“规约成为事实源”，那么 SDD 框架的目标就是：
让 Agent 在长时间、多轮、多工具、多子任务的执行过程中，始终围绕 Spec 稳定推进。
这里的核心不是单纯扩大上下文窗口，而是建立一套围绕 Spec 的持续对齐与执行控制机制。
因为真实任务中，Agent 会面临很多问题：目标漂移、约束遗忘、上下文污染、状态混乱、子任务冲突、执行失控、成本不可控、结果不可验证。
归纳下来，成熟的 SDD 框架至少要解决五个根本问题。
Agent 怎么保证自己始终围绕原始 Spec、关键约束和验收标准执行？
它不仅要知道“要做什么”，还要知道“不能做什么”“什么算完成”“哪些决策不能擅自改”。
如果没有目标锚定机制，Agent 很容易在执行中逐渐偏离原需求。尤其是任务很长、涉及多个文件、多轮修复、多次测试失败时，它会越来越关注眼前局部错误，而忘记最初的业务目标。
长任务一定涉及上下文加载、摘要、压缩、恢复和局部检索。
问题是：哪些信息必须保留？哪些信息可以压缩？摘要会不会丢掉关键约束？后续子任务拿到的上下文是否足够？
如果上下文治理不好，Agent 做出的推理就是“局部正确、整体错误”。
长任务不是一次对话完成的。
它会有阶段、任务、依赖、阻塞、失败、重试、人工决策、验证结果。框架必须维护这些状态，否则 Agent 很容易重复做事、漏掉任务、把失败当成功，或者在上下文恢复后不知道自己做到哪里。
复杂任务通常需要主 Agent、SubAgent、工具、脚本和人协同完成。
谁负责探索？谁负责设计？谁负责实现？谁负责审查？哪些任务可以并行？哪些必须串行？什么操作需要人工确认？什么命令不能跑？成本和权限边界在哪里？
这些都不是模型自己“聪明一点”就能稳定解决的问题，而是框架必须提供的执行控制能力。
Agent 最危险的地方，不是做错，而是“自信地宣布做完”。
所以 SDD 框架必须让执行过程可观测、可追溯、可验证。每个完成声明都应该有事实依据：测试结果、日志、截图、差异审查、验收用例、人工确认或对抗检查。
没有验证闭环，SDD 框架就只是一个看起来很完整的生成流程。
围绕上面五个问题，成熟的 SDD 框架通常会引入七类机制。
通过 Hook、约束再注入、上下文加载策略、压缩校验和关键事实回填，保证 Agent 在长任务执行过程中始终使用正确、完整、可信的上下文。
重点不是“尽量塞更多内容”，而是“在正确阶段加载正确内容”。
比如探索阶段需要更多代码与业务线索，计划阶段需要稳定约束和全局设计，实现阶段需要聚焦当前文件和接口契约，验证阶段需要验收标准和变更差异。
长任务不能依赖单个会话的短期记忆，而要依赖可恢复、可追溯的工程资产。
所以 SDD 框架会把需求、设计、计划、任务、决策、测试和验证结果文件化。文件不是为了仪式感，而是为了让任务可以恢复、可以审计、可以被多人和多个 Agent 接力。
框架需要通过脚本、状态文件和任务账本维护阶段状态、任务依赖、阻塞点和恢复点。
这能避免 Agent 在长任务中“靠感觉推进”。什么时候能进入实现？什么时候必须回到澄清？什么时候测试失败要修改计划？什么时候需要人工决策？这些都应该由状态机或门禁规则表达。
复杂任务可以通过主 Agent / SubAgent 分层协作、任务依赖图和上下文隔离，实现并行探索与局部处理。
但多 Agent 不是越多越好。关键是让不同 Agent 拿到合适的上下文，承担清晰的角色，并把结果回流到统一状态中。否则只是把一个混乱上下文拆成多个混乱上下文。
SDD 框架不是要消灭人，而是要减少无效打断，把必须由人判断的事情提前暴露。
比如需求边界、业务取舍、风险偏好、技术债接受程度、兼容策略、数据迁移方案，这些应该在任务开始阶段通过澄清、事件风暴和决策门禁处理掉。
越晚发现这些问题，Agent 的返工成本越高。
通过测试驱动、验收测试、基于规格和差异的审查、测试日志、对抗审查，形成事实驱动的验证闭环。
关键原则是：
每个完成声明都必须有事实依据。
“代码看起来改了”不算完成；“AI 觉得没问题”不算完成；只有被测试、日志、审查或用户验收支撑的结果，才算进入交付状态。
真实工程里还必须考虑工作区隔离、沙盒环境、权限策略、预算控制、中断机制和标准化交付包。
尤其是涉及生产数据、账号权限、外部服务、部署发布、批量修改时，SDD 框架必须提供明确边界。
否则 Agent 的效率越高，风险也越高。
一句话总结：
成熟的 SDD 框架，本质上是在 Agent 外部建立一套“目标锚定、上下文治理、状态编排、任务分解、多 Agent 协作、验证闭环和安全交付”的工程系统，让 Agent 不再依赖单次长上下文记忆，而是在可恢复、可审计、可验证的流程中持续推进。
粗看起来，SDD 框架似乎就这几个模块：澄清、探索、计划、任务、实现、验证、交付。
但实际效果好坏，全在细节。
尤其是 Explore，也就是“探索上下文”这个动作。
如果基于需求扫到的代码上下文足够完备，Plan 的准确性会大幅提高；如果扫出来的上下文不完备，后面再漂亮的计划也很可能建立在幻觉上。
我之前遇到过一个给新功能加对应权限的需求。
AI 在探索时发现，以前给新功能加权限是通过 DDL 写数据实现的。它还识别到近期既有人往老的功能权限表加数据，也有人往新的功能权限表加数据。于是 AI 判断：新老功能权限表都还在使用，所以两边都应该各加一组权限。
结果上线后，同一个功能出现了复数权限数据，使用侧报错。
问题在哪里？
AI 没扫到更早的一段历史 DDL：当有人往老表加新数据时，会自动触发同步一份到新表。所以近期还有人往老表加数据，并不代表老表仍是读链路事实源。
同时，使用侧也就是读的角度，实际上已经全部切换成走新表，老表没有任何真实使用入口。
如果这些信息都在上下文里，AI 并不难分析出正确结论：只需要往新表加一组权限数据即可。
这个例子说明，SDD 框架不能只写一句“先 Explore”。它必须进一步定义：
这些细分约束看起来琐碎，却决定了框架到底是在“装样子”，还是在真正增强 AI 的工程能力。
很多开源 SDD 框架会被调侃成“只能做 Demo、难以上生产的工程玩具”。
这个评价不一定公平，但它指出了一个真实问题：真实生产环境里，大多数研发面对的不是一个从 0 到 1 的新系统，而是一个长期演进、多人接手、充满历史包袱的遗留系统。
遗留系统最大的难点，不只是代码量大、逻辑复杂，而是真实业务路径和代码结构之间往往不是一一对应的。
代码里看起来像“同一个功能”的东西，在真实业务里可能分布在多条入口、多套页面，牵一发动全身；业务上看起来像“同一个场景”的东西，在代码里又可能是几套完全独立的实现，需要散弹式修改。
这种错位在生产系统里非常常见。
所以，遗留系统真正麻烦的地方，不是“有一段复杂代码需要读懂”，而是你很难一开始就知道完整业务路径在哪里，也很难确定自己看到的那条代码链路是不是唯一链路。
它的复杂性不是集中在一个文件、一个模块、一个调用栈里，而是分散在入口、角色、配置、历史分支、运行时状态和业务约定之间。
这对 AI 非常不友好。
AI 通常会先通过代码搜索定位相关核心片段，再根据文件关系把调用链捞出来。但这里有两个风险：
-
定位到的代码可能不是唯一核心片段；
-
捞出来的调用链分支可能不完备，受限于查看深度和摘要质量，关键上下文会丢失。
而遗留系统恰恰经常把关键上下文藏在当前代码片段之外。它不一定能通过一次静态扫描完整发现。
于是 AI 很容易基于当前看到的页面、接口或调用链，做出“局部正确”的实现，却遗漏其他角色、其他入口、其他历史链路下的真实生产场景。
我之前做过一个“在线索详情页增加字段”的需求，就遇到过类似问题。
当时我让 AI 基于浏览器里已经登录好的线索详情页去定位代码，并按预期完成了字段展示。初步验证时，销售经理角色下字段正常出现，但换成销售助理角色后，字段却消失了。
最开始我们以为页面里存在按用户角色控制字段展示的逻辑，于是让 AI 反复扫描条件渲染、权限判断、字段配置，却始终找不到问题。
后来在排查过程中才偶然发现：销售助理进入线索详情页的 URL 和销售经理并不一样。
也就是说，从最前面的线索列表页开始，不同角色进入的就是两套独立页面，而不是同一个页面里的角色分支。
这个例子说明，遗留系统里的开发任务不能简单依赖流程化的 SDD、文档模板或工程约束来解决。
真正困难的不是“让 AI 按规范写代码”，而是：
这背后依赖的是研发人员对业务上下文的组装能力、对历史实现的判断能力，以及对最终改动影响范围的决策能力。
更现实的是，即便 as-is 扫描对了，很多时候我们也会受限于影响范围不可控，选择一些不那么优雅、但风险更低的补丁式实现。
还有一些上下文根本不在代码仓里。比如当前要动的表是大表，已经不允许加字段，只能走垂直表实现。这种信息不是扫代码能得到的，而是来自团队约定、生产经验和组织上下文。
所以，面向遗留系统的 SDD 框架，不能只服务于 AI 自动执行，还要服务于人快速理解。
我自己写遗留系统 SDD 时，就会额外增加几个环节。
先让 AI 生成当前系统的现状总结和时序图。
目的不是让 AI 直接开改，而是让我快速理解现状，知道应该找谁、问什么、确认哪些隐藏上下文。
To-Be 不只写整体实现设计，还要明确呈现和 As-Is 的差异：
这样我能快速理解整体变更范围，而不是只看到一堆代码改动。
当前所有变更点，对已提供服务的依赖方可能造成什么影响和风险，需要提前列出来。
这只能形成初步认知，更多判断还要结合调用方使用情况和领域重要性，但它能显著提高人介入补齐上下文的效率。
这也是我对遗留系统 SDD 的基本判断：
人介入避无可避，所以好的 SDD 框架不是假装不需要人，而是用 AI 提高人补齐上下文、判断风险和做决策的效率。
如果把 SDD 框架理解成通用流程，它很容易停留在 Demo 水平。
真正可用的框架，一定要在细节上深入，在场景上定制。
因为不同场景下，Spec 的结构、上下文加载策略、验证方式、权限边界和人工介入点都不一样。
从 0 到 1 做新项目，重点可能是需求澄清、架构边界、模块拆分、验收测试和快速生成。
做遗留系统迭代，重点就是 As-Is 还原、真实业务路径发现、影响面分析、兼容策略和低风险落地。
做数据链路，重点是数据口径、血缘、幂等、补偿、监控和回滚。
做权限系统，重点是读写链路、历史同步、角色入口、鉴权边界和重复数据风险。
做企业内部业务流程，重点可能根本不是代码，而是岗位职责、审批节点、异常处理、表单字段、系统入口和人工兜底。
所以，一个好的 SDD 框架不应该只提供一套固定模板，而应该提供一组可组合的能力：
换句话说，SDD 框架的核心价值不是“流程长得像不像”，而是“它是否把一个领域里真正难、真正容易出错、真正依赖经验的地方显性化”。
到这里，SDD 其实已经可以从软件研发扩展到更大的范围。
因为很多业务领域本质上也有自己的“规约”。
企业里的 SOP、制度、岗位手册、审批流程、客服话术、风控规则、销售流程、交付流程，都是某种形式的 Spec。只是它们过去主要是给人看的，格式松散、执行不稳定、反馈不闭环。
AI 出现后，这些业务 SOP 有机会被重新改造成 SDD 形态。
也就是说，业务流程不再只是文档，而可以变成：
业务 Spec → Agent 执行 → 工具调用 / 系统操作 / 人工确认 → 结果验证 → 过程沉淀例如，一个企业报销流程可以被表达成：
这就是业务版 SDD。
它不一定生成代码，但它会驱动 Agent 操作企业系统、调用工具、读取上下文、完成流程，并把执行过程变成可追溯、可验证、可优化的资产。
所以 SDD 的长期价值，不只是“让 AI 更好写代码”，而是让组织里的知识、流程和执行方式，都从面向人的自然语言说明，升级成面向人和 AI 共同执行的规约系统。
如果继续往前推，未来的数字员工大概率会是这样一个组合：
数字员工 = SDD + 企业上下文 + 通用 Agent这里的通用 Agent，可以理解成“马鞍 + LLM”。
LLM 是通用认知能力，负责理解、推理、生成、判断；马鞍是企业为 LLM 装上的执行系统，负责工具调用、权限控制、上下文装载、状态管理、流程编排、审计日志和安全边界。
没有马鞍，LLM 很聪明，但难以稳定进入企业生产流程。
没有 SDD，Agent 有执行能力，但不知道应该按照什么稳定规则做事。
没有企业上下文，Agent 即使懂通用知识，也不知道这家公司的组织结构、业务规则、历史债务、系统入口、数据口径和风险偏好。
所以真正可用的数字员工，不会只是一个聊天机器人，而更像：
企业上下文提供事实SDD 提供任务规约通用 Agent 提供执行能力马鞍提供工程约束和安全控制最终形态很可能是 Web 端的、全自动的数字企业操作系统。
员工在 Web 端提出目标，系统根据企业上下文和 SDD 流程自动拆解任务、调用工具、推进流程、请求必要审批、执行变更、验证结果，并把全过程沉淀为可追踪资产。
这不是简单的“AI 助手”，而是企业流程被 AI 原生重构之后的运行方式。
在中国企业环境里，这条路线大概率还会受到数据安全和合规要求的强约束。
很多企业的核心数据、客户数据、经营数据、内部流程，不可能长期无差别交给外部闭源模型和外部 Agent 平台。
因此，未来相当一部分企业会走向：
国产 LLM + 自研通用马鞍 + 自调 SDD国产 LLM 负责基础模型能力，满足数据安全、私有化部署、合规审计和成本控制要求。
自研马鞍负责把模型接入企业真实系统，包括权限、工具、账号、日志、队列、审批、回滚、监控和沙盒。
自调 SDD 则负责把企业自己的软件研发流程、业务 SOP、组织经验和领域约束，沉淀成可执行、可演进的规约体系。
这三件事里，模型能力当然重要，但真正形成企业差异化的，很可能不是模型本身，而是马鞍和 SDD。
因为通用模型会越来越普及，基础能力会持续逼近；但每家企业的业务上下文、流程细节、系统历史、风险偏好和组织协作方式都不一样。
谁能把这些东西沉淀成可执行的 SDD，并通过可靠马鞍接入 Agent，谁就更有可能率先形成真正的数智化能力。
回到最开始的问题：SDD 到底是什么？
它不是一个模板，不是一组提示词，也不只是让 AI 按阶段写代码。
SDD 的本质，是把意图、规则、约束和验收标准提升为系统的事实源；SDD 框架的本质，是在今天模型能力还不完美的条件下，用工程系统约束 Agent，让它围绕规约稳定执行。
理想 SDD 追求的是：规约成为本体，代码成为产物。
现实 SDD 框架解决的是：在上下文有限、任务复杂、系统遗留、人机协作不可避免的条件下，让 AI 更少漂移、更少遗忘、更可验证、更能交付。
真正好的 SDD 框架，一定不是通用流程堆叠，而是深入场景细节：知道什么时候要扫读链路，什么时候要找历史迁移，什么时候要做人为决策，什么时候要补 As-Is，什么时候要给出 To-Be 差异，什么时候必须走验证门禁。
更进一步，SDD 不会停留在软件研发里。企业业务 SOP 经过 AI 再造后，也可以用 SDD 的形式沉淀下来，成为数字员工执行任务的规约底座。
未来的数字员工，大概率就是：
SDD + 企业上下文 + 通用 Agent（马鞍 + LLM）而未来一两年的关键主线，很可能不是单纯“等模型变强”，而是设计马鞍、调好 SDD、沉淀企业上下文。
这件事本质上是在给 AI 铺路。
当路铺好以后，AI 才不只是一个会回答问题的工具，而会真正进入企业流程，推动组织从信息化、数字化，走向真正的数智企业。
SDD 的终局不是让 AI 多写代码，而是把企业的软件规则和业务流程沉淀成可执行、可验证、可演进的规约系统；数字员工则是在 SDD、企业上下文和通用 Agent 共同作用下长出来的新型组织执行单元。
一、SDD 的本质：把“意图”提升为系统的事实源
二、SDD 和 SDD 框架不是一回事
三、为什么纯粹 SDD 愿景很难直接落地
四、SDD 框架真正要解决的五个问题
五、这些问题通常怎么解决
六、真正拉开差距的不是模块，而是细节
七、为什么开源 SDD 框架常常只能做 Demo
八、遗留系统里的 SDD：先帮人补齐上下文
九、优秀的 SDD 框架一定要做场景定制
十、SDD 不限于软件研发：业务 SOP 也可以被 AI 再造
十一、未来数字员工：SDD + 企业上下文 + 通用 Agent
十二、为什么很多企业会选择国产 LLM、自研马鞍、自调 SDD
十三、结语：未来一两年的主线，是给 AI 铺路
如果今天你只记得一句话
-
日常需求大多是增量的，不是全量快照
-
Spec 的边界很容易失控
-
大模型上下文不是无限可靠的
-
目标与约束对齐问题
-
上下文完整性问题
-
任务状态一致性问题
-
执行编排与控制问题
-
验证与交付问题
-
上下文治理
-
文件化工作流
-
状态机编排
-
多 Agent 协作执行
-
人工决策前置
-
验证门禁
-
安全与交付控制
-
As-Is 现状图
-
To-Be 方案和差异描述
-
影响面和风险清单
需求变更不再靠人到处找代码改，而是先演进规约，再驱动实现变化；
测试不再只是研发补充质量，而是从规约中自然派生的验收表达；
重构不再是高风险的大规模手工迁移，而是同一意图在新技术栈下的重新生成；
知识传承不再依赖“老人带新人”，而是依赖结构化、可追溯、可执行的系统说明。
有业务故事卡和验收标准；
有技术约束和技术选型；
有表达意图的描述；
也有表达实现的描述；
有长期稳定的系统规则；
也有一次性需求过程中的讨论记录。
什么场景直接用命令查；
什么场景需要启动 Explore SubAgent；
什么场景用 medium 探索；
什么场景必须 very thorough；
涉及写链路变更时，是否必须把读链路也拉进来分析；
涉及历史迁移时，是否必须搜索更早的数据同步、兼容逻辑和读写切换记录；
涉及权限、配置、数据表时，是否必须同时验证生产使用侧的真实入口。
这个需求到底覆盖哪些真实业务路径？
应该改哪几套实现？
有没有隐藏入口也需要一起验证？
当前改动会影响哪些服务依赖方？
哪些地方虽然技术上可以改，但业务风险不可控？
新增了什么环节；
删除了什么环节；
修改了什么环节；
哪些链路保持不变；
哪些入口需要一起验证。
不同类型 Spec 的分层表达；
不同任务场景的探索策略；
不同风险等级的验证门禁；
不同组织环境下的人工决策点；
不同交付对象的结果呈现方式；
不同 LLM 能力边界下的上下文压缩与约束注入。
什么角色可以发起；
哪些票据必须上传；
哪些金额走自动审批；
哪些异常必须人工复核；
需要调用哪些系统；
每一步的验收条件是什么；
执行失败如何补偿；
过程日志如何归档。
不积跬步无以至千里，欢迎来到AI时代的编码实战课
用工程化阶段约束，提高 AI 生成质量。
让 Agent 在长时间、多轮、多工具、多子任务的执行过程中，始终围绕 Spec 稳定推进。
每个完成声明都必须有事实依据。
成熟的 SDD 框架，本质上是在 Agent 外部建立一套“目标锚定、上下文治理、状态编排、任务分解、多 Agent 协作、验证闭环和安全交付”的工程系统，让 Agent 不再依赖单次长上下文记忆，而是在可恢复、可审计、可验证的流程中持续推进。
人介入避无可避，所以好的 SDD 框架不是假装不需要人，而是用 AI 提高人补齐上下文、判断风险和做决策的效率。
SDD 的终局不是让 AI 多写代码，而是把企业的软件规则和业务流程沉淀成可执行、可验证、可演进的规约系统；数字员工则是在 SDD、企业上下文和通用 Agent 共同作用下长出来的新型组织执行单元。