以规范为导向的开发模式——在企业规模中的应用

意图表达方式的演变：从指令式交互到对话式交流

过去一年中，人工智能在编码领域的应用发生了重大变化。我们已经从在集成开发环境和聊天界面之间复制代码，转变为使用专门设计的命令行工具和基于人工智能的编辑器。

“氛围式编码”——基于反馈的迭代过程

然而，即便这些工具不断进化，“氛围式编码”（即在没有事先周密规划的情况下，通过与人工智能的交互逐步完善代码）的本质仍然主要是指令式的，每次只提供一条提示信息。具体的实现过程本身会成为后续调整的依据。

图1：氛围式编码的工作流程

“计划模式”——更充分的准备

“计划模式”（即让人工智能先制定执行方案，供人类审核后再开始编写代码）标志着人工智能辅助编码技术的一次重大进步。这种模式要求人类和人工智能在开始实施之前共同讨论并确定任务清单、相关的验证机制等，从而延长了独立执行的时间，并使最终结果更加完善。这是我们第一次与人工智能进行“启动会议”，因为我们认识到，充分的前期沟通才能确保最终取得协调一致的结果。

然而，人类与人工智能之间的交互仍然属于战术性和指令性的性质。由于计划通常只在执行阶段之后才会被保留下来，因此实施过程本身就成了进一步优化和添加新功能的主要依据。

图2：规范驱动开发的工作流程

规范驱动开发——人类与人工智能的对话

当人工智能模型开始能够在较长时间内持续专注于复杂任务时，规范驱动开发这一概念应运而生。如果人类与人工智能之间的互动只是以单向指令的形式进行，那么这种能力就无法得到最佳利用；而让人工智能独立运行过长时间，则很容易导致结果与预期目标大相径庭。因此，我们需要通过有效的机制来确保双方的目标能够保持一致。规范驱动开发正是通过建立人类与人工智能之间的共同理解来实现这一目标的——其中，各种规范为两者之间的对话提供了基础，而不是仅仅作为操作说明书使用。

图3：规范驱动开发的高层工作流程

本文探讨了企业如何采用规范驱动开发模式，分析了当前需要解决的工具缺陷、哪些集成方式能够帮助团队快速获得实际收益，以及为确保这一模式能够大规模持续应用所需进行的利益相关者协作调整。

企业的采纳：其重要性及为何并非单纯的技术实施过程

在多个技术层面，规范驱动开发已经展现了明显的价值。它不仅能够让人工智能模型更长时间、更专注地独立执行任务，还能帮助解决令牌使用和上下文管理相关的问题，从而实现人工智能资源的最佳利用并降低运营成本。

然而，规范驱动开发带来的最显著影响可能并非技术层面的，而是文化层面的。

超越指令的对话

当高级工程师们进行协作时，他们的沟通方式往往是对话式的，而非单向下达指令。正是通过对话，我们才能达成共同的理解，而这种理解才是我们开展工作的基础。规范驱动开发同样促进了人类与人工智能之间的这种对话模式——在具体执行任务之前，人工智能能够帮助我们思考解决方案，挑战各种假设，并进一步完善我们的计划。

图4：规范驱动开发的详细工作流程

图4展示了规范驱动开发工具是如何帮助我们与人工智能进行有效沟通的。虽然某些工具会将开发过程划分为发现、设计和执行三个阶段，但其他工具可能会采用更加细致或灵活的方法。关键在于通过规范为人与人工智能之间的迭代性交流创造机会。尽管新型的人工智能模型能够提供更长的上下文处理范围和更强的推理能力，但如果我们不把人工智能视为我们解决方案的共同创造者，就无法充分利用这些优势。

在更智能的模型之上，协作才是关键

从概念层面来看，在规范驱动开发的模式下，团队可以将各项功能分解为具体的组成部分，从而指导人工智能的自主执行过程（见图4）：

• “是什么”：定义我们所要实现的业务场景的具体背景信息。
• “如何实现”：将这一业务场景与我们的技术架构相对接，需要考虑模块设计、实现机制以及通信方式等问题。
• “具体任务”：明确人工智能可以执行的操作步骤，确保这些操作具有可验证性，并且能够实现并行处理。

然而，即使采用这种协作式的方法，如果单独由个人来执行整个流程，也会错过很多机会。如图4所示，虽然人工智能可以在不同的环节发挥作用，帮助我们制定各种规范，但让单个开发者独自完成整个开发过程是不现实的。

通过跨职能的协作来共同构建开发框架的团队，其效率远高于那些仅仅专注于优化开发提示或追求更智能模型的个人。规范驱动开发可以通过将规范作为连接不同环节的桥梁来发挥重要作用——产品团队负责明确“目标”，架构团队负责设计实现方案，工程团队则负责具体执行各项任务。

随着开发速度的加快和成本的降低，开发过程中的瓶颈已经发生了变化。如果我们一味地专注于验证人工智能的输出结果，就会导致创新思路的匮乏。简而言之，仅依靠审查机制是无法有效应对人工智能应用带来的发展挑战的。

正是在这种情况下，团队需要齐心协力地进行协作，共同构思解决方案，这样才能让多个智能体同时并行执行开发任务。那些掌握了这种协作方式的组织，可以让人类员工将更多时间投入到战略性的问题解决中，而智能体则可以负责处理多项具体的开发工作。正是这种团队层面的协同作用，而非个人效率的提升，使得规范驱动开发对于企业来说变得不可或缺。

“规范失效”的风险

鉴于规范驱动开发所具有的重要文化意义，如果仅仅将其视为一种技术手段来应用，就会浪费其中蕴含的巨大价值。规范驱动开发的真正价值在于它是一种能够帮助组织发展的能力，而不仅仅是一项需要被机械执行的技术流程。那些经历过企业敏捷转型的人应该能够理解这一点：工具和流程虽然容易实施，但如果没有相应的文化变革作为支撑，我们就有可能面临“规范失效”的风险。

如果在不改变产品、架构、工程团队以及质量保障相关方实际协作方式的前提下采用基于规格说明书的工作流程，就有可能产生一种“混乱局面”——即随着工作的推进，会不断生成大量过时的文档。关键在于要将规格说明书同时视为各相关方之间沟通的媒介，也是人工智能辅助工具理解工作背景的依据。

大规模应用需求驱动开发模式所面临的挑战

企业实际运作的复杂性意味着现有的需求驱动开发工具存在诸多缺陷，而最流行的那些工具也或多或少存在这些问题。

以开发者为中心的工具设计

目前最受欢迎的需求驱动开发工具大多被集成到了Git仓库、代码编辑器以及命令行界面中。这种设计对单个开发者来说确实很方便，但却阻碍了跨职能团队之间的协作。当规格说明书存储在代码仓库中时，产品经理和业务分析师这些本应参与需求定义的人员就会遇到参与其中的障碍。

单一仓库的设计模式

现有的工具通常会将规格说明书与代码保存在同一个仓库中。这种设计对于简单的项目来说可能适用，但企业级系统往往并非如此。现代软件架构通常包括微服务、共享库、基础设施仓库以及各种平台组件。如果某个功能需要修改六个不同的仓库中的内容，那么规格说明书应该存放在哪里？如何确保这些不同模块之间的协调性？现有的工具并没有提供明确的解决方案。

缺乏职责分离机制

作为以开发者为中心的设计理念的延伸，现有工具并没有根据文档的更新频率或使用对象来对不同的文档进行分类管理。

诸如数据库架构设计这样的架构决策，以及验收标准这类业务相关内容，属于更具战略性的工作，它们需要由不同的团队参与审批流程；而任务列表则具有很强的操作性，通常只由负责具体实施的工程师来审核。

然而，大多数工具仍然将所有文档都存放在与特定功能相关的文件夹中，这使得人们很难从整体上了解各个功能的发展情况，也无法追踪不同功能之间的技术演变关系。虽然人工智能辅助工具理论上可以提供这样的视图，但问题依然存在：那些生命周期截然不同的文档，究竟是否应该被放在一起管理呢？

缺乏明确的起点

团队应该是从一份涵盖整个应用程序的产品需求文档开始着手吗？还是应该从现有的待办任务列表中选取某个具体功能来开始？大多数企业都会在Jira或Azure DevOps这样的工具中维护待办任务列表，这些列表通常经过了数周甚至数月的细化调整。然而，现有的需求驱动开发工具并不能与这些系统进行集成。

团队能否将待办任务列表中的功能直接纳入需求驱动开发的工作流程中？又该如何确保待办任务列表与不断更新的规格说明书保持同步呢？由于缺乏明确的集成方案，那些希望采用需求驱动开发模式但又不想完全放弃现有的工作流程和规划安排的团队，就会遇到诸多困难。

不明确的协作机制

并非所有利益相关者都会参与所有的开发阶段。产品团队主要负责功能定义，他们对技术层面的了解也仅限于较高层次；架构师则专注于系统设计及跨领域问题；平台工程部门要确保各项工作符合组织标准，但现有的工具并未能准确反映这些不同的参与模式。那么，每个利益相关者的贡献究竟从何时开始，又何时结束呢？他们该如何知道何时应该进行审查？哪些内容需要谁来审批？如果这些协作机制不够明确，就可能会阻碍各项工作的顺利开展。

多种多样的规范编写风格与详细程度

不同的SDD工具在规范编写方面采用了不同的方法。大多数工具使用markdown格式文件，但具体形式各不相同——有的采用结构化的用户故事和验收标准（如GitHub SpecKit），也有的采用像EARS（Amazon Kiro）这样的规范模板。有些工具会生成机器可解析的格式文件，用于描述数据结构或消息内容（例如SpecKit为HTTP接口生成OpenAPI规范），而另一些工具则直接在规范中嵌入测试用例，以验证各项内容的准确性（如Tessl）。

规范文件的组织方式也各不相同。有些工具会按功能模块来整理规范文件（比如SpecKit和Kiro），有些则会维护一份不断更新的统一规范，还有的工具会结合这两种方法，同时使用顶层规范和已归档的功能模块规范（如OpenSpec）。此外，不同工具对规范内容的详略程度也有不同的要求。

鉴于这些多样的编写方式与详细程度，选择合适的工具和规范格式确实是一件颇具挑战性的事情。每种工具都会对其所支持的开发流程产生一定的影响——当团队刚开始接触SDD时，这些差异可能还有助于他们快速上手；但如果工具的假设与团队的实际工作方式不符，这些差异反而会成为阻碍。

规范与实现之间的匹配程度

虽然SDD的最终目标是确保开发意图与实际实现结果能够保持一致，但这一过程实际上包含两个不同的转化环节：

• 开发意图转化为规范文档
• 规范文档转化为实际代码

开发意图转化为规范文档这个环节需要通过沟通和审查来完成；而规范文档与实际代码之间的匹配程度，则是选择SDD工具或方法时需要重点考虑的因素。因为不同的规范格式本身就具有不同的可验证性特点。

现有系统改用新方法的实施路径不明确

无论是大型企业还是小型团队，我们都已经拥有一些现有的代码需要维护，或者一些新的功能需要添加。在这种情况下，我们应该是先让大语言模型阅读整个项目来生成规范文件，还是应该逐步针对各个需要关注的领域来编写规范呢？其实这里存在两个可能影响决策的因素。

如果现有系统的规模较大，那么让大语言模型生成完整的规范文件可能会遇到困难，因为这种任务很容易超出模型的处理能力范围。即便我们最终成功生成了规范文件，其内容也可能过于冗长，从而导致审查工作变得非常繁琐。虽然通过将规范文件与实际代码进行对比来验证其准确性是一种可行的方法，但正如我们之前讨论过的那样，规范文件的本质目的是用来捕捉开发者的原始意图，而这种意图显然需要人类来进行审核。对于那些规模庞大的现有系统来说，尝试让机器来审核这些规范文件确实是不切实际的。

虽然一些工具（比如OpenSpec，它采用渐进式的方法来收集规范中现有的信息）声称自己是为适应现有环境而设计的，但在实际大规模应用时——尤其是当这些信息分散在多个代码库和项目中时——这种设计的模糊性往往会成为阻碍其被广泛采用的障碍。

在不耗费过多资源的情况下推动规范驱动开发的普及

上述提到的这些问题属于战术性的障碍，并非根本性的壁垒。企业可以先将现有工作流程进行调整，逐步适应规范驱动开发模式；等到这种开发方式带来的好处变得显而易见后，再进一步转向更加符合人工智能发展趋势的做法。

从零开始开发一套规范驱动开发的工具虽然听起来很有吸引力，但对其进行定制和整合所需的成本往往非常高。相比之下，选择一款与自身开发理念最为契合的、具有扩展性的工具，并对其进行个性化配置，才是更为实际且可行的途径。

以下是一些能够有效解决现有工具所带来障碍的实际措施。

与现有的产品待办列表集成

大多数规范驱动开发工具都是从以开发者为中心的开发环境中发展而来的，因此从工程团队开始使用这些工具是合乎逻辑的。不过，这并不意味着产品经理必须学习Git的工作流程——MCP服务器为这种集成提供了便利的手段。

开发者可以直接从Jira、Linear或Azure DevOps中提取待办任务，并将其纳入自己的规范驱动开发流程中；同时，开发进展的更新信息也会被同步回相应的待办列表工具中。

产品待办列表集成的示例

OpenSpec提供了一种三步式的规范驱动开发流程：一个变更通常会依次经历“提案”、“实施”和“归档”三个阶段。

图5-a：OpenSpec的规范驱动开发流程

在图5-b所示的改进后的流程中，我们通过MCP与产品待办列表进行集成，从而确保各项任务的状态能够得到及时更新。与默认的通过命令行输入来提交变更的方式不同：

• 当从待办列表中选取某个任务进行“提案”时，该任务的状态会变为“待处理”
• 在进入“实施”阶段后，任务状态会变为“进行中”
• 完成实施步骤后，任务状态最终会变为“已完成”

图5-b：通过MCP将OpenSpec改进后的SDD工作流程与产品待办列表集成起来

这种简单的集成方式尊重了一个现实：产品团队已经在整理待办列表上投入了大量精力。我们不会在新系统中重复这些工作，而是将这些工作整合到已经存在的系统中去。

多仓库协同开发

在多仓库SDD协同开发中，将业务背景与技术实现细节分开处理至关重要。

以那些同时涉及前端和后端、或跨越多个微服务的功能为例，我们需要明确各个仓库的职责及集成方式，这样才能将相关工作分解为适当的部分，并在不同模块之间进行协调。

图6：通过SDD工作流程，产品负责人、架构师和开发人员能够高效协作

图6展示了产品负责人、架构师和开发人员如何通过SDD工作流程在三个不同的阶段进行协作。

探索阶段

产品负责人会与人工智能系统合作，明确该功能背后的业务目标（即“要实现什么”以及“为什么需要实现它”）。这种沟通是在产品待办列表的框架内进行的，因为业务相关方已经在这个列表中对各项任务进行了规划。

设计阶段

架构师会与人工智能系统合作来确定技术实现方案。对于那些跨越多个仓库的功能，这一阶段会将整体需求分解为针对具体仓库的子任务。每个子任务都对应着仅在某个仓库内需要完成的工作，其技术边界和依赖关系也非常明确。重要的是，这些子任务仍然会被记录在产品待办列表中，这样产品和工程团队就能随时跟踪它们的进展。

开发阶段

开发人员会针对每个仓库中的子任务进行具体开发工作，并与人工智能系统合作详细规划实现细节。诸如数据结构定义、模块划分等内容都会被记录在这些文档中，而这些文件自然应该保存在相应的仓库里，因为它们与需要修改的代码紧密相关。

通过这种分离机制，业务背景信息仍然会显示在产品待办列表上，而技术实现细节则保存在各个仓库中。

重要的是，架构师并不一定需要手动为每一个需求任务进行分解。他们可以通过记录仓库边界、集成规则和架构约束来为编码工具提供指导。在这种指导下，编码工具可以自动为新的需求任务生成相应的子任务，从而确保每个受影响的仓库都能得到适当的管理。

当需要进行架构重构时，原有的业务需求保持不变，但新的架构划分会使得不同代码库中出现不同的子问题。业务目标没有改变，只是技术实现策略发生了变化。

以下是一个例子：Claude Code会根据项目层面设定的架构划分规则，自动更新与线性待办事项列表相关的信息。

图7：根据架构要求生成的前端和后端子问题

各角色特有的贡献

与架构师制定架构指南类似，基础设施专家、性能优化专家和安全专家也会根据自身职责建立相应的规则体系。这些规则体系会反映特定领域的约束条件与最佳实践。

关键在于配置相应的工具，以便在新的工作项或任务生成时，自动应用这些针对不同角色的规则。例如：

• 基础设施专家会添加部署相关的约束条件。
• 性能优化专家会标记出需要优化的地方。
• 安全专家会确认是否符合相关安全要求。

这种机制使得多个专业团队能够协同工作，将业务目标转化为具体可执行的计划。

规范编写风格与验证方法

这个话题具有一定的主观性。以下是从实际应用和企业适用性的角度需要考虑的因素：

顶层指导能力

架构设计、代码组织方式以及技术最佳实践等因素，应该贯穿整个项目，而不是只体现在某个具体的规范文件中。因此，系统是否支持这些机制（比如SpecKit中的“宪法”规则或Kiro中的指导文档），或者是否具备扩展性以实现这些目标，是非常重要的。

顶层规范视图

能够方便地获取或查看能够准确反映当前应用状态的规范文件，对于进行验证工作非常有帮助。

合理的粒度

虽然保持规范内容的一致性很重要，但那些生成的内容与实际代码几乎完全相同的工具可能会带来负面影响。从审核工作的角度来看，保持规范的规模在人类可阅读的范围内是非常重要的。如果规范文件过于庞大，就会使得详细审核变得十分困难。

因此，更实用的做法是选择那些能够促进有意义的讨论、有助于与人工智能协同思考解决方案的规范编写风格。虽然验证工作很重要，但它不应该以妨碍这种主要目标为代价来影响规范编写风格。

在现有系统中应用SDD

与其试图事后为整个系统制定详细的规范，不如采用逐步探索的方式。使用SDD的主要目的之一就是减少开发人员所需处理的信息量，只向他们提供完成特定工作所需的知识。在需要变更的区域，规范应该具有更高的详细程度。这种细致性也能降低前文提到的审核负担。

这种方法与我们在采用测试驱动的方式重构旧代码时所使用的技术并无本质区别。我们会尽可能地涵盖变更区域周围的现有逻辑，一旦对修改的可靠性有足够的信心，就会将相关部分单独提取出来，这样开发人员就可以专注于这些具体内容，而不会被过多的细节干扰。

随着时间的推移，每次修改都会使规范的内容逐渐完善。修复漏洞、添加新功能或进行代码重构，这些过程都为相关代码的规范制定提供了机会。这种循序渐进的方法能够确保生成的内容规模适中，便于人工审核，并且能聚焦于当前正在开发的领域，从而避免了为整个旧系统制定全面规范的繁琐工作，也规避了由此带来的审核压力。

到目前为止，我们已经探讨了如何将SDD应用于现有的组织架构中，而不会扰乱已经确立的工作流程。一旦团队认识到这种方法的价值，下一个问题就会浮现：组织应该如何朝着更加适合人工智能发展的方向演变呢？答案在于，应该将规范视为动态变化的指导文件，而不是静态的文档，通过反馈机制不断对其进行优化。

长期发展方向

在刚开始采用SDD的过程中，人们经常会问这样一个问题：对于一些小的修改或漏洞修复，是否真的有必要制定详细的规范？难道不能直接修改代码吗？当组织开始转向以规范为核心的开发模式时，这个问题就变得更加重要了。

这个问题的答案决定了规范是应该作为次要的文档存在，还是应该成为重要的工程依据。在成熟地应用SDD的情况下，任何修改——无论是重大的功能更新还是小的漏洞修复——都必须通过规范的制定流程来完成。这并不是单纯遵循某种流程，而是要认识到规范才是指导开发人员工作的关键工具。当我们采用以人工智能为基础的开发流程时，这种观念确实代表着一种重大的变革。

从历史上看，我们之所以禁止直接在服务器上修改代码，是因为这些更改会在下一次版本发布时被覆盖。由于无法直接修改服务器上的代码，团队就必须在版本控制系统中对代码进行修改，然后通过正规的发布流程重新部署这些变更，这样才能确保修改内容能够在未来的版本中持续生效。

对于由人工智能生成的代码来说，代码中出现的问题往往意味着规范中存在漏洞。直接修改代码反而可能会使这些漏洞更加严重。由于人工智能生成代码的过程中存在不确定性，每当根据这些规范重新生成代码时，这些漏洞就会以不同的形式再次出现。因此，继续手动修补代码是行不通的，相比之下，将问题反馈到规范中并进行相应的调整，才是更为可持续的做法。

因此，我们需要让“做正确的事情”变得更容易，并且应该在规范层面而非代码层面进行相关工作。例如，虽然代码仍然是我们需要进行版本控制并审查的对象，但编写代码的工作可以由人工智能编码工具来完成。

框架治理

在InfoQ的文章《规范驱动开发：当架构具备可执行性时`中，Leigh和Ray提出了“规范操作”这一概念，他们将规范编写视为一种重要的工程活动。

当规范成为系统开发的主要依据时，它们就应该享受到与生产代码相同的品质管理流程、版本控制机制、审查程序以及持续改进措施。

这种转变具有深远的影响。如果编码工具是根据规范来执行操作的，那么规范的质量直接决定了最终实现的结果。一个错误不仅仅是代码中的缺陷，更是改进相关规范及生成该代码的工具的机会。正是在这里，反馈循环发挥了至关重要的作用。

当错误出现时，了解其产生的原因至关重要：

规范与实现的差距

规范本身是清晰的，但实际实现却出现了偏差。为避免类似问题的再次发生，需要加强任务完成后的验证机制，或者为相关工具提供更严格的验证规则。

设计意图与规范的差距

在讨论过程中某些用例细节被遗漏了，导致规范本身不完整。为此，我们需要改进规范制定流程，通过添加特定的问题格式、研究步骤或分析框架，确保未来的开发计划能够提前涵盖这些细节。

这些问题并不仅仅是代码缺陷的分类，它们实际上反映了我们所用工具的质量状况。每一个差距都表明该工具还有哪些需要完善的地方。质量工程的角色也在发生变化——它不再仅仅是验证代码实现的结果，而是要不断改进那些指导工具运行的规范本身。

图8：框架反馈循环

图8展示了这种持续改进的机制。当验证工具发现规范与实现之间的差距时，这些信息会被用于完善相关工具。随着时间的推移，这些工具会积累更多的领域知识，能够预见更多边缘情况，并生成更加完备的规范。系统是通过不断改进那些影响未来实现的规范框架来从错误中学习的，而不是通过修补代码来实现这一目标。

将规范编写视为一项包含反馈循环、质量指标及持续改进机制的运营流程，那么各个功能模块就无需再进行过多的人工优化。这些经过实践积累的经验和方法，会为后续的工作提供有力支持。

实现协调一致的务实路径

如果意图、规范与实际实现之间缺乏完美的一致性，那么质疑SDD的价值也是情有可原的。虽然可以通过设计相应的验证机制来利用规范独立测试实现代码，但这种一致性的实现程度会因规范类型的不同而有所差异。如果从一开始就追求绝对的一致性，可能会导致规范过于详细，从而增加审查工作的难度，进而影响该方法的推广和应用。

从实际的角度来看，即使是人与人之间也常常会出现协调不一致的问题。在人类层面，我们可以通过一些机制来减少未来的沟通障碍；同样地，回顾性的反馈循环也有助于逐步改善这些问题。每发现一处差异，都会使规范更加完善，从而使实现代码与规范更加匹配。

这种转变体现了在由智能代理协作的开发模式下，质量管控方式的根本性变化。质量专家不再只是审查已经完成的实现代码，而是要验证那些用于规范编写的基础框架、其中所包含的技术约束条件，以及这些验证机制能否及时发现任何偏差。他们的职责已经从关注实现代码的质量，转变为确保这些基础框架本身的可靠性。

结语

随着具备持续自主执行能力的智能代理的出现，软件交付过程中的瓶颈已经发生了变化。问题不再在于我们编写代码的速度，而在于我们能否清晰地表达自己的设计意图。正如Adrian Cockcroft在QCon SF上所指出的那样，我们现在正在学习如何指挥这些智能代理群体来完成任务。这种开发方式与单纯管理个体开发人员相比，代表着一种截然不同的组织能力。

SDD为这种转变提供了可能，但前提是我们必须认清真正发生变化的地方。产品团队需要以足够清晰的方式描述业务背景，以便智能代理能够理解用户需求和验收标准；架构师则必须将技术约束条件及集成模式融入到可重复使用的规范框架中；工程师们则需要从编写实现代码转变为验证智能代理生成的代码是否与规范要求一致；质量专家的工作重点也应由测试已完成的产品转向确保这些基础规范框架本身的稳健性。

在SDD模式下，沟通的对象不再仅仅是人类。规范成为了产品团队、架构师、工程师和质量保障人员共同合作的平台，通过这个平台，他们可以共同构建出能够被智能代理转化为实际行动的执行方案。而规范编写过程中的反馈循环，正是这种协作得以实现的关键所在。

那些将SDD仅仅视为一种技术工具的人，将会从中获得诸如更高效地使用各种开发资源、延长智能代理的运行时间、减少错误出现频率等技术上的好处；而那些将其视为一场组织变革的人，则会发现自己能够更加有效地指挥这些智能代理群体，从而让人类可以将精力集中在战略性的问题解决上，而让智能代理来处理各项具体的实现工作。

这种转变并非未来的状态，而是目前就已经可以实现的。对于那些愿意进行这种转变的组织来说，这些措施现在就可以投入使用。