![[Pasted image 20260720094059.png]] 难度★★★☆☆ ⏱️ 阅读时间25 分钟 前置知识博文 10行业映射Spec-driven Development · TDD · AI Coding Workflow Automation排他职责解释Spec 写好了谁来执行、怎么确保代码质量这个被忽视的问题——OpenSpecSDD与 SuperpowersTDD的双驱动集成方式。导流去向想深入了解流水线 Runtime → 博文 18Sub-agent 流水线 Agent Runtime想看主线项目实战 → 博文 31主线二一句话理解OpenSpec 定好做什么Superpowers 守住做得好——两个单点工具一条完整链路。 本文产出SDDTDD 双驱动工作流全景图含真实命令与状态流转Delta Spec 反写机制5 类高频遗漏场景对照表Comet vs Temporal 选型决策树kcctl 命令优化完整实录一次真实项目、5 阶段流水线的完整时间线 商业价值独立开发者或 3-5 人小团队用 SDDTDD 双驱动流程可系统性提升 AI 编程工作流的交付质量——规格驱动保证做对的事TDD 循环保证把事做对两者互补形成完整链路。Superpowers 官方在 6.0 版本发布说明中给出的实测数据显示新版审查机制相比旧版在同等质量下速度提升约一倍Token 消耗降低近 50% 来源obra/superpowers Releases这意味着按 Token 计费的 AI 编程场景中团队规模不变的情况下月度 API 成本有直接下降空间 推断需按实际项目复杂度验证。开篇一个被忽视的裂缝你用 AI 写好了规格文档点下执行——代码生成了但质量参差不齐。同一份 Spec 跑三次边界处理、错误路径、变量命名可能截然不同。下次新会话AI 不记得上次发现的那些边界场景于是同样的坑再踩一遍。这不是模型能力的问题而是流程缺失了纪律。OpenSpec 解决了做什么的问题但它默认工作流的/opsx:apply执行阶段本身并不强制额外的工程约束没有内置的 TDD 循环、没有分阶段代码审查、没有边界场景的反向追问 来源Fission-AI/OpenSpec 官方文档。Superpowers 则反过来TDD 执行扎实brainstorming 环节会主动反问需求边界但它产出的设计文档若不进入一个有版本管理的规格系统设计决策和边界发现就容易散落在对话历史里——下次新会话同样的边界问题可能被重新发现一遍。把两者接在一起这个裂缝就合上了。一、各有短板组合互补单独使用两个工具时各自的问题比较典型。单用 OpenSpec的问题集中在实现质量的不稳定性上。规格写得再严密/opsx:apply在生成代码时调用的仍是模型的基础编码能力——核心工作流没有强制测试覆盖也没有阶段性代码审查这道关卡兜底。代码质量取决于模型当下对上下文的熟悉程度而不是流程在兜底。同一个规格跑三次边界处理和错误路径上可能有显著差异。单用 Superpowers的问题则集中在设计沉淀和跨会话记忆上。Superpowers 官方文档明确说明brainstorming 环节的产出是一份设计文档直接保存在项目里 来源obra/superpowers README——但如果这份文档不与一个有版本管理、支持增量变更delta的规格系统对接设计决策和边界发现就容易停留在单次会话的产物里难以在后续变更中被结构化追溯。组合之后职责边界变得清晰proposal design 作为输入反写 delta spec缺失场景SuperpowersTDDbrainstorming深度技术设计writing-plans实现计划subagent-driven-developmentTDD 实现 任务级审查OpenSpecSDDproposal.md做什么为什么做specs/行为场景design.md技术方案tasks.md任务拆解OpenSpec 是规格的生命周期载体——版本管理、归档、追溯。Superpowers 是代码质量的执行器——技术设计、TDD 实现、代码审查。衔接点是双向的OpenSpec 的产出作为 Superpowers brainstorming 的输入Superpowers 挖掘出的需求盲区反写回 OpenSpec 的 delta spec 中长期保存。✅ 已验证 / 来源说明OpenSpec 的 delta spec 机制是其官方文档明确定义的核心设计——“delta specs describe what’s changing rather than restating the entire spec”这也是它支持存量项目brownfield迭代而非只支持从零开始项目的关键设计 来源OpenSpec Concepts 文档。二、Superpowers 的 TDD 强制机制Superpowers 的核心是几个可组合的 Skill它们被设计为按顺序自动激活让 AI 像有纪律的工程师一样工作Skill触发时机实质作用brainstorming写代码之前反向提问澄清边界分段呈现设计供确认保存设计文档using-git-worktrees设计确认后在新分支上创建隔离工作区跑通项目初始化确认测试基线干净writing-plans设计确认后拆解为 2–5 分钟一个的可执行任务每个任务给出确切文件路径、完整代码和验证步骤subagent-driven-developmentPlan 确认后为每个任务派发独立子代理执行 TDD 循环并做任务级审查覆盖规格符合性与代码质量两方面 来源obra/superpowers 官方 README 与各 Skill 说明brainstorming 是最独特的环节。它不像普通 AI 那样接受需求直接开写而是反向提问你用这个功能解决什么问题失败时应该怎么表现有没有现成的替代方案这个环节的产出是一份分节呈现、需要开发者逐段确认的设计文档而不是模板套话。subagent-driven-development 是执行环节。每个任务启动独立子代理——之所以用独立子代理而非在主会话里连续写是为了让每个任务只带着精确构造的上下文工作避免主会话的历史记录污染实现细节 官方文档称之为 “context isolation principle”也让协调者的上下文得以保留。子代理强制走 TDD 循环先写测试红灯→实现代码绿灯→重构优化。⚠️ 版本细节提示早期版本的 Superpowers 用两个独立的 Reviewer Prompt 分别检查是否符合规格和代码质量本身在 6.0 版本发布后官方将这两份 Prompt 合并为一份统一的 task-reviewer-prompt官方说明这一改动让审查更便宜、更严格、更难被蒙混过关并在同等质量下实现约 2 倍提速、Token 消耗降低近 50% 来源obra/superpowers Release Notes / Releases。也就是说规格符合性和代码质量这两个检查维度依然都在只是合并进了同一次审查动作里而不是两次独立调用——如果你在用较新版本日志里看到的会是一次任务审查而非两次。发现问题审查通过是否任务开始子代理启动独立上下文先写测试 ❌红灯实现代码测试通过 ✅绿灯重构优化任务级审查规格符合性 代码质量阻塞修复后继续任务完成还有下一个任务整分支复核说明Superpowers 官方并未公布20 个任务 42 分钟 vs 人工 3-6 小时这类通用效率对照数据这类具体数字因项目复杂度、模型选型差异较大本文不做泛化结论仅在下文第五节的 kcctl 实战中给出这一次真实项目的实测耗时✅ 已验证作者实测非官方基准。三、SDDTDD 双驱动工作流完整流程分六步前段由 OpenSpec 主导后段由 Superpowers 主导代码仓库SuperpowersOpenSpec开发者代码仓库SuperpowersOpenSpec开发者/opsx:propose 描述需求生成四件套proposal / specs / design / tasks确认规格proposal design 作为输入brainstorming 深度技术设计发现缺失场景 → 反写 delta specwriting-plans 生成实现计划确认 Plan关键决策节点subagent-driven-developmentTDD 实现 提交代码任务级代码审查审查报告/opsx:verify 校验实现是否匹配 delta spec/opsx:archive 归档delta spec 并入主 spec 补充说明/opsx:verify属于 OpenSpec 的扩展工作流命令集与/opsx:new、/opsx:continue、/opsx:ff、/opsx:bulk-archive、/opsx:onboard同属一组默认的核心 Profile 只包含 explore / propose / apply / archive。要用上 verify需要先执行openspec config profile切到扩展 Profile再跑一次openspec update同步命令 来源OpenSpec 官方文档 How Commands Work / CLI 文档。如果你按官方默认安装后发现聊天里敲不出/opsx:verify大概率是 Profile 没切而不是命令消失了。在这条链路里开发者主要的决策节点集中在确认规格和确认 Plan两处其余步骤高度自动化。这也是为什么后面的 kcctl 实战案例里开发者手动介入的时间只占全程很小一部分——真正需要人来拍板的只是设计方向的选择。四、Delta Spec 反写AI 最容易漏掉的 5 类场景✅ 作者实测案例kcctl 项目 Todo 模块Delta spec 反写机制是本文最核心的工程洞察。它解决的问题是AI 在 brainstorming 阶段发现的需求盲区如果只停留在对话里下次新会话就会凭空消失。写回 OpenSpec 的 spec 文件——OpenSpec 用 delta spec 描述变更了什么而非重写整份规格这正是它支持存量项目迭代的关键设计 来源OpenSpec Concepts 文档——这些发现才能被长期保存和追溯。以 Todo 应用为例Superpowers brainstorming 读了 OpenSpec 生成的 proposal、design 和 specs 后发现了以下 5 类被遗漏的场景场景类型OpenSpec 原始写法Superpowers 补充后输入边界“不能添加空任务”补充whitespace-only全空白字符同样拒绝存储失败假设 localStorage 永远可用补充隐私模式抛出异常、配额满时写入失败的处理部分数据损坏有损坏数据时全部清空改为跳过损坏条目保留有效数据安全渲染使用 innerHTML改为textContent防止 XSS 注入多路径守卫仅检查按钮点击路径补充Enter 键空输入同样需要守卫这五类场景代表了 AI 在生成规格时较为高频的遗漏模式输入边界定义不完整、外部依赖异常路径被忽略、部分失败场景缺乏降级策略、安全默认值未被强制、多入口路径只守卫了主路径。如果不做这个补充这些问题往往会在测试阶段甚至上线后才被发现。Delta spec 机制的价值不仅是发现它们而是把发现的过程制度化——每次变更都走一遍反问环节每次发现的盲区都落入版本控制长期可追溯。五、kcctl 实战一次真实的完整变更记录✅ 作者实测案例kcctl 命令优化已验证Comet 工具将整个 SDDTDD 双驱动流程封装为自动化流水线 来源rpamis/comet 官方仓库Comet 官方定位为用统一跨平台 Runtime 连接 OpenSpec 制品与 Superpowers 执行方法论的 Skill Harness以下是一次真实项目kcctl 命令优化的完整记录。需求背景很简单优化 kcctl 中的 operation 和 logs 命令提高日志展示的可读性。这个需求不算复杂但涉及 TUI 布局决策、多命令联动是典型的看起来简单、边界繁多类需求。Open 阶段/comet-openOpenSpec 主导Comet 检测到这是新需求而非 hotfix进入完整流程。openspec explore propose生成四件套规格定义了步骤列表在左、日志内容在右的分栏布局作为候选方向。Deep Design 阶段/comet-design1 次人工决策Superpowers brainstorming 提出 3 种 TUI 布局方案方案 ASplit Panel 方案 BStacked 方案 CTree View ┌──────────┬────────┐ ┌─────────────────────┐ ┌─────────────────────┐ │ 步骤列表 │ 日志 │ │ 步骤列表 │ │ ▶ Phase 1 │ │ │ │ ├─────────────────────┤ │ ▶ Task 1.1 │ │ ▶ Task1 │ [log] │ │ 日志内容 │ │ [log snippet] │ │ Task2 │ [log] │ │ │ │ ▶ Phase 2 │ └──────────┴────────┘ └─────────────────────┘ └─────────────────────┘ 左右分栏适合宽屏 上下堆叠适合窄屏 树形展开适合层级深的任务开发者选择方案 ASplit Panelbrainstorming 据此产出完整 Design Doc并反写了 2 条 delta spec窄终端降级为 Stacked 布局、日志滚动区域边界处理。Plan Build 阶段/comet-buildSuperpowers 主导Plan 被拆分为 5 个 Phase 共 20 个任务subagent-driven-development 逐任务派发独立子代理执行每个任务完成后触发任务级审查。这一阶段是全流程里耗时最长的部分。Verify Finish 阶段/comet-verifyOpenSpec Superpowers 共同校验发现 1 个 FAILkcctl operation list 缺少 sponsor 列和若干 minor 问题Agent 自动修复后验证通过。验证范围覆盖所有 spec 列出的功能点是否实现、代码质量是否满足规范、测试是否全部通过、分支处理是否完成。Archive 阶段/comet-archiveOpenSpec 主导delta spec 并入主 specbrainstorming 产物、实施记录、验证报告全部归档Comet 的状态文件标记为已归档。整个过程中开发者真正需要拍板的只是 Design 阶段的布局选择——这不是AI 替代开发者而是开发者把注意力从怎么写代码腾出来聚焦在做哪种设计选择上其余环节由 Comet 按 5 阶段流水线自动衔接、自动校验。生产落地注意事项一、不要跳过 brainstorming即使需求看起来很简单。brainstorming 是 Superpowers 最有价值的环节也是最容易被跳过的环节。开发者经常判断这个需求很清楚直接让 AI 写就行——结果是代码有了但边界场景没覆盖测试阶段返工。Delta spec 里那 5 类高频遗漏几乎每个需求都会出现其中 2-3 类。brainstorming 的价值不是想清楚而是强制你被反问一遍。二、Delta spec 必须写回 OpenSpec否则发现等于没发现。Superpowers 在 brainstorming 里发现的盲区如果只停留在对话历史中下次新会话就是一张白纸。只有反写回 OpenSpec 的 spec 文件纳入版本控制这些发现才有追溯价值才不会在下一个类似需求里重蹈覆辙。三、/opsx:verify需要手动开启扩展 Profile不是开箱即用。如果你是从零搭建这条链路不通过 Comet记得先切 OpenSpec 的扩展 Profile 再同步命令否则会在确认实现是否匹配 delta spec这一步卡住误以为是工具本身缺失功能。总结OpenSpec 和 Superpowers 单独用都有明显短板前者管好了写什么却管不住写得好不好后者能把代码写好却留不住这次发现了什么。Delta spec 反写机制是把两者接起来的关键一环——它让 Superpowers 在 brainstorming 阶段挖出的需求盲区不再随对话消散而是沉淀进有版本管理的规格系统里长期可追溯。如果你现在的 AI 编程工作流还停留在Spec 写完直接丢给模型生成代码下一步可以先从最小可行版本开始给一个正在做的小需求手动跑一遍/opsx:propose → brainstorming → writing-plans → subagent-driven-development → /opsx:archive感受一下 delta spec 反写带来的差异再决定要不要上 Comet 做自动化封装。下一章预告本章打通了 SDDTDD 双驱动链路OpenSpec 定义做什么Superpowers 执行做得对。但整个流程依赖对 Superpowers 各 Skill 的深度理解——brainstorming 的反问机制、writing-plans 的拆解粒度、subagent 的上下文隔离。下一章 将深入 Superpowers 6.0 的完整功能体系从安装配置到自定义技能开发从平台兼容性到 Fable 自优化循环让你能真正驾驭这套工具而不仅仅是跑通一条流水线。本专栏的开源落地工具IvyFlow本专栏的整套方法论——多角色工作流、阶段守卫、OpenSpecSuperpowers 双驱动、Skill/Rule/Agent 三层分层——并非纸上谈兵。它们的落地载体是 IvyFlow一个 AI-Native 开发工作流 CLI 工具也是本专栏作者的开源项目。IvyFlow 用一条命令ivy init在项目中部署 5 种角色Developer / PM / QA / Architect / DevOps共 20 条命令和约 30 个 Skill将专栏中讨论的Phase Gate、Delta Spec 反写、TDD 强制循环、SubAgent 并行扇全部编码为脚本校验而非纯 Prompt 约定——守卫脚本会硬性拦截 AI 跳过阶段的行为让流程纪律从建议变成物理约束。GitHubgithub.com/jseko/IvyFlow官方网站jseko.github.io/IvyFlow安装npm install -g ivyflow-cli ivy init如果你读完本专栏想立刻落地IvyFlow 就是这套体系的开箱即用入口。