文章目录Pre一、内联执行计划的定位慢一点但要“稳”1.1 与 Subagent 驱动开发一张表看清差异二、三步走审查 → 执行 → 完成2.1 阶段一加载并审查计划——先别急着写代码2.2 阶段二按序执行任务——计划即契约2.3 阶段三完成开发——从“能跑”到“准备好被审查”三、遇阻时停下请求澄清而不是硬猜四、在整条开发流水线中的位置三大必选集成点4.1 从计划到执行如何“交接”五、真实案例执行一份 1096 行的大型计划六、从命令到技能执行方式的演进七、实践建议如何在你的团队中落地内联执行计划总结PreSuperpowers - 01 让 AI 真正“懂工程”Superpowers 软件开发工作流深度解析Superpowers - 02 用 15 个技能给你的 AI 装上「工程大脑」Superpowers 快速开始深度解析Superpowers - 03 一文搞懂 Superpowers面向多平台 AI 编码助手的安装与实践指南Superpowers - 04 从“会写代码”到“会做工程”Superpowers 工作流引擎架构深度剖析Superpowers - 05 构建一个“会自己找插件用”的 Agent深入解析 Superpowers 的技能发现与激活机制Superpowers - 06 从文档到“结构契约”Superpowers 技能剖析与 Frontmatter 深度解读Superpowers - 07 从 SessionStart Hook 看 Superpowers把「技能库」变成「行为操作系统」Superpowers - 08 在 AI 时代重写「需求评审会」深入解读 Superpowers 的头脑风暴与设计规范机制Superpowers - 09 从构思到落地如何用「计划编写与任务粒度」驾驭 AI 时代的软件开发Superpowers - 10 用 Subagent 驱动开发把「AI 写代码」变成一条严谨的生产流水线面向读者有一定实践经验的开发者、架构师、技术负责人以及正在尝试用 AI 辅助完整软件开发流程的研究者。软件工程里“写计划”比“执行计划”容易得多。当你开始让 AI 帮你写设计文档、拆分任务、生成代码时这个落差会被无限放大一份看起来很漂亮的计划真正执行起来却问题百出——步骤含糊、依赖缺失、测试不通过、上下文混乱。Superpowers 提出的executing-plans技能就是为了解决这个落差它不是一个“写计划”的工具而是一个把计划稳稳落地的执行引擎在单一会话里按任务顺序、严格验证、透明可审查地把一份书面计划变成可运行、可合并的代码。本文将围绕这篇文档展开系统解析为什么需要“内联执行计划”而不是一味追求自动化的 Subagent 驱动开发executing-plans的三阶段执行模型审查 → 执行 → 完成阻碍处理与“请求澄清而非靠猜测”的工程哲学它在 Superpowers 整体开发流水线中的位置与集成点一个真实计划的执行示例以及从命令式到“技能化”的演进趋势一、内联执行计划的定位慢一点但要“稳”Superpowers 在计划完成后提供两条执行路径Subagent 驱动开发每个任务交给新的 subagent自动审查、快速迭代是“默认推荐”的生产路径内联执行计划 (executing-plans)在单个会话中顺序执行任务强调人工可见、可控、可审查是刻意保留的一条“慢而稳”的路径。文档对executing-plans的定位非常明确当平台没有 subagent 能力、当你刻意希望人工紧密监督每个任务、当执行计划的会话与编写计划的会话不同需要完整再理解与复核时内联执行就是正确选择。同时文档也直言不讳当 subagent 可用时推荐使用 Subagent-Driven Development且“代码质量将显著更高”。这意味着内联执行不是性能退而求其次的“阉割版”而是为特定场景设计的“守正”方案——在一些需要高可控性、强监督的环境里它反而是更安全的选项。1.1 与 Subagent 驱动开发一张表看清差异一张对比表从上下文模型、审查机制、平台要求等维度解释两者的权衡维度内联执行 (executing-plans)Subagent 驱动 (subagent-driven-development)上下文模型单一连续会话每个任务启用全新 subagent审查机制依赖人工在检查点审查自动化两阶段审查规范 质量平台要求任意兼容 Claude 的平台即可需要 subagent 支持Claude Code、Codex 等迭代速度较慢任务间需要人工批准较快由自动化审查循环驱动错误隔离上下文在任务间持续累积错误可能随上下文扩散按任务隔离每个任务独立上下文适用场景学习场景、教学演示、受控实验、平台能力受限的环境正式生产开发、复杂或大型计划实施从工程实践角度看你可以简单理解为Subagent 驱动开发更像是“流水线式 CI/CD 多工位合作”的自动化工厂内联执行计划更像是“资深工程师亲自按 checklist 一步步带徒弟做”的工作模式。内联执行的价值在于它让你可以看见每一步并在关键节点停下来问“这一步真的对吗”——对学习、调试、规范建设极其有利。二、三步走审查 → 执行 → 完成executing-plans将一个“从计划到代码”的过程拆成了三大阶段加载并审查计划 → 按序执行任务 → 完成开发。每个阶段都有明确的进入条件和退出条件目的就是防止常见的失败模式带病执行、跳过验证、遇阻硬顶等。2.1 阶段一加载并审查计划——先别急着写代码在接触任何代码之前Agent 必须做的第一件事是从docs/superpowers/plans/中读取完整的计划文档并进行严格审查。这个审查并不是“走个过场”而是第一道防线是否有歧义描述是否有步骤缺失任务结构是否完整、统一验证步骤是否明确、可操作如果审查通过Agent 会创建一个TodoWrite对象记录所有任务并以此为执行清单。然后才真正进入执行阶段。如果审查不通过Agent 必须暂停执行把疑问抛给人工伙伴直到问题被修正或澄清。这一步与writing-plans技能中的自审规范呼应“计划写完后先自查一遍再交给执行者。”而在executing-plans这边执行者变成了第二道审查者再次审视计划是否可执行。这背后有个很重要的观念“计划是可执行文档而不是展示用幻灯片。”它必须写到“可以让一个没有上下文的新 Agent 按图索骥完成实现”否则就不是好计划。2.2 阶段二按序执行任务——计划即契约进入执行阶段后每个任务都必须遵循一个四步协议标记任务为 in_progress明确告诉人工伙伴“我正在做这个任务”。这既是状态同步也是为后续审计提供线索。严格按照步骤执行计划中的每个步骤被刻意拆成 2–5 分钟可完成的小块是有明确设计意图的方便人工理解与审查方便在出错时快速回溯到具体步骤强制避免“我大致懂了直接跳着干”的习惯按规范执行验证命令每个任务都携带明确的验证命令与预期输出例如运行pytest tests/path/test.py::test_name -v预期PASSAgent 必须真正执行这些命令对比实际输出与预期如果不匹配任务视为未完成不得进入下一步验证通过后才标记任务完成没有验证就没有“完成”两个字。文档用一句很强硬的话概括这一点计划即契约。也就是说执行者不能随意决定“这个验证没必要跑”。不能凭主观感觉判定“看起来没问题就算完成”。更不能跳过计划里的某一步即便你是人类工程师。“聪明的偷懒”在这个模型里会被视作违反契约。另外writing-plans在设计任务结构时就要求步骤具有“零上下文可执行性”每步要写清要改哪些文件、写什么逻辑、运行哪些命令、预期输出如何。不假定执行者拥有隐形上下文或额外知识。这让executing-plans可以在全新的会话里仅凭计划文档就完成实现极大增强了可移交性。2.3 阶段三完成开发——从“能跑”到“准备好被审查”所有任务都执行并通过验证后executing-plans并不会就此结束。它会将控制权移交给superpowers:finishing-a-development-branch这个必需子技能。finishing-a-development-branch的职责包括再次运行测试确保分支处于“健康可运行”状态选择合适的基础分支给出合并选项本地合并创建 Pull Request保留分支不合并丢弃分支清理 git worktree防止残留半成品工作区这一步其实是在完成一个重要的“仪式转变”从“测试通过的工作分支代码”变成“可以进入团队流程、接受 review、准备上线的代码”如果你把整个流程想象成一个 CI/CD pipeline那么executing-plans负责的是“从计划到可跑代码”的这段而finishing-a-development-branch则负责“从可跑代码到团队流程接入”的最后一跳。三、遇阻时停下请求澄清而不是硬猜executing-plans中最有工程味的一节是它对“阻碍处理”的严格规范。文档列举了几种典型阻碍场景并给出了明确的强制动作触发条件必须执行的操作缺少依赖项立即停止通知人工等待指示执行期间测试失败停止展示失败输出停止推进计划中的指令不明确停止向人工请求澄清验证反复失败停止提交证据并升级处理并用一句话总结了设计原则“请求澄清而非靠猜测。”这里有几个关键点值得展开一切非预期情况都不允许“先往前凑合走走看”如果依赖缺失继续写代码也是白费力气如果测试失败忽略它只会导致后続任务以错误状态为前提。阻碍是反馈不是噪音文档强调一份看起来完美的计划很多问题只有在执行时才会暴露。执行者对这些阻碍的反馈是改进未来计划质量的重要输入。因此阻碍不是“烦人的异常”而是整个工作流的一部分。阻碍解决后要回到阶段一审查而不是从中途硬接上这是一个非常细腻的点当计划被修改或澄清后整体上下文已经发生变化继续从某个中间任务切入很容易忽略前后关联约束回到阶段一重新审查是保证一致性的保守做法。工程实践中这种设计体现的是一种非常成熟的态度“不要强行突破阻碍。”不硬撑不赌不拍脑袋。对于在生产环境引入 AI 辅助开发的团队来说这一原则可以极大降低“静悄悄的灾难”发生概率——那些看似无害的小猜测往往在几轮迭代后演变成根本性设计错误。四、在整条开发流水线中的位置三大必选集成点executing-plans并不是一个孤立技能而是嵌在 Superpowers 的完整工作流里。它有三个强制集成点共同构成一个闭环开发周期集成点作用为什么是必需的superpowers:using-git-worktrees在任何代码更改前设置隔离工作空间防止污染主分支提供干净回滚点superpowers:writing-plans创建结构化、可执行的计划文档计划格式即契约前置元数据头、任务结构、验证步骤superpowers:finishing-a-development-branch处理实施后的分支生命周期确保测试通过明确合并策略清理 worktree这三个点基本覆盖了工程实践中的黄金路径开始前先把工作区隔离好使用 git worktree 为每个任务分支创建独立工作目录避免在主分支上“直接开干”的坏习惯方便随时回滚、不影响其他并行开发。真正执行前先把计划写好不再“边想边写边改”而是在进入执行前形成一个足够细致的任务分解计划中显式标注“执行方式头部元数据”REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task.这让任何后续会话都能自动根据计划指示选择正确执行技能。执行结束后要把阶段性成果纳入团队流程不遗留半成品分支不在 repo 里留下“不知道能不能用”的代码所有“执行完成”的定义都包含了测试通过 分支策略明确 工作区干净。4.1 从计划到执行如何“交接”结合writing-plans流程交接的具体方式在“计划编写与任务粒度”流程的末尾writing-plans会明确给出两个执行选项Subagent 驱动推荐若平台支持内联执行当需要或平台受限时。当选择内联执行时一个新的“执行会话”会启动它从计划文档头部的元数据读到执行建议然后调用executing-plans并进入“三阶段”流程。这意味着计划本身携带了“如何执行我”的 meta 信息。它不再是“静态文档”而是“自描述的工作流入口”。对于团队协作来说这种设计的好处在于执行者可以是另一个人、另一台机器、另一个时间点但只要拿到这份计划就知道应该怎么安全地执行它执行路径可以根据平台能力和团队偏好灵活调整而无需从头到尾重写计划本身。五、真实案例执行一份 1096 行的大型计划一份类似 OpenCode 支持实施的计划文档长达 1096 行包含分阶段任务、确切文件路径和完整代码块。executing-plans的处理方式大致如下加载计划读取docs/superpowers/plans/2025-11-22-opencode-support-implementation.md把所有阶段、所有任务结构化为待办列表。审查计划结构确认包含目标、架构说明、技术栈、任务文件路径、带复选框的步骤等如果结构不符合规范直接在阶段一暂停。从任务 1 开始执行按规范创建lib/skills-core.js并实现extractFrontmatter函数运行对应测试验证结果是否满足“预期PASS”的条件。继续执行所有任务每个任务都单独执行、验证每个任务通常对应一次提交便于后续审查与回滚。完成阶段移交给 finishing-a-development-branch由完成技能负责最终合并决策与 worktree 清理。这段示例和 Subagent 驱动开发的最大区别在于内联执行的整个过程发生在同一个连续会话人类可以实时观察进度并在任意检查点插手不需要调度额外的 implementer subagent 或 spec 审查者流程更线性、更直观。对于刚开始尝试将 Superpowers 引入团队开发流程的团队来说这样的线性模型更易于理解和落地也更适合作为“建立规范”的起点。六、从命令到技能执行方式的演进一个看似细节、实际很有意义的改变旧的commands/execute-plan.md斜杠命令已经废弃新的推荐方式是直接调用superpowers:executing-plans这个技能旧命令如果被触发会引导用户转向使用新技能。这背后的趋势是从“命令式调用”逐渐过渡到“可发现、可组合的技能系统”。命令更接近于“脚本入口”而技能则带有 Frontmatter、清晰的描述与使用约束支持被其他技能引用形成工作流图谱更利于被 IDE、平台或上层 orchestrator 自动发现和调度。从工程视角看这是 Superpowers 从“高级工具集”演进为“可编排平台”的关键一步——executing-plans作为其中的核心执行技能也显然被设计成一个可复用、可组合的积木。七、实践建议如何在你的团队中落地内联执行计划结合文档中的设计思想如果你希望在自己的工程实践中引入类似的“内联执行计划”模型可以考虑下面几个步骤建立“计划即契约”的共识任何可交付的计划必须写清任务拆分修改点路径验证命令预期输出不写清就不能进入执行环节。把“审查计划”变成正式步骤而不是口头约定明确谁负责初次审查计划作者自查谁负责二次审查执行者或代码 owner审查不过就不允许执行。执行时强制“先验证后完成”在代码评审模板或 CI 流程中加入规则没有验证记录的任务不能标记为 Done每个任务的测试命令与结果要可追踪。遇阻就停为“请求澄清”预留通道在项目协作工具里Issue/PR/Task给执行者明确权限任何阻碍都可以暂停当前任务并新建“澄清任务”完成澄清后重新从“审查计划阶段”开始而不是强行续命。分离“实现阶段”和“完成阶段”实现阶段的完成定义是本地测试通过 计划中的所有任务已执行完成阶段则包括再跑一遍流水线测试决定合并策略清理临时分支与工作目录这可以减少“工作分支堆满仓库”的常见问题。如果你使用 Superpowers 本身那么遵循文档中的集成方式即可先using-git-worktrees再writing-plans然后在合适场景下选择executing-plans最后交给finishing-a-development-branch收尾。总结executing-plans看上去只是一个“在单会话里顺序执行计划”的技能实则承载着一套完整的工程观计划是契约必须包含足够的执行细节与验证步骤执行要可审查单一会话、显式状态、明确检查点阻碍是重要信号遇到就停先问清楚再继续完成不等于合并还需要一个专门的“完成阶段”把代码纳入团队工作流从命令到技能整个系统正以“技能”为基本单位被组织和扩展。如果你关心的是“如何和 AI 一起做严肃的软件工程”而不仅仅是“让 AI 写点代码片段”那么这篇文档背后的思想值得仔细阅读、在团队内讨论并逐步融入你自己的开发规范中。