writing-plans（编写实现计划）Skill 是什么？如何下载安装使用？

编写实现计划Skill：把设计方案变成零背景工程师也能照着做的实施蓝图

核心结论速览：

它是什么：writing-plans（编写实现计划Skill）是一个把「已完成的设计方案」翻译成「可逐步执行的实施任务清单」的 AI 技能，技能 ID 为 13639。
它解决什么：设计文档往往只有结论，没有文件路径、没有代码、没有验证方式，接手的人（尤其是对代码库零背景的工程师或 AI 子代理）看不懂、不敢动、容易写跑偏。
它怎么干：强制要求精确文件路径 + 完整可运行代码 + 精确命令 + 预期输出，把每个任务拆到 2-5 分钟一个动作，并按 TDD 顺序（写失败测试 → 确认失败 → 最小实现 → 确认通过 → 提交）排列。
产出物：一份 Markdown 计划文档，固定保存到 docs/plans/YYYY-MM-DD-<功能名称>.md，文档头部写明目标、架构、技术栈和执行交接指令。
适合谁：技术负责人、独立开发者、使用 AI 编码代理做多任务并行开发的工程师，以及需要把工作交接给他人或外包团队的场景。

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

基本信息

项目	内容
技能中文名	编写实现计划Skill
技能英文名	writing-plans
技能ID	13639
输出格式	Markdown 计划文档
默认保存路径	`docs/plans/YYYY-MM-DD-<功能名称>.md`

它到底解决什么问题？

在真实的开发流程里，最贵的往往不是「写代码」，而是从「方案已经定了」到「第一个人真的动手写第一行代码」之间的信息损耗。设计讨论产出的通常是一段结论式的描述：要做登录、要做导出、要做重试。但真正动手的人需要的是：

到底改哪个文件？新文件建在哪里？现有代码是第几行到第几行？
这个函数应该长什么样？能不能直接给我完整代码，而不是一句「在这里加校验」？
我怎么确认自己写对了？跑哪条命令？应该看到什么输出？
一次改多少合适？改完要不要提交？提交信息怎么写？

writing-plans 的定位就是把这些空白全部填满。它明确假设读者是熟练的工程师，但对该代码库、工具链和问题领域零背景，且对「好的测试设计」理解不足——因此计划必须写到「不需要再做任何判断，照着做就行」的程度。

安装思路与一键生效的步骤

该技能属于围绕「superpowers」系列子技能协同工作的技能，其调用与安装通常依托对应的 AI 编码环境（如支持子技能机制的编码助手）。具体安装命令与入口以官方说明为准。通用思路如下：

第一步：确认安装前提

你已经在使用支持「技能 / 子技能」调用机制的 AI 编码环境；
环境中已具备该技能依赖的协作技能，例如用于前期头脑风暴与创建专用工作树（worktree）的技能、以及后续用于执行的 superpowers:executing-plans、superpowers:subagent-driven-development；
项目是 Git 仓库，便于执行「频繁提交」与在独立工作树中作业。

第二步：安装 / 启用技能

在技能市场、插件目录或技能包中检索技能名 writing-plans 或技能 ID 13639，按其提供的安装指引完成启用。若为本地技能包形式，通常是将技能目录放入约定的技能存放路径后重新加载环境；具体命令与路径以官方说明为准。

第三步：验证是否生效

在对话中提出一个明确的设计需求，观察 AI 是否在开始撰写前主动输出这一句声明：

「我正在使用编写计划技能来创建实施计划。」

只要这句声明出现，且随后产出的内容包含「任务 N + 文件路径 + 步骤 1…N + 运行命令 + 预期输出」的结构，即说明技能已被正确触发。

第四步：确认落盘位置

检查项目内是否出现 docs/plans/YYYY-MM-DD-<功能名称>.md 文件。如果没有，说明保存路径环节未被遵循，可要求 AI 重新按规范写入。

该技能的主要功能和特点

零背景可执行：所有任务都带精确文件路径（创建哪个文件、修改哪个文件的哪几行、测试文件放哪里），不接受模糊表述。
完整代码而非伪代码：计划中直接给出可粘贴运行的代码块，而不是「在此处添加参数校验」这类占位式描述。
小块任务粒度：每个步骤就是一个 2-5 分钟的单一动作——写失败测试、运行测试确认失败、写最小实现、运行测试确认通过、提交，五步一组，节奏清晰。
内建 TDD 工作流：步骤顺序被强制约束为测试先行，避免「先写完再补测试」的常见走样。
精确命令与预期输出：每个运行步骤都写明命令（如 pytest tests/路径/测试.py::test_name -v）和「应该看到什么」，成功与失败都有判据。
固定文档骨架：计划以 # [功能名称] 实施计划 开头，紧随其后是目标（一句话）、架构（2-3 句）、技术栈，并嵌入「对于 Claude：必选子技能 superpowers:executing-plans」的交接提示。
工程原则显式化：DRY、YAGNI、TDD、频繁提交四条原则贯穿整个计划，减少「顺手多写点」的膨胀。
自动交接执行路径：计划保存后，会主动给出两个执行选项——当前会话的子代理驱动模式（使用 superpowers:subagent-driven-development，每个任务派新子代理并做代码审查），或在独立工作树中开新会话批量执行并设置检查点。
与技能体系互操作：计划正文中可使用 @ 语法引用其他相关技能，让实施过程能顺势调用配套能力。

与普通「让 AI 写个开发步骤」的工具相比，它强在把「可执行性」写成了硬性规范：路径不精确不算完成、没有完整代码不算完成、没有验证命令不算完成。

如何使用该技能？

步骤一：先完成设计，再进入计划阶段

该技能的前提是「设计已完成」。因此先通过头脑风暴环节把方案想清楚，并在专用工作树（worktree）中开展后续写作——技能说明中明确要求在专用工作树中运行。

步骤二：触发技能

在对话中说明你已完成设计，需要一份给零背景工程师执行的实施计划。AI 会先输出启动声明：

「我正在使用编写计划技能来创建实施计划。」

步骤三：提供输入信息

输入示例（可直接参考）：

设计已定：为订单服务新增「导出为 CSV」接口。要求支持按时间范围筛选、单次最多导出 5 万行、超过则返回错误提示。代码库是 Python + FastAPI，测试用 pytest。请产出实施计划。

输出说明： AI 会产出一份结构化的 Markdown 计划，包含以下要素：

文档头：# 订单导出 CSV 实施计划，随后是「对于 Claude：必选子技能：使用 superpowers:executing-plans 逐步实施此计划」，以及目标、架构、技术栈三段简述；
任务清单：每个任务形如「任务 N: 组件名称」，先列出「文件」三行——创建 / 修改（含行号范围）/ 测试；
步骤序列：每个任务拆成 5 个动作步骤，依次是「编写失败测试」（附完整测试代码）、「运行测试以确认失败」（附命令与预期失败提示）、「编写最小化实现」（附完整实现代码）、「运行测试以确认通过」（附命令与预期结果）、「提交」（附 git add 与 git commit -m 命令）。

步骤四：核对计划质量

拿到计划后，用四条硬标准快速检查：

是否所有路径都精确到文件、修改项精确到行号？
是否每段代码都能直接粘贴运行，而不是描述性文字？
是否每个运行步骤都写了命令与预期输出？
是否每个任务都以一次提交收尾？

任一条不满足，直接要求 AI 补齐。

步骤五：确认保存

计划应保存到 docs/plans/YYYY-MM-DD-<功能名称>.md，例如 docs/plans/2025-06-01-订单导出CSV.md。

步骤六：选择执行方式

技能会主动给出两个选项并询问你的选择：

选项 1：子代理驱动（当前会话）——由 AI 为每个任务派遣新的子代理，任务之间做代码审查，迭代速度快；若选此项，必选子技能为 superpowers:subagent-driven-development，并保持在当前会话中继续。
选项 2：并行会话（独立会话）——在工作树中打开新会话，使用 superpowers:executing-plans 批量执行并设置检查点，适合长计划或需要人随时介入的场景。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
`writing-plans`（编写实现计划Skill）	面向零背景执行者的实施计划生成器	精确路径、完整代码、TDD 步骤、命令与预期输出、执行交接	需具备支持子技能机制的 AI 编码环境，按官方说明安装	设计已定、需要交接给他人或 AI 子代理执行	优势：可执行性极强，任务粒度细，配套执行技能完整；不足：前期需先有设计结论，计划文档较长
通用 AI 对话直接写步骤	聊天式开发建议	给出大致任务列表与思路	极低，打开对话框即可	个人快速开发、探索性原型	优势：上手零成本；不足：路径与代码常含糊，缺少验证判据，多人协作易走样
通用项目管理工具的任务看板	任务跟踪与协作	任务卡片、负责人、截止时间、状态流转	低，注册即用	团队进度管理	优势：协作与可视化强；不足：只回答「做什么」，不回答「改哪个文件、写什么代码、怎么验证」
规格驱动开发类工具（Spec 驱动）	以规格文档驱动 AI 编码	从需求规格生成任务与实现	中等，需配置工具链与规范	中大型项目的规范化 AI 编码	优势：流程规范、可追溯；不足：粒度常停在需求层，未必给到行号级路径与逐步验证命令

从对比可见：通用对话工具擅长「给方向」，项目工具擅长「管进度」，而 writing-plans 补的是最容易被忽略的中间那一段——把方向变成一条条带判据的动作。

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

场景一：初级工程师接手陌生模块

角色与痛点：刚入职的工程师被安排实现一个功能，但对代码库结构、测试框架写法、提交规范都不熟，反复沟通成本高。 使用方式：技术负责人先完成设计，用该技能生成计划文档，直接交给新人。新人只需按「步骤 1 → 步骤 5」顺序执行，每个任务结束就是一次干净的提交。 实际体验：上手难度低，新人几乎不需要做额外判断；计划中的测试代码同时充当了「本项目的测试写法范例」。注意事项是：若设计本身不完整，计划会把模糊点如实放大，因此设计阶段不能省。

场景二：AI 子代理并行开发

角色与痛点：使用多个子代理并行开发时，子代理缺乏上下文，容易各自发挥、互相冲突。 使用方式：选择「子代理驱动」执行方式（必选子技能 superpowers:subagent-driven-development），为每个任务派一个新子代理，任务之间做代码审查。 实际体验：因为每个任务的文件边界、代码内容、验证命令都被写死，子代理之间冲突显著减少，审查也有了明确基准。注意事项是任务拆分要足够小，否则单个子代理的上下文压力仍会上升。

场景三：外包或跨团队交接

角色与痛点：把工作交给外部团队时，「我们的代码库习惯」这一层隐性知识最难传递。 使用方式：在计划中通过 @ 语法引用相关技能与文档，把工具集用法、目录约定一并写进任务描述。 实际体验：交接文档从「需求说明」升级为「施工图」，返工率明显下降。注意计划里的命令必须与对方真实环境一致，环境差异应在合同中或计划开头显式说明。

场景四：遗留系统改造

角色与痛点：老代码改动风险高，谁也不敢先动第一刀。 使用方式：用 TDD 步骤先写失败测试锁住现有行为，再做最小化实现，逐个任务提交，出问题可单点回滚。 实际体验：频繁提交带来的可回滚性是最被低估的收益。注意对「修改现有文件第 123-145 行」这类定位，需在动工前核对行号是否仍然准确。

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

把沟通成本前置为文档成本：原本需要多轮口头澄清的细节（改哪个文件、怎么写测试、跑什么命令），一次性固化在计划里，后续沟通显著减少。
降低接手门槛：零代码库背景的工程师或 AI 子代理可以直接开工，「读懂项目」的成本被分摊进了任务步骤中。
减少返工与跑偏：每个步骤都有成功判据（预期通过 / 预期失败提示），写错了当场暴露，而不是等到联调阶段。
天然可回滚：任务以提交收尾，配合频繁提交原则，出问题时可精确定位与回退。
质量下限被抬高：TDD 顺序与 DRY、YAGNI 原则被写进流程而非口头约定，测试设计能力偏弱的工程师也能产出结构合理的测试。
可复用的过程资产：计划文档沉淀在 docs/plans/ 目录中，半年后回看，能直接还原当时的决策与实施路径，长期价值随项目积累而增长。

常见问题 FAQ

Q1：这个技能怎么安装？装完怎么知道成功？

A：在支持技能机制的 AI 编码环境中检索 writing-plans 或技能 ID 13639，按官方说明完成安装与启用；具体命令、路径与入口以官方说明为准。验证方式是提出一个设计需求，看 AI 是否先输出「我正在使用编写计划技能来创建实施计划。」这句声明，并产出含精确路径与步骤的计划文档。

Q2：它是收费的吗？

A：技能详情内容中未涉及任何定价信息，是否收费取决于你使用的技能分发平台或环境，请以官方说明为准。

Q3：适合谁用？个人开发用得上吗？

A：最适合三类人：需要把工作交出去的技术负责人、使用 AI 编码代理做并行开发的工程师、以及独立开发者。个人开发同样受益——把计划写清等于强迫自己提前想清楚文件边界和验证方式，只是收益不如多人协作场景那么立竿见影。

Q4：它能替代设计讨论吗？

A：不能。该技能的前提是「设计已完成」，它负责把设计翻译成可执行动作，而不是产出设计本身。建议先用头脑风暴类环节定方案，再进入计划阶段。

Q5：和通用 AI 直接写开发步骤相比，怎么选？

A：如果只是自己快速写个小脚本，直接对话更省事；只要涉及交接、多人并行或子代理执行，就应选用 writing-plans——它的硬性规范（精确路径、完整代码、命令与预期输出、每任务一次提交）正是防止执行走样的关键。计划生成后，可按需选择子代理驱动（superpowers:subagent-driven-development）或并行会话（superpowers:executing-plans）两条执行路线。