我已经说了“把它做完”，为什么 Codex 还是不断停下来问我？
I said "finish it" — why does Codex keep stopping?有一次，我让 Codex 完成一个比较长的开发任务。
我的要求并不含糊：
完成实现
→ 运行测试
→ commit
→ push
→ 创建 PR
→ 等待检查
→ merge
→ 等待部署
→ 完成线上验收
我以为，这已经相当于一次完整授权。
只要没有超出范围、没有出现风险，它应该可以沿着这条链路一直执行下去。
但实际过程并不是这样。
创建 worktree 要停下来，运行本地服务要停下来，访问网络、执行 Git 操作、检查登录状态，也可能停下来。
有些步骤在我看来只是完成任务的正常组成部分，系统却不断把它们重新交给我审批。
真正让我不满的，不是 AI 有安全边界。
而是一个长任务被切成了很多次细小的人工中断。我明明把目标交给了 AI，自己却仍然要守在旁边，反复确认“可以继续”。
如果每隔一会儿就需要我回来点一下允许，这就很难称得上连续执行。
也正是因为这次体验，我才停下来认真搞清楚：
我已经授权了目标，为什么 AI 还是不能自动完成？
后来我发现，我一直把三种不同的“授权”理解成了一件事。
原来，一次 AI 任务至少有三层授权
第一层：任务授权
这是人与 AI 之间的约定。
我告诉它：
- 要完成什么结果；
- 工作范围在哪里；
- 可以做到哪一步；
- 哪些动作已经得到业务授权。
例如，我允许它完成修改、测试、提交、PR、部署和线上验收。
这一层回答的是：
这件事该不该做，做到哪里。
但我允许它 push，不代表系统已经允许它访问网络。
我允许它完成部署，也不代表部署平台已经确认它的登录身份。
第二层：系统执行权限
AI Coding Agent 并不是直接在电脑里随意行动。
它通常运行在一个受限制的环境中。系统会控制：
- 哪些目录可以写；
- 是否允许访问网络；
- 能否启动本地服务；
- 能否修改 Git 相关内容；
- 能否访问工作区之外的文件；
- 哪些操作必须经过审批。
这一层回答的是：
即使任务允许做，这个具体动作能不能直接执行。
这也是我频繁被打断的主要来源。
从我的视角看，“启动服务”和“push 代码”都只是发布流程的一部分；但从系统视角看，它们分别涉及进程、网络和外部状态，需要单独判断。
业务授权和系统权限，并不会自动合并。
第三层：外部身份与权限
即使任务已经授权，系统环境也允许执行，GitHub、部署平台、数据库等外部服务仍然会独立确认：
- 当前登录的是谁；
- 凭据是否可以被当前环境读取；
- 这个账号有没有 push、merge 或部署权限；
- token 是否有效；
- 当前操作是否符合平台自己的权限规则。
这一层回答的是：
你是谁，以及你有没有资格做这件事。
可以把三层授权想成一次出差：
老板同意你出差，不等于机场会取消安检，也不等于酒店已经看过你的身份证。
任务授权确认目标，系统权限控制行动，外部认证证明身份。
任何一层没有处理好，长任务都可能中途停下来。
我不是想取消审批，而是不想审批都来找我
理解这三层之后，我也修正了自己最初的想法。
我原来觉得，解决方法可能是：
把权限全部打开，让 AI 不要再问。
但这其实不是一个好方向。
网络、文件、凭据、生产环境，本来就应该有边界。尤其 AI 可以运行命令、修改代码、连接外部服务时，完全没有限制并不值得追求。
真正的问题不是“为什么存在审批”，而是：
哪些审批真的需要我判断，哪些本可以由系统根据既定规则处理？
我不需要亲自决定每一次本地服务启动是否合理，也不想反复批准已经属于发布流程的常规 Git 操作。
我需要介入的是：
- 产品方向是否发生变化；
- 是否扩大了工作范围；
- 是否改变架构或数据结构；
- 是否涉及新的权限或费用；
- 是否需要破坏性操作；
- 线上是否出现异常。
这才是 PM 或项目负责人应该做的判断。
技术边界仍然可以存在，但不应该每一次都升级成业务决策。
可以先设置一套适合自己的系统默认值
之后，我没有选择把 Codex 的权限全部放开。
我采用的是一套相对保守、但更适合连续工作的默认设置：
- 允许在当前项目或独立 worktree 内正常写入；
- 不额外开放整台电脑或无关目录；
- 网络和工作区外操作仍然受控制；
- 越界操作按需审批；
- 将符合规则的低风险审批交给 Auto-review；
- 外部服务仍然使用各自的登录和权限机制。
这套设置的重点不是“权限更大”，而是：
项目内的日常工作尽量顺畅，真正跨越边界时仍然保留检查。
项目内可写
如果 AI 连当前项目里的文件、Git 状态或独立 worktree 都无法正常处理，开发任务自然会不断停下来。
但这不意味着它需要访问整台电脑。
通常只开放当前项目所需的范围，就已经足够。
网络权限
如果任务明确包含：
- fetch 和 push；
- 创建或更新 PR；
- 检查部署状态；
- 访问必要的远端服务；
就需要提前确认这些操作会怎样审批。
否则，AI 写完代码后才发现不能访问远端，整个“自动发布”就会在半路断掉。
Auto-review
Auto-review 的作用不是取消安全边界，而是改变审批由谁处理。
一些常规、低风险的越界请求，可以先交给自动 reviewer 判断，而不是每次都把用户叫回来。
它解决的是：
是否必须由我亲自点击批准。
它不会自动开放网络，也不会让受保护的路径从此不受限制。
但对我而言，这已经足够重要。
只要系统可以在安全范围内自行判断，我并不在意后台发生了多少次内部审批。我在意的是，任务是否频繁中断我的注意力。
外部认证
外部服务的登录也需要单独处理。
我还遇到过一个容易误判的情况：
普通 sandbox 中的检查显示 GitHub 登录似乎失效，但在能够读取系统 Keychain 的环境里复核，实际登录仍然有效，远端访问也可以正常完成。
这让我学到一个很实用的判断：
当前环境看不到凭据，不等于凭据本身已经失效。
要求用户重新登录前，应该先通过实际远端访问，或者在拥有相同凭据访问条件的环境中复核。
否则，一次环境差异就可能被误判成认证故障，又制造一轮不必要的人工中断。
系统默认值只能解决一部分问题
配置调整之后，我才发现，光把 Auto-review 打开仍然不够。
因为有些暂停并不是系统权限导致的，而是 AI 不确定：
- 我到底允许它做到哪里；
- 下一步是否仍然属于原任务；
- 某个动作是否需要重新获得业务授权；
- 出现变化后应该自行处理还是停下来问我。
所以，“把它全部做完”仍然太模糊。
更有效的方式，是在长任务开始时明确三件事。
第一件事：把结果链说清楚
不要只说：
完成这个功能。
而是说明这次任务到底覆盖哪些阶段：
创建独立工作区
→ 完成实现
→ 运行测试
→ commit
→ push
→ 创建和更新 PR
→ 等待检查
→ merge
→ 等待部署
→ 完成非破坏性线上验收
有些任务只需要写完代码。
有些任务则要求一直做到生产验证。
如果结果链没有讲清楚，AI 到达每一个新阶段时，都可能重新询问：
下一步还要继续吗？
第二件事：说明哪些步骤可以自主处理
例如：
- 从当前主线创建独立工作区；
- 同步最新代码；
- 运行已有测试；
- 修复范围内的检查失败；
- 处理不改变语义的冲突；
- 更新 PR；
- 等待 CI 和部署；
- 完成已经授权的线上检查。
这些步骤可能仍然触发系统层面的安全审批。
但在业务上，它们不应该重新被视为一次新的决策。
也就是说：
系统可以继续检查边界，但 AI 不需要再次问我“是否仍然想完成这个任务”。
第三件事：明确什么情况必须停下来
真正需要人介入的，通常不是常规执行，而是例外。
例如：
- 产品目标发生变化；
- 需要扩大原有范围；
- 需要改变架构；
- shared contract 出现语义冲突；
- 涉及数据迁移或权限变化；
- 需要新的付费调用；
- 出现计划外的破坏性操作；
- 认证经过正确方式复核后确实失效；
- 生产环境出现异常。
这一部分不能省。
否则，“减少审批”很容易变成“让 AI 在不确定时自己猜”。
我现在对完整授权的理解是：
不是告诉 AI 什么都可以做，而是把结果链、自治范围和停止条件说清楚。
一个可以直接复用的长任务授权模板
我后来会在任务开始时，用类似下面的方式表达：
本任务授权覆盖：
- 创建隔离的工作区；
- 完成范围内的实现与测试；
- commit、push、创建和更新 PR；
- 等待检查、处理范围内的非语义冲突并 merge；
- 等待部署并完成非破坏性的生产验证。
以上例行步骤属于同一条结果链，不需要重新作为业务决策询问。
遇到以下情况必须暂停：
- 产品或架构方向变化；
- 工作范围扩大；
- shared contract 出现语义冲突；
- 数据迁移或权限边界变化；
- 新的付费调用；
- 计划外破坏性操作；
- 认证经正确环境复核后确实失效；
- 异常生产状态。
它不能绕过系统安全机制，也不能替代外部登录。
但它能减少另一种常见中断：
AI 因为不知道用户的真实授权边界，而每走一步都回来询问。
调整以后，任务确实更连续了
之后，我用调整后的设置和授权方式完成了另一个长任务。
它覆盖了实现、测试、PR、合并、迁移、部署检查和生产 UAT。
那一次，发布过程中没有再频繁停下来等待我处理审批。
中途仍然遇到过认证环境的假阴性，但 AI 通过实际远端访问复核后继续执行，没有再次要求我重新登录。
这只是一个后续样本，还不能证明以后所有任务都会顺利，也不能证明某项设置让中断下降了多少。
但至少有一件事发生了变化：
系统中的安全判断仍然存在，却不再都变成我的人工工作。
这正是我想要的结果。
最后，我得到的几个 Take away
1. “我允许你完成任务”只解决了第一层授权
它不能自动开放系统权限，也不能替代外部服务的登录和账号权限。
2. 长任务开始前，先检查默认执行环境
至少要知道：
- 当前项目哪里可写；
- 网络如何审批；
- 常规越界请求由谁 review；
- 外部凭据能否在当前环境中正常使用。
不要等任务走到一半，才逐个处理这些基础问题。
3. 用结果链、自治范围和停止条件代替“全部做完”
“全部做完”表达的是意愿。
真正可以执行的授权，需要明确做到哪里、哪些步骤可以自主完成、什么情况必须暂停。
4. 自动化不是权限越大越好
更合理的状态是：
- 常规路径顺畅；
- 低风险审批自动处理；
- 外部身份提前准备；
- 真正的异常仍然找人。
5. 衡量真正落到用户身上的中断
后台存在多少安全判断，我并不在意。
我在意的是：
有多少次真的需要我回来做决定，以及那些决定是否只有我能做。
AI 的自主性，并不是取消所有边界。
我想要的不是一个永远不问的 AI，而是一个只在真正需要我判断时，才停下来问我的 AI。