专栏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 类追问目标这个功能到底解决什么问题范围哪些场景包含哪些场景不包含口径字段、状态、筛选、统计规则怎么定义边界异常、空数据、大数据量、并发怎么处理权限谁能看、谁能改、谁能导出验收怎样算完成测试用例怎么覆盖可以直接这样问请把需要追问的问题按 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 帮你写脚本处理重复性工作。
第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 类追问目标这个功能到底解决什么问题范围哪些场景包含哪些场景不包含口径字段、状态、筛选、统计规则怎么定义边界异常、空数据、大数据量、并发怎么处理权限谁能看、谁能改、谁能导出验收怎样算完成测试用例怎么覆盖可以直接这样问请把需要追问的问题按 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 帮你写脚本处理重复性工作。
