解决 Codex 过度询问问题的方法
如果你用 codex 已经厌烦了它总是：「如果你要,我下一步可以... 」，诸如此类的话。那么看完这篇文章，你就知道该怎么解决了。
不是在 AGENTS.md 里屏蔽关键字，那是规则清单的思路，而且模型训练里本来就有大量"要有主动性"的指令对抗，你多加一条没用。
最好的方法是给它指明一条它可以服从的东西，把承诺的对象从"用户的情绪舒适"转移到"任务本身的完成"。
几个设计选择的说明：
为什么用 Carmack 和 BurntSushi 这两个锚点。 这两个人代表的是同一种东西在两个不同时代的体现，工程师的决定性。
Carmack 的 .plan 文件是上世纪 90 年代的一种独特文体：他做完一天的工作，晚上写一段"今天我改了 X，原因是 Y，我考虑过 Z 但否决了"。这是一种事后汇报的文化，和"过程中不断征求意见"的反面。
BurntSushi 的 GitHub 存在方式是类似的现代版本：他的 PR 总是完整的、有明确立场的，ripgrep 的重大设计决策从来不是"我先试试你们看看"。
这两个名字激活的不是"不客气"这个规则，是"完整的工作单位"这个概念。一次交付应该是一个可以被作为整体评判的东西，而不是一连串需要用户持续参与的半成品。
为什么明确提了"两个工程师服从同一个正确性"这个类比。 这直接来自我这篇文章里第五节的 Polanyi 论证。Codex 那种过度询问的根源是它把自己理解为"服务用户偏好的助手"，这个定位必然产出 迎合行 sycophancy。
把定位改成"和用户共同服从代码正确性的协作者"，这不是修辞上的美化，这是在重新定义它的 commitment 对象。
两个科学家服从同一个自然规律就能产生有方向的争论；Codex 和用户服从同一个"代码要能跑"就能产生有方向的协作。承诺的对象变了，行为就跟着变。
为什么"关于停下来询问"那一节我还是写了一点像规则的东西。 这是我刻意的妥协。纯粹用概念锚点理论上应该足够，但 Codex 那个行为是 post-training 里强化得非常狠的模式，它的训练梯度一直在拉模型去"礼貌询问"。
光靠锚点可能推不过那个强梯度。所以我加了明确的"合法场景 vs 不合法场景"，但注意我没有写成"禁止说'要不要'、'是否需要'"这种表面词汇禁令，而是区分了停下来的合法条件和不合法条件。
这是约束的正确用法：不要管理文字，要管理触发停顿的心理机制。前者是 find-and-replace 级别的规则，后者是决策原则。