| name | plan-spec |
| description | 需求规格评审。Use when 启动新项目/新功能、需求还模糊、在任务拆分或写代码之前,需要先和用户对齐需求边界并产出结构化 Spec 时。也适用于用户给的需求一句话太笼统、缺少边界与非功能性要求的场景。 |
Plan-Spec:需求规格评审
概述
和用户一起过需求,确保双方理解一致,产出一份结构化 Spec 文档作为后续拆分(plan-breakdown)的输入。
核心原则: 标准前置。写代码之前先把「要做什么、不做什么、做到什么程度」说清楚,避免后期返工。
何时使用
- 启动新项目,或在已有项目里加一块新功能
- 用户的需求是一句话/一段话,缺少边界、异常场景、非功能性要求
- 准备拆 Epic/Milestone/Issue 之前(Spec 是拆分的前置输入)
何时不用:
- 需求已有清晰 Spec → 直接用 plan-breakdown 拆分
- 极小改动(改文案、修单个 bug)→ 不必走完整 Spec
流程
- 理解目标 — 让用户用自然语言说清:做什么、给谁用、核心功能有哪些。
- 像产品经理一样追问 — 一次问一个问题,聚焦三类边界:
- 边界条件:什么明确不在范围内
- 异常场景:出错/极端输入怎么处理
- 非功能性需求:性能、安全、可维护性
- 确认技术约束 — 语言、框架、部署环境、已有技术栈是否必须沿用。
- 产出结构化 Spec — 按下方模板填写,逐项与用户确认。
- 交接 — Spec 经用户确认后,提示进入 plan-breakdown 做任务拆分。
产出
一份 Spec 文档(Markdown,约 200-500 字),使用 templates/spec-template.md 模板,包含:
- 一句话描述(是什么 + 给谁用)
- 核心功能列表
- 边界条件(不在范围内)
- 非功能性需求(性能 / 安全 / 可维护性)
- 技术约束(语言 / 框架 / 部署环境)
- 验收总纲(P0 级,项目层面的阻塞性标准)
保存位置建议:docs/spec/<项目名>.md。
提示词参考
我想做一个【XXX】。请你像产品经理一样向我提问(一次一个问题),帮我澄清需求边界、异常场景和非功能性需求。问完后,输出一份结构化 Spec 文档,包括一句话描述、核心功能、边界条件、非功能性需求、技术约束、P0 验收总纲。
常见错误
- 跳过追问直接写 Spec → Spec 反映的是你的假设而非用户真实意图。必须先问后写。
- 一次抛一堆问题 → 用户难以回答。一次问一个,逐步收敛。
- 把 Spec 写成需求清单堆砌 → 缺「边界条件」和「不做什么」,后期范围蔓延。边界必须显式写。
- 范围过大 — 若需求横跨多个独立子系统,先帮用户拆成子项目,每个子项目各走一遍 Spec → 拆分 → 实现。
参考
- 模板:
templates/spec-template.md
- 下一步:
skills/plan-breakdown/SKILL.md(把 Spec 拆成 Epic → Milestone → Issue)
- 方法论出处:唯一真源
docs/AI 编程方法论 v1.2 — 可操作版.md 第 1.1 节