怎样让 Codex 提问而不是乱猜

Codex 很强，但它不是神。

它最容易出问题的时候，往往不是“不会做”，而是：

它以为自己已经懂了，于是直接开始猜。

一旦开始猜，就容易出现这些情况：

猜错入口文件
猜错你的真实需求
猜错影响范围
猜错技术栈
为了完成任务擅自做决定

所以高效使用 Codex 的一个关键动作，不是多催它，而是：

提前告诉它：不确定时先问。

前置教程：怎样给 Codex 补充上下文
如果你还没有建立“目标、背景、限制、期望结果”这套上下文意识，先完成前置教程，再回到本篇。

依据来源：OpenAI Codex 官方手册中关于不确定性处理、任务澄清、只读分析、审批和最小风险执行的说明。

本篇目标

跟着本篇做完后，你应该能做到：

知道什么时候一定要让 Codex 先问。
会写“先提问再动手”的约束。
会让它暴露自己的不确定点。
会区分“可以让它自己判断”和“必须先问你”的边界。
能在它开始乱猜时及时拉回来。

为什么“先问”这么重要

因为很多真实任务并不是信息完整的。

比如：

你自己也不知道问题在哪
你只知道现象，不知道原因
这个项目有历史包袱
你不知道它需要改几个文件
你不知道这次改动会不会碰到敏感区域

这时候最危险的，不是它慢，而是它快得很自信。

哪些场景必须先让它问

这些场景，建议你直接加“先问再动手”：

修真实 Bug
涉及登录、权限、支付、安全
涉及数据库结构
涉及多个模块
你自己也不确定入口
你只想先要方案，不想马上修改
你担心它会扩大范围

最实用的一句固定话术

以后你可以把这句当固定动作：

如果你对入口、影响范围、相关文件或实现路径不确定，请先提问或先说明你的判断依据，不要直接猜。

这句足够通用，而且非常有效。

如果你想更严格一点，可以这样写

在你开始修改前，如果存在下面任意一种情况，请先停下来问我：

1. 你不确定入口文件
2. 你不确定需要修改几个文件
3. 你不确定是否会影响无关模块
4. 你发现需要改配置、依赖或数据库
5. 你只能靠猜来继续推进

这会把“允许猜”变成“必须澄清”。

让它先问，不等于让它什么都来问你

这里有个平衡。

你不是要把 Codex 变成一个什么都不敢做的助手。
你是要它：

明显不确定时先问
明显有风险时先问
明显会超范围时先问

而不是：

一个变量名也来问
一个小文案也来问
已经读到明确依据了还来问

所以你可以补一句：

常规的低风险判断你可以自己做，但只要涉及不确定、超范围或敏感修改，请先问我。

一个很好用的提问模板

你可以直接要求它这样提问：

如果你需要澄清，请按下面格式问我：

## 你不确定的点
- 不确定什么：

## 你目前的判断
- 你现在怎么判断：

## 继续推进需要我回答什么
- 请只问最关键的问题：

这样它不会问得很散。

如果它已经开始猜了，怎么拉回来

最直接的说法是：

你刚才这一步已经带有猜测了。
请先停下来，不要继续修改。

请按下面格式回答：
1. 你现在不确定什么
2. 你是根据什么做出当前判断的
3. 你还需要我确认什么

这时候不要继续给新任务，先把它拉回“澄清模式”。

你怎么判断它是在判断，还是在乱猜

重点看这 4 点：

它有没有给依据
它提到的文件或结论是否真实存在
它有没有主动承认不确定
它是不是在依据不足时仍然强推下一步

如果它说：

我推测可能是这里

这不一定有问题。

但如果它说：

我推测可能是这里，所以我已经帮你改了

这就不对了。

高效用户和低效用户的差别就在这里

低效用户常常这样：

帮我修一下，有问题你看着办

高效用户更像这样：

你先分析。
如果存在不确定项，请先问我，不要直接猜。

两者的结果稳定性会差很多。

一段非常适合复制的通用约束

请继续这个任务，但加一条明确约束：

如果你对目标、入口、影响范围、相关文件或实现方式存在明显不确定，请先提问或先说明依据，不要直接猜，也不要先改再说。

只有在你已经有明确依据、且风险很低时，才可以直接继续。

这段话适合放在很多任务的前半段。

真正厉害的地方

让 Codex “先问”，不是为了拖慢它。

恰恰相反，这是为了把它的聪明用在正确地方：

已知部分，它自己推进
未知部分，它及时暴露
敏感部分，它先等你确认

这才是高效协作。

下一步该看什么

建议接着看：

因为“先问”之后，下一步就是“改完以后你怎么判断它到底干了什么”。