Codex + OpenSpec + Superpowers 企业级落地方案二 - 今日头条.md12.1 KBit/ai/Codex + OpenSpec + Superpowers 企业级落地方案二 - 今日头条.md
--- title: "Codex + OpenSpec + Superpowers 企业级落地方案二 - 今日头条" source_url: "https://www.toutiao.com/article/7629572762553582143/?wid=1782279338145" source_site: "www.toutiao.com" clipped_at: "2026-06-24T05:35:54.611078+00:00" clipper: "aiwiki-url-ingest" extractor: "toutiao_rendered" --- # Codex + OpenSpec + Superpowers 企业级落地方案二 - 今日头条 做过企业级项目的人，大概都踩过同一个坑： 要么需求一开始模模糊糊，刚把规范写好就被推翻，来回折腾浪费时间；要么干脆跳过规范直接写代码，写到一半方向跑偏，测试不过、验收不通，最后全组熬夜返工。 明明是很正常的功能开发，偏偏因为流程不清、边界不明，搞得人心力交瘁。 今天想跟大家好好聊一套，真正能在企业里用起来、不折腾人、还能管住交付质量的工作方法 —— **Superpowers 搭配 OpenSpec** 的三段式流程。 它不是纸上谈兵的理论，也不是僵硬死板的教条，而是帮你把 “不确定的需求” 变成 “可落地、可验收、可追溯” 的成果，全程清清楚楚，不内耗、不甩锅。 先用人话把核心逻辑说透： **先用 Superpowers 把方向探明白，再用 OpenSpec 把规则定下来锁死，最后再回到 Superpowers 安心编码、测试、验证，收尾交给 OpenSpec 归档留存。** 一步一步按顺序来，不跳步、不瞎改，做出来的东西既符合需求，又能经得起检查 。 # 为什么一定要这么搭配？不是多此一举 很多人会嫌麻烦：不就是做个功能吗，至于搞这么多步骤？ 但只要你在企业里待过就知道，大部分返工、争吵、延期，根源都在两件事： **需求不确定、规范不统一** 。 如果一开始需求没捋清就急着写规范，大概率写到一半被全盘推翻，前面的功夫全白费。 如果完全不写规范就埋头编码，写着写着就偏离初衷，测试、验收、后续维护全都会出问题，甚至到最后没人说得清当初到底要做什么。 所以这套组合的思路特别实在： Superpowers 专门解决 “模糊不清”，帮你把需求、方案、风险都捋顺； OpenSpec 专门解决 “标准不一”，把确定好的内容固化成正式规范，谁也不能随便改； 最后两者配合，把编码、测试、验证、归档形成完整闭环，做到有依据、有检查、有留存。 它不是为了增加流程，而是为了让你少走弯路、少加班、少背锅。 # 什么场景该用？什么场景不用？别瞎套流程 咱们职场人做事讲究效率，不该复杂的绝不复杂化，这套方法也一样，分清楚场合用才舒服。 ## **必须用完整流程的情况** 只要是涉及核心逻辑、影响范围大、需要严谨验收的需求，都建议按完整步骤走： - 新增接口或者业务能力 - 修改已有的核心业务行为 - 调整权限、审计、交易、数据一致性这类关键逻辑 - 跨多个模块的改造工作 - 需要测试验收、留痕备查的重要功能 ## **没必要用完整流程的情况** 一些不影响功能、不改变行为的小改动，直接快速处理就行： - 简单的问答内容调整 - 修正文字拼写错误 - 调整文档格式、排版 - 不改变业务逻辑的小型文档优化 简单说：小事快处理，大事稳落地。 # 总体执 行流程 1. 用户或业务方提出需求 2. Superpowers 开始探索性规划 3. 团队确认设计方向 4. OpenSpec 开始锁定规范 5. 团队确认 proposal/design/spec/tasks 6. Superpowers 开始执行编码、测试和验证 7. 团队确认验证结果 8. OpenSpec 归档已完成变更 ## **总体流程图** ## **职责关系图** # 工作时机图 # 阶段闸门图 # 完整执行流程：四步走，每一步都有明确目标 整套流程拆开来特别清晰，从提出需求到最终归档，一共四个关键阶段，每一步都有明确的任务和闸门，没过闸门绝不往下走。 ## 1 . Superpowers 探索性规划 这是整个流程的第一步， **绝对不能写代码，也不能创建规范** 。 目标只有一个：把模糊的需求，变成大家都认可的设计方向。 具体要做的事很实在： - 完整了解项目上下文，不盲目动手 - 把需求目标、边界、不做什么都明确下来 - 梳理清楚输入、输出、异常场景和验收标准 - 拿出 2 \- 3 个可行方案，对比优缺点 - 给出最推荐的方案，说明理由 - 提前识别风险，确定测试思路 - 输出一份简单易懂的设计草稿 - 等团队全部确认方向，再进入下一步 这一步就像盖房子前先勘察地形、画好草图，草图没定好，绝不动工砌墙。 **推荐产物结构** ``` <功能名称> 探索设计 ## 背景 ## 目标 ## 非目标 ## 需求边界 ## 方案选项 ## 推荐方案 ## 风险与权衡 ## 测试策略 ## 待确认问题 ``` ## 2 . OpenSpec 锁定规范 当探索阶段结束、设计方向完全确认后，就轮到 OpenSpec 上场。 它的任务是：把大家认可的设计，变成正式、固定、可执行的规范文档，不再随意改动。 具体要完成这些内容： - 确定变更名称，创建规范文档 - 编写 proposal：说明为什么做、做什么、影响范围 - 编写 design：说明技术方案、替代方案、风险与测试策略 - 编写 spec：明确正式需求和验收场景 - 编写 tasks：拆成可执行的任务清单 - 所有文档补齐，团队确认可以指导开发，再进入编码阶段 **常用命令** ``` 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 ``` ## 3 . Superpowers 执行编码、测试、验证 规范全部锁死之后，再次用到 Superpowers，这时候它的角色不再是探索，而是 **受控执行** 。 严格按照已定好的规范来，不擅自加功能、不随意改逻辑。 具体执行步骤： - 仔细阅读已确认的 OpenSpec 规范和任务清单 - 编写清晰的实现计划 - 建议用独立工作区开发，不影响主干代码 - 遵循 TDD 方式：先写测试用例，再写功能代码，小步迭代 - 完成代码后，运行真实测试命令验证结果 - 确保所有任务都完成，代码与规范完全对齐 - 验证通过后，准备进入归档阶段 **推荐实现计划结构** ``` <功能名称> 实现计划 目标 对应 OpenSpec Change 实现范围 不做范围 文件改动计划 测试计划 执行步骤 ``` **推荐 worktree 命令** ``` git worktree add .worktrees/-b codex/ ``` **推荐验证命令** ``` mvntest npmtest pnpmtest pytest gotest ./... cargotest ``` ## 4 . OpenSpec 归档 最后一步，由 OpenSpec 完成收尾，把已经落地的变更，从 “进行中” 变成 “正式完成的规范”。 归档前必须检查到位： - 所有规范文档齐全完整 - 任务清单全部完成 - 测试覆盖关键场景，结果通过 - 代码实现与规范完全一致 - 确认无误后，执行归档操作 **归档命令** ``` openspecarchive"" ``` # 每个阶段的闸门：没过这道关，绝不往下走 这套流程之所以靠谱，就是因为有明确的 “闸门” 限制，防止仓促推进、带病前行： 1. 设计没确认，不进入 OpenSpec 规范阶段 2. 规范文档没补齐，不进入编码阶段 3. 没有真实测试验证结果，不宣称功能完成 4. 代码、测试、规范不一致，不允许归档 每一道闸门都是在帮你规避风险，而不是制造麻烦。 # 团队直接能用的沟通话术 平时和团队协作，不用背复杂的概念，直接用这些大白话沟通，所有人都能听懂： ## **完整流程** ``` 请按 OpenSpec + Superpowers 三段式流程执行这个需求：先用 Superpowers 做探索性规划，再用 OpenSpec 锁定 proposal/design/spec/tasks，最后回到 Superpowers 执行编码、测试、验证和归档。 ``` ## **只做探索阶段** ``` 先不要写 OpenSpec，也不要写代码。请先用 Superpowers 做需求探索、方案比较和设计确认。 ``` ## **进入 OpenSpec 阶段** ``` 设计已经确认。请基于当前设计创建 OpenSpec change，并补齐 proposal、design、spec 和 tasks。完成后先暂停，不要开始编码。 ``` ## **进入执行阶段** ``` OpenSpec 已确认。请回到 Superpowers 执行阶段：写实现计划，使用 worktree，按 TDD 实现，并运行真实验证命令。 ``` ## **进入归档阶段** ``` 请确认代码、测试和 OpenSpec 规范已经对齐。如果验证通过，请归档这个 OpenSpec change。 ``` # 企业落地配置 ## **推荐目录** ``` openspec/ changes/docs/ superpowers/ specs/ plans/ ``` **推荐写入** **\[** **AGENTS** **.** **md** **]** **(** **AGENTS** **.** **md** **)** ``` # AGENTS.md## OpenSpec + Superpowers 工作流对于非平凡 feature，默认使用三段式组合流程：1. Superpowers 探索性规划2. OpenSpec 锁定规范3. Superpowers 执行编码、测试、验证4. OpenSpec 归档## 强制规则- 设计未确认前，不进入 OpenSpec。- OpenSpec artifacts 未完成前，不进入编码。- 行为变更默认使用 TDD。- 完成前必须运行真实验证命令。- 代码、测试、规范未对齐前，不归档。 ``` # Review 检查清单 ``` 是否完成 Superpowers 探索？ 是否有设计草稿？ 是否创建 OpenSpec change？ 是否有 proposal.md？ 是否有 design.md？ 是否有 spec.md？ 是否有 tasks.md？ 是否写了实现计划？ 是否补充测试？ 是否运行真实验证命令？ tasks.md 是否全部完成？ 代码、测试、规范是否一致？ 是否完成 OpenSpec 归档？ ``` # 企业落地路线图：四周稳步推进 ## **第一周：试点** 选择一个中等复杂度需求，完整跑一遍三段式流程。 ## **第二周：模板化** 沉淀探索设计模板、OpenSpec artifact 模板、实现计划模板和 Review checklist。 ## **第三周：纳入团队规范** 把规则写入 \[ AGENTS . md ] ( AGENTS . md ) 、 \[ CONTRIBUTING . md ] ( CONTRIBUTING . md ) 或 PR 模板。 ## **第四周：推广** 只对非平凡 feature 强制执行，持续收集团队反馈并精简流程。 # 最后说句心里话 在职场做项目，真正厉害的不是写代码有多快，而是能不能 **稳定交付、少出错、少返工、有迹可循** 。这里提供一个superpowers\+openspec按需组合技能： https://github.com/SYZ\-Coder/superpowers\-openspec\-team\-skills Superpowers \+ OpenSpec 这套流程，没有花里胡哨的概念，也没有不切实际的要求，它只是把 “先探路、再定规、后执行、终归档” 这件最朴素的道理，变成了团队能直接用的工作方式。 用久了你会发现，需求不再模糊，沟通不再费力，加班越来越少，扯皮越来越少。 职场里最舒服的状态，莫过于：每一步都有章可循，每一份成果都有据可查，每一个人都不用为混乱的流程买单。