第三章：产品思维与文档驱动
序言：为什么先写文档再写代码？
在让 AI 写代码之前，老师傅按住了你想要狂飙的手。他告诉你，写代码之前，先写文档。如果没有蓝图，AI 很容易就会像脱缰的野马，生成的代码往往缺乏结构，写出一堆谁也看不懂、改不动的功能。
产品验证三步法
老师傅说："在写任何代码之前，先做产品验证三步法：
第一步：灵魂三问。用户是谁？痛点在哪？为何用你？这三个问题看似简单，但很多人答不上来。如果用户是'所有人'，那就等于没有用户。如果痛点是'我觉得需要'，那就不是真痛点。如果'为何用你'的答案是'因为我们有最好的技术'，那用户根本不在乎。
第二步：MVP思维。能验证假设的最简版本是什么？不要想着一次做出完美产品。先做最小可行产品（MVP），快速验证核心假设。比如要做外卖 App，MVP 可能就是一个微信群 + 人工接单，而不是完整的 App。
第三步：快速验证。用最小成本验证假设。可以先用手工方式服务，或者做一个简单的落地页收集用户反馈。记住：失败得越早，成本越低。
PRD 就是 AI 的执行规范。当你想清楚了上面三步，PRD 就是把这些思考翻译成 AI 能理解的结构化文档。
PRD 的作用与结构
在传统开发中，PRD 是给团队看的；但在 AI 开发中，PRD 更重要的作用是给 AI 提供完整的上下文，让它不需要反复猜测你的意图。
老师傅告诉你，一个完整的 PRD 包含五个核心部分：
第一部分：文档信息。记录文档的当前版本、处于哪个阶段（需求评审、UI设计中、开发中、已上线）、谁是核心干系人。还要有更新记录表，清晰记录从"1稿"到"9稿"的迭代过程，让团队成员了解需求的演变。
第二部分：需求背景与目标。这是 PRD 的灵魂，要回答四个关键问题：
- 项目概述：用一两句话高度概括这个产品是做什么的
- 核心问题：目标用户是谁？他们在什么场景下遇到了什么痛点？这些问题带来了什么负面影响？
- 用户故事：以"作为一名XX，我想要XX，以便于XX"的格式描述具体需求
- 项目目标：用户价值是什么？商业价值是什么？期望达成什么具体目标（SMART原则）？
第三部分：方案概述。用可视化方式展示产品全貌：
- 核心业务流程图：用 Mermaid 图描述用户完成核心任务的完整流程
- 功能流程图：展示主要页面和功能模块如何组织和串联
- 信息架构图：列出产品包含的所有信息内容和层级关系
第四部分：细节方案。这是最详尽的部分，是研发和设计的直接依据：
- 页面原型与交互说明：描述每个页面的初始状态、触发操作、成功/失败状态
- 边缘Case处理：用户在生成过程中退出页面怎么办？快速反复点击怎么办？
- 非功能性需求：性能要求、兼容性需求、数据统计埋点
第五部分：上线计划。定义需求的生命周期：
- 上线排期：需求评审、UI/UX设计、研发、测试的时间节点
- 灰度发布：先对内部员工开放，再对1%种子用户开放，逐步放量至全量
最关键的是结构化 + 可视化，Markdown + Mermaid 的组合是最优选择，因为 AI 对这种格式理解最好。有了这个"单一事实来源"，AI 的输出就会稳定很多，也不会出现需求爆炸的问题。
PRD 编写实战
老师傅给你看了一份企业级 PRD 模板，里面详细列出了从"1稿"到"9稿"的迭代过程。
1稿（内部评审稿）：重点阐述需求背景、目标和核心价值。这时候不需要太详细，只要把"为什么要做"说清楚就行。
5稿（项目评审稿）：补充核心业务流程、功能流程图和原型交互说明。这时候要让开发、设计、测试都能看懂你要做什么。
9稿（开发前定稿）：合入最终UI设计稿，补充边缘Case、埋点方案和上线计划。这时候文档要足够详细，开发可以直接照着做。
老师傅强调："PRD 不是一蹴而就的，而是迭代出来的。1稿想清楚'为什么'，5稿想清楚'是什么'，9稿想清楚'怎么做'。每一步都有评审和修改，避免到最后才发现大问题。"
除了迭代思维，需求管理也是产品经理的核心能力。
需求管理技巧
在编写 PRD 的过程中，有几个实用的点：
需求范围管理。明确"In-Scope（范围内）"和"Out-of-Scope（范围外）"，有效管理团队预期，避免范围蔓延。比如这次做AI摘要生成，历史记录V2.0再考虑。
需求优先级排序。将需求拆解为具体的需求点，用表格列出需求ID、模块、描述、优先级、状态。高优先级先做，中优先级观察，低优先级延后。
用户故事。从用户的视角出发，以"作为一名<角色>，我想要<完成某项任务>，以便于<实现某个价值>"的格式描述需求。这比"我要做一个功能"的描述方式更贴近用户。
SMART目标设定。项目目标要符合SMART原则——具体的、可衡量的、可实现的、相关的、有时限的。比如"上线后3个月内，AI摘要功能使用率达到30%"就比"提升用户活跃度"更清晰。
Markdown 与 Mermaid
在编写文档的过程中，你还顺便了解了 Markdown (.md) 和 Mermaid。Markdown 用于编写排版整齐的文本，Mermaid 用于通过文字代码绘制流程图、时序图。
老师傅说，将这些文档提供给 AI，它生成的代码准确率显著提升。
Mermaid 流程图让业务逻辑可视化，AI 能准确理解交互流程。这种可视化方式在 AI 开发中至关重要。
老师傅补充道："写 PRD 不是形式主义，而是为了训练你的问题定义能力。很多人直接让 AI'帮我做个功能'，结果来回改很多次。但先写清楚目标、用户、业务场景、和交互逻辑，AI 往往一次就对了。差距就在想清楚。"
最后，老师傅还顺带提到了 Swagger。以后当项目变得复杂，利用 Swagger 自动生成接口文档，能更高效地确保文档与代码实现保持一致。
对了，记得让 AI 随时保持文档的更新。
下一步：关于项目说明书的详细编写，请查阅第四章：开发常识与技术栈中的"项目说明书 README.md"部分。
小节导航
- **3.1 产品验证三步法** (./01-product-validation.md) 🟢 - 灵魂三问、MVP 思维、明确 Out-of-Scope
- **3.2 跟 AI 讨论需求的技巧** (./02-discuss-with-ai.md) 🟢 - 主动让 AI 确认理解，发现盲点
- **3.3 PRD 标准模板与避坑指南** (./03-prd-template-guide.md) 🟢 - 完整模板 + 细节→代码因果关系 + 可视化技巧
- **3.4 理解 AI 如何执行 PRD** (./04-coding-agents.md) 🟢 - AI 的"阅读"方式、PRD→代码的因果关系、理解盲区学习目标
完成本章后，你将能够：
- ✅ 掌握跟 AI 讨论需求时必须确认的细节清单
- ✅ 用产品验证三步法判断想法是否值得做
- ✅ 使用标准模板写出 AI 友好的 PRD
- ✅ 理解哪些细节会影响 AI 生成的代码质量
- ✅ 训练问题定义能力，提高 AI 协作效率
动手实践
现在，打开你最近想做的一个功能想法，在网页端跟 AI 按 3.2 的细节清单逐条确认。确认完后，用 3.3 的模板让 AI 生成 PRD 初稿。
你会发现：想得越清楚，AI 写得越准。
核心理念
"想清楚再动手，用文档训练思维。"
本章强调的是，在 AI 时代，问题定义能力比代码实现能力更重要。PRD 不是形式主义，而是产品思维的体现——从"为什么做"到"是什么"再到"怎么做"，每一步都想清楚。有了结构化的 PRD 作为"单一事实来源"，AI 就能成为高效的执行伙伴而不是猜谜者。
下一章：第四章：开发常识与技术栈 (../04-dev-fundamentals/index.md)