# Plan Spec

> 需求规格评审。Use when 启动新项目/新功能、需求还模糊、在任务拆分或写代码之前，需要先和用户对齐需求边界并产出结构化 Spec 时。也适用于用户给的需求一句话太笼统、缺少边界与非功能性要求的场景。

- Skill: `swustcyt/plan-spec` (Agent Skill)
- Install (CLI): `npx skillmds@latest add swustcyt/plan-spec`
- Raw SKILL.md: https://api.skillmd.com/api/skills/swustcyt/plan-spec/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: SWUSTcyt (https://skillmd.com/u/swustcyt)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/swustcyt/plan-spec

---


# Plan-Spec：需求规格评审

## 概述

和用户一起过需求，确保双方理解一致，产出一份结构化 Spec 文档作为后续拆分（plan-breakdown）的输入。

**核心原则：** 标准前置。写代码之前先把「要做什么、不做什么、做到什么程度」说清楚，避免后期返工。

## 何时使用

- 启动新项目，或在已有项目里加一块新功能
- 用户的需求是一句话/一段话，缺少边界、异常场景、非功能性要求
- 准备拆 Epic/Milestone/Issue 之前（Spec 是拆分的前置输入）

**何时不用：**

- 需求已有清晰 Spec → 直接用 plan-breakdown 拆分
- 极小改动（改文案、修单个 bug）→ 不必走完整 Spec

## 流程

1. **理解目标** — 让用户用自然语言说清：做什么、给谁用、核心功能有哪些。
2. **像产品经理一样追问** — 一次问一个问题，聚焦三类边界：
   - 边界条件：什么明确不在范围内
   - 异常场景：出错/极端输入怎么处理
   - 非功能性需求：性能、安全、可维护性
3. **确认技术约束** — 语言、框架、部署环境、已有技术栈是否必须沿用。
4. **产出结构化 Spec** — 按下方模板填写，逐项与用户确认。
5. **交接** — 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 节