实施计划生成器

它解决什么问题

当你把一个需求丢给 AI agent 让它执行时，最常见的失败不是模型能力不够，而是计划本身写得太模糊。"优化一下性能""重构认证模块"——这类描述对人来说需要现场判断，对 agent 来说直接无法执行。结果就是反复澄清、任务间依赖混乱、验收标准缺失，最终产出的代码需要大量人工返工。

这个技能要解决的问题很具体：把模糊的意图转化为机器可直接执行的实施计划。它不是给你一份人类可读的文档，而是生成结构化的、确定性的任务清单，让下游 agent 或工程师拿到后不需要再问"接下来该做什么"。

它如何工作

技能的核心逻辑分为三个层次：

原子阶段拆分——每个阶段是一组可独立处理的任务。阶段之间默认无隐式依赖，只有在显式声明时才存在耦合。这意味着 agent 可以并行处理多个阶段，或在跳过某个阶段时不破坏整体上下文。

确定性任务描述——每条任务必须包含 文件路径、函数名、行号 级别的精确引用，而不是"修改相关代码"这种模糊表述。标识符统一使用 REQ-、TASK- 等前缀，便于自动解析和追踪。

自动验证的验收标准——每条任务都附带可机器验证的完成条件，而不是"功能正常"这种需要人工判断的描述。这使得下游系统可以在任务完成后自动确认，而不需要人工介入。

输出文件存放在 /plan/ 目录，遵循 [purpose]-[component]-[version].md 的命名规范，purpose 前缀包括 upgrade、refactor、feature、data、infrastructure、process、architecture、design 八种。每份计划的 front matter 中必须包含状态字段，值为 Completed、In progress、Planned、Deprecated 或 On Hold，对应不同颜色的徽章。

模板校验是强制的：所有 front matter 字段必须存在且格式正确，章节标题严格区分大小写，表格必须包含全部必需列，最终输出中不得残留任何占位符。

适用边界

这个技能的定位是 AI-to-AI 通信协议，不是给产品经理写汇报文档的工具。它生成的计划对人类来说可能显得过于冗长和机械，但对自动化执行链路来说这是必要的冗余。

需要注意的几点：

• 计划的"确定性"依赖于输入意图的清晰程度。如果原始需求本身就模糊，生成的计划只会把模糊性结构化，而不会消除它。
• 零歧义意味着输出可能看起来"啰嗦"——每条任务都要写全上下文、配置值、变量定义，这是为了让 agent 不需要回溯理解而设计的。
• 阶段间的并行假设需要依赖关系显式声明。如果实际存在隐式依赖但没在计划中标注，并行执行可能导致冲突。
• 不适合快速原型验证或探索性开发场景，这类场景的不确定性太高，强行结构化反而增加负担。