需求不清时，如何让 AI 帮你补全问题，而不是瞎写代码

文章目录开篇本文不会讨论什么一、需求不清时AI 最擅长做什么二、把任务从“生成代码”改成“生成问题”三、把问题分五类才不会问漏四、让 AI 给候选答案而不是替你做决定五、一份可复用的需求澄清工作流六、总结✍创作者全栈弄潮儿²⁰²⁶ 个人主页全栈弄潮儿²⁰²⁶ 专栏地址AI 编程进阶实战开篇产品同学走过来留下一句话给用户做一个积分商城可以用积分兑换商品。听起来很完整积分怎么获得、兑换比例是多少、有没有门槛、哪些商品可以兑换、兑换后能不能退、库存怎么处理、积分会不会过期、并发兑换会不会超卖……一句话背后藏着几十个没有被定义的问题。很多开发者的第一反应是把这句话直接丢给 AI帮我写一个积分商城系统。AI 会在十几秒内生成一个看起来非常完整的模块积分表、兑换接口、下单流程、前端页面甚至带上单元测试。看起来很高效。但代价是需求里所有没有定义的地方都被 AI 猜了一遍。而 AI 猜出来的结果几乎一定和产品的真实预期不一致。这不是 AI 的错。模糊的需求输入必然得到“看起来合理”的输出。问题在于我们让 AI 承担了本该由人来确认的决策。这篇文章只解决一件事需求不清时如何让 AI 帮你把“未知”全部列出来、整理成可确认的问题而不是替你把代码“瞎写”出来。本文不会讨论什么在开始之前先明确边界不会把 AI 当成业务规则的最终决定者确认权始终在人手里。不会提供“一句提示词生成整个功能”的万能公式。不绑定任何具体模型或产品方法对所有主流 AI 编程工具都适用。不会跳过与产品、业务方的确认环节。不会承诺 AI 能一次性找全所有问题它只是帮我们把遗漏概率降下来。一、需求不清时AI 最擅长做什么当需求只有一句话时AI 手里没有更多信息。它不会说“我不知道”。它会根据训练数据里的常见模式补出一个“最像”的版本。这个能力叫补全它既是 AI 最有用的能力也是需求不清时最危险的能力。用一句话需求去喂 AI它会默认假设很多业务规则。比如积分商城AI 可能会默认积分按消费金额 1:1 获得没有其他来源。兑换比例固定为 100 积分 1 元。兑换后立即扣减积分不支持取消。商品库存充足不考虑超卖。积分永久有效不过期。未登录用户不能访问积分商城。每一个默认假设都是一次未经确认的决策。你给的信息越少AI 替你拍板的地方就越多。等代码写完了才发现规则不对返工的不只是几行代码而是整张数据表、整个接口设计、整条业务链路。这就是“瞎写代码”的完整成因需求模糊 → AI 自动补全 → 补全结果被当成需求 → 错误规则被写进代码 → 后期全部推翻。所以问题的关键不是让 AI 少补全一点而是在让它写代码之前先把所有需要确认的补全点暴露出来。二、把任务从“生成代码”改成“生成问题”既然模糊需求直接生成代码必然出错那正确的做法是换一个任务不让 AI 生成代码先让 AI 生成问题。先看反例。反例帮我写一个积分商城系统用户可以用积分兑换商品。AI 会立刻进入“实现模式”设计表、写接口、出页面。你看起来拿到了一堆代码实际上只是拿到了 AI 对需求的一次猜测。正例下面是一句业务需求。先不要写任何代码。 需求用户可以在积分商城用积分兑换商品。 请完成两件事 1. 列出所有你目前无法确定、需要向需求方确认的问题。 2. 按业务规则、权限、数据、异常、交付五个维度分类。 不确定的地方直接说“不确定”不要替我假设。AI 的输出会完全不一样。它不再给你代码而是给你一份问题清单业务规则 - 积分有哪些获取途径比例分别是多少 - 兑换比例是全局统一还是按商品分类设置 - 兑换后是否支持取消/退货积分如何退回 - 积分是否有有效期过期后如何处理 权限与状态 - 未登录用户能否浏览积分商城 - 兑换是否需要实名/手机号等前置条件 数据与边界 - 商品库存是否与主商城库存联动 - 兑换记录是否需要分页和筛选 异常与幂等 - 用户重复点击兑换如何保证只兑换一次 - 库存不足或积分不足时返回什么提示 交付与验证 - 兑换成功后是否需要通知用户 - 订单状态机包含哪些状态对比一下反例给了你 2000 行代码正例给了你 20 个问题。代码随时可以再生成但问题一旦漏掉代价是整条链路的返工。记住这条原则先让 AI 证明自己理解了需求才允许它写代码。在理解需求之前产出的代码本质上都是垃圾输入驱动的猜测。三、把问题分五类才不会问漏人思考问题时习惯按“场景”想比如“用户下单时会遇到什么”。这种思维方式很容易漏掉系统侧的问题库存并发、幂等、状态流转、数据一致性。AI 恰好相反它习惯按“维度”想。让 AI 按维度生成问题再靠你的业务场景去补充两者结合遗漏率会明显下降。这里沿用本专栏在需求分析上的五类框架维度关注点积分商城的典型问题业务规则积分怎么来、怎么花、怎么退获取途径、兑换比例、有效期、退货规则权限与状态谁能做、在什么状态下能做未登录访问、实名要求、封禁用户能否兑换数据与边界数据长什么样、边界在哪里库存来源、记录分页、兑换历史保留多久异常与幂等失败怎么处理、重复操作怎么办重复点击、库存不足、积分不足、支付超时交付与验证怎么验收、怎么让用户感知通知方式、订单状态机、对账口径拿到 AI 的问题清单后再做三件事去重AI 经常把同一个问题换个说法写两遍合并同类项。补漏用你自己的业务场景过一遍把 AI 没想到的问题补进去。你比 AI 更了解业务这是你不可替代的部分。排序把会影响表结构、接口契约的问题放在前面把纯 UI 文案类问题放在后面。这一步做完你就得到了一份可以拿去开会的需求确认清单。四、让 AI 给候选答案而不是替你做决定问题列出来了下一步是确认。很多人到这里又把问题原样丢给 AI积分应该过期吗AI 会给出一个“平均答案”大多数电商积分有有效期通常 1~2 年。这个答案来自统计而不是来自你的业务。更好的做法是让 AI 给出候选方案和影响分析由你来拍板针对下面每个问题给出 2~3 个可选方案 每个方案说明实现成本、用户体验、风险。 最后给出你的推荐但不要替我做最终决定。 问题积分是否需要有效期AI 的输出会变成一张“选项卡片”方案说明成本体验风险推荐永久有效积分不清零低好长期负债、运营压力大一年滚动清零每年清一次中中清零前投诉高峰一般推荐按获取时间逐笔过期每笔积分独立计时高中计算复杂你只需要做一件事根据业务目标选一个并写进需求说明。推荐使用下面这个确认表把每一次确认都沉淀下来#问题候选方案影响决定状态1积分是否过期永久 / 滚动清零 / 逐笔过期见上方分析一年滚动清零已确认2兑换能否取消支持 / 不支持库存与积分回退逻辑支持24 小时内待确认3未登录能否浏览可浏览 / 必须登录页面与接口鉴权可浏览已确认这里的角色分工非常明确AI 负责枚举选项、分析影响、指出风险人负责根据业务目标拍板。把 AI 当成一个能快速出方案、又不会替你做主的技术顾问。它最大的价值不是“替你决定”而是“让你在 10 分钟内看到所有可能的选择”。五、一份可复用的需求澄清工作流把前面四节的方法串起来就是一套可以直接复用的流程。第一步写下需求原文。不改写、不美化、不补全产品怎么说就怎么写。模糊恰恰是流程的输入。第二步让 AI 列出所有未知问题。用第二节的正例 Prompt明确要求“不确定就说出来不要假设”。第三步按五类维度分类、去重、排序。补上你业务场景里的遗漏项把影响接口和数据设计的排前面。第四步让 AI 为每个问题生成候选答案与影响。用第四节的 Prompt逐批处理拿到选项卡片和推荐。第五步与产品、业务确认。用确认表逐行打勾标记“已确认 / 待确认 / 不适用”。没有确认的问题不进入编码。第六步把确认结果写回需求说明。把确认后的规则整理成一段完整的需求描述再开始让 AI 写代码。这套流程可以浓缩成一个 Prompt存进你的个人 Prompt 库以下是一句业务需求请帮我完成需求澄清不要写代码。 需求{这里粘贴需求原文} 请按以下顺序处理 1. 列出所有需要确认的问题不确定就直接说不要假设。 2. 按业务规则、权限与状态、数据与边界、异常与幂等、 交付与验证五个维度分类并去重排序。 3. 对前 10 个最关键的问题各给出 2~3 个候选方案 说明实现成本、用户体验与风险并给出推荐。 4. 输出一份确认表问题、候选方案、影响、推荐、状态。 完成后告诉我哪些问题必须由需求方确认才可以开始编码。花在澄清上的 30 分钟通常会省下开发期 3 天的返工。六、总结模糊需求不是拿来“喂”给 AI 的是拿来“拆”的。把一句话需求变成可确认的问题清单本质上是把 AI 的“补全权”关掉把“枚举权”打开让 AI 列出问题它能把系统维度的遗漏补全。让 AI 给出候选方案它能让你在几分钟内看到所有选择。让 AI 分析影响它能替你把返工成本提前算清楚。让你来做决定业务规则最终必须由人来确认。记住这个顺序先澄清后设计再编码。跳过澄清直接写代码AI 越强翻车越快。下一篇文章我们来把这一周的内容做一次复盘周复盘这一周最值得保存的 7 条 AI 编程原则。如果这篇文章对你有帮助欢迎点赞、收藏、关注专栏。也欢迎在评论区留言你最近遇到过哪一句“看起来清楚、细想全是问题”的需求✍坚持原创求关注点赞收藏