Codex 普通模式没有 ask__user_question？别干等，给 Agent 配一套“提问协议”

你有没有遇到过这种场景：

你把任务丢给 Codex，心想它能自己一路跑完。

结果它突然卡住了。

它想问你一个问题，可普通模式里又没有 ask__user_question 这种顺手的工具。于是你只能手动补一句：

“选方案 A，继续。”

烦不烦？真的烦。尤其是你正在写代码、切窗口、查日志，Agent 还在那等你点头。

问题不在你，也不完全在 Codex。关键是：普通模式下缺少一个稳定的“提问通道”。

那怎么办？别硬等。咱们给 Codex 设计一套可执行的提问协议，让它少问、问准、能自己往前走。

痛点：Agent 一问问题，节奏就断了

很多人用 Codex 的时候，真正难受的不是它不会写代码。

难受的是这种节奏：

• 它遇到模糊点，停下来问你
• 你没及时回复，它就不动了
• 你回复一句，它继续跑几步
• 又遇到选择题，又停住

这就像你请了个实习生，活儿能干，但每五分钟敲一次门：

“哥，这个变量名用 userInfo 还是 userData？”

你血压都上来了。

咱们要解决的，不是让 Agent 永远不问问题。

而是让它只在关键位置问。

小事自己判断，大事再找你确认。

核心思路：把“什么时候问”提前写清楚

Codex 没有顺滑的 ask__user_question 工具时，你可以换个角度。

别等它临场发挥。

你直接在任务开头告诉它：

• 哪些问题必须问
• 哪些问题不用问
• 不确定时怎么选
• 选错成本高不高
• 没有回复时如何继续

这套规则一旦写进提示词，Agent 的行为会稳很多。

推荐模板：直接复制就能用

下面这段可以放在你给 Codex 的任务前面。

执行任务时请遵守以下协作规则：

1. 如果问题不影响核心结果，请自行做合理决定，不要停下来问我。
2. 如果存在多个方案，请优先选择改动最小、风险最低、最贴近现有代码风格的方案。
3. 如果需要我确认，请一次性列出所有关键问题，不要连续追问。
4. 如果我没有提供额外信息，请基于当前上下文继续推进，并在最终说明里写清你的假设。
5. 只有遇到以下情况才暂停询问：
   - 会删除或覆盖重要数据
   - 会改变公开 API 或用户可见行为
   - 会引入新依赖或大范围重构
   - 需求之间互相冲突

这段话的价值很直接：

你把“别烦我”和“别乱来”同时讲清楚了。

Agent 不会因为一个变量名停住，也不会擅自把项目架构翻个底朝天。

让 Codex 少问废话：给它默认决策规则

Codex 卡住，很多时候不是因为它笨。

是因为你没告诉它偏好。

比如它可能纠结：

• 要不要加测试？
• 要不要改 README？
• 要不要引入新库？
• 要不要顺手修旁边的 bug？

你可以直接给默认规则。

默认偏好：
- 能不加依赖就不加依赖。
- 能小改就不要重构。
- 只处理当前任务，不顺手修无关问题。
- 有现成测试就跑相关测试，没有就说明未验证原因。
- 命名、格式、目录结构跟随项目现有风格。

这几句很管用。

尤其适合维护老项目。老项目最怕什么？

怕 Agent 太热心。

你让它修一个按钮，它顺手升级框架、改目录、换状态管理。看着很努力，实际上你想报警 🚨。

关键技巧：让它“一次性问完”

有些问题确实要问。

比如需求不完整，或者两个方向都会影响产品逻辑。

这时不要让 Codex 一次问一个。

你可以这样要求：

如果必须向我确认，请把问题合并成一个清单，每个问题给出推荐选项和原因。格式如下：

需要确认：
- 问题：xxx
  推荐：选择 A
  原因：xxx
- 问题：xxx
  推荐：选择 B
  原因：xxx

在我回复前，不要继续修改文件。

这样你只需要回一次。

甚至可以直接回复：

全部按推荐来。

爽多了。

更狠一点：给 Codex 设置“无人值守模式”

如果你想让它尽量自己跑完，可以用这个版本。

适合修 bug、补测试、改小功能。

进入无人值守模式：
- 不要因为低风险选择暂停。
- 遇到不确定点时，选择最保守方案。
- 把所有假设记录在最终回复中。
- 如果某一步失败，请尝试替代方案，最多重试 3 次。
- 只有高风险操作才暂停确认。

这招特别适合你准备去倒杯咖啡的时候。

回来一看，至少它已经推进了大半，不是停在“请问是否继续？”那里发呆。

示例：同一个需求，提示词差别很大

普通写法：

帮我修一下登录页的报错。

这句话太空了。

Codex 可能会问：哪个报错？怎么复现？要不要加测试？能不能改接口？

更稳的写法：

帮我修登录页提交空密码时报 500 的问题。

协作规则：
- 优先定位根因，不要只在前端吞错误。
- 如果后端需要参数校验，请按现有校验风格补齐。
- 不要改登录流程和接口返回结构，除非必须。
- 如果需要测试，优先补最小覆盖用例。
- 低风险问题自行决定，高风险变更再问我。

这就清楚多了。

它知道边界，也知道你不想被小问题打断。

避坑清单：别把 Agent 管得太死

很多人会走向另一个极端：写一堆限制，把 Codex 绑成木乃伊。

不建议。

下面这些坑要避开：

• 不要写“任何问题都必须问我”，它会频繁停工。
• 不要写“不要问我任何问题”，它可能在高风险场景瞎冲。
• 不要只说“你自己决定”，要给它决策标准。
• 不要让它同时做太多事，任务越大，追问越多。
• 不要省略验收标准，不然它不知道做到什么程度算完。

好用的 Agent，不是完全听话。

是知道什么时候该闭嘴干活，什么时候必须拉你一把。

我的建议：把这段存成你的 Codex 常用前缀

你可以把下面这段作为固定模板。

每次开新任务，贴在需求前面。

工作方式：
- 请尽量自主推进任务，不要因低风险选择中断。
- 遇到不确定点，优先选择最小改动、最低风险、符合现有风格的方案。
- 必须确认时，请一次性列出问题、推荐选项和原因。
- 如果我没有补充信息，请继续执行，并在最终说明中列出你的假设。
- 不要处理无关问题，不要擅自扩大范围。

这段不花哨，但很实用。

它解决的是日常使用 Codex 最磨人的地方：

别让人一直当“确认按钮”。

小结：没有工具，就用协议补上

ask__user_question 这类工具当然方便。

可普通模式没有，也不是完全没办法。

你真正需要的是一套稳定的人机协作规则：

• 小事让 Agent 自己判断
• 大事让它集中提问
• 风险边界提前说清
• 默认偏好直接写明
• 最终结果里保留假设和取舍

这样用 Codex，节奏会顺很多。

你不用守在旁边一句句回。

它也不会因为芝麻大的问题原地罚站。

这才是舒服的 Agent 工作流。