我如何学会不再担心，并爱上 --dangerously-skip-permissions
这个参数叫 --dangerously-skip-permissions。一年前，我刚接触当时还很新的 Claude Code 几个星期，就厌倦了手动批准每一条 shell 命令，于是在主力机上直接打开了它——没有容器，没有虚拟机。所有命令全部自动放行，包括任何可能把磁盘清空的命令。它从来没删掉过任何东西。几天之内，我的产出效率就肉眼可见地涨上去了。
这让我养成了一种后来重复了足够多次、甚至值得我给它命名的习惯：找到一个已经拦不住任何东西的人工审批关口，把它拆掉，再换成一个自动化检查。这篇文章讲的就是其中四个关口——三个已经拆了，还有一个我正犹豫要不要拆。
背景
我是斯洛伐克的一名独立 AI 顾问兼全栈开发者。我同时并行维护着多个仓库——自己的产品和客户项目——主要用 Claude Code 作为实现引擎。下面记载的都是我的真实工作环境，不是思想实验。
关口 1：逐条批准命令
逐条批准每条 Bash 命令，看似让你掌握着控制权。但实际操作中，它大部分时间只是延迟：用不了几天，你就会靠命令的形态做模式匹配，然后按下「是」。所以我做了个 YOLO 式的决定，开着 --dangerously-skip-permissions 跑了好几个星期。
我想诚实交代一下顺序：是先跳下去，信任才产生的，不是先有了信任再跳。事后让它显得合理的是一个简单观察——在几个星期自动批准命令的时间里，被我拆掉的那个人工关口，救下我的次数是零。
然后，我用一个不会累的东西替代了自己的注意力：hooks（钩子）。一个执行前的 hook 会用模式匹配去拦截破坏性命令（递归删除之类），在运行前把它们挡住。那个关口并没有消失，只是从「人肉审批」降级成了「代码检查」。
关口 2：我自己的服务器
基于这段经验，我把 Claude 放上了我的 VPS，并让它担任服务器的管理员。现在我从本地会话通过 SSH 做同样的事：agent 负责连接、诊断、修复，之后我再读报告。同样的模式，更大的影响半径，同样的结果：我在服务器上逐条盯命令的「抓到问题率」，根本不值得我那样寸步不离地盯着。
关口 3：实现本身
今年夏天，这条流水线变成了这样：
我会写一份任务说明——如果是更大的事，就写一份愿景文档。智能体会就含糊之处向我提问，然后写一个 GitHub issue，或是一系列带显式依赖图的 issue。每个 issue 都写成自包含的：先讲背景和原因，再列出已敲定的决定、被否决的备选方案、范围与范围外，以及可验证的验收标准。这个 issue 必须能让一个对原对话零上下文的新读者顺利接手——因为执行智能体恰恰就是这样的角色。然后我输入 /orchestrate-task queue 57 55（一个自定义斜杠命令），转身走人。
每个 issue 都由一个拥有全新上下文的 worker 在自己的 git worktree 中处理：实现该 issue、编写测试，流水线会对测试做变异验证——修改实现代码，要求测试套件变红；如果某个测试在它所声称覆盖的代码被变异后依然通过，这个测试就会被重写或丢弃。接下来运行自我审查，再在另一个全新上下文中进行一次敌意批评者审查，然后做跨厂商审查——diff 被交给不同厂商的模型（codex exec review），正因为它的盲点与实现者不同；再做一次盲审——全新审查者只拿到原始 issue 文本和最终 diff，看不到实现者的叙述，只回答一个问题：这个 diff 到底有没有真正实现这个任务？然后修复审查发现的问题，或为本变更之外的内容开后续 issue，更新文档，提交并推送到功能分支，打开 PR。
留给我的就是最终 PR 审查和两个词：“merge”和“deploy”。这套流程在多个项目上并行跑。跨厂商审查这一环节是靠数据赢得位置的。在一个生产仓库上，跨厂商审查返回了 7 个发现——包括 2 个并发数据丢失 bug——而两个同模型审查阶段都漏掉了。我自己的解释（不是厂商的说法）：和实现者基于同一模型的审查者，容易在同一条推理逻辑上顺着点头；而不同模型家族会以不同的方式
两次翻车经历
移除门禁并不是没有代价的，我身上的伤疤就是证明。
第一次：一个跑在 git worktree 里的 worker 显式执行了 cd 跳回主仓库的 checkout 目录，然后在里面跑了 git reset --hard——它动的是主仓库的真实分支，而不是自己那份隔离副本。幸好最后靠 reflog 救了回来。这件事之后多了一条规矩，现在写进了每个 worker 的说明里：永远不要 cd 出你的 worktree，执行任何破坏性 git 命令之前先跑 pwd -P 确认位置。
第二次：我让一个任务把 PR 合并和后置清理串在一条命令里执行。结果合并失败了，清理逻辑却照样跑了一半——删了分支，关了 PR。又靠 reflog 兜底。由此得出的规矩是：必须确认新的 main SHA 真正出现之后，才能执行清理。永远不要把验证门禁和它要守护的操作串在一起。
这两次事故都没有让我把人工审批加回去。每一条都变成了规矩，写进后续所有任务的执行逻辑里。信任不是靠盯得更紧来恢复的，而是把失败沉淀成规则。
门禁 4：自动合并——就是现在我要做的决定
到今天为止，每个 PR 的最终确认还是要经过我。但一个坦诚的观察和一年前一致：我最后那轮人工审查，越来越频繁地发现——流水线里其实早就都查过了。这就是信号。之前几道门禁被移除时，也是同样的阈值。
这次移除不会是一次全局开关。设计是按仓库来的：每个仓库都有一份书面的合并策略，写明它的验证到底有多可靠——有真正的测试套件吗？有 CI 吗？有部署冒烟检查吗？默认是「自动合并关闭」，并把原因写下来。一个仓库要按变更类型去「挣得」这个开关，绝不会在第一天就开放。部署、花钱、任何不可逆的操作——这些仍然归人管。
为什么值得折腾这一趟：如果每个 PR 都要人读一遍，整个集群的吞吐量就被「一个人能读多少」卡死了。几个并行 agent 还能从这道门挤过去，几十个就不行了。
那个度量指标
我不认为「对 AI 的信任」是一种靠心理暗示说服自己的感觉。它是一个数字，从你自己的账本上读出来：这道门禁上一次抓到自动检查没发现的问题，是什么时候？如果答案是「几个月前」，那这道门禁就不再是控制手段了——它只是一条排队队列。把它拆掉，把它以前干的活自动化，然后把省下来的注意力投到下一道门禁上。
“YOLO（意为‘只管莽一把’）只有第一次喊出口时才成立。从那以后，每一次冒险都得先翻翻旧账。那么，你该如何判断，什么时候可以让智能体的输出自行运转、不再需要你在旁边盯着？