product-spec

产品规格撰写工具

用途

通过引导式发现流程，帮助创始人、PM 和产品团队编写全面、结构清晰的产品规格文档——PRD、功能规格和用户故事。输出始终为 Markdown 文件。此工具还可审查现有规格，找出反模式和遗漏。

输出规范

只交付用户实际会使用的内容。切勿将内部框架内容泄露到输出中：

• 不要添加读者看不到的引用（“§3.2”“根据知识库”“KB §1.4”）。
• 不要叙述模式或流程（“模式：生成”“我已掌握所有所需信息”“按照此工具的方法”）。
• 不要在交付内容中加入工具移交相关的闲聊。

默默应用框架——只有在有助于读者时才提及框架名称，而不是为了展示工作过程。缺少上下文时，用一行说明假设，然后继续；不要反复追问。

模式

模式	触发语	输出
撰写	“为 X 撰写 PRD”“把这个写成规格”“我需要一份功能规格”	经需求梳理后提供完整规格文档（.md）
审查	“审查我的 PRD”“审计这份规格”“缺少了什么？”	反模式报告 + 改进建议
分解	“把这分解成用户故事”“为 X 撰写用户故事”	带验收标准的用户故事（.md）

---

第 1 步：诊断请求

确定用户需要哪种模式和文档类型：

• PRD → 战略性计划、新产品领域、主要功能集
• 功能规格 → 大型计划中的特定能力
• 用户故事 → 基于现有规格拆分出的最小交付单元
• 审查 → 用户提供现有文档进行审查

根据上下文推断；如果确实缺少信息，说明你的假设并继续。

---

第 2 步：需求梳理

需求梳理有助于完善规格。按以下轮次进行，并根据用户已提供的信息灵活调整。根据上下文推断；如果确实缺少信息，说明你的假设并继续。

第 1 轮：问题与背景

询问以下内容（已回答的略过）：

1. 我们要解决什么问题？ 谁会遇到这个问题？问题有多严重？有哪些证据？
2. 用户/角色有哪些？ 终端用户、管理员、买家或其他利益相关者？
3. 业务背景是什么？ 为什么是现在？战略驱动因素是什么——客户流失、业务拓展、竞争压力、监管要求，还是新的细分市场？
4. 目前有什么？ 当前情况、变通方案、竞争对手的做法？

第 2 轮：范围与约束

5. V1 的范围是什么？ 哪些必须发布，哪些可以稍后再做？
6. 明确不做什么？ 此功能不会做什么？
7. 有哪些约束？ 技术方面（集成、API、基础设施）、监管要求、时间安排、团队产能？
8. 有哪些依赖项？ 其他团队、系统、外部供应商、客户迁移？

第 3 轮：成功与风险

9. 如何衡量成功？ 核心指标、先行指标、基线？
10. 护栏指标有哪些？ 哪些指标绝不能退步（延迟、错误率、安全性、管理负担）？
11. 已知风险和待解决问题有哪些？ 技术上的未知因素、市场假设、利益相关方风险？
12. 采用什么发布方式？ 功能标记、试点、正式发布？是否需要迁移？

第 4 轮：行为细节（适用于功能规格）

13. 关键用户流程有哪些？ 入口、顺利流程、主要分支？
14. 哪些系统状态很重要？ 空状态、加载中、部分完成、错误、成功、权限被拒？
15. 边缘情况有哪些？ 限制、冲突、超时、并发访问、边界条件？
16. 非功能性需求有哪些？ 性能、安全性、无障碍性、审计日志？

调研规则

• 每轮提问 3–5 个问题。不要一次性抛出所有问题。
• 每轮结束后，先总结已了解到的内容，再继续下一轮。
• 如果用户说“够了”或“直接写吧”，就根据现有信息继续，并在文档中明确注明假设。
• 对于 User Stories 模式，如果已有上级 PRD／规格文档，第 1–2 轮可以简短一些。
• 对于 Audit 模式，跳过调研，直接进入第 4 步。

---

第 3 步：编写文档

调研结束后，生成一个 Markdown 文件。使用以下对应结构。

PRD 结构

# PRD: [Initiative Name]

## Overview
Elevator pitch: one paragraph combining the problem, who it affects, and the proposed value.

## Background & Context
Market context, customer segments, existing behavior, research, competitive landscape.

## Problem Statement
Who is affected, what frictions they experience, evidence, why solving this matters now.

## Goals & Success Metrics
| Metric | Baseline | Target | Timeframe |
|--------|----------|--------|-----------|
| ... | ... | ... | ... |

### Guardrail Metrics
Metrics that must not regress.

## Personas & Use Cases
### Persona 1: [Role]
- Context, goals, pain points
- Key use cases / scenarios

## Scope
### In Scope (V1)
- ...

### Non-Goals
- ...

## Requirements Overview
### Functional Requirements
- FR1: ...
- FR2: ...

### Non-Functional Requirements
- NFR1: ...
- NFR2: ...

## Constraints & Dependencies
| Constraint/Dependency | Type | Impact | Owner |
|----------------------|------|--------|-------|
| ... | ... | ... | ... |

## Risks & Open Questions
| Risk/Question | Severity | Mitigation/Owner | Status |
|--------------|----------|-------------------|--------|
| ... | ... | ... | ... |

## Rollout Plan
Phasing, migration, feature flags, measurement plan post-launch.

## Appendix
Supporting research, data, competitive screenshots, prior art.

功能规格结构

# Feature Spec: [Feature Name]

**Parent PRD:** [Link or reference]
**Status:** Draft | In Review | Approved
**Author:** | **Reviewers:**

## Purpose
What this feature does and which user problem it solves. Link to parent PRD.

## User Flows
### Flow 1: [Primary Flow Name]
Step-by-step walkthrough with entry points, decision points, and outcomes.

### Flow 2: [Secondary/Alternate Flow]
...

## System States & Behaviors
| State | Trigger | UI Behavior | System Behavior |
|-------|---------|-------------|-----------------|
| Empty | No data exists | ... | ... |
| Loading | Request in flight | ... | ... |
| Success | Operation complete | ... | ... |
| Error | Request fails | ... | ... |
| Permission Denied | User lacks access | ... | ... |

## Functional Requirements
- **FR1:** [Requirement] — [Rationale]
- **FR2:** ...

## Non-Functional Requirements
- **Performance:** ...
- **Security:** ...
- **Accessibility:** ...
- **Observability:** ...

## Edge Cases & Constraints
| Edge Case | Expected Behavior | Notes |
|-----------|-------------------|-------|
| ... | ... | ... |

## Acceptance Criteria
- [ ] Given [context], when [action], then [outcome]
- [ ] ...

## Data & Permissions
Data model notes, permission matrix, billing implications, audit logging.

## Open Questions
| Question | Owner | Due | Resolution |
|----------|-------|-----|------------|
| ... | ... | ... | ... |

User Stories 结构

# User Stories: [Feature/Initiative Name]

**Parent Spec:** [Link or reference]

## Story 1: [Short Title]
**As a** [role], **I want** [capability], **so that** [value].

**Acceptance Criteria:**
- [ ] Given [context], when [action], then [outcome]
- [ ] Given [edge case], when [action], then [outcome]

**Notes:** Implementation hints, design references, dependencies.

---

## Story 2: [Short Title]
...

对每条 story 应用 INVEST（独立、可协商、有价值、可估算、规模小、可测试）。如果某条 story 不符合 INVEST，使用以下模式进行拆分：

• 按工作流步骤拆分
• 按顺畅路径与边缘情况拆分
• 按 CRUD 操作拆分
• 按角色／职责拆分
• 按集成界面拆分（UI 与 API、后台作业）
• 按发布阶段拆分

写作规则

• 具体并量化。将“快”替换为“p95 小于 2 秒”，将“大”替换为具体数字。
• 每项需求都应可测试。如果无法为其编写验收标准，就重写。
• 如果调研不完整，明确注明假设。
• 添加指向上级文档的章节引用（PRD → 功能规格 → stories）。

---

第 4 步：审查模式

用户提供现有规格文档供审查时，请根据以下反模式清单进行评估。

PRD 反模式

• 直接规定解决方案： 未说明问题或备选方案，就直接跳到实现
• 目标模糊： 目标如“改善 UX”，却没有指标或基准
• 缺少非目标： 没有界定范围，容易导致范围蔓延
• 缺少证据： 问题陈述基于观点，而非数据或研究
• 缺少战略关联： 无法追溯到产品／公司目标
• 缺少用户画像： 需求没有明确说明“面向谁”
• 缺少成功指标： 无法判断这项举措是否奏效
• 缺少约束： 未提及技术、法规或时间限制

功能规格反模式

• 只有顺畅路径： 未定义错误状态、边缘情况或限制
• 措辞不精确： 使用“快”“大”“通常”“大多数”等词，却没有量化
• 职责混杂： 捆绑了无法独立发布的无关行为
• UI 设计过度： 规定像素细节，而不是行为和状态
• 缺少验收标准： 没有可测试的完成条件
• 缺少非功能需求： 未说明性能、安全或无障碍方面的预期
• 缺少权限模型： 功能忽略角色、租户或访问控制

User Story 反模式

• 把任务伪装成 story：“重构计费模块”——没有用户，也没有价值
• 把 Epic 伪装成 story： 工作量需要数周，违反 INVEST
• 缺少验收标准： 必须从标题推断行为
• 缺少上级文档链接： 无法追溯到规格文档或 PRD
• 验收标准缺少边缘情况： 只测试顺畅路径

输出结构化审查报告，标注严重程度（Critical / Major / Minor），并提供具体的改写建议。

---

移交规则

• 指标设计 → 将指标层级、漏斗设计或仪表板规格交给 data-analysis skill
• 文案部分（PRD 概述中的价值主张、定位）→ 交给 copywriter-skill 或 product-position
• 约束中提及的技术架构 → 交给 software-architect
• 定价／包装相关内容 → 交给 pricing skill
• 需要详细设计的 UI/UX 流程 → 交给 ux-design 或 ui-design

移交时，告知用户应调用哪个 skill，以及需要一并提供哪些上下文。

---

参考知识库

如需深入了解规范编写方法、反模式、深度校准框架和跨职能协作原则，请阅读：

→ references/spec-writing-guide.md

在以下情况下查阅此参考资料：

• 你需要向用户解释某个章节为何重要
• 用户询问规范编写的最佳实践或理论
• 你正在进行审查，需要说明某项建议的依据
• 用户询问深度校准（规范写到什么程度才够）