𝟮𝟬𝟮𝟲 年的规范驱动开发 (Spec-Driven Development)

AI 智能体非常擅长编写代码，但它们极不擅长猜测你的真实意图。

这就是为什么规范驱动开发 (SDD) 会成为 2026 年的标准。

过去，人们流行“氛围编程 (vibe coding)”。这意味着你给 AI 一个模糊的提示词，然后直接发布它返回的任何内容。这对于原型开发行得通，但对于需要维护的真实软件来说，这注定会失败。

SDD 是一种严谨的构建方式。你将规范视为“单一事实来源 (source of truth)”。规范声明了你的意图，而代码仅仅是将其实现。

技能需求的转变显而易见： 你不再把时间花在敲代码上。 你开始花时间清晰地定义意图，直到机器无法出错。

团队如何使用 SDD：

  • 规范优先 (Spec-First)：规范指导初稿。代码随后可能会发生偏移。适用于原型开发。
  • 规范锚定 (Spec-Anchored)：规范与代码同步演进。自动化测试确保两者保持一致。这是大多数生产系统的最佳选择。
  • 规范即源码 (Spec-as-Source)：人类只编辑规范，AI 生成所有代码。这需要对工具具有极高的信任度。

SDD 工作流：

  1. 宪章 (Constitution)：定义项目规则（语言、框架、测试）。
  2. 规范 (Specify)：使用用户故事定义“做什么”和“为什么”。
  3. 澄清 (Clarify)：智能体通过提问来消除歧义。
  4. 规划 (Plan)：定义架构和数据模型。
  5. 任务 (Tasks)：将计划分解为细小的、可交付的项目。
  6. 实现 (Implement)：执行任务。
  7. 分析 (Analyze)：检查计划和任务是否与原始规范一致。

金科玉律：永远不要直接从规范跳到代码。务必先审查计划和任务。

为了使规范具有可执行性，请使用 EARS (Easy Approach to Requirements Syntax，需求语法简易方法)。不要使用模糊的句子，而是使用如下模式：

  • 当 [事件] 时，系统应当 [动作]。 (WHEN [event] THE system SHALL [action].)
  • 如果 [条件]，则 [结果]。 (IF [condition] THEN [result].)

这使得你的需求可以直接映射到测试用例。

值得关注的工具：

  • GitHub Spec Kit：开源且与模型无关。
  • AWS Kiro：最适合 AWS 原生企业。
  • Claude Code (cc-sdd)：非常适合以终端为先的工作流。
  • Cursor：最适合以 IDE 为先的用户体验。

底线结论： 思考发生在规范阶段。如果你使用 AI 来编写代码，那么规范就是你产出的最重要的东西。

Source: https://dev.to/krlz/spec-driven-development-in-2026-what-it-is-the-tooling-and-how-teams-actually-use-it-2fk2

Optional learning community: https://t.me/GyaanSetuAi