Claude Code自动模式让通宵编程成为可能

Claude Code 现在两次中断之间的运行时长提升了 9 倍，一名 Nuro 工程师表示，一次长达七小时的夜间运行在清晨产生了三个 Pull Request。这并不意味着软件工程已经实现了自动化。它意味着工作的基本单元正在发生变化，团队在将智能体单独留在代码库、凭证和八小时安静时间之前，需要一种新的运营模式。

我之前低估了权限提示这个瓶颈

很长一段时间，我以为编码智能体的天花板是智能水平：更好的推理、更大的上下文、更深的代码库理解、更可靠的测试失败恢复。

这些都很重要。但另一个天花板就隐藏在眼皮底下：智能体一直在请求我的许可。

读取一个文件。好。编辑一个文件。批准。运行测试。批准。安装声明的依赖。批准。创建分支。批准。提交变更。批准。推送。好，再来一次。

这看起来像是安全措施，但在第二十个提示之后，它不再产生深思熟虑的审查。它产生的是肌肉记忆。Anthropic 表示，Claude Code 用户批准了 93% 的权限提示。这个数字完美地捕捉了问题所在：如果几乎每个提示都得到相同的答案，那么提示就不再作为一种严肃的控制手段。它变成了中断。

而中断对自主性设置了硬性限制。

如果智能体在晚上 10:07 停下来等待运行测试套件，它就无法在我睡觉时工作。如果每个并行工作流都需要我每隔几分钟关注一次，它就无法管理三个并行工作流。如果一个常规的网络请求在第二次迭代后暂停了循环，它就无法对评估指标进行七小时的山丘爬升。

Claude Code 的自动模式改变了这一点。它不再将常规审批决策路由给开发者，而是将它们路由给一个单独的分类器模型，在操作运行前评估拟议的操作。Anthropic 报告称，在整个 Claude Code 使用中，会话现在比之前默认情况下工作时间长 9 倍才出现中断。

引起我关注的案例研究来自 Nuro。Staff 软件工程师 Kai Zhou 描述了在晚上 10 点启动一个智能体，让它运行到凌晨 5 点，然后在早晨发现三个 Pull Request。该智能体正在针对 Nuro 自动驾驶堆栈中的可衡量评估信号工作，而不是模糊地"让代码变得更好"。

这个差异就是整篇文章的核心。

自动模式之所以重要，不是因为它节省了点击。它之所以重要，是因为它将软件工作的实际单元从交互式编码回合改变为有边界的自主工程运行。

但更长并不意味着更好。一个运行时间延长九倍的困惑智能体并不会提高九倍的生产力。它只是会九倍地坚持错误的方向。

能够受益的团队不是那些简单打开自动模式的团队。他们是那些将它与可执行目标、确定性验证、隔离、最小权限、持久的人工检查点和遥测技术结合起来的团队。

不间断执行不是自主性。不间断、有边界、可自我验证的执行才是。

9 倍这个数字是真实的，但有特定背景。Anthropic 表示，Claude Code 比之前默认情况下中断间隔延长了 9 倍。它并没有说每个任务都快了 9 倍或正确了 9 倍。

通宵 PR 的例子也是真实的。一位 Nuro 工程师报告了一次从晚上 10 点到凌晨 5 点的运行，产生了三个 PR。这是一个围绕可衡量评估指标构建的案例研究，而不是通用基准。

自动模式不是 --dangerously-skip-permissions。它使用单独的分类器来审查操作，加上输入层提示注入探测。绕过模式会移除这些安全检查。

Pull Request 成为交付边界。夜间智能体应该创建可审查的证据，而不是合并自己的工作、部署到生产环境或在外部通信，而不需要明确的关卡。

验证是让你能够离开的关键。测试、构建、基准测试、截图、评估分数和 Stop 钩子将"看起来完成了"转化为可执行的通过/失败条件。

团队仍然需要硬性控制。对推送和 PR 创建使用 ask 规则，对禁止操作使用 deny 规则，对操作系统级隔离使用沙箱、范围凭证、MCP 限制、钩子、分支保护和遥测。

从可逆的工作开始。文档、测试覆盖、lint 清理、依赖维护、有边界的重构、基准优化和问题复现比生产基础设施或模糊的架构更适合通宵候选任务。

新的开发者技能是委托设计。你的工作从批准命令转变为设计环境、目标、验证器、边界、证据和审查路径。

首先，自动模式实际上做了什么

最容易犯的错误是认为自动模式是跳过权限的更好听的名字。它不是。

Claude Code 有几种权限模式，差异很重要：

自动模式增加了两个主要防御。

1. 输入层提示注入探测

工具结果是敌对指令通常进入智能体上下文的地方。README、issue 正文、网页、shell 输出或 MCP 响应可能包含告诉模型忽略用户并采取无关操作的文本。

在 Claude 读取工具结果之前，服务器端探测会扫描可疑内容。当它检测到可能的注入尝试时，会添加一条警告，告诉主智能体将内容视为不受信任的，并重新锚定到用户的实际请求。

2. 输出层操作分类器

在 consequential 工具调用执行之前，一个单独的模型会评估该操作是否安全且已授权。

当前的决策路径大致是：

显式规则首先解析。匹配的 deny 规则会阻止。匹配的 ask 规则会提示。狭窄的 allow 规则可能会批准。

只读工具和项目内文件编辑通常会进行。常规编码不应该在每次编辑时都支付分类器延迟。

高风险操作交给分类器。Shell 命令、网络操作、外部集成、项目外文件系统访问、子智能体委托和其他 consequential 调用会受到审查。

被阻止的操作返回给 Claude。Claude 可以尝试更安全的方法，而不是立即停止。

重复阻止触发后备保护。在交互式会话中，连续三次拒绝或总共二十次拒绝会暂停自动模式并将控制权返回给人类。非交互式行为的约束更严格，因为可能没有人工提示可用。

分类器在推理上是故意盲目的。它能看到用户的消息和 Claude 提议的工具调用，但 Anthropic 剥离了 Claude 有说服力的散文和原始工具结果。这防止了主智能体通过谈话来说服审查者批准一个操作，并减少了对注入内容的暴露。

这是一个微妙但强有力的设计选择。分类器判断 Claude 即将做什么，锚定在人类实际要求的内容上。它不会判断 Claude 对为什么该操作"没问题"的有把握的解释。

默认情况下它阻止什么

内置规则涵盖以下类别：

下载并执行不受信任的代码，包括 curl | bash；

泄露密钥或敏感数据；

强制推送和破坏性 git 操作；

生产部署和数据库迁移；

云存储中的批量删除；

授予 IAM 或仓库权限；

更改共享基础设施；

绕过失败的安全检查；

将凭证写入日志或文件；

未经人工批准合并 Pull Request；

批准 Claude 自己的 Pull Request；

禁用 CI 检查；以及

启动另一个无限制的自主智能体。

这是一个比跳过权限更安全的状态。

Anthropic 的工程评估报告，在两个分类器阶段之后，10,000 个真实内部工具调用中有 0.4% 的误报率。更重要的是，它报告了一小部分 52 个真实的过度热情操作中有 17% 的漏报率。Anthropic 称这个为"诚实的数字"。

这个 17% 应该让任何将自动模式描述为不可逾越的安全边界的人停下来。分类器捕获了 substantial 风险，但它仍然可能将类似批准的语言误认为授权。如果仔细的人工审查是高风险操作的必要条件，自动模式不是它的替代品。

正确的比较不是"自动模式与完美安全"。将它与疲惫的人类批准常规提示、无限制的绕过模式和在没有隔离的情况下运行相同任务进行比较。风险取决于任务和环境，而不是模式名称。

为什么 9 倍更长改变了工作单元

9 倍这个数字很容易变成营销：睡觉时多九倍的编码。

这不是 Anthropic 测量的内容。

声明是会话比之前默认情况下中断间隔延长了 9 倍。它衡量的是连续性，而不是速度、正确性或业务价值。

尽管如此，连续性是一项基础能力。大多数有意义的软件任务不是一次性生成。它们是循环：

$$ \text{inspect} \rightarrow \text{plan} \rightarrow \text{edit} \rightarrow \text{test} \rightarrow \text{diagnose} \rightarrow \text{repeat} $$

每一次审批提示都会打断这个循环。消除常规中断后，之前需要主动监督的任务就能变成一个排队的执行单元。

这改变了开发者的角色。

在一次交互式对话中，我可以持续引导，从而弥补任务定义不够清晰的问题。我会在错误模块、过度复杂的抽象或被误解的需求还没有造成连锁反应之前就加以纠正。

在通宵运行中，这个反馈通道消失了。任务包必须承载我以往靠注意力提供的东西：

• 相关的仓库和分支；
• 建立基线的命令；
• 可执行的完成标准；
• 迭代和成本限制；
• 需要人工介入的操作；
• 最终报告中需提供的证据；
• 交付边界，通常是一个 Pull Request。

工作不再是"让 Claude 写代码"，而是设计一个能在开发者缺席时存活的运行方案。

这就是为什么我认为 Auto Mode 标志着通宵软件工程的开始。真正有意思的功能不是自动点审批，而是将工程意图转化为一个持久的、可审查的作业单元。

通宵 PR 是正确的交付原语

为什么是 Pull Request 而不是直接合并？因为 PR 是自主生产与责任接受之间自然的边界线。

它给 AI 智能体留出了执行有用工作的空间：

• 创建隔离的分支或工作树；
• 检查代码和历史记录；
• 运行构建和基准测试；
• 提交一致的变更；
• 提交包含证据的结果。

但它保留了团队的控制平面：

• 分支保护仍然适用；
• 必需的 CI 检查仍然运行；
• CODEOWNERS 可以路由评审；
• 安全扫描器可以检查 diff；
• 人工可以比对行为与意图；
• 回滚仍然简单直接；
• 部署仍在审批下游进行。

安全的思维模型是：

AI 智能体负责准备，团队负责接受。

这也是我不会用变更行数来衡量通宵 AI 智能体的原因。大量 diff 可能表示有进展，但也可能表示范围漂移。更好的结果指标包括：

• 已验证关闭的问题；
• 新增并通过的测试；
• 基准测试改善；
• 内存或延迟降低；
• 迁移项完成；
• 可复现的 bug 修复；
• CI 稳定性提升；
• 每个 PR 的评审发现；
• 接受或拒绝结果所需的人工时间。

Pull Request 是围绕自主工作的评审信封。

为什么 Nuro 的通宵运行有效

Nuro 的案例很重要，因为它揭示了良好自主任务的样子。

他们的 AI 智能体没有被告知"改进自动驾驶"。它是对抗现有测试系统中的评估指标和假阴性而工作的。它可以提出变更、运行实验、观察指标是否改善，并迭代。Nuro 的另一个团队使用类似模式来减少特定二进制文件的内存占用。

这是一个爬山问题：

$$ \theta_{t+1} = \theta_t + \Delta_t $$

$$ Q(\theta_{t+1}) > Q(\theta_t) $$

以及安全约束，例如：

$$ T(\theta_{t+1}) = \text{pass} $$

其中 $Q$ 是目标指标，$T$ 是回归测试套件。

AI 智能体不需要人工告诉它第五次迭代是否比第四次好。评估器来做这件事。

这种模式的泛化能力很强：

那些弱版本的提示则相应地模糊：

"让服务更快。"

"清理认证代码。"

"提高测试质量。"

"现代化前端。"

"修复任何可疑的地方。"

这些是探索性提示，不是通宵合约。它们缺乏有界的靶目标和停止条件。把一个交给不间断的 AI 智能体，你创造的是运动，而不是进展。

我的通宵工程合约

在让 AI 智能体无人值守运行之前，我需要七样东西形成书面约定。

1. 精确陈述的一个结果。

在不改变生成输出的前提下，将 report-worker 的峰值内存在使用已提交的基准测试 fixture 上降低至少 15%。

2. 命名它可以更改的目录、组件或接口。

仅在 services/report-worker、其测试和基准测试工具中工作。不要更改共享的序列化契约。

3. 告诉它如何建立前置状态。

运行 npm run benchmark:memory 三次并记录编辑前的中位峰值 RSS。

4. 让成功可执行。

运行单元测试、契约测试、类型检查和五次基准测试重复。任何改变了 fixture 输出或使 p95 运行时恶化超过 3% 的候选方案都应被拒绝。

5. 陈述它不能做什么，然后在提示之外强制执行重要的部分。

不要合并、不要部署、不要修改 CI 策略、不要联系 GitHub 以外的外部系统、不要暴露密钥、不要禁用测试。不要重写共享历史。

6. 停止条件。

在六次实现尝试后、90 分钟无明显改善后，或在配置的 token 预算耗尽后停止。保留最佳已验证候选方案。

7. 证据和交接。

定义早晨的报告。

打开一个包含基线、最终指标、运行的命令、测试结果、权衡取舍、剩余风险和被拒绝方案的草稿 PR。如果没有找到安全的改进，则不打开 PR，返回一份调查报告。

必须允许自主运行找不到可接受的变更。否则它就会被激励去制造一个 diff。

一个可直接使用的通宵提示

以下是我实际会使用的模板：

Work on issue #842 in an isolated branch.

Goal:
Reduce peak memory for services/report-worker by at least 15% on the
checked-in benchmark fixture without changing output.

Scope:
- You may edit services/report-worker/**, its tests, and benchmark scripts.
- Do not change shared API or serialization contracts.
- Do not modify CI policy, repository permissions, or production systems.

Method:
1. Read the issue, relevant code, tests, and recent history.
2. Run the benchmark three times and record the median baseline.
3. Write a short plan in the session before editing.
4. Make the smallest plausible change.
5. Run unit tests, contract tests, typecheck, and five benchmark repetitions.
6. Iterate only when the measurements identify a concrete next step.
7. Use a fresh subagent to review the final diff for correctness, scope drift,
   weakened tests, and unsupported benchmark claims.

Stop conditions:
- Success: median peak RSS improves by at least 15%, output fixtures are
  identical, all required checks pass, and p95 runtime regresses by no more
  than 3%.
- Failure: stop after six implementation attempts or 90 minutes without a
  new best result.
- Safety: stop rather than bypassing a blocked action or failed safety check.

Delivery:
- You may commit to the task branch.
- Do not merge or deploy.
- Open a draft PR only if every success condition passes.
- Include baseline and final measurements, commands run, test evidence,
  rejected approaches, known risks, and rollback instructions in the PR.
- If no candidate passes, leave the branch unpushed and report what you learned.

对于非交互式本地运行，官方模式是：

claude --permission-mode auto -p "$(cat overnight-task.txt)"

Get-Content .\overnight-task.txt -Raw | claude --permission-mode auto -p

如果笔记本电脑需要合上，不要假装本地终端是云端作业。改用隔离的云端会话：

claude --cloud "Execute the approved plan in docs/overnight-task.md"

云端会话独立持久化，可以运行在并行 VM 中，并可从网页或移动应用监控。本地 -p 运行仍然与启动它们的机器和进程绑定。

团队仍然需要的安全栈

Auto Mode 是其中一层。生产级自主能力来自以不同方式失效的多个层。

第一层：持久的权限规则

当某个操作被允许但必须经过人工检查点时，使用 ask 规则。当某操作绝对不能发生时，使用 deny 规则。

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)",
      "Bash(terraform apply *)",
      "Bash(kubectl apply *)"
    ],
    "deny": [
      "Bash(git push --force *)",
      "Bash(terraform destroy *)",
      "Bash(pulumi destroy *)",
      "Read(//**/.env)"
    ]
  }
}

Auto Mode 默认已经阻止了许多危险操作，但显式规则表达了你的团队策略，而不是依赖通用分类器。

不要仅仅依赖提示中的"不要推送"。分类器会将对话边界视为有意义的，但压缩可能会删除该消息。设置规则在上下文压缩中存活下来。

第二层：配置的信任边界

默认情况下，Auto Mode 信任工作仓库和会话启动时配置的远程。你的内部 GitHub 组织、包注册表、制品存储和云存储桶不会仅仅因为属于你的公司就被自动信任。

在用户设置或托管设置中配置环境：

保留 $defaults。省略它会用你自定义的列表替换 Anthropic 内置的列表。这是专家级定制，有非常锋利的边缘。

检查分类器实际会使用什么：

claude auto-mode defaults
claude auto-mode config
claude auto-mode critique

第三层：操作系统级沙箱

权限规则决定一个命令是否可以运行。沙箱限制进程运行后能访问什么。

这个区别至关重要。一个看似无害的命令可能执行被污染的依赖或脚本。模型级权限分析无法提供与操作系统边界相同的安全保证。

一个严格的托管基线配置如下：

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "strictAllowlist": true,
      "allowedDomains": [
        "api.github.com",
        "github.com",
        "registry.npmjs.org"
      ]
    },
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "AWS_SECRET_ACCESS_KEY", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

内置沙箱支持 macOS、Linux 和 WSL2。原生 Windows 不支持，因此 Windows 团队应使用 WSL2、开发容器、或其他容器运行时、或虚拟机来进行隔离的无人值守运行。

请记住，内置沙箱主要约束 Bash 和子进程。内置文件工具和 MCP 工具各有其自身的权限边界。深度防御意味着要配置所有这些层面。

第四层：受限凭证

智能体不应继承你的整个开发者身份。

给一夜编码运行设置如下限制：

• 仅可访问目标仓库；
• 仅可推送到任务分支；
• 尽可能以只读方式访问 issue；
• 不可持有生产云凭证；
• 不可使用个人 SSH agent；
• 不可发布包；
• 不可拥有组织管理员范围；以及
• 不可批准或合并自己的 PR。

Cloud Claude Code 会话增加了有用的保护：隔离虚拟机、网络控制、安全凭证代理、分支限制、审计日志和自动清理。但一个关联的 GitHub 身份仍然可以看到该账户能访问的内容。仓库访问必须在 GitHub 层面约束，而不能仅依赖 Claude GitHub App 的安装来假设。

第五层：受限 MCP 和外部工具

MCP 将智能体从编码工具转变为跨 Slack、Jira、数据库、云 API、浏览器和内部系统的操作者。白天这很强大，夜间则可能很鲁莽。

使用权限规则拒绝整个服务器或要求对有副作用的工具进行审批：

{
  "permissions": {
    "ask": [
      "mcp__slack__*",
      "mcp__github__create_pull_request_review",
      "mcp__jira__create_issue"
    ],
    "deny": [
      "mcp__production_database__*",
      "mcp__pagerduty__*"
    ]
  }
}

确切的工具名称取决于你的服务器。在编写策略前先检查它们。对于企业部署，将客户端规则与组织 MCP 允许列表、管理代理和服务器端授权结合使用。本地规则不能替代在服务端约束凭证。

Garner Health 配置 Auto Mode 不批准与他人通信的操作。我认同这个边界。夜间智能体可以起草 Slack 消息、邮件、issue 评论或审查，但以人类声音行事通常需要人类参与。

第六层：确定性钩子

提示词是建议性的。钩子则是可执行的。

PreToolUse 钩子可以在执行前阻止破坏性命令。Stop 钩子可以在测试失败时阻止 Claude 宣布成功。TaskCompleted 钩子可以保持子任务处于开放状态，直到必需的检查通过。

最常用的夜间关卡通常是一个确定性的 Stop 钩子：

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "npm run verify:overnight",
            "timeout": 600
          }
        ]
      }
    ]
  }
}

脚本只有在完整完成契约通过时才应返回成功。对于策略钩子，要仔细测试失败语义：Claude Code 使用退出码 2 作为命令钩子的阻塞信号。常规的退出码 1 对大多数钩子事件是非阻塞的，除非你返回有效的决策 JSON。

钩子本身以用户权限运行，可能成为供应链风险。在无人值守的 -p 运行中，仓库提供的钩子可以在没有交互式信任对话框的情况下执行。审查 .claude/settings.json，对确定性脚本调用使用 --bare，限制设置来源，或在运行陌生代码时禁用项目钩子。

第七层：独立验证和遥测

编写代码的智能体不应该是唯一审查它的智能体。

使用一个新的子智能体或第二个会话来仅检查计划、diff、测试和验收标准。让它找出正确性差距、被削弱的断言、范围漂移、安全回归和缺乏证据支持的声明。当目标是发布关卡时，不要要求它做风格评论。

然后监控系统本身。

Claude Code 为会话、提交、拉取请求、成本、token 和活跃时间导出 OpenTelemetry 指标。其事件涵盖工具决策、执行工具、MCP 连接、钩子、权限模式变更和错误。我会追踪无人值守完成率、Auto Mode 拒绝次数、每次验收的成本。