什么时候必须停下来问：给 Codex 设置确认门禁

“把登录模块整理一下，测试也补上。”

Codex 调查后发现两条路：一条只整理模块内部结构，另一条顺便统一身份模型，但会牵动数据库字段和三个调用方。它该直接选择看起来更彻底的方案，还是把搜索代码、运行检查、修改文件都停下来逐项请示？

两种做法都有问题。前者替用户决定了任务目标，后者把协作变成不断点“同意”。小编更愿意把确认门禁理解成一个决策点：当下一步可能改变结果定义、越出已有授权，或者留下难恢复的影响时，Codex 必须停下来；范围明确且后果可控的执行，不必反复询问。

一、先分清三套规则

讨论确认门禁时，最容易把产品机制、项目规则和个人建议混在一起。三者都能约束 Codex，但来源和作用并不相同。

第一层是产品提供的安全与审批能力。不同运行环境可以限制文件、网络或外部工具操作，并在某些动作真正执行前请求批准。它解决的是“这次操作能否执行”。具体权限配置和工具操作半径留到下一篇展开。

第二层是项目自己的协作规则。例如当前 JVS 项目约定：主题完整方案没有得到确认，不启动正文写作；审阅发现问题后，也不能直接修改正文，需要先说明问题和修改范围。这是仓库里的工作约定，不是 Codex 的通用内置流程。

第三层是本文给出的任务设计方法。OpenAI 的模型使用建议提出了一条可借鉴的边界：回答、解释、审阅、诊断和规划通常先检查并报告；明确要求修改、构建或修复时，可以完成范围内的本地修改和非破坏性验证；外部写入、破坏性动作、购买或实质扩大范围应取得确认。这段内容是提示词与工作流设计建议，不等于所有 Codex 环境都会自动执行同一套门禁。

把三层分开，遇到问题时才知道该改什么：执行被环境拦住，要检查产品权限；流程走得不合团队预期，要检查项目规则；任务经常误问或漏问，才需要调整门禁判断。

二、下一步要不要问，先过三道判断

门禁不应该按“第几步”机械设置。每当计划要进入下一阶段，检查信息缺口、动作影响和授权覆盖，通常就够了。

2.1 信息缺口会不会改变结果

缺信息不等于立即提问。仓库结构、现有测试、调用入口和错误日志，可以通过只读调查得到，先查比把问题退给用户更有效。

只有一种缺口值得立刻停下来：用户选择无法从材料中推导，而且不同答案会产生不同结果。例如“整理登录模块”究竟要求保持所有接口兼容，还是允许统一身份模型，这会改变目标、改动范围和验收方式。Codex 即使能判断哪个方案技术上更整洁，也不能替用户决定业务取舍。

可以用一个简单问题筛选：如果按当前假设继续，用户给出另一个答案后，已经完成的主要产物是否要推倒重来？ 若答案是肯定的，就应在产生成本之前确认。只是影响变量名或说明文字的细节，可以先采用可逆的合理默认值，并把假设说清楚。

2.2 动作会留下多大影响

读文件和整理调查结果不会改变工作对象；修改任务范围内的新草稿，通常也容易审阅和撤回。删除已有数据、覆盖用户改动、发布文章、部署服务或向外部平台发消息，影响对象和恢复成本明显不同。

这里不能只看动作名称。“写文件”可能只是创建用户明确要求的新草稿，也可能覆盖一份尚未提交的重要配置；“运行命令”可能是本地测试，也可能触发生产发布。门禁判断应落到四个具体问题：改了什么对象，谁会受到影响，结果能否完整预览，失败后怎样恢复。

影响越难收回，确认越要靠近真实动作。方案讨论时说“以后可以发布”，不等于已经授权现在把内容发到外部系统。

2.3 现有授权是否覆盖下一步

一句“可以”必须放回它回答的问题里理解。用户认可方向、确认局部方案和授权完整执行，不是同一件事。

• 讨论认可：同意继续研究某个方向，没有授权落盘或对外执行。
• 局部确认：同意一个明确选择，例如采用兼容方案，授权只覆盖该选择及约定的后续动作。
• 完整执行授权：同意在清楚的目标、范围和边界内连续完成任务，范围内的常规写入与检查不必逐项再问。

判断授权是否有效，要同时核对目标、对象、动作和边界。当前系列中，用户已明确要求按顺序自动完成所有文章，因此创建已规划的正文、更新对应状态和执行本地检查都在授权内，不需要每篇再问一次。若审阅后要改动已经完成的正文，项目规则另设了确认门禁，之前的连续写作授权不能绕过它。

三、把门禁放进任务阶段

上一篇把复杂任务拆成现状调查、方案收敛、实施修改和阶段检查。确认门禁可以直接附着在这些阶段的出口，而不是另建一套审批流水线。

所在阶段与触发条件	为什么停	用户要决定什么	本次授权范围	确认后的动作
调查中出现无法从材料确认的关键需求，且不同答案会改变主要产物	继续只能依赖用户偏好或业务选择	目标、约束或验收口径	只覆盖被确认的需求分支	回写计划，再进入方案收敛
方案收敛后仍有多条路径，影响范围、兼容性或成本明显不同	技术可行不代表替用户作取舍	采用哪条方案，以及接受哪些影响	选定方案及列明的改动对象	固化目标、非目标和完成条件
实施前发现要覆盖用户已有改动、删除数据或执行难恢复变更	后果超出普通本地编辑	是否执行、备份或回退要求	精确到对象和动作，不外延	按确认方式保护现场后执行
任一阶段准备发布、部署、发消息或写入外部系统	影响从本地扩展到外部对象	目标位置、内容和执行时机	指定外部目标与本次操作	预览一致后执行并返回结果
新证据使目标、对象或工作量实质扩大	原确认针对的已经不是当前方案	接受新范围，还是回到原目标	以新确认重新定义边界	更新计划、依赖与后续门禁

这张表里没有“开始读文件前确认”“每改一个文件确认”或“每跑一次本地检查确认”。只要用户明确要求修改，目标文件属于任务范围，动作可审阅且没有触及额外边界，这些就是完成任务的正常步骤。门禁过密会把同一份执行授权切成大量没有新决策的信息确认，计划看似安全，实际上无法连续推进。

反过来，门禁缺失也不只是“少问一句”。Codex 可能把“方案不错”解释成“立即实施”，把“准备发布”解释成“已经可以发布”，或在调查发现旁支后顺手扩建整个模块。问题出在授权对象发生了变化，而流程没有停下来让用户重新选择。

四、一次有效确认要让人能做决定

“现在有两个方案，请确认”把整理工作留给了用户。确认请求至少要交代四件事：当前发现、推荐选择、可行备选和各自影响。最后还要说清楚，请用户授权的究竟是哪一步。

仍以前面的登录模块为例，可以这样问：

调查发现，问题既可以通过模块内部重构解决，也可以借机统一身份模型。小编建议本次只做内部重构，因为它能保持现有接口，符合原任务范围。备选方案会修改数据库字段并影响三个调用方，需要增加迁移和兼容验证。请确认是否按推荐方案修改列出的模块文件并运行本地检查；本次不包含数据库迁移、部署和外部发布。

这段请求让用户看到推荐，不必从零设计方案；同时写出了备选方案为何不同。最重要的是，结尾把授权对象钉在“哪些修改、哪些检查、哪些事情不做”上。得到确认后，Codex可以连续完成范围内动作，无需把同一个决定换成多个问题再问。

若用户没有接受推荐，而是补充了新需求，原确认请求就失效。此时先更新目标、非目标、依赖和影响，再给出新的完整选择。旧确认只证明用户接受过旧方案，不能成为新方案的永久通行证。

五、门禁守的是决策权，不是操作次数

复杂任务需要确认的节点并不多：关键信息只能由用户提供，方案选择会改变结果，动作会产生难恢复或外部影响，以及新发现已经越出原授权。其余只读调查、范围内实现和非破坏性检查，应沿着计划继续走。

因此，判断“要不要停下来问”时，不必统计 Codex 将调用多少工具，也不必把所有不确定性都升级成审批。依次检查三件事：缺失信息是否改变主要结果，动作影响是否难以恢复或越出本地，当前授权是否明确覆盖下一步。任一项触发门禁，就带着现状、推荐、备选、影响和精确授权范围来问；三项都没有触发，就继续执行，并用计划状态和产物让过程保持可核验。