61975110_让Claude_Code自己提问反向引导的高级技巧
不是标题党。是真实测出来的数字。
以前我的流程是：想清楚需求 → 写 Prompt → 等输出 → 发现遗漏 → 补充 → 再等。一个中等复杂的功能，来回三到五轮才能对上。
现在的流程是：说一句话 → 让它问我 → 回答它的问题 → 第一轮就对上。
那一句话是：在开始之前，先问我你需要知道的问题。
你描述需求的方式，决定了它猜测的空间有多大
Section titled “你描述需求的方式，决定了它猜测的空间有多大”用 Claude Code 开发，有一个底层矛盾你可能没意识到：
你知道你想要什么，但你不知道你遗漏了什么。
你描述了主流程，忘了边界条件。你说了要什么，没说不要什么。你定义了成功状态，没定义失败状态。这些遗漏不是因为你粗心，是因为你在描述需求时，脑子里已经默认填补了那些空白——但它没有。
它基于你说的内容推断，推断的方向取决于它的”默认假设”，而你的默认假设和它的默认假设，经常对不上。
我当时傻乎乎地以为，只要 Prompt 写得足够详细，这个问题就能解决。实际上解决不了，因为你不知道自己遗漏了什么，所以再详细也有盲点。
让它主动提问，是目前我找到的解决这个矛盾最有效的方法。
反向引导的三种用法
Section titled “反向引导的三种用法”用法一：需求启动时的”问题清单”
Section titled “用法一：需求启动时的”问题清单””这是最基础的用法，用于开始一个新功能的时候。
标准 Prompt：
我要实现一个功能：[一句话描述]。在你开始任何实现之前，先列出你需要了解的所有问题，确保完全理解需求。问题列完之后等我回答，不要自己假设。
关键是最后那句”不要自己假设”。不加这句话，它有时候会列出问题，然后自己回答，然后直接开始写代码——等于绕过了你。
我用这个 Prompt 开始做一个优惠券系统，它问了我九个问题：
-
-
-
-
- 过期的优惠码应该提示什么信息，还是直接当不存在处理？
-
-
-
-
- 优惠码作用于哪个环节——Checkout 之前，还是 Stripe 里处理？
-
- 后台需不能管理优惠码（创建/停用），还是只有前台使用？
我自己之前写的需求文档里，只覆盖了前三个问题。后六个是它问出来的。
其中”优惠码是在前端验证还是后端验证”这个问题尤其重要——如果只在前端验证，有人改 JavaScript 就能绕过去。我没想到这个，它问出来了。
用法二：复杂 bug 的”诊断式提问”
Section titled “用法二：复杂 bug 的”诊断式提问””遇到难以定位的 bug，不要直接把错误扔给它让它猜，改成让它问你诊断需要的信息。
我遇到一个 bug，[一句话描述现象]。我不确定是哪里的问题。你需要哪些信息才能帮我定位它？列出你的问题，我来回答。
它会问你：
-
-
- 错误是在前端还是后端，有没有 console 报错或服务端日志？
-
-
这些问题本身就是一个排查清单。你回答的过程里，有时候答到一半自己就发现问题了。
我有一次在回答”最近有没有修改过相关代码”时，突然想起来三天前改了一个 middleware 的执行顺序——答完那句话，bug 就定位了，都没等它给我分析。
用法三：方案设计前的”假设暴露”
Section titled “用法三：方案设计前的”假设暴露””这是最高阶的用法，也是最容易被忽视的。
在让它设计方案之前，先让它把它的假设暴露出来：
我要做 [功能描述]。在你给出方案之前，先列出你在设计这个方案时会做的所有假设——关于用户行为、技术环境、边界条件的假设。列完之后我来确认哪些是对的，哪些需要纠正。
这个 Prompt 的逻辑是：它做技术方案时一定有隐性假设，只是通常不说出来。让它说出来，你来校对，比等它基于错误假设做出方案、你再发现不对、再推翻重来，要省时间得多。
我用这个方法做过一个多时区支持的功能，它列出的假设里有一条：假设用户的时区信息在注册时已经收集并存储在数据库里。
我们的系统根本没存这个字段，是实时从浏览器获取的。这个假设如果没有被暴露，它的整个方案会设计成”从数据库读时区”，而实际上我们需要”从请求头读时区”，两种实现方式差很多。
大多数教程不告诉你的细节在这里： 暴露假设这个做法，对出海产品尤其重要。它对”北美英语用户”有很多根深蒂固的默认假设——货币是美元、时区是 UTC-5 到 UTC-8、日期格式是 MM/DD/YYYY——如果你的产品面向其他市场，这些假设全部要被纠正。
控制它问问题的质量：三个调节技巧
Section titled “控制它问问题的质量：三个调节技巧”让它问问题，不等于让它漫无目的地问。你可以精确控制它问什么维度的问题。
技巧一：限定问题类型
只问和技术实现直接相关的问题，不问业务背景类的问题（业务背景我已经在 CLAUDE.md 里说清楚了）
技巧二：设定问题数量上限
最多问 5 个最关键的问题，不够关键的不用问
这个很重要。不加限制的话，它有时候会问十几个问题，其中有一半是可以推断的，浪费你的时间。
技巧三：要求它对问题排优先级
列出你的问题，按重要程度排序，最先列最影响技术方案的问题
加了这个之后，如果你时间紧，可以只回答前三个问题，后面的它会基于上下文合理推断。
进阶用法：让它问完再给你一份”需求确认书”
Section titled “进阶用法：让它问完再给你一份”需求确认书””这是我最近固定下来的一个习惯，算是反向引导的完整版。
流程：问题清单 → 你的回答 → 它生成需求确认书
第三步的触发 Prompt：
好，基于我的回答，给我一份需求确认书。内容包括：功能描述（你理解的版本，不是我说的原话）、边界条件列表、你将要做的假设（你自己确认过的）、不在本次范围内的内容。我确认这份文档之后，你再开始实现。
它生成的需求确认书，我看一遍，有问题当场纠正，没问题直接说”确认，开始实现”。
这个文档还有一个隐性价值：它是这次任务的上下文摘要 。如果你中途开新会话，把这份文档贴进去，新会话里的它立刻就知道这个任务的所有背景。
坑一：让它问问题，它问了但自己回答了，直接开始写代码
有一段时间我的 Prompt 是”先问我你需要知道的问题”，没有加”等我回答”。
结果它会列出一个问题清单，然后在每个问题后面自己猜一个答案，然后说”基于以上假设，我的实现方案是……”——直接绕过了我。
我盯着它的输出愣了一会，才意识到它把”提问”和”自行假设”做了合并处理。
解决方案： Prompt 里明确加一句：列完问题之后停下来，等我逐条回答，不要自己假设答案。加了这句话，它会老老实实等你。
坑二：它问的问题太泛，像在走流程而不是真的在思考
有一次我让它针对一个 Webhook 功能提问，它问了一堆”请问您的技术栈是什么”、“请问有什么特殊要求”这样的问题。
这种问题是废话——技术栈在 CLAUDE.md 里，特殊要求根本没法回答。说明它没有认真读上下文，只是在走”提问流程”。
解决方案： 在让它提问之前，先明确说”CLAUDE.md 里已有的信息不用问”，然后给一个具体的问题范围，比如”只问和这个功能的边界条件、错误处理、数据格式相关的问题”。具体化问题范围之后，它的问题质量立刻提升了一个档次。
让它提问，本质是把”你猜我想要什么”变成”我告诉你你不知道的事”。
你的盲点是固定的，它的问题能照亮你看不到的地方。学会让它问，比学会怎么描述需求更有价值。
最后一个实际的问题： 你最近做的一个功能，如果当时先让 Claude Code 对你提问，你觉得它会问出哪个你之前没想到的问题——然后你们的对话会不会走向一个不同的实现方向？
在开始之前，先问我你需要知道的问题
假设用户的时区信息在注册时已经收集并存储在数据库里
列完问题之后停下来，等我逐条回答，不要自己假设答案