1. SDD不是TDD的换皮规格先行的逻辑变了什么1.1 一个让我重新审视SDD的契机我最初系统接触SDDSpec-Driven Development基于规范编程是在开始重度使用AI编码助手之后。项目做中期一个扎眼的问题越来越频繁AI生成代码的速度越来越快但代码的“方向感”越来越差。这次会话加的功能下次会话就被它自己改没了上星期刚定下的设计约束这星期它完全不记得。促使我真去研究SDD的导火索是一次需求变更。产品说要加一个过滤条件我在对话框里改了一句话AI花二十分钟改了七八个文件。功能确实实现了但上周写好的分页逻辑、缓存策略全被它顺手改坏。那次之后我意识到问题不在AI而在我给AI的输入方式。1.2 SDD、TDD、BDD三者的定位差异先把概念理清楚。SDD这个缩写有歧义有人说是Spec-Driven Development有人说是Security-Driven Development这里讨论的是前者。很多人第一反应是“这不就是测试先行吗”还真不是。TDD测试驱动开发先写失败测试再写实现最后重构。约束对象是代码行为交付物是测试套件。BDD行为驱动开发用Given-When-Then的自然语言场景描述行为让业务和技术共用一套语言。约束的是沟通方式交付物是场景文档。SDD规格驱动开发先用结构化格式描述系统该做什么、满足什么条件算完成再把规格作为AI或人类的实现依据。约束的是需求到实现的映射交付物是规格文档。用个不严谨但好记的类比TDD是每铺一块砖就检查一次BDD是出发前把所有路牌写清楚SDD是动工前把整条路的验收标准、限高、限速全部定好然后让施工队照着干。1.3 为什么AI时代SDD的优先级突然上来了SDD方法论很早就存在但以前一直没大规模流行原因在于规格文档的写作成本高而且规格翻译成代码还是靠人等于凭空多一道工序。AI编码工具普及后情况彻底反转。大模型编码助手有三个显著特点执行力强给它明确任务它能写出结构完整、可直接运行的代码。边界感弱需求里没写清的地方它会自己脑补脑补方向每次还都不一样。上下文存续性差新会话它完全不懂旧决策除非你把上下文完整喂进去。规格文档恰好补上AI的两块短板给足边界、保存决策。所以你会发现OpenSpec这类工具几乎和AI编程生态同步火起来SDD本质就是为“人机协写代码”这个场景准备的。1.4 SDD瞄准的三个核心痛点痛点没有SDD时的表现有SDD之后需求漂移口头改需求改完不知道改到哪规格和CHANGELOG忠实记录每次变更AI幻觉失控AI自由发挥做出来的不是你要的规格边界限制AI发挥空间协作断层需求方和开发方各自理解、各自表达规格成为双方共用的“中间语言”以我的实际体验来说用了SDD之后AI犯的错误从“方向性错误”降级为“局部性错误”。方向错最麻烦因为得推翻重来局部错改一两个文件就完事。这一个降级带来的时间节省是肉眼可见的。2. OpenSpec实操拆解从安装到规格落地的完整链路2.1 OpenSpec是什么以及它和“随手写文档”的区别OpenSpec是一个开源CLI工具它干三件事提供标准化的规格目录结构让规格不再是一堆散落的Markdown文件。提供规格生命周期管理命令从创建、修改、验收、废弃全程有迹可循。提供agent启动器把规格文档打包成AI编码助手的初始上下文让AI照着规格干活。总有人问“我自己写个Markdown丢给AI不也一样” 能用但跑一阵你就会发现问题格式不统一AI分不清哪些是硬性需求、哪些是随笔没有版本概念改着改着就忘了哪版生效没有任务拆分AI拿到整篇文档不知道从哪动手。OpenSpec的价值不在于“能写文档”而在于把规格变成可执行、可追踪、可验收的数据结构。2.2 安装与初始化macOS上安装很省事brew install openspec也可以用npm全局安装npm install -g openspec两者选一即可。Homebrew的好处是后续升级方便npm的好处是新版本发得快。我这边用的是macOS版本装完先确认一下openspec --version保证是最新release。进入项目目录后初始化openspec init执行完会生成openspec/目录这就是后续所有规格管理的大本营。2.3 目录结构与规格格式拆解一个典型的OpenSpec项目结构如下openspec/ ├── project.md ├── specs/ │ ├── user-auth/ │ │ ├── spec.md │ │ └── CHANGELOG.md │ └── shared-upload/ │ ├── spec.md │ └── CHANGELOG.md └── agents/ ├── openspec-agent.md └── superpowers-agent.mdproject.md是项目级上下文里面应该写清楚技术栈、主要目录的用途、编码约定、明确禁止事项。这些内容会成为AI每次任务的全局背景。specs/下一个功能模块一个文件夹核心文件是spec.md。它用YAML frontmatter加Markdown组织四个部分缺一不可Context、Requirements、Tasks、Acceptance Criteria。以“用户认证”规格为例--- id: user-auth title: 用户认证 status: active --- ## Context 用户系统需要在第一版支持基础的注册和登录暂不考虑OAuth等三方登录。 ## Requirements - REQ-AUTH-001: 用户可以使用邮箱密码注册账号 - REQ-AUTH-002: 注册时邮箱需要唯一密码需要存入数据库的哈希字段 - REQ-AUTH-003: 用户可以退出登录退出后token立即失效 ## Tasks - T-001: 设计用户表结构和token方案 - T-002: 实现注册接口 - T-003: 实现登录接口 - T-004: 实现退出登录接口 ## Acceptance Criteria - AC-001: 注册成功返回201和用户基本信息 - AC-002: 重复邮箱注册返回409 - AC-003: 登录成功返回有效tokentoken有效期7天 - AC-004: 退出登录后旧token访问受保护接口返回401几条写作原则都是踩过坑之后总结的Requirements是硬性约束每条都要能被明确判定为“满足/不满足”不要出现“尽量”“可能”这类模糊词。Tasks是给AI的执行清单粒度控制在一个任务对应一次完整的小改动太大AI无从下手太小又显得琐碎。Acceptance Criteria要写成可测试的行为描述不是“代码怎么实现”的内部细节。2.4 核心命令与生命周期管理OpenSpec的命令不多但每个都要用好openspec spec add name # 新增规格 openspec spec update name # 修改规格 openspec spec accept name # 标记为已接受/已实现 openspec spec reject name # 标记为打回 openspec spec list # 查看所有规格状态 openspec agent add # 启动AI agent执行规格openspec agent add是核心中的核心。执行后工具会把规格内容整理成agent的初始prompt拉起你配置好的编码助手AI从第一条需求开始逐项执行。一个使用习惯强烈建议养成每次改需求都走openspec spec update并且顺手更新CHANGELOG不要直接编辑spec.md就完事。变更记录平时没什么存在感但项目做到第三个月、需求大改的时候你一定会感谢当时记下的每一行变更说明。3. SuperPowers技能包它到底解决了AI编码的什么问题3.1 SuperPowers是什么SuperPowers是Jesse Vincent发起的开源项目现在社区维护很活跃。它的定位很清晰给AI编码助手装配“技能”。这里的“技能”不是简单的prompt模板而是一套带工作流的指令文件以SKILL.md为核心包含技能的适用场景、执行步骤、注意事项。AI加载技能之后不是“知道这个知识点”而是“遇到这类任务时强制按指定流程执行”。对比一下你就明白没有技能时你让AI“修个bug”它会立刻开始猜。有了debugging技能后你让AI“修个bug”它会先要复现步骤再定位根因再写修复再做验证整个流程被动地规范起来。3.2 安装方式不同工具的skill目录约定SuperPowers的安装命令在主流AI前端基本都配套了。Codex CLI安装codex install skill superpowers装完可用codex list skills验证。Claude Code安装claude install skill superpowersClaude Code的skill机制比较成熟装完重启会话即可生效。Cursor技能配置放在~/.cursor/skills/目录手动放进去或通过CLI操作都行装好后在设置界面确认技能被识别。Trae和Workbuddy方式是类似的核心是找到对应工具的skills目录并放置技能文件。Trae一般在~/.trae/skills/Workbuddy的具体路径看版本装完后在技能列表里确认superpowers出现。这里有个特别值得说的坑装完一定要验证加载状态。不同工具对技能加载时机不一样有的重启会话就生效有的还需要在设置里手动开启。判断方法很简单——新开会话直接问AI“你当前加载了哪些技能”如果回答里没有spec-driven-development、test-driven-development等关键词那基本就是没加载成功去检查安装路径和开关。3.3 技能包里的主力技能与配合逻辑SuperPowers包里技能很多日常编码最常用的有这些spec-driven-development检测到规格文档时按规格驱动流程执行任务。test-driven-development先写测试、再写实现、再重构的固定节奏。debugging结构化排查问题先复现、再定位、再修复、再验证。systematic-thinking遇到非确定性任务时先拆解问题边界再动手。subagent-driven-development把大任务拆成多个子任务分配给子agent并行处理。特别想强调的是它们的“配合逻辑”。SuperPowers不是把一堆技能简单堆叠起来它们之间有层级调用关系。比如spec-driven-development内部会调用test-driven-developmentdebugging遇到需要写测试验证的场景也会自动切到TDD流程。这种技能间的协作机制才是它区别于普通prompt集合的核心价值。3.4 SuperPowers和OpenSpec的边界两者不是竞品不少刚接触的人会混淆。用一句话说清OpenSpec负责需求侧的标准化需求怎么组织、任务怎么拆、验收标准怎么定。SuperPowers负责执行侧的标准化AI拿到任务后用什么工作流把它做漂亮。OpenSpec解决“做什么”SuperPowers解决“怎么做好”。两者在同一条流水线上前者上游后者下游。4. OpenSpec与SuperPowers的配合方式与工具链整合4.1 一套开箱即用的组合工作流把实际用下来的完整流程整理成可直接抄作业的版本第一步初始化规格目录openspec init在openspec/project.md里写好项目背景、技术栈、目录约定、禁止事项。第二步写规格openspec spec add user-auth按Context、Requirements、Tasks、Acceptance Criteria的结构填写。需求要硬性可判验收标准要可测试。第三步启动agent执行openspec agent addOpenSpec会启动配置好的编码助手SuperPowers的规格驱动技能接管执行流程。AI先给出任务拆解清单确认规格理解无误再逐项实现每个任务完成后对照验收标准自查。第四步人工验收agent执行完先别急着commit。看它给的验收结果列表逐条对照AC。没满足的让它回到对应任务重做满足的再进入下一步。这套流程跑下来的整体感受是AI不再像一个“等指令的实习生”更像一个“拿着需求说明书工作的远程工程师”沟通成本下降返工量明显变少。4.2 有OpenSpec和没OpenSpec一次对比实验为了验证组合价值我做了一次A/B对比。同一个功能——给博客加标签筛选——分别走两种模式跑一遍。没有OpenSpec的模式直接对AI说“帮我做一个标签筛选功能支持按标签过滤文章列表”。AI的典型反应是猜数据库字段、猜筛选接口URL、顺手加了一个它觉得“有用”的排序参数最后提交的代码里大约10%的内容是需求里没有的。有OpenSpec的模式花十分钟写规格明确REQ-BLOG-TAG-001标签筛选接口接受tag参数并返回匹配文章、AC-001传入不存在的tag时返回空列表而非报错、AC-002不传tag时返回全部文章。AI拿到规格后实现的代码几乎完全落在需求边界内每条需求都有对应实现说明。结论很明确没有OpenSpec时AI工作质量的波动方差很大有OpenSpec时AI表现稳定可预期。对工程项目来说稳定比偶发的灵光一现重要得多。4.3 工具链整合Cursor、Codex CLI、IDEA插件ccgui、Trae/Workbuddy这套组合的工具生态兼容性不错逐个说下整合现状。Cursor OpenSpecCursor对上下文管理能力强在.cursor/rules/加一条规则让它启动时自动加载openspec/specs/下的规格文件。这样每次新建会话AI都带着规格上下文工作不需要手动粘贴。Codex CLI SuperPowers通过codex install skill superpowers装好技能包在同一个CLI里跑OpenSpec的agent指令。Codex现在的agentic能力配合SuperPowers的流程约束做多步任务很稳。IDEA插件ccgui集成OpenSpecccgui是社区开发的IDEA插件把OpenSpec管理界面放进IDE侧边栏支持直接查看规格状态、创建规格、发起agent任务省去了频繁切终端的麻烦。对于重度使用IDEA的团队这个集成很值得装。Trae / Workbuddy安装superpowers skill这类新工具的skill机制还在快速演进但底层逻辑一致把superpowers技能目录放到对应工具的skills目录再到配置里确认加载。注意每个工具的目录名可能不同装完务必验证。4.4 组合工作中人的角色迁移从写代码到写规格用了这套体系之后我对自己工作重心的变化有了很清晰的感知。以前核心工作是“写代码”现在变成了两块写规格和验收获。写规格要求你具备比“会写代码”更高层的抽象能力。你得能从模糊的业务需求里提炼出硬性约束能预判验收标准是否可测试能为AI划定合理的行动边界。这恰恰是资深工程师最值钱的能力。验收获也不是简单看跑通没跑通而是对照规格逐条判断“做了没有、做对没有”。这个环节的质量直接决定SDD闭环是否生效。所以“SDD会取代程序员”是个伪命题它真正做的是优化精力分配把重复、机械的编码工作尽量交给AI让自己抽出时间做更有决策含量的事。5. 实战踩坑记录规格驱动的边界与非适用场景5.1 规格写成PRDAI掉进细节黑洞我第一次写规格几乎把PRD的所有内容都搬了进去界面布局、按钮位置、颜色取值、交互文案。结果就是AI把大量精力花在“对齐按钮”“调整间距”这些细枝末节上核心业务逻辑反而实现得马马虎虎。后来我给自己立了一条原则规格只管行为和边界不管外观和实现方式。按钮长什么样、代码用什么模式实现留给AI自己决定。规格管得太细既消耗写作时间又限制AI发挥空间两头不讨好。真正的规格应该是“薄而清晰”的——薄到每个字都有信息量清晰到每条需求都能被判定对错。5.2 验收标准写成测试用例验收标准AC和测试用例的高频混用是另一个常见问题。正确的AC写法AC-001: 未登录用户访问个人页会被重定向到登录页错误的AC写法AC-001: GET /api/profile 无Authorization头时返回302且Location为/login第一种描述的是用户可感知的行为第二种描述的是HTTP接口的具体实现。AC写成测试用例会把AI锁死在特定实现方案上失去让它选择最优解的空间。我的建议是AC停留在“用户场景行为结果”这一层具体测试用例让AI在TDD技能指导下自己生成。5.3 技能装好了却没生效SuperPowers最常见的“无效安装”技能确实在目录里AI表现却和没装一个样。原因通常有三类装完技能后没有重启会话AI还是旧上下文。图形化工具里的技能开关没打开文件在目录里不代表运行时加载了。技能安装到了错误目录不同工具的skills路径约定不同。排查方法很直接新开会话直接问AI当前加载了哪些技能。或者用codex list skills这类CLI命令查看技能列表。经验是多数问题重启一次会话就解决所以技能“不生效”时先重启再排查路径顺序别反过来。5.4 规格变更不走记录三个月后一片混乱SDD体系里最容易被忽视的是CHANGELOG。项目初期规格少直接改文件没毛病项目大了之后没有变更记录的规格目录就是一堆分不清哪版有效的文档。OpenSpec在specs/name/目录下天然生成了CHANGELOG.md就要物尽其用。每次修改规格把“改了什么、为什么改”写进CHANGELOG。这个习惯能让你在做需求回溯、代码Review甚至复盘“当初为什么这么设计”的时候有据可查。5.5 不适合SDD的场景以及我的判断标准最后说边界。SDD是工具不是信仰下面几种场景我不会硬套一次性Demo或Hackathon目标是快速验证想法写规格的时间不如直接写代码。纯探索性研究连要解决的问题都不清晰规格文档只会变成空中楼阁。一两天能做完的小脚本规格维护成本高于代码本身不划算。我自己的判断标准是两问检测法这个项目需要多轮迭代吗后续会有AI或其他人接手吗只要有一个回答为“是”就值得用SDD两个都否定可以直接跳过。项目规模变大之后规格文档就是防止AI反复跑偏的护栏。我实际项目里的感受是当代码规模超过三个模块、迭代周期超过两个月规格文档的存在感会越来越强前期写的每一条验收标准后期都会变成防止回归的护城河。最后分享一个自己养成的习惯每次新项目init完OpenSpec我都会花十分钟在project.md里写清三件事——技术栈、目录约定、禁止事项。看起来不起眼却决定了AI后续所有任务的执行基调。SDD做久了你会发现工具只是载体真正的门槛是你有没有把需求想清楚的习惯。OpenSpec和SuperPowers恰好是把这个习惯落地的两个趁手工具。 
长河君 · 2026/9/14 10:26:22 · 阅读 1.2k 规范驱动开发（SDD）实战：用OpenSpec和SuperPowers约束AI编程
1. SDD不是TDD的换皮规格先行的逻辑变了什么1.1 一个让我重新审视SDD的契机我最初系统接触SDDSpec-Driven Development基于规范编程是在开始重度使用AI编码助手之后。项目做中期一个扎眼的问题越来越频繁AI生成代码的速度越来越快但代码的“方向感”越来越差。这次会话加的功能下次会话就被它自己改没了上星期刚定下的设计约束这星期它完全不记得。促使我真去研究SDD的导火索是一次需求变更。产品说要加一个过滤条件我在对话框里改了一句话AI花二十分钟改了七八个文件。功能确实实现了但上周写好的分页逻辑、缓存策略全被它顺手改坏。那次之后我意识到问题不在AI而在我给AI的输入方式。1.2 SDD、TDD、BDD三者的定位差异先把概念理清楚。SDD这个缩写有歧义有人说是Spec-Driven Development有人说是Security-Driven Development这里讨论的是前者。很多人第一反应是“这不就是测试先行吗”还真不是。TDD测试驱动开发先写失败测试再写实现最后重构。约束对象是代码行为交付物是测试套件。BDD行为驱动开发用Given-When-Then的自然语言场景描述行为让业务和技术共用一套语言。约束的是沟通方式交付物是场景文档。SDD规格驱动开发先用结构化格式描述系统该做什么、满足什么条件算完成再把规格作为AI或人类的实现依据。约束的是需求到实现的映射交付物是规格文档。用个不严谨但好记的类比TDD是每铺一块砖就检查一次BDD是出发前把所有路牌写清楚SDD是动工前把整条路的验收标准、限高、限速全部定好然后让施工队照着干。1.3 为什么AI时代SDD的优先级突然上来了SDD方法论很早就存在但以前一直没大规模流行原因在于规格文档的写作成本高而且规格翻译成代码还是靠人等于凭空多一道工序。AI编码工具普及后情况彻底反转。大模型编码助手有三个显著特点执行力强给它明确任务它能写出结构完整、可直接运行的代码。边界感弱需求里没写清的地方它会自己脑补脑补方向每次还都不一样。上下文存续性差新会话它完全不懂旧决策除非你把上下文完整喂进去。规格文档恰好补上AI的两块短板给足边界、保存决策。所以你会发现OpenSpec这类工具几乎和AI编程生态同步火起来SDD本质就是为“人机协写代码”这个场景准备的。1.4 SDD瞄准的三个核心痛点痛点没有SDD时的表现有SDD之后需求漂移口头改需求改完不知道改到哪规格和CHANGELOG忠实记录每次变更AI幻觉失控AI自由发挥做出来的不是你要的规格边界限制AI发挥空间协作断层需求方和开发方各自理解、各自表达规格成为双方共用的“中间语言”以我的实际体验来说用了SDD之后AI犯的错误从“方向性错误”降级为“局部性错误”。方向错最麻烦因为得推翻重来局部错改一两个文件就完事。这一个降级带来的时间节省是肉眼可见的。2. OpenSpec实操拆解从安装到规格落地的完整链路2.1 OpenSpec是什么以及它和“随手写文档”的区别OpenSpec是一个开源CLI工具它干三件事提供标准化的规格目录结构让规格不再是一堆散落的Markdown文件。提供规格生命周期管理命令从创建、修改、验收、废弃全程有迹可循。提供agent启动器把规格文档打包成AI编码助手的初始上下文让AI照着规格干活。总有人问“我自己写个Markdown丢给AI不也一样” 能用但跑一阵你就会发现问题格式不统一AI分不清哪些是硬性需求、哪些是随笔没有版本概念改着改着就忘了哪版生效没有任务拆分AI拿到整篇文档不知道从哪动手。OpenSpec的价值不在于“能写文档”而在于把规格变成可执行、可追踪、可验收的数据结构。2.2 安装与初始化macOS上安装很省事brew install openspec也可以用npm全局安装npm install -g openspec两者选一即可。Homebrew的好处是后续升级方便npm的好处是新版本发得快。我这边用的是macOS版本装完先确认一下openspec --version保证是最新release。进入项目目录后初始化openspec init执行完会生成openspec/目录这就是后续所有规格管理的大本营。2.3 目录结构与规格格式拆解一个典型的OpenSpec项目结构如下openspec/ ├── project.md ├── specs/ │ ├── user-auth/ │ │ ├── spec.md │ │ └── CHANGELOG.md │ └── shared-upload/ │ ├── spec.md │ └── CHANGELOG.md └── agents/ ├── openspec-agent.md └── superpowers-agent.mdproject.md是项目级上下文里面应该写清楚技术栈、主要目录的用途、编码约定、明确禁止事项。这些内容会成为AI每次任务的全局背景。specs/下一个功能模块一个文件夹核心文件是spec.md。它用YAML frontmatter加Markdown组织四个部分缺一不可Context、Requirements、Tasks、Acceptance Criteria。以“用户认证”规格为例--- id: user-auth title: 用户认证 status: active --- ## Context 用户系统需要在第一版支持基础的注册和登录暂不考虑OAuth等三方登录。 ## Requirements - REQ-AUTH-001: 用户可以使用邮箱密码注册账号 - REQ-AUTH-002: 注册时邮箱需要唯一密码需要存入数据库的哈希字段 - REQ-AUTH-003: 用户可以退出登录退出后token立即失效 ## Tasks - T-001: 设计用户表结构和token方案 - T-002: 实现注册接口 - T-003: 实现登录接口 - T-004: 实现退出登录接口 ## Acceptance Criteria - AC-001: 注册成功返回201和用户基本信息 - AC-002: 重复邮箱注册返回409 - AC-003: 登录成功返回有效tokentoken有效期7天 - AC-004: 退出登录后旧token访问受保护接口返回401几条写作原则都是踩过坑之后总结的Requirements是硬性约束每条都要能被明确判定为“满足/不满足”不要出现“尽量”“可能”这类模糊词。Tasks是给AI的执行清单粒度控制在一个任务对应一次完整的小改动太大AI无从下手太小又显得琐碎。Acceptance Criteria要写成可测试的行为描述不是“代码怎么实现”的内部细节。2.4 核心命令与生命周期管理OpenSpec的命令不多但每个都要用好openspec spec add name # 新增规格 openspec spec update name # 修改规格 openspec spec accept name # 标记为已接受/已实现 openspec spec reject name # 标记为打回 openspec spec list # 查看所有规格状态 openspec agent add # 启动AI agent执行规格openspec agent add是核心中的核心。执行后工具会把规格内容整理成agent的初始prompt拉起你配置好的编码助手AI从第一条需求开始逐项执行。一个使用习惯强烈建议养成每次改需求都走openspec spec update并且顺手更新CHANGELOG不要直接编辑spec.md就完事。变更记录平时没什么存在感但项目做到第三个月、需求大改的时候你一定会感谢当时记下的每一行变更说明。3. SuperPowers技能包它到底解决了AI编码的什么问题3.1 SuperPowers是什么SuperPowers是Jesse Vincent发起的开源项目现在社区维护很活跃。它的定位很清晰给AI编码助手装配“技能”。这里的“技能”不是简单的prompt模板而是一套带工作流的指令文件以SKILL.md为核心包含技能的适用场景、执行步骤、注意事项。AI加载技能之后不是“知道这个知识点”而是“遇到这类任务时强制按指定流程执行”。对比一下你就明白没有技能时你让AI“修个bug”它会立刻开始猜。有了debugging技能后你让AI“修个bug”它会先要复现步骤再定位根因再写修复再做验证整个流程被动地规范起来。3.2 安装方式不同工具的skill目录约定SuperPowers的安装命令在主流AI前端基本都配套了。Codex CLI安装codex install skill superpowers装完可用codex list skills验证。Claude Code安装claude install skill superpowersClaude Code的skill机制比较成熟装完重启会话即可生效。Cursor技能配置放在~/.cursor/skills/目录手动放进去或通过CLI操作都行装好后在设置界面确认技能被识别。Trae和Workbuddy方式是类似的核心是找到对应工具的skills目录并放置技能文件。Trae一般在~/.trae/skills/Workbuddy的具体路径看版本装完后在技能列表里确认superpowers出现。这里有个特别值得说的坑装完一定要验证加载状态。不同工具对技能加载时机不一样有的重启会话就生效有的还需要在设置里手动开启。判断方法很简单——新开会话直接问AI“你当前加载了哪些技能”如果回答里没有spec-driven-development、test-driven-development等关键词那基本就是没加载成功去检查安装路径和开关。3.3 技能包里的主力技能与配合逻辑SuperPowers包里技能很多日常编码最常用的有这些spec-driven-development检测到规格文档时按规格驱动流程执行任务。test-driven-development先写测试、再写实现、再重构的固定节奏。debugging结构化排查问题先复现、再定位、再修复、再验证。systematic-thinking遇到非确定性任务时先拆解问题边界再动手。subagent-driven-development把大任务拆成多个子任务分配给子agent并行处理。特别想强调的是它们的“配合逻辑”。SuperPowers不是把一堆技能简单堆叠起来它们之间有层级调用关系。比如spec-driven-development内部会调用test-driven-developmentdebugging遇到需要写测试验证的场景也会自动切到TDD流程。这种技能间的协作机制才是它区别于普通prompt集合的核心价值。3.4 SuperPowers和OpenSpec的边界两者不是竞品不少刚接触的人会混淆。用一句话说清OpenSpec负责需求侧的标准化需求怎么组织、任务怎么拆、验收标准怎么定。SuperPowers负责执行侧的标准化AI拿到任务后用什么工作流把它做漂亮。OpenSpec解决“做什么”SuperPowers解决“怎么做好”。两者在同一条流水线上前者上游后者下游。4. OpenSpec与SuperPowers的配合方式与工具链整合4.1 一套开箱即用的组合工作流把实际用下来的完整流程整理成可直接抄作业的版本第一步初始化规格目录openspec init在openspec/project.md里写好项目背景、技术栈、目录约定、禁止事项。第二步写规格openspec spec add user-auth按Context、Requirements、Tasks、Acceptance Criteria的结构填写。需求要硬性可判验收标准要可测试。第三步启动agent执行openspec agent addOpenSpec会启动配置好的编码助手SuperPowers的规格驱动技能接管执行流程。AI先给出任务拆解清单确认规格理解无误再逐项实现每个任务完成后对照验收标准自查。第四步人工验收agent执行完先别急着commit。看它给的验收结果列表逐条对照AC。没满足的让它回到对应任务重做满足的再进入下一步。这套流程跑下来的整体感受是AI不再像一个“等指令的实习生”更像一个“拿着需求说明书工作的远程工程师”沟通成本下降返工量明显变少。4.2 有OpenSpec和没OpenSpec一次对比实验为了验证组合价值我做了一次A/B对比。同一个功能——给博客加标签筛选——分别走两种模式跑一遍。没有OpenSpec的模式直接对AI说“帮我做一个标签筛选功能支持按标签过滤文章列表”。AI的典型反应是猜数据库字段、猜筛选接口URL、顺手加了一个它觉得“有用”的排序参数最后提交的代码里大约10%的内容是需求里没有的。有OpenSpec的模式花十分钟写规格明确REQ-BLOG-TAG-001标签筛选接口接受tag参数并返回匹配文章、AC-001传入不存在的tag时返回空列表而非报错、AC-002不传tag时返回全部文章。AI拿到规格后实现的代码几乎完全落在需求边界内每条需求都有对应实现说明。结论很明确没有OpenSpec时AI工作质量的波动方差很大有OpenSpec时AI表现稳定可预期。对工程项目来说稳定比偶发的灵光一现重要得多。4.3 工具链整合Cursor、Codex CLI、IDEA插件ccgui、Trae/Workbuddy这套组合的工具生态兼容性不错逐个说下整合现状。Cursor OpenSpecCursor对上下文管理能力强在.cursor/rules/加一条规则让它启动时自动加载openspec/specs/下的规格文件。这样每次新建会话AI都带着规格上下文工作不需要手动粘贴。Codex CLI SuperPowers通过codex install skill superpowers装好技能包在同一个CLI里跑OpenSpec的agent指令。Codex现在的agentic能力配合SuperPowers的流程约束做多步任务很稳。IDEA插件ccgui集成OpenSpecccgui是社区开发的IDEA插件把OpenSpec管理界面放进IDE侧边栏支持直接查看规格状态、创建规格、发起agent任务省去了频繁切终端的麻烦。对于重度使用IDEA的团队这个集成很值得装。Trae / Workbuddy安装superpowers skill这类新工具的skill机制还在快速演进但底层逻辑一致把superpowers技能目录放到对应工具的skills目录再到配置里确认加载。注意每个工具的目录名可能不同装完务必验证。4.4 组合工作中人的角色迁移从写代码到写规格用了这套体系之后我对自己工作重心的变化有了很清晰的感知。以前核心工作是“写代码”现在变成了两块写规格和验收获。写规格要求你具备比“会写代码”更高层的抽象能力。你得能从模糊的业务需求里提炼出硬性约束能预判验收标准是否可测试能为AI划定合理的行动边界。这恰恰是资深工程师最值钱的能力。验收获也不是简单看跑通没跑通而是对照规格逐条判断“做了没有、做对没有”。这个环节的质量直接决定SDD闭环是否生效。所以“SDD会取代程序员”是个伪命题它真正做的是优化精力分配把重复、机械的编码工作尽量交给AI让自己抽出时间做更有决策含量的事。5. 实战踩坑记录规格驱动的边界与非适用场景5.1 规格写成PRDAI掉进细节黑洞我第一次写规格几乎把PRD的所有内容都搬了进去界面布局、按钮位置、颜色取值、交互文案。结果就是AI把大量精力花在“对齐按钮”“调整间距”这些细枝末节上核心业务逻辑反而实现得马马虎虎。后来我给自己立了一条原则规格只管行为和边界不管外观和实现方式。按钮长什么样、代码用什么模式实现留给AI自己决定。规格管得太细既消耗写作时间又限制AI发挥空间两头不讨好。真正的规格应该是“薄而清晰”的——薄到每个字都有信息量清晰到每条需求都能被判定对错。5.2 验收标准写成测试用例验收标准AC和测试用例的高频混用是另一个常见问题。正确的AC写法AC-001: 未登录用户访问个人页会被重定向到登录页错误的AC写法AC-001: GET /api/profile 无Authorization头时返回302且Location为/login第一种描述的是用户可感知的行为第二种描述的是HTTP接口的具体实现。AC写成测试用例会把AI锁死在特定实现方案上失去让它选择最优解的空间。我的建议是AC停留在“用户场景行为结果”这一层具体测试用例让AI在TDD技能指导下自己生成。5.3 技能装好了却没生效SuperPowers最常见的“无效安装”技能确实在目录里AI表现却和没装一个样。原因通常有三类装完技能后没有重启会话AI还是旧上下文。图形化工具里的技能开关没打开文件在目录里不代表运行时加载了。技能安装到了错误目录不同工具的skills路径约定不同。排查方法很直接新开会话直接问AI当前加载了哪些技能。或者用codex list skills这类CLI命令查看技能列表。经验是多数问题重启一次会话就解决所以技能“不生效”时先重启再排查路径顺序别反过来。5.4 规格变更不走记录三个月后一片混乱SDD体系里最容易被忽视的是CHANGELOG。项目初期规格少直接改文件没毛病项目大了之后没有变更记录的规格目录就是一堆分不清哪版有效的文档。OpenSpec在specs/name/目录下天然生成了CHANGELOG.md就要物尽其用。每次修改规格把“改了什么、为什么改”写进CHANGELOG。这个习惯能让你在做需求回溯、代码Review甚至复盘“当初为什么这么设计”的时候有据可查。5.5 不适合SDD的场景以及我的判断标准最后说边界。SDD是工具不是信仰下面几种场景我不会硬套一次性Demo或Hackathon目标是快速验证想法写规格的时间不如直接写代码。纯探索性研究连要解决的问题都不清晰规格文档只会变成空中楼阁。一两天能做完的小脚本规格维护成本高于代码本身不划算。我自己的判断标准是两问检测法这个项目需要多轮迭代吗后续会有AI或其他人接手吗只要有一个回答为“是”就值得用SDD两个都否定可以直接跳过。项目规模变大之后规格文档就是防止AI反复跑偏的护栏。我实际项目里的感受是当代码规模超过三个模块、迭代周期超过两个月规格文档的存在感会越来越强前期写的每一条验收标准后期都会变成防止回归的护城河。最后分享一个自己养成的习惯每次新项目init完OpenSpec我都会花十分钟在project.md里写清三件事——技术栈、目录约定、禁止事项。看起来不起眼却决定了AI后续所有任务的执行基调。SDD做久了你会发现工具只是载体真正的门槛是你有没有把需求想清楚的习惯。OpenSpec和SuperPowers恰好是把这个习惯落地的两个趁手工具。