第14讲｜需求不清晰时，如何让 AI 反向追问

专栏：AI 编程提效实战 30 讲
标签：AI编程 / 需求拆解 / 提示词 / 工作流 / 程序员效率

先说结论

很多程序员用 AI 写代码效果不稳定，不是因为 AI 不会写代码，而是因为输入的需求本身就不清楚。

你只说“帮我做一个导出功能”“给这个接口加个筛选条件”“优化一下列表查询”，AI 很容易直接开始写方案，甚至直接给代码。但它不知道边界、不知道异常、不知道数据口径、不知道兼容要求，最后生成出来的东西看似完整，落到项目里却要大改。

更稳的做法是：不要让 AI 在信息不足时硬写，而是先让它反向追问。

这篇给你一套可以直接复制的工作流：先识别需求缺口，再让 AI 按优先级追问，最后把回答整理成可执行方案。它适合新功能、接口改造、后台页面、数据统计、脚本任务等常见开发场景。

为什么不能直接让 AI 写方案

模糊需求最大的问题，是它把很多关键判断藏起来了。

比如产品只说：

给订单列表加一个导出功能。

如果你直接让 AI 生成方案，它可能会默认：

• 导出当前筛选结果
• 导出 Excel
• 同步生成文件
• 字段和列表展示一致
• 不考虑数据量
• 不考虑权限和脱敏

但真实项目里，可能有完全不同的约束：

• 只能导出本人有权限的数据
• 手机号、地址、证件号需要脱敏
• 超过 5000 条必须走异步任务
• 导出字段和页面字段不完全一致
• 导出动作要记录审计日志
• 历史订单和实时订单来自不同表

AI 不知道这些上下文时，越快给答案，返工越快发生。

所以第一条规则是：需求不清楚时，不要把 AI 当代码生成器，要先把它当需求分析助手。

第 1 步：先让 AI 判断信息是否足够

不要一上来问“怎么实现”。先问它：当前信息够不够做方案。

提示词可以这样写：

下面是一段需求描述。 请先判断这段需求是否足以进入开发方案设计。 如果信息不足，不要直接给方案，也不要写代码。 请按以下结构输出： 1. 已经明确的信息 2. 还缺失的信息 3. 缺失信息可能导致的开发风险 4. 你需要向产品或业务方追问的问题 需求： {粘贴需求描述}

这一步的价值不是让 AI “显得严谨”，而是避免它在关键上下文缺失时过早下结论。

第 2 步：把追问分成 6 类

AI 提问如果不加约束，也可能问得很散。我的习惯是让它按 6 类追问：

1. 目标：这个功能到底解决什么问题
2. 范围：哪些场景包含，哪些场景不包含
3. 口径：字段、状态、筛选、统计规则怎么定义
4. 边界：异常、空数据、大数据量、并发怎么处理
5. 权限：谁能看、谁能改、谁能导出
6. 验收：怎样算完成，测试用例怎么覆盖

可以直接这样问：

请把需要追问的问题按 6 类整理： 目标、范围、口径、边界、权限、验收。 每类最多给 3 个问题。 每个问题后面说明：如果不问清，开发时可能出现什么问题。 请优先提出会影响数据结构、接口设计、兼容性和测试范围的问题。

注意“每类最多 3 个问题”很重要。否则 AI 很容易列出一长串问题，看起来完整，但你根本没法拿去和产品沟通。

第 3 步：让 AI 给问题排序

不是所有问题都值得立刻问。

有些问题会影响架构和数据模型，比如“导出是同步还是异步”“数据权限按什么规则过滤”。这些必须先问。

有些问题只是展示文案，比如“按钮叫导出还是下载”。这些可以后置。

所以追问清单生成后，还要让 AI 做一次优先级排序：

请把上面的追问问题分成 P0、P1、P2 三类。 P0：不问清就不能设计方案的问题 P1：不问清会影响开发工作量或测试范围的问题 P2：可以在实现过程中确认的问题 请输出表格： 问题 / 优先级 / 影响范围 / 建议询问对象

这一步会让沟通更省力。你拿着 P0 问产品和后端负责人，先把大方向定下来；P1 放到方案评审；P2 放到开发过程中确认。

第 4 步：把回答整理成开发方案

追问不是目的，形成可执行方案才是目的。

当产品或业务方回答完以后，不要直接让 AI 写代码。先让它把回答整理成结构化方案：

下面是需求原文、追问清单和业务方回答。 请把它整理成开发方案，要求包含： 1. 需求目标 2. 功能范围 3. 不做范围 4. 核心流程 5. 接口改动 6. 数据规则 7. 权限与安全 8. 异常处理 9. 测试用例 10. 仍未确认的问题 如果仍有 P0 问题未确认，请明确标记“暂不建议进入开发”。

这个方案比一段聊天记录更适合进入开发。它能直接用于评审、拆任务、写测试用例，也能作为后续让 AI 生成代码的上下文。

低效问法和高效问法的区别

低效问法通常是：

帮我实现订单导出功能。

或者：

这个需求怎么做？

这类问法会逼 AI 猜上下文。

更好的问法是：

这是一个订单导出需求。请先不要给实现方案。 你要先检查需求是否清楚，并反向追问会影响实现的关键问题。 优先关注： - 数据范围 - 导出字段 - 权限规则 - 数据量 - 脱敏规则 - 同步还是异步 - 失败重试和审计日志 等我回答后，你再整理开发方案。

区别不在于字数更多，而在于你明确告诉 AI：信息不足时先问，不要猜。

可直接复制的完整提示词

你现在是我的需求分析和开发方案助手。 目标：当需求不清晰时，先帮我反向追问，而不是直接写方案或代码。 请按以下流程工作： 第一步：判断信息是否足够 请输出： 1. 已明确的信息 2. 缺失的信息 3. 缺失信息可能带来的开发风险 第二步：生成追问清单 请按 6 类整理问题： 1. 目标 2. 范围 3. 口径 4. 边界 5. 权限 6. 验收 每类最多 3 个问题。 每个问题都要说明“不问清会导致什么风险”。 第三步：问题分级 请把问题分成： P0：不问清不能设计方案 P1：不问清会影响工作量或测试范围 P2：可以开发过程中确认 第四步：等我补充回答后，再整理开发方案。 开发方案必须包含： 需求目标、功能范围、不做范围、核心流程、接口改动、数据规则、权限安全、异常处理、测试用例、未确认问题。 如果仍有 P0 问题未确认，请明确提示：暂不建议进入开发。 需求原文： {粘贴需求} 已有上下文： {粘贴相关页面、接口、数据表、历史规则或产品说明}

最后

AI 编程真正提效的关键，不是每次都让 AI 更快写代码，而是让它在该停下来的时候停下来。

需求不清晰时，先让 AI 反向追问，把目标、范围、口径、边界、权限和验收补齐，再进入方案和代码阶段。这样生成结果更稳定，沟通成本也更低。

下一篇讲：让 AI 帮你写脚本处理重复性工作。