计划编写Skill：在写第一行代码前，把需求变成可执行的多步骤实施蓝图
核心结论速览：
- 它是什么：plan-write（计划编写Skill）是一个在动手写代码「之前」使用的技能，专门把需求文档或多步骤任务，转换成一份开发者可以零上下文接手、按任务逐个执行的实施计划。
- 它解决什么：解决"需求想清楚了但没人拆解"“AI 一上来就写代码、写到一半发现方向错了”"新人接手看不懂方案"这三类高频问题。
- 它怎么工作：强制走 TDD 生命周期（失败测试 → 验证失败 → 最小代码 → 验证通过 → 提交），把每个任务切到 2–5 分钟粒度，并自动把计划存档到
docs/plans/YYYY-MM-DD-<feature-name>.md。 - 它的差异化：不是"帮你写文档"，而是产出一份可被另一个技能（计划执行技能）直接消费的执行蓝图，头部结构固定，交接无歧义。
- 适合谁用：需要把需求落地成代码的开发者、做技术方案的技术负责人、以及希望 AI 编码过程可控可审查的团队。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
1.1 基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 计划编写Skill |
| 技能英文名 | plan-write |
| 技能ID | 11787 |
| 适用时机 | 有规范或多步骤任务的需求时，在编写代码之前使用 |
1.2 它到底解决什么问题
日常开发中最容易出事的环节，往往不是"代码写不出来"，而是在没想清楚的情况下开始写。plan-write 的定位非常明确：它是编码前的"减速带"。它假设阅读计划的人是技能娴熟但对代码库、业务领域和良好测试设计一无所知的开发者——也就是说，计划必须写到"零上下文也能接手"的程度。
它把模糊需求转化成三种确定性的东西：
- 确定的目标与架构：一句话目标 + 2–3 句方法说明 + 技术栈清单；
- 确定的任务粒度：每个任务 2–5 分钟可完成，杜绝"这个任务做三天"的黑洞；
- 确定的落盘位置：统一存到
docs/plans/YYYY-MM-DD-<feature-name>.md，团队共享、可追溯、可版本管理。
1.3 一键安装的思路与步骤
"一键安装 AI 技能"的本质，是把一段结构化的技能指令装进你的 AI 编码助手，让它在合适的时机自动按这套规则工作。通用流程如下：
第一步：确认安装前提
- 你已经有一个支持"技能/插件/指令包"扩展能力的 AI 编码助手或智能体平台；
- 该平台支持读取带有
name与description字段的技能描述文件（plan-write 的技能描述为：当您有规范或多步骤任务的需求时，在编写代码之前使用）； - 你的项目是一个可写的代码仓库（因为计划需要写入
docs/plans/目录）。
第二步：找到入口并安装
在技能市场、技能中心或平台插件面板中，按技能中文名「计划编写Skill」、英文名「plan-write」或技能ID「11787」检索，找到条目后点击安装 / 添加到工作区。具体安装命令、入口路径与账号要求，请以官方说明为准。
第三步：验证是否生效
安装完成后，用一个最小用例验证：向助手描述一个多步骤需求（例如"给登录页加邮箱验证码登录"），观察它是否出现以下行为特征：
- 明确宣布"我正在使用编写计划技能来创建实施计划。"；
- 先产出计划，而不是直接吐代码；
- 计划中出现固定的头部（目标 / 架构 / 技术栈）与 TDD 任务序列；
- 在仓库的
docs/plans/目录下生成YYYY-MM-DD-<feature-name>.md文件。
四个特征全部命中，说明技能已正确加载。若只出现部分，通常是助手未读取到技能描述文件，或当前对话未处于"编码前"阶段，可以显式提示"请使用计划编写技能先生成实施计划"。
2. 该技能的主要功能和特点
- 编码前的强制前置动作：技能被触发时，第一步不是写代码，而是产出实施计划。这在流程上把"想清楚"变成不可跳过的环节。
- 固定的计划头部结构：每份计划都自带功能名称、一句话目标、2–3 句架构说明、关键库/工具组成的技术栈，以及一条醒目提示——“使用计划执行技能来按任务实施此计划”。这让计划天然具备"可交接性"。
- TDD 五步生命周期：失败测试 → 验证失败 → 最小代码 → 验证通过 → 提交。任务不是按"写模块 A、写模块 B"来切，而是按"先写一个会失败的测试"来切，保证每一步都有可验证的产出。
- 2–5 分钟的任务粒度：这是一条硬约束。粒度足够细，计划才不会退化成愿望清单，执行者也不会因为任务过大而卡住。
- DRY / YAGNI 原则内建：技能明确要求保持简洁、不做不必要的抽象。它倾向于"先不设计扩展点"，防止过度工程。
@语法引用：计划中可以用@语法引用相关技能或文档，把上下文以引用方式挂到任务上，而不是把大段背景抄进计划里。- 统一的存档路径：
docs/plans/YYYY-MM-DD-<feature-name>.md，日期 + 功能名组成文件名，天然按时间排序，方便回顾和复盘。 - 零上下文假设：这是它和普通"AI 写文档"最大的区别。它不假设读者懂你的项目，所以会主动写清楚为什么这么做、改哪个文件、怎么验证。
3. 如何使用该技能？
步骤一：明确输入（把需求说清楚）
技能需要"规范或多步骤任务"作为输入。输入越接近一份需求说明，产出的计划质量越高。建议输入包含：要实现什么、涉及哪些模块、有无技术约束。
输入示例：
我们现在的登录只支持手机号+验证码。产品希望在用户中心增加"邮箱验证码登录"能力：用户可以在设置页绑定邮箱，绑定后可以用邮箱接收 6 位验证码登录；验证码 5 分钟内有效；同一邮箱 1 分钟内不可重复发送。请先生成实施计划，不要直接写代码。
步骤二：触发技能
技能会在合适的时机被调用；如果助手没有自动触发，可以直接提示「请使用计划编写技能，为上面的需求生成实施计划」。技能会先宣布：“我正在使用编写计划技能来创建实施计划。”
步骤三：确认计划头部
技能产出的文件开头会是这样（示例）：
# 邮箱验证码登录 实施计划
> **重要：** 使用计划执行技能来按任务实施此计划。
**目标：** 让已绑定邮箱的用户可以通过 6 位邮箱验证码完成登录。
**架构：** 新增邮箱绑定与验证码两套表结构和对应服务；登录流程在现有认证入口前插入邮箱验证码分支，复用现有会话签发逻辑。
**技术栈：** 现有 Web 框架、ORM、缓存（验证码存储）、邮件发送服务、测试框架。
---
检查三件事：目标是否是一句话、架构是否说清"改哪里 + 怎么改"、技术栈是否列全。这一步不要跳过，头部写歪了，后面的任务全歪。
步骤四：审阅任务列表
头部之后是按 TDD 拆解的任务序列，每个任务 2–5 分钟。一个健康的任务长这样：
任务 3：编写失败测试——
sendEmailCode对同一邮箱 60 秒内二次调用应返回限流错误。 验证方式：运行该测试，预期失败（限流逻辑尚未实现）。 引用：@限流中间件文档
审阅关注点：任务是否都带有"验证方式"、是否有任务超过 5 分钟、是否出现了不必要的抽象层（YAGNI 违规）。
步骤五：落盘与执行
计划会保存到 docs/plans/2025-06-01-email-otp-login.md（日期与功能名按实际情况生成）。之后把这份文件交给"计划执行技能"按任务逐条实施——这正是头部提示语所指向的下一步。
步骤六：修改与迭代
需求变了怎么办？不要口头补一句"顺便再加个解绑"。正确做法是回到计划文件里增删任务，保持"计划是唯一事实来源"。否则执行者会同时面对两份互相矛盾的指令。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| plan-write（计划编写Skill） | 编码前的实施蓝图生成器 | 固定计划头部、TDD 五步生命周期、2–5 分钟任务粒度、统一存档路径、@ 引用、零上下文假设 |
需在支持技能扩展的 AI 助手中安装；入口与命令以官方说明为准 | 多步骤需求落地、需要交接给他人或另一个 AI 技能执行 | 优势：结构固定、可交接、强制 TDD 与细粒度；不足：对小改动偏重，需要先有需求描述 |
| 直接让 AI 编码助手写代码 | 即时编码 | 对话即出代码 | 极低，开箱即用 | 单文件小改动、探索性原型 | 优势：快；不足：无计划、易跑偏、改错方向成本高、无法交接 |
| 人工撰写技术方案文档 | 团队级方案评审 | 背景、方案、风险、排期 | 高，依赖作者经验与时间 | 跨团队大项目、需要正式评审 | 优势：严谨、可评审；不足：耗时长、常缺可执行的任务粒度、容易写成"概述文" |
| 通用任务看板/待办清单 | 任务跟踪 | 拆卡片、拖状态 | 低 | 已拆好的任务做进度管理 | 优势：进度可视；不足：不产出方案内容、不约束 TDD、不管任务粒度合理性 |
一句话结论：看板管"做没做"，技术方案管"为什么这么做"，plan-write 管"具体按什么顺序做、每步怎么验证"。三者是互补关系，plan-write 恰好补上了中间最容易被跳过的一层。
5. 该技能的典型应用场景与实际体验情况
场景一：中型功能开发前的一次性拆解
角色：业务线后端开发。 痛点：需求文档写了三页，但不知道从哪下手，习惯性先建表、再写服务、最后补测试，结果测试阶段发现接口设计不合理，返工两天。 使用方式：把需求丢给助手并明确"先出计划"。技能产出带 TDD 序列的计划，第一个任务就是"写一个会失败的接口测试"。 实际体验：上手难度低，一次安装长期可用。效果最明显的是方向纠错提前了——接口设计问题在写第一个失败测试时就暴露，而不是在第三天。注意点：需求描述太模糊时，计划会偏抽象，需要用一两句话补充约束条件后重新生成。
场景二：把计划交接给执行技能或另一位同事
角色：技术负责人 / 带新人的导师。
痛点：口头讲一遍方案要 40 分钟，新人还是似懂非懂；讲完自己去忙，回头发现实现和设想不一致。
使用方式：用 plan-write 生成计划文件并提交到仓库的 docs/plans/，让新人直接读文件。
实际体验：因为技能内置"零上下文假设"，计划里会写清改哪个文件、为什么这么改、怎么验证，交接成本显著下降。头部那句"使用计划执行技能来按任务实施此计划"让交接对象知道下一步该做什么，不用再解释流程。
场景三：AI 辅助编码过程的可审查化
角色：使用 AI 编码助手的独立开发者。 痛点：AI 一口气生成几百行代码，看不懂、不敢合、出问题难定位。 使用方式：强制"先计划后编码"，每次只执行计划中的一个 2–5 分钟任务。 实际体验：审查单元从"几百行 diff"变成"一个测试 + 几行最小实现"，评审压力大幅下降。DRY/YAGNI 约束还能抑制 AI 常见的"过度抽象"倾向。注意点：一定要自己过一遍任务列表，删掉明显超出需求范围的任务，否则会按计划"合法地"做多余的事。
场景四：复杂缺陷排查与重构
角色：维护老系统的工程师。 痛点：一个跨三层的 bug，改一处崩一处。 使用方式：把复现步骤当作需求输入，让技能拆成"先写复现测试 → 验证失败 → 最小修复 → 验证通过 → 提交"的序列。 实际体验：TDD 生命周期在这个场景里几乎是量身定做，复现测试变成了回归测试，一次投入长期受益。注意点：老系统可能缺测试基建，第一个任务往往会变成"补测试框架"，这属于正常现象，不要误判为计划跑偏。
6. 该技能能为用户带来的价值
效率价值：把返工成本前移。 计划阶段多花 15–30 分钟，通常能省下数小时的返工。任务粒度被约束在 2–5 分钟，意味着进度是可感知的——你不会再有"今天忙了一天但说不清做了什么"的情况，计划文件的完成项就是最诚实的日报。
质量价值：TDD 与 YAGNI 是硬约束，不是建议。 失败测试优先，让每个功能都有验证依据；DRY/YAGNI 让代码不被"以后可能会用到"的抽象污染。长期看，仓库里留下的测试和计划文档本身就是可检索的决策记录。
协作价值：消除"零上下文"沟通成本。 统一存放于 docs/plans/YYYY-MM-DD-<feature-name>.md 的文件，按日期天然排序，新人入职时按时间线读一遍，就能理解项目是怎么一步步长成现在这样的。这比任何口头交接都可靠。
门槛价值：让不擅长做方案的人也能产出合格方案。 你不需要会写技术方案文档，只需要把需求说清楚。结构、粒度、验证方式由技能兜底。对初级开发者而言，这相当于每次做方案都有一个"资深视角"在旁校对。
可控价值：让 AI 编码从"黑盒输出"变成"白盒执行"。 这是最被低估的一点。计划是人和 AI 之间的契约，人审契约，AI 履约。审查成本从"读几百行代码"降到"读一份结构化清单"。
7. 常见问题 FAQ
Q1：这个技能怎么安装？装了怎么确认生效？
在支持技能扩展的 AI 编码助手或智能体平台中，按中文名「计划编写Skill」、英文名「plan-write」或技能ID「11787」检索并安装即可。具体入口、命令与平台要求以官方说明为准。验证方式：提出一个多步骤需求，看助手是否先声明"我正在使用编写计划技能来创建实施计划。"，并在 docs/plans/ 下生成计划文件。
Q2：这个技能收费吗？
技能本身的授权与计费方式取决于你所在的平台与账号类型，本技能信息中未包含价格相关内容，请以官方说明为准。需要说明的是，使用过程中消耗的是你所使用 AI 助手的模型调用额度。
Q3：它和"直接让 AI 写代码"到底差在哪？
差在顺序和可交接性。直接写代码是"边想边做"，跑偏了要重来；plan-write 是先产出固定结构的计划（目标、架构、技术栈、TDD 任务序列），你可以先审计划再动手。另外计划会落盘成文件，能提交进仓库、能交给同事、能交给计划执行技能逐条实施，而对话里的代码片段做不到这些。
Q4：适合谁用？小改动也要走一遍吗？
最适合三类人：需要把需求落地成代码的开发者、需要做方案交接的技术负责人、希望 AI 编码过程可控可审查的团队。至于小改动——技能本身的定位是"规范或多步骤任务"，一行文案修改、单个样式调整这类改动直接做即可，不必强行走计划流程，否则反而增加负担。
Q5：为什么每个任务只有 2–5 分钟？会不会太碎？
2–5 分钟是刻意的约束。它对应 TDD 的一个最小闭环（写失败测试 → 验证失败 → 最小实现 → 验证通过 → 提交），太大会退化成"写一个模块"的愿望式任务，太小则变成机械拆行。碎不碎取决于任务是否自带验证方式——只要每个任务都能被独立验证，粒度就是合理的。
Q6：计划写完之后怎么执行？
计划头部会明确提示"使用计划执行技能来按任务实施此计划"。也就是说，plan-write 只负责产出蓝图，执行交给配套的执行技能或人工按序完成。需求变更时，请回到计划文件增删任务，保持它是唯一事实来源。