计划执行Skill：把一份书面计划变成带审查检查点的分批交付
- 它是什么：计划执行Skill（plan-execute，技能ID：11788）是一个专门用来“执行书面实施计划”的 AI 技能，核心原则是带有架构师审查检查点的分批执行，而不是一次性把计划全部做完。
- 它解决什么问题：AI 拿到一份长计划后容易一口气做到底、跳过验证、偏离步骤；这个技能强制它先批判性审查计划，再默认按每批 3 个任务推进，每批结束必须停下来报告并等待反馈。
- 关键机制：加载计划 → 批判性审查 → 分批执行（每个任务标记进行中/已完成并运行验证）→ 批次间报告“准备好接受反馈”→ 循环至完成 → 调用收尾子技能。
- 强制性的安全边界：遇到阻碍、测试失败、指令不清、验证反复失败时必须停止并求助，不允许猜测着往下做；未经用户明确同意，不得在主分支上开始实施。
- 适合谁：手里已经有成型书面计划（如重构方案、功能实施方案、迁移计划）的开发者和技术负责人，希望在可控节奏下让 AI 分步落地。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
这个技能的中文名是计划执行Skill，英文名是 plan-execute，技能 ID 为 11788。它的官方描述是：当您有一个书面实施计划需要在带有审查检查点的单独会话中执行时使用。
它解决的是“计划很好，落地很乱”的问题。日常开发中，我们经常让 AI 帮忙写出一份漂亮的实施计划，但真正执行时问题就来了：AI 可能一口气改十几个文件，中途跳过了测试验证，遇到不清晰的地方也不问，自己猜着往下写，最后出了问题很难定位是哪一步走偏的。计划执行Skill 把“执行”这件事拆成有节奏的批次：先审查、再小步执行、每批必报告、有阻碍就停，让整个过程可观察、可干预、可回退。
关于安装，该技能的详情内容只给出了技能定义本身，并未提供具体的安装命令或下载地址，因此这里给出通用的“一键安装”思路，具体命令与入口请以官方说明为准：
- 安装前提：确认你使用的 AI 编程客户端或技能市场支持加载外部技能（Skill）机制，并已登录账号、具备安装权限。
- 找到技能：在技能市场/技能库中搜索技能英文名 plan-execute 或技能 ID 11788，确认作者与描述匹配（描述应为“当您有一个书面实施计划需要在带有审查检查点的单独会话中执行时使用”）。
- 一键安装：点击安装/添加按钮，按官方说明完成确认；部分客户端需要重启会话或新建会话后生效。
- 验证是否生效：在新会话中提供一份简短的书面计划并明确要求使用该技能。若技能已生效，AI 应当首先宣布“我正在使用plan-execute技能来实施这个计划。”，随后进入“加载和审查计划”环节，而不是直接开始改代码。
- 补充依赖：该技能在收尾阶段依赖子技能 superpowers:finishing-a-development-branch，建议一并确认该子技能可用，否则最后一步“完成开发”会中断。
该技能的主要功能和特点
- 强制批判性审查计划：执行前先读取计划文件并批判性审查，主动识别计划中的问题或疑虑；若发现问题，必须在动手前先向你提出，而不是带着隐患开工。
- 默认小批次执行（前 3 个任务）：把长计划切成小批次，默认一次只推进前 3 个任务，避免一次性大改带来的失控风险。
- 逐任务状态管理：每个任务先标记为进行中，再精确遵循计划中的细小步骤执行，执行后运行计划指定的验证，最后标记为已完成。TodoWrite 用于承载这套状态跟踪。
- 批次间强制报告与等待：一批完成后不是继续埋头干，而是显示已实施的内容与验证输出，并明确说“准备好接受反馈。”，把节奏控制权交回给人。
- 明确的停止规则：遇到批次内阻碍（缺少依赖、测试失败、指令不清）、计划本身有严重缺陷、看不懂某条指令、验证反复失败时，立即停止并寻求澄清，禁止猜测。
- 可回退到审查环节：当人类伙伴根据反馈更新了计划，或基本方法需要重新思考时，回到步骤 1 重新审查。
- 收尾有规范出口：所有任务完成并验证后，宣布切换到 finishing-a-development-branch 技能，按该技能验证测试、呈现选项、执行选择。
- 与普通“直接执行”方式的差异：普通方式是“你给计划，AI 一次性做完给你看结果”；这个技能是“你给计划，AI 先挑毛病，再小步做，每批停下来等你确认”。前者快但不可控，后者慢一点但每一步都可追溯。
如何使用该技能？
以下是基于技能定义整理的分步骤使用指南。
第 1 步：准备一份书面计划文件 把你希望 AI 执行的内容写成结构化的书面计划，越细越好（技能明确要求“计划有细小的步骤”）。例如：
计划名称：为博客系统增加评论功能 任务 1：新增评论数据模型与迁移脚本，验证方式：执行迁移并检查表结构 任务 2：实现发表评论接口，验证方式：运行接口单元测试 任务 3：实现评论列表接口（分页），验证方式：运行接口单元测试 任务 4：前端评论组件接入，验证方式：本地页面手动验证 任务 5：补充错误处理与权限校验，验证方式：运行全量测试
第 2 步：在单独会话中触发技能 新建会话，把计划交给 AI，并说明要按计划分批执行。技能生效后，AI 会先宣布“我正在使用plan-execute技能来实施这个计划。”
第 3 步：接收审查意见 AI 会读取计划并做批判性审查。若提出疑虑（例如“任务 4 缺少验证手段”“任务 2 依赖的配置项在计划中未定义”），你应先答复或修订计划，再让它继续。
第 4 步：确认第一批执行 无异议时，AI 创建 TodoWrite 并开始执行默认前 3 个任务。每个任务都会走“标记进行中 → 按步骤实施 → 运行验证 → 标记已完成”的流程。
第 5 步：查看批次报告并给反馈 第一批结束后，你会看到：已实施的内容清单 + 验证输出（如测试命令的结果），以及一句“准备好接受反馈。”此时你可以要求调整、补充或直接让它继续下一批。
第 6 步：循环推进直至完成 AI 根据反馈应用更改并执行下一批次，重复直到所有任务完成并验证。
第 7 步：走完收尾流程 全部完成后，AI 会宣布“我正在使用finishing-a-development-branch技能来完成这项工作。”并调用 superpowers:finishing-a-development-branch，按该技能验证测试、呈现选项、等待你选择。
两种常见输出形态对照：
| 阶段 | 你看到的输出 | 你需要做什么 |
|---|---|---|
| 审查阶段 | 计划问题清单或“无重大疑虑” | 修订计划或确认放行 |
| 批次报告 | 已实施内容 + 验证输出 + “准备好接受反馈。” | 给出反馈或说“继续” |
| 收尾阶段 | 收尾子技能给出的选项列表 | 选择收尾方式 |
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 计划执行Skill（plan-execute） | 带审查检查点的计划分批执行器 | 批判性审查、默认 3 任务一批、逐任务验证、批次间报告、阻碍即停、收尾调用子技能 | 需支持技能机制的客户端，安装后新会话生效，无需额外配置（以官方说明为准） | 已有书面计划、需要可控节奏落地 | 优势：节奏可干预、每步可追溯、强制验证；不足：批次间等待会拉长总时长，需要人持续参与反馈 |
| 直接一次性执行（普通对话指令） | 通用 AI 对话直接改代码 | 给出指令后一次性完成全部改动 | 零门槛，无需安装 | 小改动、单文件修改、探索性尝试 | 优势：快、无额外负担；不足：长计划容易跳步、跳过验证、出问题难定位 |
| 人工按计划逐步执行 | 人工开发流程 | 人自己读计划、逐步实现与自测 | 零工具门槛 | 高风险核心模块、合规要求高的变更 | 优势：完全可控、责任清晰；不足：效率低、重复劳动多、进度受人力限制 |
| 自主式编码代理（单轮长任务代理） | 端到端自动完成任务的通用代理 | 自主规划与执行，长时间连续作业 | 通常需要配置运行环境与权限（以官方说明为准） | 边界清晰、验证自动化的批处理任务 | 优势：人力介入少、吞吐高；不足：中途缺少人工检查点，偏离计划时纠正成本高，验证易被弱化 |
对比可以看出，计划执行Skill 的独特价值不在“更聪明”，而在节奏控制：它把“检查点”写进了流程本身，这是纯对话指令和全自主代理都容易缺失的一环。
该技能的典型应用场景与实际体验情况
场景一：技术负责人交付重构计划 架构师写好了模块拆分重构计划，但自己没时间逐步盯。把计划交给计划执行Skill 后，AI 每批只动 3 个任务，批次结束给出验证输出，架构师只需在检查点花几分钟确认方向，避免 AI 一口气重构到底导致大面积返工。
场景二：独立开发者的功能实施方案 独立开发者习惯先写实施计划再动手，但执行时容易“顺手多改一点”。该技能的默认小批次与“不要跳过验证”提醒，恰好能压制这种冲动，同时通过 TodoWrite 保持任务可见。
场景三：需要强验证的迁移任务 数据模型迁移、依赖升级这类任务，验证比编码更重要。技能要求每个任务跑完指定验证才标记完成，验证反复失败时还会主动停下求助，避免在错误基础上继续叠加改动。
场景四：多人协作中的计划交接 把计划文件交给 AI 执行、人在检查点审查，相当于把“编码实施”和“方案把关”分离。审查意见可以直接回流到计划文档，形成“计划—执行—反馈—修订”的闭环。
实际体验情况：
- 上手难度：低。不需要学习新语法，只要有一份像样的书面计划即可；难点反而在“把计划写细”，因为技能要求精确遵循细小步骤。
- 效果表现：最直观的改善是异常更早暴露。阻碍、依赖缺失、指令歧义都会在批次边界被抛出，而不是留到最后才爆。
- 注意事项：一是要有耐心，批次间必须等待你反馈，不反馈就不会自动推进；二是不要把没有验证手段的任务塞进计划，否则会卡在“验证”环节；三是若主分支保护严格，需在开始前就明确工作分支，技能明确规定未经用户明确同意不得在主分支上开始实施。
该技能能为用户带来的价值
- 把不可控的“长跑”变成可控的“接力”：默认 3 任务一批 + 批次间报告，让人在关键节点介入，问题修正成本从“事后返工”降到“当场纠偏”。
- 降低 AI 跑偏的概率：批判性审查前置，计划缺陷在动手前暴露；指令不清就停、验证失败就停的规则，从机制上压制了“猜测式编码”。
- 验证不再被跳过：每个任务都必须运行计划指定的验证并标记完成，验证输出直接呈现在报告里，质量证据可追溯。
- 减少沟通与复盘成本：TodoWrite 维护任务状态、批次报告固定格式，团队可以按批次回溯“这一步做了什么、验证结果是什么”。
- 长期价值：它把一种工程习惯（先审查、小步走、每步验证、有阻碍就问）固化成可复用的技能流程，团队新人和 AI 协作时也能沿用同一套节奏，减少对个人经验的依赖。
常见问题 FAQ
Q1：这个技能怎么安装？装完怎么确认生效？ 在技能市场或技能库中搜索英文名 plan-execute 或技能 ID 11788，按官方说明完成安装。验证方法是新建会话、给出一份简短书面计划并要求按计划执行，若 AI 先宣布“我正在使用plan-execute技能来实施这个计划。”并进入计划审查环节，说明已生效。具体安装命令与入口以官方说明为准。
Q2：这个技能收费吗？ 技能详情中未包含任何定价信息，是否收费取决于你所用平台或技能市场的规则，请以官方说明为准。
Q3：为什么它一批只做 3 个任务？能不能一次做完？ “默认前 3 个任务”是该技能定义的默认批次粒度，目的是让每批结束后都有一次审查检查点。如果你希望调整节奏，可以在反馈环节提出，但需注意批次越大，纠偏成本越高。
Q4：它会不会自己乱改代码、跳过测试？ 技能本身明确要求“精确遵循计划步骤”“不要跳过验证”，并且遇到缺少依赖、测试失败、指令不清、验证反复失败时会立即停止求助。同时它规定未经用户明确同意不得在主分支上开始实施，建议你仍在版本控制下使用，保留回退能力。
Q5：它和“直接让 AI 按计划执行”有什么区别，我该选哪个？ 如果计划只有三五步、改动集中在一个文件，直接对话即可；如果计划较长、涉及多个模块、需要逐步验证和人工把关，建议用计划执行Skill。判断标准很简单：你是否希望在中途多次介入并看到验证证据——需要，就选它。