Codex + OpenSpec + Superpowers 企业级落地方案二 - 今日头条 摘要
文档概览
本文不是单纯介绍某个工具，而是在说明一种企业级功能交付方法：把 Superpowers 与 OpenSpec 组合起来，形成“先探索、再定规、后执行、终归档”的闭环流程。
核心主张：先用 Superpowers 把需求、边界、方案和风险探索清楚；再用 OpenSpec 把已经确认的内容锁定为正式规范；随后回到 Superpowers 严格按规范编码、测试、验证；最后由 OpenSpec 归档留痕。
原文反复强调，这套流程不是为了增加流程而增加流程，而是为了处理企业项目里最常见的两类根因问题：
- 需求不确定
- 规范不统一
作者给出的目标很明确：减少返工、争吵、延期与甩锅，让交付过程变成“可落地、可验收、可追溯”的结果。
关键事实
这套组合要解决什么问题
原文认为，企业项目里大部分返工、争吵、延期，根源通常都落在两件事上：
- 需求尚未捋清，就过早开始写规范，结果规范很快被推翻。
- 干脆跳过规范直接写代码，导致实现方向跑偏，后续测试、验收、维护都出问题。
因此，两个工具在流程中的职责被刻意拆开：
- Superpowers：专门处理“模糊不清”，用于探索需求、比较方案、识别风险、形成方向。
- OpenSpec：专门处理“标准不一”，用于把已确认内容固化成正式规范，避免被随意改动。
这种分工的最终目标不是流程美观，而是降低混乱交付带来的成本：少走弯路、少加班、少背锅。
适用场景与不适用场景
原文明确提醒“别瞎套流程”，不是所有改动都值得走完整闭环。
适合使用完整流程的需求
以下类型建议完整走完探索、定规、执行、归档四阶段：
- 新增接口或者新增业务能力
- 修改已有的核心业务行为
- 涉及权限、审计、交易、数据一致性等关键逻辑
- 跨多个模块的改造工作
- 需要测试验收、需要留痕备查的重要功能
这些需求的共同特征是：影响面大、逻辑敏感、需要严谨验收、后续可能被追责或复盘。
不必套完整流程的需求
以下类型可以直接快速处理，不必强行套完整流程：
- 简单的问答内容调整
- 文字拼写错误修正
- 文档格式、排版调整
- 不改变业务逻辑的小型文档优化
原文的判断原则可以概括为一句话：小事快处理，大事稳落地。
总体 8 步执行链路
文章把完整流程拆成 8 个连续动作：
- 用户或业务方提出需求
- Superpowers 开始探索性规划
- 团队确认设计方向
- OpenSpec 开始锁定规范
- 团队确认 proposal、design、spec、tasks
- Superpowers 开始执行编码、测试和验证
- 团队确认验证结果
- OpenSpec 归档已完成变更
这 8 步实际上可以归纳为 4 个关键阶段，每个阶段之间都有明确闸门。
重要细节
四个关键阶段的职责分工与顺序
阶段一：Superpowers 探索性规划
这是整个流程的起点，也是最容易被企业团队做错的一步。原文特别强调两条禁止项：
- 绝对不能写代码
- 绝对不能创建规范
也就是说，这一阶段只做探索，不做实现，不做正式固化。目标是把模糊需求转成大家认可的设计方向。
原文列出的具体任务包括：
- 完整了解项目上下文，不盲目动手
- 明确需求目标
- 明确边界和“不做什么”
- 梳理输入、输出、异常场景、验收标准
- 给出 2 到 3 个可行方案，并比较优缺点
- 明确最推荐方案及其理由
- 提前识别风险
- 确定测试思路
- 输出一份简单易懂的设计草稿
- 等团队确认方向后，再进入下一阶段
这一阶段的定位很像“先勘察、再画草图”，草图没定之前，不能砌墙。
推荐产物：探索设计草稿结构
<功能名称> 探索设计
## 背景
## 目标
## 非目标
## 需求边界
## 方案选项
## 推荐方案
## 风险与权衡
## 测试策略
## 待确认问题
阶段二：OpenSpec 锁定规范
只有在探索阶段结束、设计方向已经确认后，才能进入这一阶段。它的职责不是继续讨论方向，而是把已确认内容转成正式、固定、可执行的规范。
原文列出的任务包括：
- 确定变更名称，创建 change
- 编写 proposal：说明为什么做、做什么、影响范围
- 编写 design：说明技术方案、替代方案、风险与测试策略
- 编写 spec：写清正式需求和验收场景
- 编写 tasks：拆解成可执行任务清单
- 所有文档补齐并得到团队确认后，才允许进入编码阶段
这里的关键点是“锁定”。探索阶段是开放式收敛，规范阶段是正式固化，不能混用。
常用 OpenSpec 命令
openspec new change ""
openspec status --change "" --json
openspec instructions proposal --change "" --json
openspec instructions design --change "" --json
openspec instructions specs --change "" --json
openspec instructions tasks --change "" --json
推荐产物路径
openspec/changes//proposal.md
openspec/changes//design.md
openspec/changes//specs//spec.md
openspec/changes//tasks.md
阶段三：Superpowers 执行编码、测试、验证
这一阶段再次使用 Superpowers，但角色已经从“探索者”切换为“执行者”。原文明确强调：
必须严格按照已确认规范执行，不擅自加功能，不随意改逻辑。
也就是说，到了执行阶段，自由度应该显著收缩。工作重点从“想清楚做什么”变成“按既定规范把事情做对”。
原文列出的执行步骤包括：
- 仔细阅读已确认的 OpenSpec 规范和任务清单
- 编写清晰的实现计划
- 建议用独立 worktree 开发，避免影响主干
- 按 TDD 方式工作：先写测试，再写功能代码，小步迭代
- 完成代码后运行真实测试命令
- 确保所有任务完成，且代码与规范完全对齐
- 验证通过后，准备进入归档阶段
推荐产物：实现计划结构
<功能名称> 实现计划
目标
对应 OpenSpec Change
实现范围
不做范围
文件改动计划
测试计划
执行步骤
推荐 worktree 命令
git worktree add .worktrees/-b codex/
推荐验证命令
原文给出了一组按语言或生态区分的真实测试命令示例：
mvntest
npmtest
pnpmtest
pytest
gotest ./...
cargotest
虽然文中命令排版较紧凑，但意图很明确：必须运行真实测试，而不是口头声称“应该没问题”。
阶段四：OpenSpec 归档
最后一步由 OpenSpec 收尾，把“进行中的 change”转成“已完成并可留痕的规范”。
归档前必须检查：
- 规范文档齐全完整
- 任务清单全部完成
- 测试覆盖关键场景且结果通过
- 代码实现与规范完全一致
- 确认无误后再执行归档
归档命令
openspecarchive""
阶段闸门：哪些条件没满足就不能往下走
原文把这套流程之所以靠谱的原因，归结为“闸门”机制。四条闸门分别是：
- 设计未确认，不得进入 OpenSpec 规范阶段。
- 规范文档未补齐，不得进入编码阶段。
- 没有真实测试验证结果，不得宣称功能完成。
- 代码、测试、规范不一致，不允许归档。
这四条规则对应着四类常见企业风险：
- 方案还没稳就过早固化
- 规范不完整就急着开发
- 没测就报完成
- 实现、验证、文档三套说法互相打架
文档结构与团队落地建议
推荐目录
原文建议在项目中沉淀一组固定目录，用于承载规范、计划和测试相关产物：
openspec/
changes/
docs/
superpowers/
specs/
plans/
建议写入 AGENTS.md 的规则
文章建议把流程规则写进团队约束文件，以便成为默认工作方式。原文给出了一段可直接采用的内容，大意包括：
- 对非平凡 feature，默认采用三段式组合流程
- 顺序为：Superpowers 探索性规划 → OpenSpec 锁定规范 → Superpowers 执行编码测试验证 → OpenSpec 归档
- 设计未确认前，不进入 OpenSpec
- OpenSpec artifacts 未完成前，不进入编码
- 行为变更默认使用 TDD
- 完成前必须运行真实验证命令
- 代码、测试、规范未对齐前，不归档
这里的重点是“非平凡 feature 默认执行”，也就是并非要求所有琐碎改动都重走一次完整流程。
Review 检查清单
原文还给出了一份很实用的审核清单，检查点包括：
- 是否完成 Superpowers 探索
- 是否有设计草稿
- 是否创建 OpenSpec change
- 是否有 proposal.md
- 是否有 design.md
- 是否有 spec.md
- 是否有 tasks.md
- 是否写了实现计划
- 是否补充测试
- 是否运行真实验证命令
- tasks.md 是否全部完成
- 代码、测试、规范是否一致
- 是否完成 OpenSpec 归档
这份清单说明，作者关注的不只是“产出代码”，而是要求整个变更链路都有可检查证据。
团队沟通话术
文章还提供了几段可以直接在团队协作中使用的提示语，目的是让流程要求变成可执行指令，而不是抽象理念。
完整流程指令