✍创作者：全栈弄潮儿²⁰²⁶

🏡 个人主页：全栈弄潮儿²⁰²⁶

📙 专栏地址：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 的问题清单后，再做三件事：

1. 去重：AI 经常把同一个问题换个说法写两遍，合并同类项。
2. 补漏：用你自己的业务场景过一遍，把 AI 没想到的问题补进去。你比 AI 更了解业务，这是你不可替代的部分。
3. 排序：把会影响表结构、接口契约的问题放在前面，把纯 UI 文案类问题放在后面。

这一步做完，你就得到了一份可以拿去开会的需求确认清单。

四、让 AI 给候选答案，而不是替你做决定

问题列出来了，下一步是确认。

很多人到这里又把问题原样丢给 AI：

积分应该过期吗？

AI 会给出一个“平均答案”：大多数电商积分有有效期，通常 1~2 年。这个答案来自统计，而不是来自你的业务。

更好的做法是让 AI 给出候选方案和影响分析，由你来拍板：

针对下面每个问题，给出 2~3 个可选方案， 每个方案说明：实现成本、用户体验、风险。 最后给出你的推荐，但不要替我做最终决定。 问题：积分是否需要有效期？

AI 的输出会变成一张“选项卡片”：

你只需要做一件事：根据业务目标选一个，并写进需求说明。

推荐使用下面这个确认表，把每一次确认都沉淀下来：

这里的角色分工非常明确：

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 编程原则。

如果这篇文章对你有帮助，欢迎点赞、收藏、关注专栏。
也欢迎在评论区留言：你最近遇到过哪一句“看起来清楚、细想全是问题”的需求？

✍坚持原创，求关注，点赞，收藏