SDD基于规范编程-OpenSpec及SuperPowers如何应用于处理？

AI 编码助手越来越强，但"写代码"从来不是软件开发最难的部分——写对代码才是。 当我们把需求丢给 AI，它能秒出几百行代码，但这些代码真的是我们想要的吗？它符合设计意图吗？有没有超出范围？有没有遗漏场景？ 如果没有一套规范驱动的工作流来约束 AI 的行为，"AI 写代码"很容易变成"AI 制造技术债"。 本文介绍两个解决这个问题的框架：OpenSpec和Superpowers。它们都属于SDD（Spec-Driven Development，规范驱动开发）的实践——先写规范，再写代码，用规范约束 AI 的每一步行为。 什么是规范驱动开发（SDD） 传统的 AI 辅助编码是这样的： 用户描述需求 → AI 直接写代码 → 用户检查代码 → 发现不对 → 重来 SDD 的思路完全不同： 用户描述需求 → 生成规范文档（提案/设计/规格/任务） → AI 按规范实现 → 按规范验证 核心理念只有一句话：先想清楚再动手，用文档约束行为，用验证确保正确。 下面分别看两个框架是怎么落地这个理念的。 OpenSpec — 规格驱动的变更管理 OpenSpec Fission-AI/OpenSpec: Spec-driven development (SDD) for AI coding assistants.是结构化开发工作流框架，核心思想是每次变更都有完整的设计文档可追溯。它不是一个独立工具，而是嵌入在 AI 编码助手中的一套工作流规范。 安装：npm install -g @fission-ai/openspec@latest 初始化：cd your-project，然后openspec init 2 核心概念：Artifact 链 OpenSpec 的核心是一条Artifact 依赖链，每个 artifact 都是前一个的细化： proposal.md → design.md → specs/*.md → tasks.md → 代码实现 → 归档 (为什么做) (怎么做) (做成什么样) (分几步做) (动手做) (存档) 每个 artifact 的职责： Artifact职责核心内容 proposal.md 变更提案 为什么做、目标/非目标、影响范围 design.md 设计决策 技术方案选择、替代方案对比、风险评估 specs/*.md 需求规格 Requirements + Scenarios（WHEN/THEN） tasks.md 任务清单 可执行的 checkbox 任务列表 2 工作流程 OpenSpec 提供了一组命令来驱动整个流程： 命令作用说明 /opsx:explore 探索模式 自由思考，不写代码，只讨论 /opsx:propose 提案 生成 proposal + 后续 artifacts /opsx:ff 快速通道 一次性生成所有 artifacts /opsx:apply 实现 逐 task 实现代码 /opsx:verify 验证 对照 artifacts 检查实现 /opsx:archive 归档 归档完成的变更 3 典型使用流程 以"启动时检查并拉起后台服务"为例： 第一步：快速生成所有 artifacts /opsx:ff 启动时检查并拉起 UniCloudService 后台服务 AI 会自动生成： proposal.md— 阐述为什么需要这个变更 design.md— 技术方案：复用 ServiceUtils、启动失败不阻塞 specs/unicloud-service-startup/spec.md— 4 个场景（未注册/已运行/未运行/启动失败） tasks.md— 3 个可执行任务 第二步：开始实现 /opsx:apply AI 逐个 task 实现代码，每个 task 完成后自动对照 specs 验证。 第三步：归档 /opsx:archive 变更归档到openspec/changes/archive/2026-03-25-start-unicloud-service/，形成可追溯的变更历史。