当 OpenSpec 遇上 SuperpowersAI 辅助编程的终极工作流大家想学习更多AI知识可以收藏下面两个网站GPTBUYS、ZeoAPI对于一线工程师来说AI 编程真正的瓶颈早就不是“模型会不会写代码”而是“需求是否被澄清”“设计是否可复用”“执行是否可审计”“多代理是否能协同”。如果这些环节仍然靠聊天窗口里的即时记忆项目一复杂输出就会失控。OpenSpec 和 Superpowers 值得放在一起讨论原因很直接前者更像规格驱动的 planning layer强调 proposal、spec、design、tasks 这些可落库的工件后者则更像执行层的方法论与技能框架强调 brainstorm → plan → execute → finish并且正在强化 subagent-driven development。把两者组合起来正好补上“从需求到实现”的完整链路。摘要摘要OpenSpec 解决“先想清楚再写”Superpowers 解决“按方法执行并审查”两者叠加可形成面向 Claude Code、Codex、Cursor、Copilot 等多工具的一套工程化 AI 工作流。这套工作流的核心思想不是让 AI 直接生成代码而是先把需求、约束、设计决策沉淀为代码库中的活文档再让执行型 agent 或 subagent 消费这些文档分角色完成实现、测试、评审和收尾。结合官方资料可以把它概括为三层规格层OpenSpec入口推荐从/opsx:propose your idea开始。工件以 proposal、spec、design、tasks 为中心。流程强调 iterative、fluid、not waterfall。更适合 brownfield 场景中的增量演进。执行层Superpowers官方主流程为 brainstorm → plan → execute → finish。新版本把 specs 与 plans 统一落到docs/superpowers/specs/和docs/superpowers/plans/。在支持 subagent 的环境中正在强化 subagent-driven development。通过 EnterPlanMode 等机制防止模型跳过设计阶段直接开写。宿主层Claude Code / Codex / Copilot coding agentClaude Code 提供 slash commands 与 subagents 作为底层机制。Codex 侧Superpowers 已采用 native skill discovery。GitHub Copilot coding agent 则可以作为异步执行与 PR 生成层把规范驱动的任务最终落到仓库协作流程中。为什么要把 OpenSpec 放在前、Superpowers 放在后摘要OpenSpec 擅长把“问题定义清楚”Superpowers 擅长把“解决过程制度化”先后顺序决定了 AI 输出质量上限。很多团队使用 AI 编程失败不是因为模型能力差而是因为把“需求分析、设计、任务拆解、编码、测试、审查”全部混成一轮对话。结果通常是需求边界不清设计决策无法复盘上下文只存在于聊天窗口代理一换历史推理链路丢失代码虽能生成但后续维护成本很高。OpenSpec 的价值在于把“需求和设计”前置并且把它们落成仓库工件。官方仓库已经重构为 artifact-guided workflow推荐从 proposal 开始再到 spec、design、tasks。这意味着它不是一个简单 prompt 集合而是一套可评审、可提交、可迭代的规范层机制。[1][3]Superpowers 的价值在于把“怎么做”进一步标准化。它的 README 给出完整工作流 brainstorm → plan → execute → finish近期版本还强化了 plan 阶段约束并在支持 subagent 的环境中推动 subagent-driven development。[2][4]所以更合理的组合方式不是二选一而是OpenSpec 负责定义问题Superpowers 负责推进解法宿主 agent 负责实际落地与自动化协作这是一个典型的工程分层而不是工具堆叠。OpenSpec把需求、设计和任务从聊天记录变成仓库工件摘要OpenSpec 的本质是“规格即上下文”让 AI 的前置理解不依赖会话记忆而依赖可持久化的文档工件。OpenSpec 官方将自身描述为 lightweight spec-driven framework并明确强调它是通用 planning layer可跨不同 coding agent 使用。[3] 这点非常关键它不是绑定某一个模型而是在代码库中建立一种稳定的上下文结构。结合仓库与官网信息OpenSpec 有几个工程上非常实用的特征1. 以 proposal 为入口官方推荐从/opsx:propose your idea开始。[1]这意味着任何稍大的改动不再是“直接让 AI 改代码”而是先提交一个变更意图目标是什么为什么要做范围是什么风险在哪里哪些内容不做。这一步非常适合需求澄清、方案预评审和影响面分析。2. 工件化而不是流水账化OpenSpec 的 proposal、spec、design、tasks 不是聊天摘要而是可以进入代码库、被版本控制管理的“活文档”。[1][3]这带来三个直接收益agent 切换时不丢上下文团队评审时有明确锚点后续回溯时能知道“为什么这样设计”。3. 不是瀑布流程官方 README 明确强调流程是 fluid、iterative、not waterfall。[1]也就是说proposal 并不意味着必须一次写死全部设计。更合理的实践是先出 proposal经过讨论补成 spec在遇到技术细节时沉淀 design最后才落到 tasks。这很适合老项目改造因为 brownfield 场景往往需要边分析边发现约束。[3]Superpowers把执行阶段从“会写代码”升级到“会按流程写代码”摘要Superpowers 更像 AI 开发团队的操作系统它不只提供 prompt而是提供执行套路、技能分工和阶段约束。Superpowers 官方把自己定义为 agentic skills framework software development methodology。[2] 这里最重要的不是“skills”而是 “methodology”。也就是说它要解决的是让 agent 在工程实践中按可控方式工作而不是凭模型临场发挥。1. 四阶段主流程官方给出的主流程是brainstormplanexecutefinish这四步对应工程团队常见的协作节奏brainstorm快速收敛问题空间plan形成实施方案与拆解execute编码、测试、修复finish收尾、验证、交付说明。2. 文档工件开始标准化落地根据 v5.0.0 发布说明specs 与 plans 已重构输出到docs/superpowers/specs/docs/superpowers/plans/这说明 Superpowers 也在强化“可沉淀工件”的方向。[4]这与 OpenSpec 并不冲突反而天然互补OpenSpec 可用于高层需求与设计Superpowers 可用于执行期的 plan 和具体行动记录。3. 强化“先 plan 再 execute”发布说明特别提到加入 EnterPlanMode 拦截避免模型直接跳过设计阶段进入原生 plan mode。[4]这说明官方已经意识到一个常见问题模型太容易“看起来很懂”然后直接开始写。工程上最怕的就是这种“未设计先编码”。4. subagent-driven development 成为重要方向在支持 subagent 的环境里Superpowers 把 subagent-driven development 变成强制路径之一。[4]这和 Anthropic 官方对 subagents 的定义高度一致subagent 可以有独立上下文、工具权限、定制提示适合做任务专项委派。[5]换句话说Superpowers 的价值正在从“单代理技能包”升级为“多代理协作框架”。从单代理走向多代理为什么 subagents 是这套工作流的关键拼图摘要多代理不是噱头它解决的是上下文拥塞、角色混杂和审查缺位三个现实问题。Anthropic 官方文档对 subagents 的说明很明确它们可以按任务定制有独立上下文窗口、专门工具权限和定制系统提示。[5] 同时Claude Opus 4.6 的官方新闻也提到Claude Code 中已经可以组装 agent teams 一起处理任务。[9]这对 OpenSpec Superpowers 的组合非常关键因为你终于可以把不同工件分发给不同角色需求代理消费 proposal补齐缺失边界设计代理基于 spec/design 讨论架构取舍实现代理只关注 tasks 和代码修改测试代理负责补测试、跑 lint、分析失败审查代理对照 spec 校验是否偏离安全代理检查依赖、密钥、输入校验和危险调用。这种拆分有三个明显收益1. 上下文隔离实现代理不必背负全部需求讨论历史只需消费稳定工件。这能显著降低上下文窗口被噪声占满的风险。2. 角色边界清晰过去一个 agent 同时扮演 PM、架构师、开发、测试、Reviewer结果常常自我确认偏误。多代理后可以把“写代码”和“挑毛病”分离开。3. 审查可制度化你可以要求评审代理只根据 spec 和 diff 做审查而不是根据主代理的“自述”来判断。这样更接近真实团队协作。Key Comparison Table摘要选型关键不在“哪个更强”而在“哪个放在哪一层最合适”。DimensionOpenSpecSuperpowersClaude Code / Codex 宿主能力GitHub Copilot coding agent核心定位规格驱动的 planning layeragentic 技能框架与开发方法论提供 slash commands、subagents、原生技能发现等运行机制异步执行编码任务并发起 PR最适合阶段proposal、spec、design、tasksbrainstorm、plan、execute、finish命令触发、上下文注入、代理协作仓库内自动编码、测试、提交、开 PR上下文载体仓库内活文档与工件specs / plans 等执行期文档会话 命令 子代理配置issue、PR 评论、聊天消息及相关仓库上下文主要优势先对齐需求避免直接开写约束执行节奏减少跳过设计将流程能力稳定注入工具入口与 GitHub 工作流天然打通典型风险写了文档但未进入执行闭环如果缺少前置规格计划可能方向偏依赖宿主工具能力与配置质量自治能力强但仍需人工 review 与治理更推荐的角色前半段需求/设计层后半段执行/审查层流程承载层异步落地与 PR 交付层适合项目类型brownfield 增量演进尤其合适需要稳定执行方法的团队协作多工具、多代理环境GitHub 为中心的团队仓库协作在 Claude Code、Codex、Copilot 中如何落地这套组合摘要真正可用的工作流必须依赖宿主工具提供的命令入口、技能发现和异步执行机制。1. Claude Code最适合做“主控台”Anthropic 官方文档说明Claude Code 支持 project-level 和 user-level 的自定义 slash commands命令可直接由 Markdown 文件定义。[6]这意味着 OpenSpec 和 Superpowers 这类命令驱动系统不再依赖“模型记得流程”而是依赖明确命令入口。同时Claude Code 对 subagents 的支持使它非常适合承担提案生成规格补全多角色拆分执行审查代理调用。2. Codex更轻的原生技能接入Superpowers 的 Codex 安装说明显示其已改用 native skill discovery通过~/.agents/skills/superpowers软链接接入而不是旧的 bootstrap 方案。[7]这说明生态方向已经很明确尽量贴近宿主原生能力减少额外包装层。工程意义是安装链路更短技能发现更稳定与 OpenSpec 的组合更轻量。3. Copilot coding agent最适合做异步执行层GitHub 官方文档指出Copilot coding agent 可根据 issue 或聊天提示独立完成编码任务、执行测试并发起 PR。[8][10]这非常适合放在工作流后半段人类或主代理先用 OpenSpec 生成 proposal/spec/design/tasks再用 Superpowers 做 plan 与执行约束最后把任务投递给 Copilot coding agent由其在 GitHub 环境中完成实现并提交 PR再由人工或审查代理按 spec 审核。这是一种非常实用的“同步规划 异步编码”模式。实战代码示例摘要下面给出一个可操作的最小落地示例覆盖 OpenSpec 提案、Claude Code 命令和 GitHub 异步执行衔接。示例 1在 Claude Code 中定义 OpenSpec 风格命令入口!-- 文件示例.claude/commands/propose-feature.md -- !-- 作用把“先提案再开发”固化为团队命令入口 -- 请基于用户输入生成一个变更 proposal要求 1. 明确目标、非目标、影响范围 2. 标识风险与待确认问题 3. 输出到仓库约定目录例如 docs/openspec/proposals/ 用户需求$ARGUMENTS# 作用在 Claude Code 中通过 slash command 触发提案# 关键点让需求分析走稳定入口而非临时聊天/propose-feature为支付服务增加幂等键校验与重试保护这个做法利用了 Claude Code 的自定义 slash commands 能力。[6]它的好处是团队成员都从同一个命令入口生成 proposal格式和约束更统一。示例 2把 OpenSpec 输出衔接到 Superpowers 执行阶段# 作用先产出规格再进入执行计划# 关键点避免一上来直接让 agent 修改代码# Step 1: 用 OpenSpec 风格命令生成 proposal/opsx:propose在订单服务中新增取消原因审计字段# Step 2: 基于 proposal 补充 spec/design/tasks# 注这里可以由主代理或子代理逐步完成/opsx:spec补充接口变更、数据库迁移、回滚策略/opsx:design评估是否采用事件补偿而非同步更新/opsx:tasks拆分后端、测试、文档任务# Step 3: 进入 Superpowers 的 plan/execute 阶段# 注让执行代理只消费已沉淀工件减少上下文漂移/superpowers:plan根据 docs 中的规格生成实施计划/superpowers:execute按计划修改代码、补测试、运行 lint上面这套命令链背后的思路是OpenSpec 管前置澄清与设计Superpowers 管执行与收尾命令就是流程边界。示例 3把任务交给 GitHub 异步执行# 作用示意如何把规格链接放入 issue供 GitHub agent 消费# 文件类型issue 模板片段或任务描述模板title:实现订单取消原因审计字段body:-需求规格:docs/openspec/specs/order-cancel-audit.md-设计说明:docs/openspec/designs/order-cancel-audit.md-执行计划:docs/superpowers/plans/order-cancel-audit-plan.md-验收标准:-API 返回字段兼容旧客户端-数据库迁移可回滚-单元测试与集成测试通过这样做的意义在于Copilot coding agent 的上下文不只是 issue 文本还能结合相关仓库上下文工作。[8][10]如果 issue 里直接引用 OpenSpec 和 Superpowers 工件agent 的输入质量会比“帮我改一下这个模块”高得多。代码块注释规范摘要AI 时代的代码块示例不仅要能跑还要让人和代理都能快速理解意图。建议在技术博客和团队文档里遵守以下规则每个代码块先写“作用”注释例如# 作用生成 proposal 并固化需求边界这样读者和 agent 能先理解目的再看细节。关键步骤必须有“为什么”注释不只写“做什么”还要写“为什么这样做”。例如# 关键点避免直接跳过设计阶段进入编码注释控制在 1-2 行避免淹没主逻辑代码块注释应帮助理解不应把代码变成大段说明文。路径、命令、输出目录要标明约定例如说明docs/openspec/、docs/superpowers/plans/的用途。这对团队协作和 agent 一致性非常重要。示例代码尽量体现可复制的最小闭环一个代码块最好只解决一个问题生成提案、触发计划、提交 issue、跑测试。避免把多个动作混在一起。常见问题与排错摘要多数落地失败并非模型不够强而是工件、命令和角色边界没有建立好。1. OpenSpec 文档写了很多但 agent 还是直接开写检查是否给了稳定命令入口。没有 slash command 或明确流程约束时模型容易跳过 proposal/spec 阶段。[6]2. Superpowers 已安装但执行时像普通聊天一样失控确认当前宿主是否真的启用了对应技能发现与工作流机制。尤其在 Codex 中需要按官方文档切到 native skill discovery 方式。[7]3. 多代理协作后结果反而更混乱通常是角色定义不清。不要让实现代理同时负责需求澄清和代码审查应按工件拆角色。[5][9]4. Copilot coding agent 提交了 PR但和预期偏差很大检查 issue 或任务描述是否明确引用了 spec/design/plan。GitHub agent 依赖 issue、PR 评论和相关上下文构成提示输入模糊会直接影响输出。[8][10]5. 老项目里觉得 OpenSpec 太“重”OpenSpec 官方强调流程是 iterative、not waterfall也强调 brownfield-first。[1][3]实践上可以只从 proposal tasks 开始不必一开始就把全部工件补齐。结论一套更稳的 AI 编程闭环应该从“规范化上下文”开始摘要别再把 AI 当成只会补全代码的工具而要把它纳入可审计、可协作、可复用的工程流程。如果只用一个强模型直接写代码你得到的是“短期快感”如果把 OpenSpec、Superpowers 和宿主 agent 机制组合起来你得到的是“团队可持续的生产力系统”。一个非常实用的落地顺序是先在仓库中引入 OpenSpec从 proposal 开始不要求一步到位。再接入 Superpowers把 execute 前的 plan 阶段强制化。在 Claude Code 或 Codex 中固化命令入口用 slash commands 或 native skills 替代口头约定。最后接入 GitHub 异步 agent让 issue → 实现 → PR 成为自动化后半段。下一步建议很明确挑一个真实的中小型需求不要从“让 AI 写页面”开始而是从“让 AI 先写 proposal 和 spec”开始。你会明显感觉到后面的代码质量、评审效率和返工率都不一样。参考资料Fission-AI/OpenSpec: Spec-driven development (SDD) for AI coding assistantshttps://github.com/Fission-AI/OpenSpecOpenSpec — A lightweight spec-driven frameworkhttps://openspec.dev/obra/superpowers: An agentic skills framework software development methodology that workshttps://github.com/obra/superpowerssuperpowers/RELEASE-NOTES.mdhttps://github.com/obra/superpowers/blob/main/RELEASE-NOTES.mdSubagents - Anthropichttps://docs.anthropic.com/en/docs/claude-code/sub-agentsSlash commands - Anthropichttps://docs.anthropic.com/en/docs/claude-code/slash-commandsInstalling Superpowers for Codexhttps://github.com/obra/superpowers/blob/main/.codex/INSTALL.mdAbout GitHub Copilot coding agenthttps://docs.github.com/en/copilot/concepts/about-copilot-coding-agentResponsible use of GitHub Copilot coding agent on GitHub.comhttps://docs.github.com/en/copilot/responsible-use/copilot-coding-agentClaude Opus 4.6https://www.anthropic.com/news/claude-opus-4-6