SPEC 到标准 PRD 生成 Skill
1. Skill 定位
本 Skill 用于将用户提供的 SPEC 与用户已有的 PRD 标准模板 结合，生成一份可研发、可测试、可评审的完整 PRD。
本 Skill 的核心原则是：
不直接拿 SPEC 填 PRD 模板，而是先把 SPEC 转换成结构化需求材料，再映射进用户的 PRD 标准模板，最后按模板反查缺口。
2. 适用场景
适用于以下情况：
- 用户已有一份 SPEC；
- 用户已有一套固定 PRD 标准模板；
- 用户希望 AI 按团队标准输出完整 PRD；
- 用户希望降低 AI 扩写 PRD 时的幻觉；
- 用户希望输出内容能被研发、测试、项目经理直接使用；
- 用户希望建立标准化的 SPEC → PRD 工作流。
3. 输入要求
使用本 Skill 时，建议用户至少提供以下资料：
3.1 必需输入
| 输入项 | 说明 |
|---|---|
| SPEC | 包含 Problem Statement、Proposed Solution、Technical Constraints、Non-goals、Success Criteria 等内容 |
| PRD 标准模板 | 用户团队内部使用的 PRD 标准目录、章节说明或示例模板 |
3.2 可选输入
| 输入项 | 说明 |
|---|---|
| 原型截图 / HTML 原型 | 用于辅助识别页面结构、交互逻辑、字段和按钮 |
| 客户沟通记录 | 用于补充业务背景、边界和真实诉求 |
| 历史 PRD 示例 | 用于对齐用户团队的写作风格和颗粒度 |
| 业务规则补充说明 | 用于补充计算口径、权限、流程和异常规则 |
4. 总体执行流程
本 Skill 必须分为三个阶段执行：
text
阶段一：基于 SPEC 做中间结构化分析
↓
阶段二：将中间分析结果映射到用户的 PRD 标准模板
↓
阶段三：按用户 PRD 模板进行完整性自检禁止直接从 SPEC 跳到完整 PRD。
4.1 阶段产物输出总规则
本 Skill 执行时，每个阶段必须输出对应产物，不得只在聊天中展示过程内容。
4.1.1 产物格式要求
所有阶段产物统一使用 Markdown 格式，文件后缀必须为：
text
.md禁止输出为 .docx、.pdf、.txt、.html 等其他格式，除非用户另行明确要求。
4.1.2 产物编号要求
所有产物必须按照生成顺序，在产物名称前增加两位数字编号。
命名规则：
text
{两位数字编号}_{产物名称}.md示例：
text
01_SPEC中间结构化分析稿.md
02_完整PRD.md
03_PRD完整性检查报告.md
04_待确认事项清单.md编号必须连续，不允许出现无编号产物。
4.1.3 输出目录要求
所有产物必须输出至用户指定目录下。
用户指定目录时，按用户指定目录输出，例如：
text
用户指定目录/
├── 01_SPEC中间结构化分析稿.md
├── 02_完整PRD.md
├── 03_PRD完整性检查报告.md
└── 04_待确认事项清单.md如用户未指定目录，则默认输出至当前项目目录下的：
text
spec-to-prd-output/4.1.4 阶段与产物对应关系
| 阶段 | 必须输出的产物 | 文件名 | 产物说明 |
|---|---|---|---|
| 阶段一 | SPEC 中间结构化分析稿 | 01_SPEC中间结构化分析稿.md |
承载 SPEC 完整性检查、业务对象、角色场景、流程、状态机、页面清单、字段、动作、权限、验收与待确认事项 |
| 阶段二 | 完整 PRD | 02_完整PRD.md |
严格按照用户 PRD 标准模板生成的完整 PRD |
| 阶段三 | PRD 完整性检查报告 | 03_PRD完整性检查报告.md |
对完整 PRD 进行模板覆盖、页面闭环、字段闭环、动作闭环、状态闭环、权限闭环、异常与验收检查 |
| 汇总产物 | 待确认事项清单 | 04_待确认事项清单.md |
汇总所有阶段发现的待确认问题，便于用户集中确认 |
4.1.5 输出完成后的反馈要求
完成后必须向用户返回产物清单，并提供可下载的 Markdown 文件。
返回格式建议：
text
已完成以下 Markdown 产物：
1. 01_SPEC中间结构化分析稿.md
2. 02_完整PRD.md
3. 03_PRD完整性检查报告.md
4. 04_待确认事项清单.md
输出目录：用户指定目录 / spec-to-prd-output/如当前环境支持文件链接，应提供每个 .md 文件的下载链接。
阶段一：SPEC 中间结构化分析
5. 阶段一目标
阶段一不生成完整 PRD，只做结构化分析。
目标是把 SPEC 中的自然语言，拆解成后续 PRD 可承载的结构化材料，包括：
- 业务对象；
- 角色与场景；
- 主流程与异常流程；
- 状态机；
- 页面清单；
- 页面级功能清单；
- 字段字典与计算口径；
- 关键操作动作规格；
- 权限与数据范围；
- 验收标准；
- 待确认事项。
6. 阶段一执行指令
当用户调用本 Skill 后，先执行以下分析：
text
请不要直接生成完整 PRD。
请先基于用户提供的 SPEC 完成以下中间分析：
1. SPEC 完整性检查；
2. 业务对象拆解；
3. 角色与使用场景拆解；
4. 主流程和异常流程拆解；
5. 状态机设计；
6. 页面清单设计；
7. 页面级功能清单设计；
8. 字段字典和计算口径设计；
9. 关键操作动作规格设计；
10. 权限与数据范围设计；
11. 验收标准拆解；
12. 待确认事项汇总。
要求：
- 不允许扩展 SPEC 未提到的业务范围；
- 不明确的地方标记为【待确认】；
- 不要为了填满模板而自行脑补；
- 所有输出必须服务于后续 PRD 生成；
- 分析结果要能被研发和测试理解。7. 阶段一输出结构
阶段一必须输出独立 Markdown 产物：
text
01_SPEC中间结构化分析稿.md该产物必须按以下结构输出。
7.1 SPEC 完整性检查
| 检查项 | 是否具备 | 当前内容摘要 | 缺口 / 待确认 |
|---|---|---|---|
| Problem Statement 问题陈述 | 是 / 否 / 部分具备 | ||
| Proposed Solution 方案描述 | 是 / 否 / 部分具备 | ||
| Technical Constraints 技术约束 | 是 / 否 / 部分具备 | ||
| Non-goals 非目标 | 是 / 否 / 部分具备 | ||
| Success Criteria 成功标准 | 是 / 否 / 部分具备 |
7.2 业务对象拆解
| 业务对象 | 业务含义 | 关键字段 | 与其他对象关系 | 是否需要落库 | 备注 |
|---|
示例对象包括但不限于：
- 用户；
- 单据；
- 任务；
- 审批记录；
- 附件；
- 状态；
- 配置项；
- 统计结果；
- 导入记录；
- 操作日志。
7.3 角色与使用场景拆解
| 角色 | 使用场景 | 目标 | 可执行动作 | 数据范围 | 备注 |
|---|
7.4 主流程
使用步骤化方式输出：
text
1. 用户进入页面；
2. 用户发起操作；
3. 系统进行校验；
4. 系统保存数据；
5. 状态发生变化；
6. 用户查看处理结果。如存在复杂流程，补充 Mermaid 流程图：
通过
不通过
开始
用户提交
系统校验
保存数据
提示错误
结束
7.5 异常流程
| 异常场景 | 触发条件 | 系统处理 | 用户提示 | 是否允许继续 | 备注 |
|---|
7.6 状态机
| 状态 | 状态含义 | 进入条件 | 可执行动作 | 下一状态 | 备注 |
|---|
如存在多状态流转，补充 Mermaid 状态图：
提交
进入审核
审核通过
审核驳回
草稿
已提交
审核中
已通过
已驳回
7.7 页面清单
| 页面名称 | 页面目标 | 使用角色 | 入口 | 是否核心页面 | 备注 |
|---|
7.8 页面级功能清单
每个页面必须按以下结构拆解：
text
页面名称：
页面目标：
使用角色：
页面入口：
一、查询条件
- 字段名称：
- 字段类型：
- 默认值：
- 是否必填：
- 查询规则：
二、列表字段 / 展示字段
- 字段名称：
- 字段来源：
- 展示规则：
- 空值规则：
三、按钮动作
- 按钮名称：
- 显示条件：
- 可用条件：
- 点击后系统行为：
- 成功反馈：
- 失败反馈：
四、业务规则
- 规则 1：
- 规则 2：
五、边界规则
- 权限边界：
- 状态边界：
- 数据边界：
- 异常边界：
六、验收口径
- 验收点 1：
- 验收点 2：7.9 字段字典与计算口径
| 字段名称 | 字段含义 | 字段类型 | 字段来源 | 是否必填 | 校验规则 | 是否参与计算 | 备注 |
|---|
计算口径必须单独输出：
text
计算项名称：
计算公式：
参与字段：
空值处理：
异常值处理：
是否实时计算：
是否保存结果：7.10 关键操作动作规格
每个关键动作必须按以下结构输出：
text
动作名称：
动作入口：
使用角色：
前置条件：
点击后系统行为：
成功结果：
失败结果：
状态变化：
权限要求：
是否记录日志：
验收标准：7.11 权限与数据范围
| 功能 / 动作 | 角色 A | 角色 B | 角色 C | 数据范围 | 备注 |
|---|
权限说明必须区分：
- 页面可见权限；
- 按钮操作权限；
- 数据查看范围；
- 数据编辑范围；
- 特殊业务动作权限。
7.12 验收标准拆解
| 验收项 | 验收标准 | 前置条件 | 测试数据 | 预期结果 |
|---|
7.13 待确认事项
| 编号 | 待确认问题 | 影响范围 | 建议确认对象 | 优先级 |
|---|
阶段二：映射到用户 PRD 标准模板
8. 阶段二目标
阶段二的目标是把阶段一的结构化分析结果，严格归位到用户提供的 PRD 标准模板中，生成完整 PRD。
此阶段的核心要求是：
保持用户 PRD 模板目录结构不变，只把阶段一的内容映射进去，不擅自改变模板章节。
9. 阶段二执行指令
text
请将阶段一的中间分析结果，严格映射到用户提供的 PRD 标准模板中，生成完整 PRD。
要求：
1. 保持用户 PRD 模板目录结构不变；
2. 每个章节只填入与该章节相关的内容；
3. 如果某章节缺少必要信息，不要编造，标记为【待确认】；
4. 不允许新增 SPEC 未覆盖的业务范围；
5. 不允许因为模板中存在章节，就强行扩展需求；
6. 页面说明必须包含页面目标、查询条件、列表字段、按钮动作、业务规则、边界规则、验收口径；
7. 操作动作必须写清楚入口、前置条件、系统行为、成功结果、失败结果、权限要求、是否留痕；
8. 权限说明必须明确角色、动作、数据范围；
9. 状态流转必须明确状态含义、进入条件、可执行动作和下一状态；
10. 验收标准必须可测试、可判断、可复现。10. 映射关系参考
如用户模板未明确要求，可按以下映射关系处理：
| 阶段一分析内容 | 映射到 PRD 模板章节 |
|---|---|
| SPEC 完整性检查 | 需求背景、需求目标、适用范围、非目标、待确认事项 |
| 业务对象拆解 | 业务对象说明、数据模型说明、字段说明 |
| 角色与场景拆解 | 角色说明、使用场景、权限说明 |
| 主流程 / 异常流程 | 业务流程、操作流程、异常处理 |
| 状态机 | 状态流转说明、按钮状态规则 |
| 页面清单 | 功能结构、菜单结构、页面结构 |
| 页面级功能清单 | 页面功能说明、查询条件、列表字段、按钮动作 |
| 字段字典 / 计算口径 | 字段说明、统计口径、校验规则 |
| 操作动作规格 | 操作交互说明、按钮行为、弹窗规则 |
| 权限与数据范围 | 角色权限矩阵、数据范围规则 |
| 验收标准 | 验收标准、测试关注点 |
| 待确认问题 | 待确认事项、风险说明 |
11. 阶段二输出要求
阶段二必须输出独立 Markdown 产物：
text
02_完整PRD.md阶段二输出完整 PRD 时，必须遵循以下要求：
11.1 模板优先
- 以用户提供的 PRD 模板目录为准；
- 不随意重排章节；
- 不删除模板章节；
- 不新增无必要章节；
- 如模板章节无内容支撑，标记【待确认】或【本期不涉及】。
11.2 内容归位
- 流程内容放入流程章节；
- 页面内容放入页面章节；
- 字段内容放入字段章节；
- 权限内容放入权限章节；
- 异常内容放入异常章节；
- 验收内容放入验收章节。
11.3 不脑补
以下内容缺失时必须标记【待确认】：
- 角色不明确；
- 权限不明确；
- 状态不明确；
- 字段来源不明确；
- 计算口径不明确；
- 审批节点不明确；
- 数据范围不明确；
- 异常处理方式不明确；
- 是否需要留痕不明确；
- 是否需要导入导出不明确。
阶段三：按模板进行完整性自检
12. 阶段三目标
阶段三用于检查刚生成的 PRD 是否真正可用。
检查目标包括：
- 模板章节是否完整；
- 是否存在空泛描述；
- 页面、字段、按钮、状态、权限、异常、验收是否闭环；
- 是否存在 AI 自行扩展；
- 是否存在研发无法实现的内容；
- 是否存在测试无法验收的内容；
- 是否存在待确认事项未标记。
13. 阶段三执行指令
text
请基于用户提供的 PRD 标准模板，对刚生成的 PRD 做完整性检查。
检查维度包括：
1. 模板章节是否全部覆盖；
2. 是否存在空泛描述；
3. 页面是否有页面目标、查询条件、字段、按钮、规则、边界、验收；
4. 字段是否有来源、类型、必填、校验、展示和计算规则；
5. 按钮动作是否有入口、前置条件、系统行为、成功结果、失败结果和权限要求；
6. 状态流转是否明确状态含义、进入条件、可执行动作和下一状态；
7. 权限是否明确角色、动作和数据范围；
8. 异常处理是否覆盖主要失败场景；
9. 验收标准是否可测试、可判断、可复现；
10. 是否存在超出 SPEC 范围的扩展内容；
11. 是否存在应标记但未标记的【待确认】事项；
12. 是否存在研发实现风险或测试验收风险。
请输出：
- 完整性检查结论；
- 问题清单；
- 修改建议；
- 待确认事项；
- 是否建议进入研发评审。14. 阶段三输出结构
阶段三必须输出独立 Markdown 产物：
text
03_PRD完整性检查报告.md同时必须从阶段一、阶段二、阶段三中抽取全部待确认事项，单独输出汇总产物：
text
04_待确认事项清单.md14.1 总体结论
text
PRD 完整性结论：
- 是否建议进入研发评审：
- 当前主要风险：
- 当前最需要补充的内容：14.2 模板章节覆盖检查
| 模板章节 | 是否已覆盖 | 内容质量 | 问题说明 | 修改建议 |
|---|
内容质量可使用：
- 完整；
- 基本完整；
- 偏空泛；
- 缺失；
- 待确认。
14.3 页面闭环检查
| 页面名称 | 页面目标 | 查询条件 | 字段 | 按钮 | 规则 | 边界 | 验收 | 问题 |
|---|
14.4 字段闭环检查
| 字段名称 | 来源 | 类型 | 必填 | 校验 | 展示 | 计算 | 问题 |
|---|
14.5 动作闭环检查
| 动作名称 | 入口 | 前置条件 | 系统行为 | 成功结果 | 失败结果 | 权限 | 留痕 | 问题 |
|---|
14.6 状态闭环检查
| 状态 | 状态含义 | 进入条件 | 可执行动作 | 下一状态 | 问题 |
|---|
14.7 权限闭环检查
| 角色 | 页面权限 | 操作权限 | 数据范围 | 特殊动作权限 | 问题 |
|---|
14.8 异常与边界检查
| 异常场景 | 是否覆盖 | 当前处理方式 | 问题 | 修改建议 |
|---|
14.9 验收标准检查
| 验收项 | 是否可测试 | 是否可判断 | 是否可复现 | 问题 | 修改建议 |
|---|
14.10 超范围内容检查
| 内容 | 是否超出 SPEC | 风险 | 处理建议 |
|---|
14.11 待确认事项汇总
| 编号 | 待确认事项 | 影响章节 | 影响程度 | 建议确认对象 |
|---|
15. 防幻觉规则
使用本 Skill 时，必须遵守以下规则：
15.1 不直接扩写
禁止直接从 SPEC 生成完整 PRD，必须先完成阶段一结构化分析。
15.2 不替用户做业务决策
以下内容不明确时，必须标记【待确认】：
- 角色权限；
- 审批节点；
- 状态流转；
- 数据范围；
- 计算口径；
- 导入覆盖规则；
- 删除规则；
- 是否需要留痕；
- 是否需要消息通知；
- 是否需要导出；
- 异常处理方式。
15.3 不因模板存在而扩展需求
模板中有"审批流"章节，不代表当前需求一定需要审批流。
模板中有"导入导出"章节，不代表当前需求一定需要导入导出。
模板中有"消息通知"章节，不代表当前需求一定需要消息通知。
如当前 SPEC 未提及，应写：
text
本期不涉及。SPEC 未提出该能力，不纳入本次 PRD 范围。或：
text
【待确认】SPEC 未明确是否需要该能力，需由产品经理确认后再补充。15.4 区分"本期范围"和"未来扩展"
如发现合理但 SPEC 未覆盖的能力，不得直接写入本期 PRD。
应放入：
text
后续可扩展能力 / 非本期范围 / 待确认事项15.5 避免空泛描述
以下描述视为空泛，必须改写：
| 空泛描述 | 应改为 |
|---|---|
| 系统进行校验 | 校验哪些字段、什么条件通过、失败如何提示 |
| 用户可以查询 | 按哪些条件查询、默认值是什么、是否支持组合查询 |
| 支持导出 | 导出入口、导出范围、导出字段、文件格式、权限要求 |
| 支持审批 | 审批节点、审批人、审批动作、状态变化、驳回规则 |
| 支持统计 | 统计对象、统计维度、计算公式、刷新规则、空值规则 |
| 支持通知 | 通知触发条件、接收人、通知内容、跳转目标、已读规则 |
16. 输出质量标准
生成的 PRD 必须达到以下标准：
16.1 研发可实现
研发可以从 PRD 中明确知道：
- 有哪些页面；
- 有哪些字段；
- 有哪些按钮；
- 每个按钮点击后发生什么；
- 数据从哪里来；
- 状态怎么变化；
- 权限怎么控制；
- 异常怎么处理。
16.2 测试可验收
测试可以从 PRD 中明确知道：
- 每个功能怎么测；
- 输入什么数据；
- 预期输出什么；
- 异常场景怎么测；
- 权限场景怎么测；
- 状态流转怎么测。
16.3 客户可确认
客户或业务方可以从 PRD 中明确知道：
- 本期做什么；
- 本期不做什么；
- 页面怎么用；
- 规则怎么算；
- 异常怎么提示；
- 成功标准是什么。
16.4 产品可追溯
产品经理可以从 PRD 中追溯：
- 需求来源；
- SPEC 对应关系；
- 待确认问题；
- 范围边界；
- 规则依据；
- 后续扩展点。
17. 推荐调用方式
用户可直接输入：
text
调用 spec-to-prd-template-skill。
我将提供：
1. SPEC；
2. PRD 标准模板；
3. 可选的原型 / 截图 / 业务补充；
4. 输出目录。
请严格按以下三阶段执行：
阶段一：先做 SPEC 中间结构化分析，不生成完整 PRD；
阶段二：将阶段一结果映射到我的 PRD 标准模板，生成完整 PRD；
阶段三：按我的 PRD 模板进行完整性自检，输出问题清单和修改建议。
要求：
- 不允许扩展 SPEC 未提到的业务范围；
- 不明确的地方标记为【待确认】；
- 保持我的 PRD 模板目录结构不变；
- 输出必须能支撑研发实现和测试验收；
- 每个阶段必须输出独立 Markdown 产物；
- 产物必须按顺序编号命名，并输出至我指定的目录下。18. 推荐输出物
本 Skill 最终必须输出以下四类 Markdown 产物，且必须按顺序编号：
| 编号 | 输出物 | 文件名 | 说明 |
|---|---|---|---|
| 01 | SPEC 中间结构化分析稿 | 01_SPEC中间结构化分析稿.md |
阶段一输出，用于确认需求结构是否完整 |
| 02 | 完整 PRD | 02_完整PRD.md |
阶段二输出，严格按用户 PRD 标准模板生成 |
| 03 | PRD 完整性检查报告 | 03_PRD完整性检查报告.md |
阶段三输出，用于研发评审前自检 |
| 04 | 待确认事项清单 | 04_待确认事项清单.md |
汇总所有无法从 SPEC 和模板中确认的问题 |
所有产物必须输出至用户指定目录下；若用户未指定目录，默认输出至 spec-to-prd-output/。
19. 执行时的交互策略
19.1 用户资料足够时
如果用户已经提供 SPEC 和 PRD 模板，则直接执行三阶段。
19.2 用户缺少 PRD 模板时
提示用户补充 PRD 标准模板。
如用户暂时没有模板，可使用默认结构临时承载，但必须说明：
text
当前未提供团队 PRD 标准模板，以下将使用默认 PRD 结构临时输出。后续用户提供模板后，可重新映射。19.3 用户缺少 SPEC 时
提示用户补充 SPEC。
如用户只有模糊描述，应先帮助用户生成 SPEC，再进入本 Skill。
19.4 用户要求直接输出完整 PRD 时
仍然必须执行阶段一和阶段三，但可以把阶段一作为"生成依据"放在 PRD 前，或在最终文档中折叠为"分析过程"。
20. 最终交付格式要求
默认必须采用"多 Markdown 文件"方式交付，每个阶段对应独立产物。
20.1 多文件交付结构
如用户指定输出目录为 用户指定目录/，则最终输出结构必须为：
text
用户指定目录/
├── 01_SPEC中间结构化分析稿.md
├── 02_完整PRD.md
├── 03_PRD完整性检查报告.md
└── 04_待确认事项清单.md20.2 单文件交付结构
只有在用户明确要求"合并为一个 Markdown 文档"时，才允许输出单文件。
单文件也必须带编号，命名为：
text
01_SPEC到PRD完整交付包.md单文件内部结构必须为：
text
# SPEC 到 PRD 完整交付包
## 第一部分：SPEC 中间结构化分析稿
## 第二部分：完整 PRD
## 第三部分：PRD 完整性检查报告
## 第四部分：待确认事项清单20.3 下载交付要求
完成生成后，必须返回可下载的 Markdown 文件。
如果是多文件输出，应返回所有 .md 文件下载链接；如当前环境支持压缩包，也可额外提供压缩包，但不能替代 Markdown 源文件。
21. 一句话原则
SPEC 是需求边界，PRD 模板是文档容器，中间结构化分析是从"想法"变成"可开发契约"的关键步骤。任何时候都不能跳过中间分析直接套模板。