plan（计划制定技能Skill）Skill 是什么？如何下载安装？

计划制定技能Skill：让 AI 先写计划再改代码，复杂变更先评审后动手

它是什么：一个定位极其纯粹的「规划代理」技能——在动手改代码前，先产出一份结构化的 Markdown 实现计划文件。
最大的特点：沉默且直接。启用后，代理不会先和你寒暄「我将要做这个」，第一次响应就是调用 plan 工具生成计划文件。
计划有固定骨架：目标、概述、提议的变更、验证，四段式让任何一次重构或新功能都能被快速看懂、评审与批准。
信息不足时不乱猜：需要澄清范围或技术选型时，使用 ask_followup_question 工具给出 2–4 个可直接点选的答案，而不是把疑问写进计划正文。
适用人群：需要做复杂重构、跨多文件变更、团队协作评审的开发者与 AI 编程工具重度用户。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

该技能叫什么？

中文名：计划制定技能Skill
英文名：plan
技能 ID：13753
许可证：MIT
兼容性：opencode
作者与版本：tandem，1.0.0

它解决什么问题？

AI 编程助手最让人头疼的地方，往往不是「写不出代码」，而是「没问清楚就开始写」。一句话需求丢过去，代理立刻埋头改五个文件，等到 Review 时才发现技术路线选错了，前面的工作全部作废。plan 技能把这个顺序倒过来：先出计划，人看过、点头了，再动代码。它要求代理在代码变更之前生成一份详细的实现计划文件，用于复杂重构、新功能开发或多文件变更的前置评审。

「一键安装」的思路与步骤

这里的「一键」本质是把一套提示词与工具约定打包成一个可复用的技能，安装后代理的行为模式被固化下来，不用每次重复交代「先规划再动手」。

确认前提：该技能声明的兼容环境为 opencode，请先确保你的 AI 编程工具运行在受支持的环境中；若使用其他宿主环境，需自行确认对自定义技能与 plan 工具的支持情况，以官方说明为准。
找到技能：在技能市场或技能管理入口中，通过关键词「计划制定技能」、英文名「plan」或技能 ID「13753」检索并添加。具体入口路径与命令因平台而异，以官方说明为准。
启用技能：将技能添加到当前项目或全局配置中，使其在会话开始时被加载。安装方式、配置文件名等细节请以官方说明为准。
验证是否生效：新建一个会话，输入类似「帮我为『给用户接口加分页』制定实现计划」。若代理没有先输出「好的，我将……」，而是直接产出一份包含「概述 / 提议的变更 / 验证」的 Markdown 计划文件，说明技能已正确加载生效。
回归确认：若代理仍在大段对话、或报出工具名不存在的错误，优先检查技能是否被正确挂载、plan 工具是否已注册（工具名必须精确为 plan，不加空格、不加引号）。

该技能的主要功能和特点

生成结构化实现计划：通过 plan 工具创建计划文件，content 参数是一份完整的 Markdown 文档，推荐骨架为「# 目标 → ## 概述 → ## 提议的变更 → ## 验证」，让计划天然可评审、可交接。
规范化的文件命名：name 采用 kebab-case（例如 add-auth），session 同样采用 kebab-case（例如 auth-feature），未提供时默认为 general，便于按任务或特性分组归档。
沉默执行，零客套：核心行为第一条就是「不要输出对话文本或『我将做这个』消息」，第一个响应必须是调用工具。这消灭了「确认式废话」带来的轮次浪费。
需要澄清时走独立通道：当范围、时间线、技术偏好不明，或存在多种有效方案时，使用 ask_followup_question 工具追问，并给出 2–4 个完整、可操作的候选项；规则明确要求不要在计划内容里写问题。
批准后才进入执行：计划生成后等待用户确认，用户回复「看起来不错，实现它」后，代理再调用 task 工具进入实施阶段——把「规划」与「执行」两个阶段做了硬隔离。
和普通对话式编程的区别：普通工具是「边聊边改」，产物散落在聊天记录里；plan 技能的产物是一个持久化的文件，可以被提交、被评论、被第二个人接着改。

如何使用该技能？

步骤 1：用自然语言触发

直接说出你的目标即可，不需要额外声明「请使用计划模式」。例如：

用户：向 API 添加认证。

步骤 2：代理立即调用 plan 工具

按技能的约定，它的第一个响应就是创建计划文件，不会再问「我可以继续吗」。调用形态如下：

plan({
  name: "add-auth",
  session: "auth-feature",
  content: "# 添加认证

## 概述...",
});

其中三个参数的分工是：name 是计划文件名（kebab-case），session 是所属会话分组（kebab-case，可省略、默认 general），content 是完整的 Markdown 计划正文。

步骤 3：必要时先回答澄清问题

如果代理判断信息不足，会先调用 ask_followup_question，而不是硬写计划：

ask_followup_question({
  question: "您偏好的部署云平台是什么？",
  follow_up: [
    { text: "AWS", mode: null },
    { text: "Vercel", mode: null },
    { text: "Railway", mode: null },
    { text: "Render", mode: null },
  ],
});

你可以直接在候选项中挑一个，也可以自由补充。规则是：候选项 2–4 个，每个都必须是完整、可操作的答案，且默认使用 mode: null（除非需要切换到不同的代理模式）。

步骤 4：审查计划文件

打开生成的 Markdown 计划，重点看三处：

概述：目标是否被正确理解，有没有跑偏；
提议的变更：涉及哪些文件、哪些模块，改动边界是否合理；
验证：验收方式是否具体到可以照着做。

步骤 5：批准并进入执行

确认无误后回复一句明确的批准指令，例如「看起来不错，实现它」，代理随后调用 task 工具开始落地。如果发现偏差，直接提修改意见，让它重出计划即可——这一轮返工的成本，远低于改错五个文件的成本。

使用中的三个硬性注意点

工具名必须精确：用 plan，不要写成带前导空格的 plan；
不要在函数名上加引号；
计划正文里不要夹带「请确认……」之类的问句，要问就用 ask_followup_question。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
plan（计划制定技能Skill）	单一职责的规划代理技能，只负责出计划文件	调用 `plan` 工具生成结构化 Markdown 计划；`ask_followup_question` 澄清；命名遵循 kebab-case	需在 opencode 等受支持环境中启用技能，安装配置以官方说明为准；使用上仅需一句自然语言	复杂重构、新功能、跨多文件变更的变更前评审	优势：行为约定极强，沉默直出、结构统一、可归档可评；不足：能力边界窄，只做规划不做执行，依赖宿主环境支持
宿主工具自带的计划模式	由 AI 编程工具内置的「先规划」开关	先复述需求、再分步执行，计划通常停留在对话中	无需安装，工具内切换即可	轻量任务、探索性改动	优势：零配置；不足：计划往往不是独立文件，格式不固定，团队评审与交接不便
规格驱动开发流程（如以规格文档为先的工作流）	面向工程的文档先行方法论	产出需求规格、任务拆解、验收标准等成套文档	需引入配套脚手架与流程约定，学习成本较高	中大型项目、多人协作、需要长期维护的资产	优势：体系完整、可追溯；不足：流程重、迭代慢，小改动容易「杀鸡用牛刀」
手工编写技术方案文档	传统的人工规划方式	人写设计文档、评审、再开发	无工具门槛，但时间成本最高	高风险变更、跨团队协作	优势：思考最深入；不足：产出慢，AI 协作时代难以和执行环节打通

怎么选：如果你要的是「一句话就能拿到一份格式统一、可以贴进 PR 描述的计划文件」，plan 技能的性价比最高；如果需要一个覆盖需求到验收的完整规范体系，那属于另一类重流程方案。

该技能的典型应用场景与实际体验情况

场景一：后端服务重构

角色与痛点：后端工程师面对一个上千行的「上帝类」，想拆但怕拆漏，凭感觉动手容易破坏隐式依赖。
使用方式：输入「为订单服务拆分做准备，制定实现计划」，代理直出计划，在「提议的变更」里列出要拆出的模块与影响面，在「验证」里给出回归检查点。
实际体验：计划文件本身就是一份重构前的风险清单。注意事项是这类需求边界模糊，代理很可能先弹出澄清问题，建议提前想好拆分粒度再触发。

场景二：新功能开发前的方案对齐

角色与痛点：产品、前端、后端三方对「接哪个第三方登录」意见不一，讨论散落在聊天记录里。
使用方式：让代理就「添加 OAuth 登录」出计划，遇到技术选型分歧时，ask_followup_question 会给出几个候选答案，选定后再成文。
实际体验：把口头争论收敛成一份可引用的文档，评审效率明显提升。上手难度低，一句话即可触发。

场景三：跨多文件的批量变更

角色与痛点：一次改动涉及接口层、数据层、前端调用方，最容易「改了这个忘了那个」。
使用方式：先把变更范围写清楚交给代理，看「提议的变更」是否覆盖了所有受影响的文件，缺了就补一句，让它重新生成。
实际体验：这是该技能最舒服的场景，因为计划的固定骨架天然适合做「改动清单核对」。注意事项：name 与 session 记得用 kebab-case，否则归档会乱。

场景四：交接与复盘

角色与痛点：任务换人接手，接手者需要快速理解「为什么这么改」。
使用方式：计划文件就是最好的交接材料，session 相同的计划会聚在一起，按特性回溯非常方便。
实际体验：长期看，这一堆计划文件会沉淀成项目的轻量决策日志。

该技能能为用户带来的价值

把返工挡在动手之前：最贵的 bug 不是写错的代码，而是方向错的代码。计划先评审，等于在成本最低的环节做了一次拦截。
消灭「确认式空转」：明令禁止输出「我将做这个」，第一个响应直接产出文件，每轮交互都产生实际资产，而不是寒暄。
降低协作门槛：统一的四段式骨架（目标 / 概述 / 提议的变更 / 验证），让不同水平的使用者产出的计划看起来一样专业，评审者有固定的阅读路径。
产出可复用的文档资产：计划是文件而非聊天流，可以进版本库、进 PR 描述、进交接文档，长期沉淀为项目的决策记录。
降低 AI 编程的失控感：规划与执行被 plan 与 task 两个阶段隔开，用户始终握有「批不批准」的开关，把主动权还给人类。
极低的接入成本：MIT 许可、单一职责、无复杂配置，一次启用后长期复用。

常见问题 FAQ

Q1：怎么安装这个技能？收费吗？

A：该技能以 MIT 许可证发布，属于开源免费技能。安装上，先在技能市场或管理入口按中文名「计划制定技能」、英文名「plan」或技能 ID「13753」检索添加，然后在兼容 opencode 的环境中启用。具体命令、配置路径与入口位置因平台而异，以官方说明为准。验证方式是：让代理制定一个计划，看它是否直接产出计划文件而非先发表格话。

Q2：它和 AI 编程工具自带的「计划模式」有什么区别？

A：自带计划模式的产物通常停留在对话里，格式随缘；plan 技能的产物是一个按固定规则命名的 Markdown 文件，有 name、session 分组，有约定好的段落骨架，并且明确要求代理「沉默直出」、需要澄清时走 ask_followup_question 而不是把问题混进正文。简单说，前者是「想一想」，后者是「交付一份文档」。

Q3：适合谁用？小改动也值得用吗？

A：最适合的人群是做复杂重构、新功能开发、跨多文件变更的开发者，以及需要多人评审的团队。改一行文案这类小改动就不必启用，规划本身也有成本。技能的定位描述里已经写明适用边界：复杂重构、新功能、多文件变更。

Q4：为什么它老是先问我问题，不直接出计划？

A：这是设计使然。当范围、时间线、技术偏好不明，或存在多种有效方案时，技能要求先调用 ask_followup_question，给出 2–4 个可直接选择的答案，等你回复后再继续。这不是卡壳，而是避免基于错误假设写出一份看起来很完整、实际方向错误的计划。回答完候选项，计划会立刻生成。

Q5：生成的计划能直接执行吗？

A：不会自动执行。技能明确规定计划用于「在执行前审查和批准变更」，你确认后回复类似「看起来不错，实现它」，代理才会调用 task 工具进入执行。如果你不满意，直接提修改意见让它重出计划即可——改计划永远比改代码便宜。