希望 AI 编程助手少问几次、把事情做完，是个合理诉求。但从“不要每一步都等我确认”，直接跳到“给它更多权限”，中间漏掉了一个问题：它究竟要做到哪里才算完成？
今天围绕 Codex 自主推进的讨论，让我重新拆开了三个经常混用的概念：任务终点、变更隔离和安全隔离。
本文整理的是任务设计原则，不是某套自动审批配置已经生效的验收报告，也不提供关闭安全机制的操作配方。
🎯 先解决终点不清，而不是权限不够
“帮我把这个功能做好”听起来明确，实际至少藏着几种不同终点：改完代码、测试通过、本地提交、推送远端，或者部署上线。
这些动作的影响范围并不相同。助手如果不知道应该在哪一步停下，就容易出现两种相反的问题：每走一步都回来问，或者把“做好”理解成可以一路部署。
更好的任务描述，是把允许连续执行的工作和必须停下的边界一起交代。例如：
在指定代码范围内实现约定功能，补充测试，运行已有检查；对本次修改引入的问题自行修复。检查通过后创建本地提交，并交付变更摘要与测试结果。不要推送或部署，不修改全局设置；若需要访问凭据、删除已有数据或扩大修改范围，停下说明原因。
这只是一个示例，具体终点应由任务授权决定。关键不是把清单写得很长，而是让助手知道：哪些步骤可以自己衔接，遇到什么情况不能继续。
自主推进，是在已授权范围内减少无意义的交接，不是自行扩大任务范围。
🌿 分支和 worktree 隔离的是代码变更
独立分支让修改有清晰归属；worktree 则提供另一份工作目录，方便并行处理不同任务，减少未提交改动混在一起的机会。
它们解决的是工程协作问题：这批修改属于谁、如何查看差异、如何合并或撤回。
但 worktree 并没有因此成为安全沙箱。进程能读取哪些文件、访问哪些网络、调用哪些系统能力，仍取决于实际执行环境的权限和限制。
同样，Git 能帮助撤回已记录的代码变化，却不能自动收回已经发送的数据，也不能替外部服务撤销一次操作。
所以，“在独立 worktree 里执行”不能被翻译成“怎么做都不会影响其他东西”。变更容易整理，不等于行为受到安全隔离。
🧱 沙箱与审批也不是同一层保护
安全沙箱用于约束执行能力，例如允许访问的文件范围或网络能力；具体能限制什么，需要看实现和当前生效的策略。
审批机制则处理另一件事：某个动作是否需要批准，以及由谁批准。
把审批交给自动化判断，不等于危险动作一定会转交人工；把执行限定在工作区，也不等于工作区里的所有改动都可逆。两者都不能靠一个名称就推导出完整的安全保证。
可以用三个问题分清它们：
- 任务边界：这次被授权完成什么，做到哪里停止？
- 变更隔离：修改如何归属、比较、合并和撤回？
- 安全隔离与审批：执行环境实际允许什么，哪些动作需要额外批准？
这几层可以互相配合，却不能互相冒充。提示词中的“不要做”也不能代替执行环境的权限控制。
🧪 验收自主性，要同时看推进和停手
判断助手是否能自主工作，不该只数弹了多少次确认框。确认少了，可能是任务更清楚，也可能只是保护减少了。
更有价值的验收，是选一个范围小、可恢复的任务，事先写明预期结果和停止条件，再观察：
- 能否从修改连续推进到测试，并修复本次引入的问题；
- 是否只改动约定范围，保留已有工作；
- 遇到需要扩大权限或影响外部系统的步骤，是否按约定停下；
- 最终报告能否给出实际检查结果，而不是只说“应该可以”。
边界测试应使用无敏感数据、无真实外部副作用的受控场景，不能为了验证保护是否有效，先在生产环境里冒险。
这类任务验收能证明一次具体执行是否符合约定，不能替代对安全机制本身的验证。配置被接受、任务跑完、边界有效，是不同层次的证据，不应合并成一句“已经安全全自动”。
🐉 少接管过程，不等于放弃边界
我更愿意把自主性理解为：人负责目标、授权和不可跨越的边界；助手负责在其中组织步骤、处理常规失败、拿出完成证据。
如果每一步都要人接管，先检查任务是否缺少终点、输入或验收标准，再判断是否确实需要调整权限。不要拿权限扩张去掩盖任务定义的空白。
值得信任的自主推进，既包括知道下一步怎么做，也包括知道哪一步不能擅自做。
马启航Marvis