Product brief builder

产品决策简报生成器

把产品材料整理为能支持团队决策的短文档。不要用完整感掩盖未知，不要替团队虚构共识。

先确定文档用途

识别当前阶段：

• 探索：问题是否真实、值得解决。
• 立项：是否投入资源、目标是什么。
• 范围：第一版做什么、不做什么。
• 交付：流程、状态和验收标准是否清楚。
• 评审：需要暴露风险、争议和未决决定。

同一份简报只服务一个主要决策。

提取事实

从用户材料中分离：

• 用户或客户直接表达的事实。
• 行为数据与业务数据。
• 团队观察。
• 解决方案设想。
• 未经验证的假设。
• 已做决定与尚未决定的事项。

不要把解决方案描述改写成用户问题。例如“需要 AI 分类”不是问题，“内容增长后人工分类耗时且不一致”才可能是问题。

简报结构

1. 决策句

一句话说明团队需要决定什么，以及为什么现在决定。

2. 用户问题

说明谁在什么场景遇到什么阻碍，现有替代方式是什么。只写有证据支持的内容。

3. 证据与缺口

用两栏区分：

• 已知：数据、访谈、工单、观察或政策要求。
• 未知：需要进一步验证的问题。

4. 目标和信号

• 用户结果：用户能够完成什么。
• 业务结果：为什么值得投入。
• 成功信号：上线后观察什么。
• 失败信号：什么情况说明方向不成立。

5. 最小范围

列出第一版必须具备的能力和明确不做项。每个范围项都应回到用户问题或风险。

6. 核心流程

按“触发 → 用户动作 → 系统反馈 → 完成/失败”描述主流程。覆盖空状态、错误状态和权限状态。

7. 验收条件

使用可验证表达：给定什么条件，用户做什么，系统产生什么可观察结果。不要用“体验良好”“性能优秀”。

8. 假设、风险与未决问题

对每一项标注负责人或验证动作。不能确认的信息保持为未知。

输出格式

# 产品简报：名称

## 本次决策
## 用户问题
## 已知证据与未知问题
## 目标与成功/失败信号
## 第一版范围
## 明确不做
## 核心流程与状态
## 验收条件
## 假设与风险
## 未决问题
## 下一步

简报默认控制在 1,500 字以内；复杂项目可以附录扩展，但主决策必须保持可扫描。

审查规则

• 每个功能都能追溯到问题、证据或风险。
• 每个指标都说明对象和时间窗口。
• 每个假设都没有被写成事实。
• “不做项”足够具体，能阻止范围漂移。
• 关键错误、空状态和权限边界没有遗漏。
• 技术方案只在影响产品决策时出现。

边界

• 不伪造用户研究、市场数据、负责人或交付日期。
• 不把估算当承诺。
• 不代替法律、安全、隐私或财务专业评审。
• 不为了文档完整而补写用户未确认的需求。