title: "3.2 与 AI 确认需求" description: "避免误解的沟通技巧" chapter: "第三章" priority: "" 3.2 与 AI 确认需求 阅读完本节后,你将会收获: 理解 AI 的理解盲区,知道何时需要主动确认 掌握让 AI 确认理解的提示词模板 学会使用确认清单检查关键细节 掌握发现盲点的提示词方法 序言中提到的:AI 不一定会追问所有关键细节,你需要主动让它确认理解。 AI 的理解盲区 AI 不一定会追问所有关键细节。当需求描述模糊时,它可能主动追问,也可能按常见模式处理。这种默认处理往往与预期不符。 AI 的理解来源于上下文。上下文越完整,理解越准确。但上下文不是"字数越多越好",而是"关键信息越明确越好"。 这种差异源于 AI 的工作方式。
title: "3.2 与 AI 确认需求" description: "避免误解的沟通技巧" chapter: "第三章" priority: ""
阅读完本节后,你将会收获:
- 理解 AI 的理解盲区,知道何时需要主动确认
- 掌握让 AI 确认理解的提示词模板
- 学会使用确认清单检查关键细节
- 掌握发现盲点的提示词方法
序言中提到的:AI 不一定会追问所有关键细节,你需要主动让它确认理解。
AI 不一定会追问所有关键细节。当需求描述模糊时,它可能主动追问,也可能按常见模式处理。这种默认处理往往与预期不符。
AI 的理解来源于上下文。上下文越完整,理解越准确。但上下文不是"字数越多越好",而是"关键信息越明确越好"。
这种差异源于 AI 的工作方式。当你与一个人类开发者讨论需求时,如果对方有不清楚的地方,他会停下来问你:"这个按钮是放在左上角还是右上角?""用户没有登录时能看到这个页面吗?"这些问题可能会让你感到有些烦琐,但它们确保了双方理解的一致性。AI 有时会追问,但不保证每次都问到关键点。当需求模糊时,它可能基于常见模式做出假设就开始工作。如果这些假设恰好符合你的预期,那当然是好事;但如果假设错了,你将在后续的迭代中付出更多的沟通成本来纠正。
更糟糕的是,AI 的假设往往是"合理"的——它选择的方案在技术上是可行的,在逻辑上是自洽的,只是不符合你的特定需求。这种偏差很难在代码生成之前被发现,因为你可能根本不会想到去确认那些"显而易见"的细节。只有当代码运行起来,看到结果与预期不符时,问题才会暴露。
常见的理解偏差来源:
| 偏差来源 | 导致的问题 |
|---|---|
| 用户模糊 | AI 猜测目标用户,可能猜错 |
| 功能边界不明确 | AI 可能加功能,也可能漏功能 |
| 技术约束未说明 | AI 选用了不兼容的技术 |
| 边缘情况未考虑 | 生成的代码缺少错误处理 |
主动确认的核心是:不要等 AI 来问你,而是让 AI 明确说出它的理解。
每次讨论完需求后,使用以下模板让 AI 确认理解:
请确认你理解了我的需求。请按以下格式回复:
- 目标用户:[你理解的目标用户]
- 核心功能:[你理解的 3-5 个核心功能]
- 不做的事情:[你理解的不做的功能]
- 可能的问题:[你认为我可能没考虑到的地方]
如果有任何不确定,请列出问题清单。
这个模板的作用是让 AI 明确输出它的理解,方便逐项检查。
使用这个模板时,不要把它当作一种形式主义的流程。它的真正价值在于强迫 AI 把隐含的假设显性化。当 AI 写下"目标用户是职场人士"时,你可以立即发现这个理解是否准确——也许你指的是"大学生",也许你指的是"自由职业者"。这种显性的对比让误解无处藏身。
另一个容易被忽视的好处是,这个模板实际上在训练 AI 更好地理解你的需求。当你第一次使用时,AI 的确认可能有很多偏差;但随着你不断纠正这些偏差,AI 会逐渐学习到你的偏好和习惯,后续的理解会越来越准确。这是一个双向适应的过程。
| 只说"帮我做X" | 用确认模板 |
|---|---|
| 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 根据你的回答,不断挖掘新的隐藏假设(如"数据丢失风险"、"已完成任务的处理"),直到所有关键细节都明确。
当满足以下条件时,可以停止:
此时你说"没问题了,开始吧",AI 就可以基于对齐后的理解生成方案或代码。
::: tip 追问是双向澄清
回答 AI 的问题时,你也会发现自己之前没考虑到的细节。这种"被问到才想起来"的情况很正常,正是 AI 追问的价值所在。
:::
误区一:AI 问的问题太基础,觉得没必要回答
误区二:回答模糊,让 AI "看着办"
误区三:怕麻烦,一轮问答就喊停
让 AI 确认时,检查它是否回答了这些关键问题。
| 确认项 | 为什么重要 |
|---|---|
| 目标用户是谁 | 决定 UI 复杂度、操作方式 |
| 使用场景是什么 | 决定技术选型(移动端/桌面端) |
| 解决什么问题 | 确保做的是有价值的功能 |
| 确认项 | 为什么重要 |
|---|---|
| 最核心的 3-5 个功能 | 防止 AI 加太多功能 |
| 用户完成任务的流程 | 确保 AI 理解业务逻辑 |
| 有哪些状态变化 | 影响 UI 设计(加载、成功、失败) |
| 确认项 | 为什么重要 |
|---|---|
| 哪些功能这次不做 | 防止范围蔓延 |
| 哪些功能永远不做 | 保持产品聚焦 |
AI 倾向于"多做",必须明确告诉它边界。
这种倾向有其根源。在训练数据中,AI 看到了大量功能丰富的应用,它学会了"完整的产品应该包含什么"。但你的需求可能只是一个极简的原型,或者一个特定场景下的工具。如果不明确边界,AI 会默认按照"完整产品"的标准来生成代码,结果就是过度工程。
明确"不做的事情"还有一个心理层面的好处:它迫使你思考产品的核心是什么。当你列出"不做登录、不做云同步、不做分类标签"时,你实际上在确认这个产品最本质的价值是什么。这种聚焦对于早期产品至关重要。
| 确认项 | 为什么重要 |
|---|---|
| 需要存储哪些数据 | 决定数据结构设计 |
| 数据从哪里来 | 决定实现方式 |
| 边缘情况怎么处理 | 防止 bug(快速点击、网络错误等) |
| 确认项 | 为什么重要 |
|---|---|
| 有技术栈限制吗 | 影响 AI 的代码选择 |
| 需要兼容哪些设备 | 影响 UI 实现 |
| 有性能要求吗 | 影响技术方案 |
讨论完需求后,用以下提示词让 AI 帮助发现问题:
基于我们刚才的讨论,请列出:
- 我可能没考虑到的边缘情况
- 你认为常见但我可能不需要的功能
- 需要明确的技术细节
请逐条列出,我会逐一确认。
AI 可能会指出:
这些就是被忽略的细节。
让 AI 帮你发现盲点是一种高效的做法。作为产品负责人,你不可避免地会有一些思维定式——你会假设某些事情是"显然"的,或者某些情况是"不会发生的"。AI 没有这些定式,它会从纯逻辑的角度审视你的需求,指出那些你因为太过熟悉而忽视的问题。
当然,AI 指出的问题不一定都需要解决。有些边缘情况可能确实很少发生,不值得为此增加复杂度。但知道这些问题的存在,让你能够做出知情的权衡,而不是在无知中冒险。
在让 AI 生成完整代码之前,先让它生成方案或架构。
让 AI 先输出方案的好处:
先输出方案,相当于给你一个审核整体设计的机会。审查一份方案文档只需要关注高层设计是否合理,比直接审查代码更容易发现方向性问题。
从认知负荷的角度看,方案确认也降低了你的审核难度。审查一份方案文档,你只需要关注高层设计是否合理;而审查一份代码,你需要同时关注架构逻辑和语法细节。前者更容易发现根本性的误解,后者往往让人陷入细节的泥潭而忽略了整体方向的问题。
方案确认模板:
请先不要写代码,先给出实现方案:
- 数据结构设计
- 主要页面/组件及其职责
- 核心流程的实现思路
- 可能遇到的技术难点
你:帮我做一个待办清单。 AI:[生成带登录、云同步、分类标签的复杂版本] 你:太多了,我只要简单的。 AI:[重新生成,但可能还有其他你没说的功能]
你:帮我做一个待办清单。请确认理解... AI:我有几个问题...个人用还是团队用? 你:个人用,只要添加/勾选/删除。 AI:确认了:个人用,核心功能是添加/勾选/删除任务,不做登录/云同步/分类标签。 AI:[生成准确的版本]
当能全部打钩时,就可以让 AI 生成 PRD 或代码了:
A: 这说明边界不够明确。在确认模板中强调"不做的事情",并具体列出不需要的功能类别。
A: 不要直接说"不对"。先理解它是如何理解的,然后指出偏差。使用"我说的 X 是指...,你理解的是..."这种对比方式。
A: 不需要。第一次或复杂需求需要完整确认。简单或后续的迭代,可以简化为"请确认理解"或"有没有不清楚的地方"。
A: 检查是否遗漏了某些细节,或者让 AI 生成方案时没有仔细审核。方案是代码的蓝图,方案错了,代码一定错。
理解确认后,接下来用标准模板写 PRD。