计划设计Skill 用法详解

计划设计Skill：先想清楚再动手，把粗糙想法变成可评审的完整设计

• 它解决的是"想不清楚就开工"的问题：在写代码、写实施方案之前，通过协作提问、替代方案探索和增量验证，把一个模糊的点子收敛成一份结构化的设计文档。
• 有强制的落地载体：技能要求在任何对话之前，先创建 .claude/docs/plans/<topic>-design.md，并且每次用户响应后都要更新它，而不是等最后一次性补写。
• 节奏被明确设计过：一次最多问 4 个相关问题、给 2-3 个备选方案并说明权衡、设计稿按 200-300 词分块呈现、每块之后确认对齐。
• 边界非常清晰：只做高层架构、组件职责、数据流逻辑与取舍，不写具体文件路径、编号实施步骤、代码片段；一旦越界就应停下并转交 plan-write 技能。
• 最适用场景：需求还很粗的新项目、新功能、改造类任务；对于清晰的"机械"流程，技能本身明确说明不要使用。

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

这个技能的中文名是计划设计Skill，英文名是 plan-design，技能ID 为 11789。它的官方定位一句话可以概括为：在创建或开发时使用，在编写代码或实施计划之前，通过协作提问、替代探索和增量验证，将粗略想法转化为完整设计；不要在清晰的"机械"过程中使用。

它解决的核心痛点是：绝大多数返工不是因为程序员不会写代码，而是因为动手之前没人把"到底要做什么、有几种做法、为什么选这一种"讲清楚。plan-design 把"设计"这一步从头脑里的口头讨论，变成一个有固定产物、有固定节奏的过程——产物就是 .claude/docs/plans/ 目录下的设计文件。

关于安装，有一点必须说明：本次提供的技能详情中没有给出具体的安装命令、下载地址或价格信息，因此这里只讲通用的"一键安装"思路，具体命令与入口请以官方说明为准，不要凭猜测执行。

通用安装思路与步骤：

1. 确认前提：你使用的是支持 AI 技能（Skill）机制的客户端或开发环境，并且该环境具备读写项目文件的能力——因为本技能的第一步就是强制创建并持续编辑 .claude/docs/plans/<topic>-design.md，同时它依赖提问工具（如 AskUserQuestion）来做多选题式确认。没有文件写入与提问能力，技能的核心节奏就跑不起来。
2. 完成安装：按官方说明，通过技能市场一键安装、或在技能管理入口导入该技能，或在项目内按官方指引配置技能目录。安装时注意确认技能标识为 plan-design。
3. 验证是否生效：安装后开启一个新会话，提出一个明显处于"设计阶段"的需求（例如"我想给现有系统加一个导出功能，但还没想好怎么做"），观察技能是否先创建计划文件、并以最多 4 个问题的批量形式提问。如果它直接开始写代码或直接给出一份长方案，说明技能未被正确加载。
4. 准备协同技能：详情末尾提到设计完成后转交 plan-write，建议一并装好，形成"设计 → 实施计划"的连贯链路。

“一键安装提升开发效率"的逻辑并不神秘：把专家级的设计思考流程固化成一个可复用的技能，用户不需要每次都想"我该问哪些问题、该写到哪、该写到多细”，流程本身替你兜底。

该技能的主要功能和特点

• 强制计划文件先行：在任何对话之前，立即创建 .claude/docs/plans/<topic>-design.md，初始内容包含问题陈述、目标和已知需求。设计不再是散落在聊天记录里的碎片。
• 黄金规则：每次响应后更新：用户每回答一次，就更新一次文件，不攒到最后。这让设计文档始终是"当前最新共识"，而不是事后回忆录。
• 上下文检查优先于提问：先看现有文件、文档和提交记录，再问人。避免问出"其实项目里已经写着"的低质量问题。
• 批量提问，最多 4 个一组：用提问工具把问题分组，覆盖目的、约束、成功指标三个方向，并优先采用多选/多选题形式，降低用户回答成本。
• 闭环循环：提问 → 回答 → 编辑计划 → 跟进，形成可追溯的迭代。
• 替代方案探索：主动呈现 2-3 种做法及其权衡，并以首选方案为主导说明"为什么选它"，而不是把选择困难原样丢回给用户。
• YAGNI 裁剪：主动砍掉"你不需要它"的范围，防止设计阶段就开始堆需求。
• 分块呈现 + 增量批准：设计按 200-300 词的篇幅分块输出（如架构、数据流），每块之后用 AskUserQuestion 确认对齐，避免一次性甩出万字长文让人无从反馈。
• 设计/实施边界表：明确列出在范围内（高层架构与技术栈、组件职责、数据流逻辑、权衡与假设）与不在范围内（具体文件路径与目录结构、编号实施阶段、完整代码片段或 Git 命令、"要创建/修改的文件"列表）的内容，越界即停。
• 收尾明确：结束时做最终审查，确保计划文件完善，并主动询问"准备好设置实施了吗？"，若确认则转至 plan-write。

和"直接找 AI 聊需求"相比，它强在有产物、有节奏、有边界：产物是可复用的 Markdown 文件，节奏是被验证过的提问-确认循环，边界防止设计与实施混为一谈。

如何使用该技能？

以下为通用使用步骤，具体交互以你所使用的客户端为准。

1. 触发技能。在创建或开发类任务开始时提出你的初步想法，例如：“我要给内部数据平台加一个数据导出功能，但细节还没想清楚，帮我做设计。”

2. 等待计划文件被创建。技能应立即生成 .claude/docs/plans/<topic>-design.md，其中写入问题陈述、目标与已知需求。第一步就该检查这个文件是否真的出现了。

3. 让技能先做上下文检查。它会先读现有文件、文档与提交记录。如果你的项目里有历史设计或规范，可以顺带提示它一并纳入。

4. 回答第一轮批量提问。你会收到最多 4 个问题，方向通常是目的、约束、成功指标。示例（示意）：

   Q1（多选）这个导出功能主要服务于哪类用户？A. 业务分析师 B. 外部客户 C. 运维排查 D. 其他 Q2 单次导出的数据量级大致是多少？A. 万行以内 B. 十万级 C. 百万级 Q3 成功的判定标准是什么？A. 导出可在 30 秒内完成 B. 支持断点续传 C. 仅需能下载即可 Q4 有哪些硬约束？A. 不能引入新依赖 B. 必须复用现有权限体系 C. 无特殊约束

5. 观察计划文件被更新。你每回答一轮，<topic>-design.md 就应被改写一次，把答案沉淀进去。若没有更新，说明"黄金规则"未被遵守。

6. 进入设计探索。技能会给出 2-3 种技术路线并列出权衡，同时标出它推荐的那一种及理由。此时你的反馈应该是"选哪个/为什么否掉某个"，而不是立刻讨论代码。

7. 分块评审设计。设计会按 200-300 词分块给出（例如：整体架构 → 组件职责 → 数据流），每块之后会有一个确认问题。逐块回答"对齐/不对齐 + 原因"，对齐成本远低于事后返工。

8. 做边界自查。看一眼设计文件里有没有出现具体文件路径、"阶段一：初始化"这类实施步骤、或完整代码片段。如果有，按技能规则应当停止并转交 plan-write。

9. 收尾并决定下一步。技能会做最终审查，然后询问"准备好设置实施了吗？"回答是，则转向 plan-write 生成实施计划；回答否，就继续在设计层面迭代。

输出说明：本技能的最终产出不是代码，而是一份位于 .claude/docs/plans/ 下、包含问题陈述、目标、约束、2-3 个备选方案与权衡、推荐结论、高层架构、组件职责与数据流的设计文档。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
plan-design（本技能）	结构化的"想法 → 设计"协作流程	强制计划文件、批量提问（≤4）、2-3 备选方案、分块增量批准、设计/实施边界表、YAGNI	需支持技能机制与文件写入、提问工具；安装以官方说明为准	需求模糊的新项目、新功能、改造任务	优势：有固定产物与节奏，防跑偏、可追溯；不足：对已经想清楚的机械流程偏重，官方明确不建议使用
通用 AI 对话（直接聊需求）	零门槛的需求讨论	自由问答、随时追问	极低，打开即用	快速探路、闲聊式梳理	优势：灵活、无流程负担；不足：结论散落在聊天记录里，容易跳步、缺少方案权衡与确认节点
传统 PRD / 设计文档模板	文档规范	固定章节：背景、目标、方案、风险	低，但需要人自己组织内容	团队正式立项、评审留档	优势：格式统一、便于评审；不足：模板不会提问，思考质量完全取决于作者本人
plan-write（配套技能）	设计之后的实施计划	把设计拆成可执行的实施步骤与文件清单	与 plan-design 同源，建议配套安装	设计已确认、准备落地	优势：与 plan-design 无缝衔接，边界互补；不足：单独使用缺少前置的设计收敛环节

从对比看，plan-design 的差异化不在"能生成文档"，而在"用流程保证你在该问的时候问了、该砍的时候砍了、该确认的时候确认了"。

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

场景一：独立开发者的新功能立项 角色：全栈独立开发者。痛点：脑子里有个功能雏形，但一打开编辑器就开始纠结目录结构和依赖选择，最后写了一堆又推翻。使用方式：先用一句话描述想法交给 plan-design，按它的 4 个问题回答目的、数据量、成功标准与约束，拿到 2-3 个方案对比后再定。实际体验：上手难度低，主要成本是"忍住不写代码"；效果是把纠结从写代码阶段前移到讨论阶段，返工明显减少；注意事项是要如实回答问题，随便敷衍会导致设计建立在错误假设上。

场景二：技术负责人做方案评审前的预演 角色：团队技术负责人。痛点：需求会上各说各话，会后没人记得当初为什么否掉了某个方案。使用方式：把评审议题作为 topic 跑一遍，让技能把 2-3 个方案的权衡和推荐理由落到 .claude/docs/plans/ 里。实际体验：分块呈现（200-300 词）非常适合会上逐段过，每段确认一次，会议时长反而缩短；注意事项是设计文件要纳入版本管理，否则共识又丢了。

场景三：需求模糊的遗留系统改造 角色：接手老系统的工程师。痛点：不了解历史约束，凭直觉设计，改到一半发现踩了旧坑。使用方式：让技能先做上下文检查（读现有文件、文档、提交记录），再提问。实际体验：这一步价值极高，很多时候问题在代码历史里已有答案，提问质量显著提升；注意事项是上下文检查依赖项目本身有可读的文档与提交信息，仓库过于混乱时需手动补充背景。

场景四：非技术角色把想法说清楚 角色：产品经理或业务方。痛点：描述停留在"我想要一个能看数据的页面"，开发反复问细节。使用方式：跟着多选题走，把目的、约束、成功指标一次性说明白。实际体验：多选题形式比开放式提问友好得多，回答成本低；注意事项是涉及技术选型的部分仍需工程同学参与确认。

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

• 把隐性的设计思考显性化：一份持续更新的设计文件，让"我们当初为什么这么定"有据可查，降低新人接手和跨期回溯的成本。
• 降低设计能力门槛：不知道该怎么问、该问几个、该问哪些维度，是多数学不好设计的真正原因。技能把目的、约束、成功指标三个方向固化成最多 4 个一组的批量提问，用户只需回答。
• 减少方向性返工：2-3 个备选方案 + 权衡 + 推荐理由，加上每 200-300 词一次的对齐确认，把"大方向错了才发现"的概率显著压低。分块确认的成本是几分钟，方向返工的成本往往是几天。
• 防止范围膨胀：YAGNI 原则被写进流程，设计阶段就砍掉"你不需要它"的部分。
• 让设计与实施各归其位：边界表明确禁止在设计里写文件路径和编号步骤，避免"设计文档写着写着变成了不完整的实施清单"，也让 plan-write 有干净的输入。
• 长期价值：.claude/docs/plans/ 目录会逐步积累成项目的设计档案库，形成可复用、可检索的组织记忆。

常见问题 FAQ

Q1：怎么安装这个技能？装完怎么确认生效？ 按官方说明通过技能市场或技能管理入口安装，技能标识为 plan-design（技能ID 11789），具体命令与入口以官方说明为准。验证方法：新开会话提出一个设计阶段的需求，看它是否先创建 .claude/docs/plans/<topic>-design.md 并以最多 4 个问题的批量形式提问；若直接给代码或长篇方案，说明未生效。

Q2：这个技能收费吗？ 本次提供的技能详情中未包含任何价格或授权信息，收费情况请以官方说明为准。建议在安装入口确认授权方式后再使用。

Q3：它和直接跟 AI 聊天问需求有什么区别？ 直接聊天的结论散落在对话里，容易跳步，也没有强制的方案权衡与确认节点；plan-design 有固定产物（计划文件）、固定节奏（提问→回答→编辑计划→跟进）、固定边界（只做设计不做实施），并且遵循"每次用户响应后更新文件"的黄金规则。

Q4：为什么它不给我写具体文件路径和实施步骤？ 这是技能刻意设定的边界。设计阶段只输出高层架构与技术栈、组件职责、数据流逻辑、权衡与假设；具体文件路径、编号实施阶段、代码片段属于实施范畴。一旦开始写"阶段1：设置"这类内容，按规则应停止并转交 plan-write 技能。

Q5：适合谁用？什么情况下不该用？ 适合独立开发者、技术负责人、需要把模糊想法讲清楚的产品与业务角色，尤其适合需求还粗的新项目、新功能与改造任务。官方明确说明：不要在清晰的"机械"过程中使用——如果你已经确切知道要改哪几个文件、按什么顺序改，直接进入实施更高效，用本技能反而增加流程负担。