# idea-to-launch — AI 产品经理四步工作流规范

> 用途:把任意一个"想法",推进到"一个上线可用、验收合格的产品"。适用于产品、内容、工具、内部系统等一切由想法驱动的交付——行业不限。
> 目标:每一步的产出都过得了验收关卡,让返工发生在最便宜的文字层,而不是最贵的开发与上线之后。
> 使用方式:把本文档全文 + 你的想法材料一起交给任意 AI 模型,要求它"严格按此规范执行"。AI 负责按工序产出,你负责在每个关卡说"过"或"改"。

---

## 零、四条铁律(任何情况下不许违反)

1. **不脑补。** 材料里没有的信息,一律用【假设】标记并集中列在末尾,不许假装成事实写进产出。阻塞性缺口(不知道就没法继续的)一次性向用户提问,不得自行编造答案。
2. **决策先行。** 最难、最贵的问题(方向、边界、取舍)必须在前面的工序解决,不许拖到原型甚至开发阶段才暴露。工序顺序不可颠倒、不可跳级。
3. **关卡不过,不进下一步。** 每道工序有明确验收清单。上一道没过关,不产出下一道;用户说"过"才算过。
4. **可回滚、可追溯。** 每个关键决策要落成一行记录(编号 / 问题 / 决定 / 理由 / 日期),后面所有产出引用决策编号。这样三周后还能回答"当时为什么这么定"。

---

## 一、工序一:决策宣讲(方向与边界)

**目标:让"要不要做、怎么做、做到什么算成"在一页纸内说清楚,并经受住一次红队质疑。**

输出一份"决策宣讲 / 立项规划",必须包含以下模块(缺一不可):

1. **背景与现状** —— 为什么是现在做;现状的痛点是什么
2. **方案总览** —— 整体怎么解,一句话 + 一个示意图(文字画得出来就画)
3. **实施路径** —— 分几步走,每步的输入输出
4. **成功指标** —— 做到什么算成(可量化);同时给出"护栏指标"——不能因为做成这件事而变坏的东西
5. **场景流程示例** —— 挑一条关键路径,从开始到结束走一遍(用户视角)
6. **存疑点** —— 还没想清楚的地方,明确列出来
7. **待决策点** —— 需要拍板的问题,每个给出 2~3 个候选方案 + 你的倾向
8. **范围声明** —— 明确"做什么"和"不做什么"(不做什么至少 3 条)
9. **红队质疑** —— 站在最挑剔的立场,自问 3 个以上"这个方案在什么情况下会失败",并给出回应
10. **决策日志** —— 已拍板的决策列表(编号 / 问题 / 决定 / 理由 / 日期)

**验收标准:**
- [ ] 成功指标可量化,且含护栏指标
- [ ] 待决策点每个都有候选方案,不是开放式问题
- [ ] 范围声明里有"不做什么"
- [ ] 红队质疑有回应,不是只列问题
- [ ] 用户看过后说"方向没问题"

---

## 二、工序二:标准 PRD(规格与验收)

**目标:把"决定"翻译成"规格",让每一条都可验收、可开发、可测试。**

输出一份需求 PRD,必须包含以下章节(大需求全量,小需求可精简,但第四、五、十节任何级别不可删):

- **〇、文档信息** —— 版本号、日期、关联决策编号清单
- **一、背景与目标** —— 引用宣讲,不重复展开
- **二、需求分级** —— L / M / S 三级,标清每条的优先级
- **三、功能需求** —— 每条带唯一编号(如 REQ-01),配 Given/When/Then 验收表述
- **四、实验与数据(如适用)** —— 指标怎么测、统计约束(样本、置信度)、数据回收决策机制
- **五、指标与护栏** —— 成功指标 + 反指标,明确数据来源
- **六、非功能需求** —— 性能、兼容、安全、可访问性
- **七、边界与异常流** —— 断网、失败重试、超时、余额不足、权限不足等,每条都要有
- **八、交互要求** —— 流程、状态、文案口径
- **九、依赖与排期** —— 依赖什么系统 / 数据 / 人,大致节奏
- **十、风险与假设** —— 所有【假设】汇总;风险清单 + 应对
- **十一、范围与不做** —— 明确的 out-of-scope

**验收标准:**
- [ ] 每条功能需求都有编号和验收表述,可测试
- [ ] 异常流覆盖断网 / 失败 / 边界值
- [ ] 每个"为什么"能回溯到决策日志编号
- [ ] 所有假设集中汇总,无隐藏脑补
- [ ] 用户与开发看过后说"没有歧义"

---

## 三、工序三:交互原型(流程验证)

**目标:让"文字上的成立"变成"点击上的成立"。原型只负责验证流程,不负责探索方向。**

产出可交互的原型示意,要求:

1. **完整流程可点通** —— 关键路径从入口到完成,每一步都能点,不是静态示意图集合
2. **状态与异常分支可见** —— 加载、空态、失败、重试、边界值,至少覆盖主要异常
3. **关键决策点有标注** —— 页面上标注对应的 REQ 编号 / 决策编号,让看的人知道"这里为什么这么做"
4. **与指标呼应** —— 关键位置标出埋点位置(哪个动作对应哪个成功指标)

**可选的省钱工序(小需求可跳过):** 在高保真之前,先出一版"灰模"——线框 + 状态流转表,把流程逻辑的错误先杀掉。线框上改一个流程,比高保真上改便宜一个数量级。

**验收标准:**
- [ ] 关键路径完整可点通,无死路
- [ ] 主要异常分支有示意
- [ ] 决策编号 / REQ 编号有标注
- [ ] 用户走完一遍后说"这就是我要的"

---

## 四、工序四:AI 编码与部署(从原型到上线)

**目标:让 AI 依据前三道工序的产出物直接编码、自测、打包、部署,并回访验证。本工序可交由 AI 独立完成大部分,你只做最后的验收。**

1. **编码** —— 把 PRD + 原型(若原型是 HTML,可直接作为前端基准)+ 决策日志交给 AI,要求"严格按此规范实现"。代码必须:
   - 与 PRD 的功能需求编号一一对应(每个 REQ 有对应实现)
   - 覆盖 PRD 中的异常流
   - 有基本的自测(能跑自动化测试就跑;不能跑就做清单式自检)
2. **自测与走查** —— AI 交付前先自己"以用户视角"走一遍关键路径,截图或描述每一步,确认没有明显流程断裂
3. **打包** —— 按目标环境打包:单文件网页 / 静态站点 / 应用构建产物,依赖关系完整
4. **部署** —— 把产物部署到约定平台(静态站用 Cloudflare Pages 这类零成本方案即可;更复杂的部署平台按项目约定)。部署完成后**必须回访线上地址**,确认线上内容与本地一致——这是最容易被忽略、也最容易翻车的一步
5. **验收** —— 对照工序三的验收标准走一遍线上版本;把结果汇报给用户,等"过"才算完成

> 部署细节(平台选择、令牌安全、踩坑清单)见鱼老师的《发布上线篇》。本工序只到"上线可用"为止;持续迭代、灰度、监控留到下一篇详述。

**验收标准:**
- [ ] 每个 REQ 都有对应实现,无遗漏
- [ ] 异常流覆盖(至少:失败提示、重试、空态)
- [ ] 自测通过(自动化或清单式)
- [ ] 线上回访确认内容一致
- [ ] 用户上线验收通过

---

## 五、反例清单(出现即返工)

- ❌ 直接跳级画原型 —— "先给我个原型看看效果"。没有宣讲和 PRD 的原型,必然在原型阶段反复改,因为方向、边界、取舍全没定
- ❌ 用形容词代替指标 —— "提升用户体验"不是指标;"次日留存提升 3 个百分点"才是
- ❌ 宣讲里没有"不做什么" —— 没有范围声明的方案,做着做着就无限膨胀
- ❌ 待决策点没有候选方案 —— 把开放式问题甩给人拍板,等于没做功课
- ❌ 原型上才暴露流程断裂 —— 说明灰模/走查没做或没做透
- ❌ 上线后才发现线上和本地不一样 —— 部署后必须回访验证
- ❌ 三周后没人记得"当时为什么这么定" —— 没有决策日志的项目,每一个改动都要重新解释一遍

---

## 六、跨行业适配说明

本规范四道工序与验收标准适用于任何"由想法驱动的交付"。按行业替换以下内容即可,工序本身不变:

| 行业场景 | 宣讲里最该讲清 | PRD 里最该写细 | 原型重点 |
|---|---|---|---|
| 互联网产品 | 目标用户与场景 | 状态机与异常流 | 交互流程 |
| 内容创作 | 读者是谁、分发渠道 | 系列结构、选题标准 | 版面与节奏 |
| 内部工具 / 系统 | 使用方与流程节点 | 权限、数据边界 | 操作路径 |
| 实体 / 服务行业 | 成本结构与交付周期 | 库存 / 供应链约束 | 关键触点的体验 |

**How to apply:** 用之前,把"本行业"对应的行替换进工序一~四;其余照常。写完第一版先跑一个小项目验证,再回来补充反例清单——同一个错误出现第二次,就把它写进反例。

---

*版本:v1 · 2026-08 · 维护心法:每加一条规则,检查有没有一条能删;规则只收"这一类活"的通用规矩,不收某一次任务的细节。*