阅读完本节后，你将会收获：
- 理解 AI 如何"阅读"和执行 PRD
- 掌握 PRD 细节如何影响生成代码质量
- 学会使用可视化减少误解
- 掌握"方案先行"的工作方法
序言中提到的：理解 AI 如何执行 PRD，能让 PRD 写得更有效。
AI 从 PRD 中提取：
如果 PRD 写得太模糊，AI 会按"常见做法"猜测，可能猜错。
AI 根据 PRD 中的"数据"相关描述，设计数据结构：
| PRD 中的描述 | AI 理解的数据结构 |
|---|---|
| "任务有标题、完成状态" | { title: string, completed: boolean } |
| "用户可以添加多个任务" | tasks: Array<Task> |
| "数据需要保存" | 需要 localStorage 或数据库 |
注意：本章 PRD 只需描述"需要什么数据"，AI 会据此设计初步的数据模型。详细的数据库设计（表结构、关联关系、索引优化）在第八章学习后，你可以用新知识重新审视和优化这个设计。
如果 PRD 没说需要保存什么数据，AI 可能漏掉关键字段，后期需要重构数据结构。
数据模型的设计是架构的基础，一旦确定，后续的很多决策都会围绕它展开。如果 AI 在这个阶段产生了误解，比如把应该关联的数据设计成了独立表，或者漏掉了某个关键字段，这种错误会在后续阶段被放大。前端代码会基于错误的数据结构来渲染，后端接口会基于错误的模型来查询，整个系统的数据流都会受到影响。修正这种错误不仅仅是改几行代码那么简单，往往需要重新设计数据库 schema、修改 API 契约、调整前端组件。这种重构的成本，远高于在 PRD 阶段多写几句话来明确数据需求。
AI 根据 PRD 中的流程图和交互描述，编写代码逻辑：
| 交互描述 | AI 生成的代码逻辑 |
|---|---|
| "点击添加按钮，任务出现在列表" | handleAddTask() 函数 |
| "点击勾选，任务显示删除线" | toggleTask() + CSS 样式 |
| "快速点击防抖" | debounce() 或 disabled 状态 |
如果 PRD 没写边缘情况，AI 可能不做防抖、不做错误处理。
AI 有一些理解盲区，写 PRD 时要注意。
| 你写的 | AI 理解的默认值 |
|---|---|
| "显示任务列表" | 列表最多显示多少条？AI 可能猜 10、50、100 |
| "按钮点击后..." | 按钮要禁用吗？AI 可能不处理 |
| "数据保存" | 保存多久？AI 可能猜"永久" |
解决方案：明确写出期望的默认值。
默认值的问题之所以重要，是因为它反映了 AI 和人类在"常识"上的差异。对于人类来说，"显示任务列表"默认意味着"显示所有任务"，"数据保存"默认意味着"永久保存"。但 AI 没有这种默认假设，或者更准确地说，它的默认假设来自统计学习，可能与你的直觉不同。当 AI 猜测"列表最多显示多少条"时，它可能会选择 10（因为移动端常见）、50（因为是一个"合理"的数字）、或者 100（因为是一个"安全"的上限）。这些选择都是"合理"的，但可能都不是你想要的。明确写出期望的默认值，实际上是在把你的"常识"传递给 AI。
| 你写的 | AI 可能误解 |
|---|---|
| "任务可以勾选完成" | 勾选后是删除线？移到底部？还是消失？ |
| "加载中..." | 加载中按钮要禁用吗？要显示转圈吗？ |
解决方案：用状态描述："初始状态 → 触发 → 加载中 → 成功/失败"。
| 你写的 | AI 可能误解 |
|---|---|
| 列了一堆功能 | AI 可能按列出的顺序全部实现 |
| 没说哪些重要 | AI 可能把次要功能做得太复杂 |
解决方案：用 P0/P1/P2 标注优先级。
一个有效的实践是：让 AI 先输出技术方案，再写代码。
请先给出这个功能的技术实现方案，包括数据结构、接口定义、主要步骤。我确认后你再写代码。
这样做的好处：
| 直接让 AI 写代码 | 先让 AI 输出方案 |
|---|---|
| 方向性错误发现得晚 | 方案阶段就能纠偏 |
| 有误解返工量大 | 方案阶段就能发现问题 |
| 结果是否符合预期不可控 | 方案确认后再写，预期更明确 |
这是"思维链"的应用——把复杂任务拆成"先想清楚再动手"两步。
方案先行把复杂任务分成两步：第一阶段只关注"做什么"和"怎么做"，第二阶段只关注"怎么写"。更重要的是，方案阶段提供了一个检查点，让你能够在投入大量时间之前发现并纠正方向性的错误。
第三章学完了。接下来：