阅读完本节后，你将会收获：
- 理解 AI 的理解盲区，知道何时需要主动确认
- 掌握让 AI 确认理解的提示词模板
- 学会使用确认清单检查关键细节
- 掌握发现盲点的提示词方法
序言中提到的：AI 不一定会追问所有关键细节，你需要主动让它确认理解。
每次讨论完需求后，使用以下模板让 AI 确认理解：
请确认你理解了我的需求。请按以下格式回复：
- 目标用户：[你理解的目标用户]
- 核心功能：[你理解的 3-5 个核心功能]
- 不做的事情：[你理解的不做的功能]
- 可能的问题：[你认为我可能没考虑到的地方]
如果有任何不确定，请列出问题清单。
这个模板的作用是让 AI 明确输出它的理解，方便逐项检查。
使用这个模板时，不要把它当作一种形式主义的流程。它的真正价值在于强迫 AI 把隐含的假设显性化。当 AI 写下"目标用户是职场人士"时，你可以立即发现这个理解是否准确——也许你指的是"大学生"，也许你指的是"自由职业者"。这种显性的对比让误解无处藏身。
另一个容易被忽视的好处是，这个模板实际上在训练 AI 更好地理解你的需求。当你第一次使用时，AI 的确认可能有很多偏差；但随着你不断纠正这些偏差，AI 会逐渐学习到你的偏好和习惯，后续的理解会越来越准确。这是一个双向适应的过程。
| 只说"帮我做X" | 用确认模板 |
|---|---|
| AI 按猜测理解 | AI 必须明确说出理解 |
| 不知道 AI 理解对不对 | 能逐项检查 AI 的理解 |
| 有误解只能返工 | 在写代码前就发现误解 |
让 AI 确认时，检查它是否回答了这些关键问题。
| 确认项 | 为什么重要 |
|---|---|
| 目标用户是谁 | 决定 UI 复杂度、操作方式 |
| 使用场景是什么 | 决定技术选型（移动端/桌面端） |
| 解决什么问题 | 确保做的是有价值的功能 |
| 确认项 | 为什么重要 |
|---|---|
| 最核心的 3-5 个功能 | 防止 AI 加太多功能 |
| 用户完成任务的流程 | 确保 AI 理解业务逻辑 |
| 有哪些状态变化 | 影响 UI 设计（加载、成功、失败） |
| 确认项 | 为什么重要 |
|---|---|
| 哪些功能这次不做 | 防止范围蔓延 |
| 哪些功能永远不做 | 保持产品聚焦 |
AI 倾向于"多做"，必须明确告诉它边界。
这种倾向有其根源。在训练数据中，AI 看到了大量功能丰富的应用，它学会了"完整的产品应该包含什么"。但你的需求可能只是一个极简的原型，或者一个特定场景下的工具。如果不明确边界，AI 会默认按照"完整产品"的标准来生成代码，结果就是过度工程。
明确"不做的事情"还有一个心理层面的好处：它迫使你思考产品的核心是什么。当你列出"不做登录、不做云同步、不做分类标签"时，你实际上在确认这个产品最本质的价值是什么。这种聚焦对于早期产品至关重要。
| 确认项 | 为什么重要 |
|---|---|
| 需要存储哪些数据 | 决定数据结构设计 |
| 数据从哪里来 | 决定实现方式 |
| 边缘情况怎么处理 | 防止 bug（快速点击、网络错误等） |
| 确认项 | 为什么重要 |
|---|---|
| 有技术栈限制吗 | 影响 AI 的代码选择 |
| 需要兼容哪些设备 | 影响 UI 实现 |
| 有性能要求吗 | 影响技术方案 |
在让 AI 生成完整代码之前，先让它生成方案或架构。
让 AI 先输出方案的好处：
先输出方案，相当于给你一个审核整体设计的机会。审查一份方案文档只需要关注高层设计是否合理，比直接审查代码更容易发现方向性问题。
从认知负荷的角度看，方案确认也降低了你的审核难度。审查一份方案文档，你只需要关注高层设计是否合理；而审查一份代码，你需要同时关注架构逻辑和语法细节。前者更容易发现根本性的误解，后者往往让人陷入细节的泥潭而忽略了整体方向的问题。
方案确认模板：
请先不要写代码，先给出实现方案：
- 数据结构设计
- 主要页面/组件及其职责
- 核心流程的实现思路
- 可能遇到的技术难点
当能全部打钩时，就可以让 AI 生成 PRD 或代码了：
AI 明确说了目标用户是谁
AI 列出了 3-5 个核心功能
AI 明确了不做哪些功能
AI 理解了完整的使用流程
数据怎么存、存什么已明确
边缘情况已讨论
技术约束已说明
让 AI 总结确认，它的理解准确
理解确认后，接下来用标准模板写 PRD。