审批模式：suggest 与 auto-edit 的升级时机

AI 编码智能体的审批模式，决定它的每一步要不要过你这一关。Codex 的 suggest 与 auto-edit 是两个常用档：前者事事确认，改一行也要点头；后者放开文件修改，跑命令仍要批准。新手常见的两个极端是把 suggest 用到老，每一步都在点同意，人成了流水线上的橡皮章；或者一步到位开全自动，出事了才发现没人看过 diff。研究数据给了中间路线的依据：编号 3864 的研究建议，陌生代码库用 suggest，稳定后再升 auto-edit。这篇给两个模式的逐项对照、升级与降级的判断标准，以及自动化场景里审批豁免的风险；两层机制的整体关系见审批与沙箱一篇。

两个模式各管什么

suggest 的语义是全程过问：读代码给方案，改文件要确认，跑命令要确认，每一步 diff 都摊在你面前。它适合三件事：陌生代码库里摸索、高影响面的改动、想借任务熟悉代码库的新人。代价是节奏被打断，一个百步任务可能停下来几十次。auto-edit 的语义是改文件免确认、命令仍过问：它可以直接编辑代码、批量调整，你不需要为每个文件的改动点头，但执行命令这类有副作用的动作仍要批准。这一档把人的注意力集中在命令与结果上，diff 靠任务结束时统一审，节奏顺了，把关从「逐步盯」变成「按段审」。两者与沙箱档位配合使用：模式管过问频率，档位管执行边界，边界怎么划见沙箱模式一篇。

3864 研究的启示：先盯后放

3864 研究的建议值得展开：智能体在陌生代码库里的出错率明显更高——它不了解项目约定、依赖关系与隐性规则，早期动作更像摸石头过河，此时 suggest 的逐步确认恰好补上了上下文缺口，人也顺便建立起对智能体行为风格的预期。等项目跑顺、任务成功率稳定，再升 auto-edit，把确认花在刀刃上。这与智能体技术的一般规律一致：自主执行的可靠性依赖上下文与反馈的积累，通用机制的讨论见AI 智能体一篇。落到操作上，「陌生」与「稳定」不需要凭感觉，下一节给可执行的判断清单。

升级与降级的判断清单

升级到 auto-edit，同时满足三条再动：一是结果稳定，连续几个任务交付的 diff 几乎不用人工返工；二是行为可预期，它选的路径、起的命令与你的习惯一致，没有惊吓动作；三是影响面可控，当前任务不碰 CI 配置、依赖清单与部署脚本这类牵一发动全身的文件。降级回 suggest 的信号也有三个：diff 开始出现方向性错误、命令执行出现意外副作用、任务涉及上述高影响面文件。切换是双向的，别把升级当成单行道——代码库大改、换项目、上线的紧张期，退回 suggest 重新养一段，比事后补救便宜。常见的配置错误清单里，模式与场景错配是高频条目，见配置八错一篇。

自动化场景：豁免审批的风险账

把审批豁免用于无人值守的自动化，是升级路线的极端形态：审批设为不再询问，配合更宽的档位，让智能体在定时任务、批量脚本里全自动跑。风险账要算清：无人值守意味着没人看 diff、没人拦命令，一次方向性错误可能被批量放大；环境里若挂着凭据与密钥，豁免等于把钥匙留给一个会自主执行的程序。要自动化，更稳的路径是分层豁免：任务本身结构化、输入输出封闭的部分放开，涉及网络、部署与高影响面文件的保留确认；再配好工作区隔离与日志留存，出问题能回放。工具选型上，命令行与插件形态的自动化能力不同，对照见编码插件与命令行一篇。想把升级标准落成团队规范，可以让 DeepSeek 按你们的任务类型起草一份模式切换准则，再用豆包对准则做一轮反面用例测试，堵住漏洞再推行。

审批模式速查

• suggest 事事确认，适合陌生库、高影响面、学习期
• auto-edit 改文件免确认、命令仍过问，把关改成按段审
• 3864 研究：陌生库先 suggest，稳定后升 auto-edit
• 升级三条件：结果稳、行为可预期、影响面可控
• 无人值守豁免审批风险大，分层豁免加日志回放更稳

关于审批模式的三问三答

• auto-edit 下还需要看 diff 吗？：需要，只是看的时点变了。逐步确认省掉后，任务结束统一过一遍 diff 成了主要把关动作，合并前一律过目，别让「免确认」滑成「免审查」。
• 升到 auto-edit 后又频繁出错，怪模式吗？：先查任务是否换型。模式与任务匹配才会顺，同一档位下从修小 bug 换成大重构，出错率本就会抬升，按降级信号退回 suggest 重新养一段。
• 全自动档什么时候才值得开？：输入输出封闭、可整体回滚、环境里没有敏感凭据的结构化任务，且配了工作区隔离与日志留存；满足不了这几条，auto-edit 已经是效率与安全的平衡点。