Agent 系列（一）：Agent 与 SDD 重塑 AI 时代的软件开发生命周期

从 2025 到 2026，对于所有的企业软件行业来说，都在经历一次明显转变；因为 AI 已不再只是开发工具中的辅助能力，而开始影响整个研发流程，从需求分析、代码生成到测试与运维，都在逐步被重构。据统计，GenAI 已将软件开发效率整体提升约 20%—30%。Gartner 预测，到 2028 年，约 90% 的企业软件工程师将在日常工作中使用 AI 代码助手，而 2024 年 这一比例仍只有 14%。同时，未来 超过三分之一的企业应用 预计会引入 Agent 形态的组件，用于自动完成跨系统或跨部门的复杂任务。

但是，伴随这种前所未有的加速，软件工程界也遭遇了被称为 “人工智能生产力悖论” 的困境：编码速度的显著提升并未能自动转化为研发支出的减少、产品周期的实质性加快或最终利润的增长 。真正的瓶颈已经从底层的代码编写转移到了系统设计、架构约束以及对非确定性人工智能输出的治理上 。在早期的 LLM 应用中，大家普遍沉迷于 Vibe Coding 的开发模式，这种模式依赖于开发者与 AI 之间即兴的、缺乏边界的自然语言交互，虽然在构建初期原型或进行简单实验时极具爆发力，但在面对复杂的、需要长期维护的企业级应用时，往往会导致严重的上下文腐化、架构失控以及难以追溯的系统性缺陷 。

有新问题，也就有新的思路；“规范驱动开发”（Spec-Driven Development，简称 SDD） 这种新型软件工程范式迅速崛起。 SDD 颠覆了传统敏捷开发中 “代码为王、文档为辅” 的理念，它将高度结构化、机器可读的规范文件直接转化为可执行的工程代码，使之成为引导AI Coding Agent 编写代码的强制性契约 。在这种模式下，人类开发者的核心职责从微观的 “编写逻辑” 上升为宏观的 “定义意图与边界” ，而 AI Coding Agent 则在严格的规范框架内完成从任务拆解、代码实现到自动化测试的闭环。

基于上述的演进背景，本篇从技术演进与认知升级两个维度，深度剖析当前开源社区中比较主流的几种框架 GitHub Spec Kit、OpenSpec、BMAD Method以及 Superpowers（本质上它还不太算 SDD 范畴），通过对这些工具底层逻辑与工作流的拆解，简单和各位读者探讨下 Agentic AI如何重构未来的软件开发生命周期（SDLC）。

从 Vibe Coding 到 SDD

Vibe Coding 的问题

Vibe Coding 我认为它代表的是一种直觉驱动的、重在行为探索的编码风格。我只需向模型提供模糊的需求，便能瞬间获得大量代码，这种体验极大地降低了编程门槛 。但是随着系统规模的扩大和业务逻辑的复杂化，纯粹依赖对话历史的开发模式不可避免地陷入系统熵增的泥潭。

首先，自然语言本身固有的歧义性与大型语言模型的概率性特征发生碰撞，导致了严重的 “状态漂移” 与 “上下文腐化” 问题。在冗长的对话中，AI 的上下文窗口会逐渐被废弃的代码片段、修改建议和无关噪音填满，模型开始遗忘最初设定的架构原则，导致后续生成的代码与整体设计严重脱节 。

其次，Vibe Coding 缺乏对 “已完成” 状态的严谨定义。AI 为了快速响应，往往倾向于生成 “表面上能运行” 的代码，跳过必要的测试环节，这种妥协产生了大量隐性的技术债 。最后，当多个开发者或多个 Coding Agent 在同一代码库中并行工作时，由于缺乏一个统一的、机器可读的 Source of Truth ，不同代理之间的修改极易发生冲突，甚至相互覆盖，导致生产环境面临巨大风险 。

SDD：意图即契约

在 SDD 的理念中，规范成为了人类意图与 AI 执行力之间的标准化 API 。人类开发者专注于回答 “构建什么”（What）以及 “为什么构建”（Why），而 AI 则在规范的严格约束下解答 “如何构建”（How）。这种方法不是要倒退到瀑布流模型，按部就班的编写又丑又长又无人阅读的文档，而是要求创建动态的、可管理的、能够被大模型深度解析和执行的需求文档 。

通过将安全要求、设计系统和性能指标等非功能性需求前置并硬编码到规范中，SDD 确保了 AI 在生成第一行代码时就已经处于合规的轨道上 。这种多步细化的流程，彻底取代了依靠单一提示词进行代码生成的即兴式操作，从而极大提升了软件输出的一致性、可维护性和可追溯性 。

GitHub Spec Kit

仓库地址：https://github.com/github/spec-kit

由微软和 GitHub 团队主导开源的 Spec Kit 是 SDD 的一种实践，其核心愿景是为 AI 辅助的软件工程提供一套高度结构化、可复用的SOP，以取代无序的提示词猜测 。

核心组件与 pipeline 设计

Spec Kit 摒弃了复杂的外部依赖，其基础架构极其精简，主要由一个用于引导项目脚手架的 Specify CLI 以及一套预定义的 Markdown 模板和辅助脚本构成 。这些模板精确定义了规范的结构、技术计划的覆盖范围，以及如何将宏大目标拆解为 AI 可消化的独立任务 。

在工作流层面，Spec Kit 通过斜杠命令强制执行一个严密的五阶段细化 pipeline，这种分层架构就是为了防止 AI 在处理复杂逻辑时的上下文迷失问题。

多方案探索与遗留系统改造

Spec Kit 的设计方式为开发团队提供了更大的技术选择空间。由于系统规范与具体代码实现彼此分离，团队可以在同一份规范基础上快速尝试不同技术方案，而无需反复修改设计。例如，可以基于同一规范分别生成 Java 与 Go 两种语言的微服务实现，用于对比性能表现；也可以接入 Figma 的 MCP 服务，同时生成多个前端界面版本，便于在设计阶段进行对比和筛选。

在面对存量系统或推进遗留系统升级时，这种模式同样具有实际价值。对于设计文档缺失、原始设计意图难以追溯的旧系统，可以借助 AI 对大量历史代码进行分析，从代码结构中整理出系统的核心规范。当这些规范被重新梳理并确认之后，再依据规范对系统进行重新实现，使系统能够在较为稳定的前提下迁移到新的技术架构，减少大规模回归问题带来的风险。

OpenSpec

仓库地址：https://github.com/Fission-AI/OpenSpec

如果说 GitHub Spec Kit 是一套适合企业级全新项目的重型工业 Pipeline ，那么由 Fission AI 开发的 OpenSpec 则是一套极具机动性、专注于存量系统改造的动态意图追踪框架 。OpenSpec 遵循 “流动而非僵化、迭代而非瀑布” 的设计哲学，主张以最小的配置成本实现人类意图与机器执行的完美对齐 。OpenSpec 本质上也是 SDD 的一种实现。

Source of Truth 与 Change Sandbox 的隔离机制

Source of Truth：很多机翻直接干成 “真相源”，缺少灵魂。Source of Truth 可以理解为系统中唯一被认可为“权威”的信息来源，所有其他数据、配置、代码或文档，都必须从这个来源生成或同步，而不是各自独立维护。

在未经管理的开发流程中，系统规范往往散落于多个文档或各种群聊记录中，导致在引入新功能时极易发生未预期的冲突。OpenSpec 创新性地在文件系统层面引入了物理隔离机制。它将代表系统当前行为状态的 Source of Truth 集中存放于 openspec/specs/ 目录，并将所有正在探索的功能变更隔离在独立的沙箱目录（如 openspec/changes/<feature-name>/）中 。

当需要引入修改时，开发者通过发起变更提案在独立目录中生成包含 proposal.md（变更意图）、基于 RFC 2119 标准（明确区分 MUST、SHALL 等强制性约束）编写的增量规范文件、以及 design.md 和 tasks.md 的标准化制品集 。这种隔离确保了开发团队可以同时安全地并行处理多个变更，且在正式归档前，不会对全局架构文档造成任何污染 。

闭环验证与合并同步

在具体的执行层面，OpenSpec 原生支持包括 Claude Code、Cursor、Windsurf、GitHub Copilot 及 Amazon Q 在内的超过二十四种主流 AI Agent 编码助手，其核心工作流依赖于一组高度一致的交互指令：

降低回归风险与构建审计轨迹

OpenSpec 对增量规范（Delta specs）的处理极大降低了系统演进中的回归风险。AI 在提出任何修改前，必须先交叉对比已文档化的基线规范，从而在未写一行代码时就阻断逻辑冲突的发生 。更进一步，OpenSpec 将每一个特性的演变历史变为了版本控制系统中的一等公民。无论大模型的输出多么不可预测，其背后的每一次决策动机和变更历史都被永久固化在归档记录中，就是你随便造，我都有记录的。

BMAD Method

仓库地址：https://github.com/bmad-code-org/BMAD-METHOD

区别于侧重文件结构的静态工具，BMAD Method（也称为 Build More Architect Dreams）采取了一种组织行为学视角，它认为 LLM 才是不可控的主要因素。然后又通过一种叫 协作优化反射引擎（C.O.R.E.） 的底层机制，在开发者的本地集成开发环境（IDE）中直接实例化出一个由专业虚拟角色组成的完整敏捷团队 。

基于角色分工的上下文协作机制

在 BMAD 框架中，分析师、产品经理、系统架构师、Scrum Master、QA 等角色并不是简单地作为提示词使用，而是通过独立的 Markdown 文件进行定义，形成相对完整的 Agent 配置。每个角色文件都会明确该角色的思考方式、职责范围、操作规则以及输出格式，从而让不同阶段的工作具备清晰边界。 通过这种方式，原本复杂的软件开发流程被拆分为多个连续衔接的阶段，由不同角色依次完成：

1. 1. 需求分析：由解决方案架构师接收最初的产品想法，对业务背景、市场需求以及技术可行性进行梳理，最终整理形成描述产品目标与整体方向的 product-brief.md。
2. 2. 产品规划：产品经理在产品简报基础上进一步细化需求，形成包含功能需求与非功能需求的完整产品需求文档（PRD.md）。如果涉及交互设计，UX 角色会同时补充界面与用户体验方面的规范说明。
3. 3. 架构设计：架构师根据 PRD 制定系统技术方案，明确技术选型与关键架构决策，并形成 architecture.md 以及相关的架构决策记录。随后由 Scrum Master 将整体需求拆分为多个可执行的 Epic 与 Story，为后续开发做好任务结构化准备。
4. 4. 实施与质量验证：开发角色根据拆分后的任务实现具体功能，并编写相应测试代码。完成后再由 QA 角色进行代码检查与质量验证，确保实现结果符合既定架构和需求约束。

文档拆分与按规模调整的任务组织方式

在处理超长上下文时，大模型往往难以稳定关注所有信息，内容越多，干扰也越大。针对这种场景，BMAD 在流程中引入了 “文档拆分” 的做法，将原本庞大的需求文档拆分成多个更小的任务单元。Scrum Master 会把需求进一步整理为类似 {epicNum}.{storyNum}.{storyTitle}.md 的文件，每个文件只描述一个具体任务。当开发阶段执行某个功能时，系统只提供该任务相关的内容以及必要的架构原则，使上下文保持简洁，从而减少无关信息对生成结果的影响，同时也能降低 Token 消耗并提高代码生成的稳定性。

除此之外，BMAD 在流程设计上还考虑了不同规模项目的差异。对于结构简单的修改，例如常见的缺陷修复，流程可以直接进入实现阶段，而无需经过完整的规划与拆解步骤；如果是涉及范围较大的系统开发或重构，则会按照完整流程逐步展开，包括需求分析、规划、架构设计以及质量检查等环节。通过这种方式，开发流程能够根据任务复杂度灵活调整，使经验化的软件工程方法可以在不同规模的项目中重复使用。

Superpowers

仓库地址：https://github.com/obra/superpowers，它本质上是一个 Agent Skills 框架，不属于 SDD 的实践范畴。

如果说前面的框架主要关注文档组织和角色分工，那么 Superpowers 的重点则放在约束模型的行为上。实际使用过程中可以发现，大模型在长时间执行任务时往往会逐渐偏离规范，例如跳过测试、减少设计说明，甚至为了尽快让程序运行而忽略原有的架构原则。

Superpowers 正是针对这种情况提出的解决思路。该框架并不依赖模型自行维持工程规范，而是将测试、设计校验以及架构约束等工程规则直接写入系统流程中，使这些步骤成为执行过程中的必要环节。通过这种方式，可以减少模型在实现阶段“走捷径”的情况，让生成的代码更加符合既定的工程标准。

以强制流程来约束开发行为

Superpowers 的运行依赖两部分机制：一个可组合的 Skills 库 和 一段在会话开始时加载的固定执行规则。 系统通过明确的指令约束执行流程：只要某项技能与当前任务相关，代理就必须调用，而不能自行跳过步骤或简化流程。

在这种机制下，AI 编码流程被重新组织为几个基础的阶段：

• • brainstorming：在开始编写代码之前启用。通过不断提问澄清模糊想法，比较不同实现方案，并将设计思路分块整理出来供确认。最终形成并保存设计文档。
• • using-git-worktrees：在设计方案确认后启用。为开发任务创建新的分支和独立工作区，完成项目初始化，并确认当前代码能够在干净环境下正常通过测试。
• • writing-plans：在设计获得批准后启用。将整体工作拆分为多个小任务，每个任务预计只需 2–5 分钟即可完成。每个任务都明确包含需要修改的文件路径、完整的代码内容以及对应的验证步骤。
• • subagent-driven-development / executing-plans：在任务计划生成后启用。系统会为每个任务启动一个新的子代理执行，并在提交结果前进行两轮检查：先验证是否符合既定规范，再评估代码质量；也可以按批次执行，并在关键节点保留人工确认。
• • test-driven-development：在实现阶段启用。严格遵循“红—绿—重构”（Red-Green-Refactor）流程：先编写必然失败的测试并确认失败，再编写最少代码使其通过，最后进行必要的重构并提交。如果发现先写代码再补测试，相关代码会被移除。
• • requesting-code-review：在各任务之间启用。按照既定计划进行代码审查，并根据问题严重程度给出反馈。若发现严重问题，流程会暂停，直到问题解决。
• • finishing-a-development-branch：在任务全部完成后启用。再次确认测试全部通过，并提供后续处理选项，例如合并分支、创建 Pull Request、保留当前分支或直接丢弃，同时清理对应的工作区。

子代理执行机制与系统化问题排查

Superpowers 另一个重要设计是 subagent-driven-development（子代理驱动开发）。在任务规划完成后，主控代理不会直接执行具体开发，而是为每个微任务启动一个新的子代理。每个子代理都在独立且干净的上下文中工作，从而避免前后任务之间的上下文干扰。

这种方式也方便结合 Git Worktrees 等机制进行并行开发。子代理在提交结果之前，需要通过两类自动检查：首先确认实现是否符合既定规范，其次进行代码质量评估。未通过检查的内容会被退回重新处理。

当系统检测到错误或异常行为时，调试流程会被触发。代理需要按照既定步骤进行问题定位，而不是通过反复猜测来修改代码。通过这种方式，整个开发流程更接近工程化的持续集成模式，使系统能够在较长时间内稳定运行，而不需要频繁人工干预。

四种开源框架的能力对比与选型参考

为了便于在不同研发环境中选择合适的工具，可以从设计理念、解决的问题以及适用场景三个方面，对这四个开源框架进行横向对比。它们的关注点各不相同：有的侧重规范驱动开发流程，有的强调上下文管理，还有的更关注工程纪律和代码质量控制。

Agent 时代的软件开发流程变化

从这些框架的设计可以看到，软件开发流程其实本质上并没有什么太大变化，无非是从 人-人 协同转变成 人-Agent 协同，另外就是，用规则约束人，规则越重效果越差；但是用规则约束机器，规则越重效果越好。过去的软件开发通常按照固定阶段推进，例如需求、设计、开发、测试、发布等，整体流程相对线性。而在引入智能体之后，很多环节开始形成持续运行的闭环，开发、验证和修正不再完全依赖人工串联，而是在系统内部不断循环执行。

安全能力逐步前移

传统的软件安全通常集中在开发后期，例如 代码扫描、渗透测试或上线前的安全评审。这种方式在代码生成速度显著提升的环境下越来越难以覆盖全部风险。在以 Spec Kit、BMAD 等框架为代表的新模式中，安全规则和合规要求会在项目早期就被纳入规范体系。例如，在架构设计阶段就明确技术边界、安全策略以及依赖约束，并将这些规则写入系统流程中。后续无论是人工开发还是模型生成代码，都需要遵守这些限制。随着这种方式的普及，安全检查也逐渐从 “事后扫描” 转向 “实时拦截”。未来的软件环境中，很可能会出现专门负责治理与合规的智能体，它们会在 CI/CD 流水线甚至本地开发环境中对代码进行持续检查，当发现违反架构或安全规则的实现时直接阻止进入代码库。

测试逐渐成为开发的起点

在传统敏捷开发中，测试虽然被强调，但在实际项目中常常因为时间压力而被弱化。而在新的 Agent 驱动开发流程中，测试的重要性反而进一步提升。像 Superpowers 强调的 TDD，以及 OpenSpec 中围绕验证机制设计的流程，都将测试放在开发之前。借助大模型的文本理解能力，系统可以直接读取需求描述，并自动生成覆盖各种边界情况的测试用例。开发阶段只需要实现能够通过这些测试的代码。这种方式使测试从 “事后验证” 转变为 “实现依据”。

工具链逐渐被整合

当前的开发往往依赖大量独立工具，例如 代码托管、问题追踪、持续集成、监控系统 等。开发者需要在不同系统之间频繁切换，流程也容易被打断。一些新的 SDD 框架正在尝试改变这种状况。它们并不直接替代这些工具，而是将其抽象为统一的任务执行环境，由智能体在后台协调调用。例如在一次任务执行过程中，可以同时完成代码生成、测试执行、分支管理以及代码审查，而我们只需要关注结果。从更宏观的角度来看，这种变化也可能影响软件产品的商业模式，越来越多的软件服务不再只是提供工具，而是直接提供完成某项工作的能力，即所谓的 “Service-as-Software”，用户购买的不再是开发工具，而是一整套可以完成特定业务流程的智能服务。

结语：开发者角色的变化

随着算力和模型能力的持续提升，单纯依赖手工编写代码的时代已经过去了，真正的价值开始转向系统设计、问题建模以及对复杂流程的组织能力。从 BMAD 的角色化流程，到 Spec Kit 的规范驱动开发，再到 OpenSpec 的变更管理以及 Superpowers 对工程纪律的强调，可以看到一个共同趋势：软件开发正在从 “写代码” 为中心，转向 “设计系统与规则” 为中心。

未来的优秀开发者更像系统设计者，他们需要能够把业务目标转化为清晰的规范，并利用各种工具和智能体去实现这些目标。在这样的环境下，理解系统结构、建立清晰边界以及组织复杂流程的能力，将逐渐成为最重要的核心竞争力。