---
title: "3.2 与 AI 确认需求"
description: "避免误解的沟通技巧"
chapter: "第三章"
priority: "🔴"
---

# 3.2 与 AI 确认需求 🔴

> **阅读完本节后，你将会收获：**
>
> - 理解 AI 的理解盲区，知道何时需要主动确认
> - 掌握让 AI 确认理解的提示词模板
> - 学会使用确认清单检查关键细节
> - 掌握发现盲点的提示词方法

> 序言中提到的：AI 不一定会追问所有关键细节，你需要主动让它确认理解。

---

## AI 的理解盲区

AI 不一定会追问所有关键细节。当需求描述模糊时，它可能主动追问，也可能按常见模式处理。这种默认处理往往与预期不符。

AI 的理解来源于上下文。上下文越完整，理解越准确。但上下文不是"字数越多越好"，而是"关键信息越明确越好"。

这种差异源于 AI 的工作方式。当你与一个人类开发者讨论需求时，如果对方有不清楚的地方，他会停下来问你："这个按钮是放在左上角还是右上角？""用户没有登录时能看到这个页面吗？"这些问题可能会让你感到有些烦琐，但它们确保了双方理解的一致性。AI 有时会追问，但不保证每次都问到关键点。当需求模糊时，它可能基于常见模式做出假设就开始工作。如果这些假设恰好符合你的预期，那当然是好事；但如果假设错了，你将在后续的迭代中付出更多的沟通成本来纠正。

更糟糕的是，AI 的假设往往是"合理"的——它选择的方案在技术上是可行的，在逻辑上是自洽的，只是不符合你的特定需求。这种偏差很难在代码生成之前被发现，因为你可能根本不会想到去确认那些"显而易见"的细节。只有当代码运行起来，看到结果与预期不符时，问题才会暴露。

常见的理解偏差来源：

| 偏差来源 | 导致的问题 |
|---------|-----------|
| 用户模糊 | AI 猜测目标用户，可能猜错 |
| 功能边界不明确 | AI 可能加功能，也可能漏功能 |
| 技术约束未说明 | AI 选用了不兼容的技术 |
| 边缘情况未考虑 | 生成的代码缺少错误处理 |

主动确认的核心是：**不要等 AI 来问你，而是让 AI 明确说出它的理解**。

---

## 确认理解的提示词模板

每次讨论完需求后，使用以下模板让 AI 确认理解：

> 请确认你理解了我的需求。请按以下格式回复：
>
> 1. **目标用户**：[你理解的目标用户]
> 2. **核心功能**：[你理解的 3-5 个核心功能]
> 3. **不做的事情**：[你理解的不做的功能]
> 4. **可能的问题**：[你认为我可能没考虑到的地方]
>
> 如果有任何不确定，请列出问题清单。

这个模板的作用是让 AI 明确输出它的理解，方便逐项检查。

使用这个模板时，不要把它当作一种形式主义的流程。它的真正价值在于强迫 AI 把隐含的假设显性化。当 AI 写下"目标用户是职场人士"时，你可以立即发现这个理解是否准确——也许你指的是"大学生"，也许你指的是"自由职业者"。这种显性的对比让误解无处藏身。

另一个容易被忽视的好处是，这个模板实际上在训练 AI 更好地理解你的需求。当你第一次使用时，AI 的确认可能有很多偏差；但随着你不断纠正这些偏差，AI 会逐渐学习到你的偏好和习惯，后续的理解会越来越准确。这是一个双向适应的过程。

### 为什么这样有效

| 只说"帮我做X" | 用确认模板 |
|-------------|-----------|
| AI 按猜测理解 | AI 必须明确说出理解 |
| 不知道 AI 理解对不对 | 能逐项检查 AI 的理解 |
| 有误解只能返工 | 在写代码前就发现误解 |

---

## 让 AI 主动追问

**不要等 AI 确认，让 AI 主动提问。** 当你给出需求后，直接告诉 AI "基于现有方案，列出多个你不确定的问题向我确认"，AI 会主动挖掘隐藏假设，双方通过多轮问答对齐理解。

### 为什么让 AI 主动追问

传统的"用户问 AI 答"模式下，用户需要自己发现问题，这要求用户对产品有完整思考。但现实中，很多细节是在对话中逐渐清晰的。

让 AI 主动追问的好处：

- **AI 能发现你忽略的问题** —— 基于训练数据中的常见模式，AI 知道哪些地方容易有歧义
- **对话更自然** —— 像讨论一样，一问一答，逐步深入
- **减少你的认知负担** —— 不需要一次性想清楚所有细节

### 如何启动

当你描述完需求后，直接说：

> "基于现有方案，列出多个你不确定的问题向我确认"

AI 会输出一批问题（通常 3-5 个），你逐一回答后，AI 根据你的回答继续追问，直到双方对齐。

### 追问示例

**你提出需求：**

```
你：我想做一个待办清单应用。
```

**启动追问：**

```
你：基于现有方案，列出多个你不确定的问题向我确认
```

**AI 第一轮追问：**

```
AI：好的，基于你的需求，我有以下几个问题：

1. 目标用户是谁？是个人使用还是团队协作？
2. 核心功能有哪些？（如添加任务、设置截止日期、分类标签等）
3. 数据存储在哪里？本地浏览器还是云端？
4. 需要用户登录吗？还是开箱即用？
5. 有移动端需求吗？还是只做桌面端？

请逐一回答，我会继续追问需要澄清的细节。
```

**你回答后，AI 继续追问：**

```
你：1. 个人使用 2. 添加/完成/删除任务，不做标签 3. 本地存储
    4. 不需要登录 5. 只做桌面端

AI：明白了。基于你的回答，我还有几个问题：

1. 本地存储的话，如果用户清理浏览器数据，任务会丢失吗？
   这个风险需要处理吗，还是可接受？
2. "完成"的任务是删除还是保留但标记为已完成？
3. 任务有截止日期吗？还是只做简单的清单？

请确认这些细节。
```

**关键洞察：** AI 根据你的回答，不断挖掘新的隐藏假设（如"数据丢失风险"、"已完成任务的处理"），直到所有关键细节都明确。

### 追问的终点

当满足以下条件时，可以停止：

1. **AI 的理解与你的预期完全一致** —— 逐条检查，没有偏差
2. **所有关键细节都已明确** —— 没有模糊地带，没有"视情况而定"
3. **边缘情况已讨论清楚** —— 异常情况怎么处理，有明确方案
4. **你自己也感到清晰了** —— 通过回答 AI 的问题，你对自己的需求也有了更完整的认识

此时你说"没问题了，开始吧"，AI 就可以基于对齐后的理解生成方案或代码。

::: tip 追问是双向澄清

回答 AI 的问题时，你也会发现自己之前没考虑到的细节。这种"被问到才想起来"的情况很正常，正是 AI 追问的价值所在。

:::

### 常见误区

**误区一：AI 问的问题太基础，觉得没必要回答**

- 结果：跳过了关键确认，理解偏差被隐藏
- 正确做法：即使是基础问题，也明确回答，消除歧义

**误区二：回答模糊，让 AI "看着办"**

- 结果：AI 按默认方式处理，不符合你的特定需求
- 正确做法：明确给出选择，不要说"都可以"、"你决定"

**误区三：怕麻烦，一轮问答就喊停**

- 结果：深层假设没被挖掘，后续返工成本更高
- 正确做法：耐心回答多轮问题，直到双方真正对齐

---

## 必须确认的细节清单

让 AI 确认时，检查它是否回答了这些关键问题。

### 用户与场景

| 确认项 | 为什么重要 |
|-------|-----------|
| 目标用户是谁 | 决定 UI 复杂度、操作方式 |
| 使用场景是什么 | 决定技术选型（移动端/桌面端） |
| 解决什么问题 | 确保做的是有价值的功能 |

### 核心功能

| 确认项 | 为什么重要 |
|-------|-----------|
| 最核心的 3-5 个功能 | 防止 AI 加太多功能 |
| 用户完成任务的流程 | 确保 AI 理解业务逻辑 |
| 有哪些状态变化 | 影响 UI 设计（加载、成功、失败） |

### 不做的事情

| 确认项 | 为什么重要 |
|-------|-----------|
| 哪些功能这次不做 | 防止范围蔓延 |
| 哪些功能永远不做 | 保持产品聚焦 |

AI 倾向于"多做"，必须明确告诉它边界。

这种倾向有其根源。在训练数据中，AI 看到了大量功能丰富的应用，它学会了"完整的产品应该包含什么"。但你的需求可能只是一个极简的原型，或者一个特定场景下的工具。如果不明确边界，AI 会默认按照"完整产品"的标准来生成代码，结果就是过度工程。

明确"不做的事情"还有一个心理层面的好处：它迫使你思考产品的核心是什么。当你列出"不做登录、不做云同步、不做分类标签"时，你实际上在确认这个产品最本质的价值是什么。这种聚焦对于早期产品至关重要。

### 数据与状态

| 确认项 | 为什么重要 |
|-------|-----------|
| 需要存储哪些数据 | 决定数据结构设计 |
| 数据从哪里来 | 决定实现方式 |
| 边缘情况怎么处理 | 防止 bug（快速点击、网络错误等） |

### 技术约束

| 确认项 | 为什么重要 |
|-------|-----------|
| 有技术栈限制吗 | 影响 AI 的代码选择 |
| 需要兼容哪些设备 | 影响 UI 实现 |
| 有性能要求吗 | 影响技术方案 |

---

## 发现盲点的提示词

讨论完需求后，用以下提示词让 AI 帮助发现问题：

> 基于我们刚才的讨论，请列出：
>
> 1. 我可能没考虑到的边缘情况
> 2. 你认为常见但我可能不需要的功能
> 3. 需要明确的技术细节
>
> 请逐条列出，我会逐一确认。

AI 可能会指出：

- 用户删除数据后，需要能恢复吗？
- 数据列表有没有数量上限？
- 如果用户输入特别长的内容，怎么显示？
- 需要在手机上用吗？

这些就是被忽略的细节。

让 AI 帮你发现盲点是一种高效的做法。作为产品负责人，你不可避免地会有一些思维定式——你会假设某些事情是"显然"的，或者某些情况是"不会发生的"。AI 没有这些定式，它会从纯逻辑的角度审视你的需求，指出那些你因为太过熟悉而忽视的问题。

当然，AI 指出的问题不一定都需要解决。有些边缘情况可能确实很少发生，不值得为此增加复杂度。但知道这些问题的存在，让你能够做出知情的权衡，而不是在无知中冒险。

---

## 方案先行原则

在让 AI 生成完整代码之前，先让它生成方案或架构。

让 AI 先输出方案的好处：

- 能更快发现理解偏差
- 修改方案比修改代码成本低
- 确保整体架构合理后再进入细节

先输出方案，相当于给你一个审核整体设计的机会。审查一份方案文档只需要关注高层设计是否合理，比直接审查代码更容易发现方向性问题。

从认知负荷的角度看，方案确认也降低了你的审核难度。审查一份方案文档，你只需要关注高层设计是否合理；而审查一份代码，你需要同时关注架构逻辑和语法细节。前者更容易发现根本性的误解，后者往往让人陷入细节的泥潭而忽略了整体方向的问题。

方案确认模板：

> 请先不要写代码，先给出实现方案：
>
> 1. 数据结构设计
> 2. 主要页面/组件及其职责
> 3. 核心流程的实现思路
> 4. 可能遇到的技术难点

---

<AIConfirmationDemo />

## 对比：有确认 vs 无确认

### 无确认（常见错误）

```
你：帮我做一个待办清单。
AI：[生成带登录、云同步、分类标签的复杂版本]
你：太多了，我只要简单的。
AI：[重新生成，但可能还有其他你没说的功能]
```

### 有确认（正确做法）

```
你：帮我做一个待办清单。请确认理解...
AI：我有几个问题...个人用还是团队用？
你：个人用，只要添加/勾选/删除。
AI：确认了：个人用，核心功能是添加/勾选/删除任务，不做登录/云同步/分类标签。
AI：[生成准确的版本]
```

---

## 讨论结束的检查清单

当能全部打钩时，就可以让 AI 生成 PRD 或代码了：

<ConfirmationChecklist />

- [ ] AI 明确说了目标用户是谁
- [ ] AI 列出了 3-5 个核心功能
- [ ] AI 明确了不做哪些功能
- [ ] AI 理解了完整的使用流程
- [ ] 数据怎么存、存什么已明确
- [ ] 边缘情况已讨论
- [ ] 技术约束已说明
- [ ] **让 AI 总结确认，它的理解准确**

---

## 常见问题

### Q1: AI 列出了很多我不需要的功能

**A**: 这说明边界不够明确。在确认模板中强调"不做的事情"，并具体列出不需要的功能类别。

### Q2: AI 的理解完全错了

**A**: 不要直接说"不对"。先理解它是如何理解的，然后指出偏差。使用"我说的 X 是指...，你理解的是..."这种对比方式。

### Q3: 每次都要写这么长的确认提示吗？

**A**: 不需要。第一次或复杂需求需要完整确认。简单或后续的迭代，可以简化为"请确认理解"或"有没有不清楚的地方"。

### Q4: AI 确认了，但生成的代码还是不对

**A**: 检查是否遗漏了某些细节，或者让 AI 生成方案时没有仔细审核。方案是代码的蓝图，方案错了，代码一定错。

---

## 本节核心要点

- ✅ **AI 不一定会追问所有关键细节，你需要主动让它追问**
- ✅ 用"基于现有方案，列出多个你不确定的问题向我确认"启动追问
- ✅ **多轮问答，直到所有隐藏假设都被挖掘**
- ✅ 明确回答每个问题，不要让 AI "看着办"
- ✅ 方案先行，确认方案后再生成代码
- ✅ 双方理解一致后，再让 AI 生成 PRD
- ✅ 回答 AI 的问题也是自我澄清的过程

理解确认后，接下来用标准模板写 PRD。

---

## 相关内容

- 前置：[3.1 想法验证实战](./01-product-validation.md)
- 详见：[3.3 PRD 编写实战](./03-prd-template-guide.md)