Claude Code 需要的引导更少，无人值守工作却需要更强的检查

在 Anthropic 从事 Claude Code 工作的 Lydia Hallie 说，能力更强的模型改变了团队的工作方式：它们能承担更长的任务、理解代码库，并验证更多自己的输出。随着能力变化，围绕频繁干预形成的做法也应重新审视。

过去的会话需要更多引导：人们反复纠正模型、强调 CLAUDE.md 中的指令、逐条批准命令，或者采取跳过权限检查这一风险更高的方式。Hallie 将其与 Anthropic 现在的会话对比：它们运行数小时，有时并行运行数十个线程，其中一些会话还负责编排其他会话。

Hallie 说，Anthropic 报告每日改动数从五月约 2500 次增长到九月的 3 万多次。她认为，随着人从各个具体步骤中退出，模型、执行框架或环境必须接手引导、审批和验证。

在她的例子中，旧模型和手动审批设置被替换成 Opus 5.5 和自动模式。她说，新模型在会话中需要的引导更少，并建议重新审视 CLAUDE.md 中反复警告等强调性指令；她称这些指令可能导致额外工具调用或更差的结果。

Hallie 建议保留 Claude 无法从代码推断的信息，例如没有直接引用的遗留依赖。她介绍了 doctor prompt-audit 命令，用来检查项目指令和 skill，找出新模型可能不再需要的内容。

Hallie 说，自动模式对读取或编辑项目文件之外的大多数操作使用独立分类器。它可以允许常规命令，阻止不确定的命令。在她的例子中，向另一个预发布部署仓库推送会被阻止，因为默认信任范围只覆盖当前文件夹和仓库。

如果自动模式提示过于频繁，Hallie 说可以在设置中用自然语言列出信任的仓库、存储桶和域名，包括始终允许或永不允许的操作。这些指令会提供给分类器；她在演讲后面将这种配置与更强的强制限制区别开来。

分类器并不提供保证。Hallie 引述 Anthropic 的一项研究：约 14% 的人识别出明显危险的命令，自动模式则拦截了 89%；此类命令约有十分之一仍然通过。她认为，必须始终生效的规则应在执行框架层面强制实施。

她说，拒绝规则在自动模式分类器之前检查；匹配规则的工具调用根本不会送到分类器。她判断什么值得设为规则的标准是一次错误能否撤销：普通代码改动或许可以回退，但丢失未提交工作或泄露密钥可能更难挽回。

例如，如果环境文件的内容绝不能进入会话，她建议设置拒绝读取的规则。但获准命令可能产生间接影响：普通的 npm test 可能执行依赖或脚本，读取私有文件并连接外部服务器。仅凭工具调用权限，无法限制之后运行的所有内容。

沙箱限制 shell 命令及其子进程可以读取、写入和访问的内容，并由操作系统强制执行边界。Hallie 说，相关拒绝规则可以传给沙箱，使依赖程序也无法打开受保护的环境文件。她指出，默认情况下机器的大部分内容仍可读取，因此其他敏感路径需要各自的限制。

她描述的沙箱覆盖 shell 命令及其子进程，不覆盖 Claude 自身的文件操作、MCP 服务器或钩子。因此 Hallie 建议考虑在独立机器上的云会话中使用全新仓库副本：只要本地环境文件、SSH 密钥和令牌不在仓库里，它们就不会出现在该环境中。

如果云会话需要 API 密钥，Hallie 介绍说，可以使用网络密钥，让会话使用密钥而不将其暴露给模型。她说，网络访问默认仅限包注册表和 GitHub 等已批准服务，其他域名需要显式配置。

临时机器不会撤销离开机器的操作：已推送的提交或通过连接器发送的消息仍会存在。因此 Hallie 在云会话中仍使用自动模式和提交到仓库的拒绝规则，例如防止强制推送或将密钥写入提交。

长时间无人值守的会话同样需要验证。Hallie 以认证 API 迁移为例：模型可能保留旧 API、只迁移新登录流程，或者让所有用户退出登录。如果不检查期望结果，这些做法都可能看似合理。

她建议设置明确的通过或失败检查点，例如测试、构建和截图，并审查这些结果，而不是依赖最终印象。提示词可以定义完成标准、要求拆分带测试的子任务并展示实际输出，但仅靠提示不能保证检查一定运行。

对于必须运行的检查，Hallie 推荐使用钩子，即在指定时点调用的脚本。她的例子是在编辑后运行静态检查、标记任务完成前运行相关测试，并在会话结束前运行完整测试套件。检查失败时，智能体可以尝试其他修复。

Hallie 提醒，在她描述的钩子设置中，退出码 1 不会阻止任务被标记为完成，而退出码 2 会让 Claude 返回并处理问题。她建议据此设计钩子脚本。

独立的云机器让多个会话可以运行而不共享同一个工作文件夹。手动启动和审查每个会话仍然是一种有用的控制方式；Hallie 并未建议每个团队都必须立即自动化这些决策。

无论发起拉取请求的会话如何运行，CI 都能对每个请求提供一致检查。Hallie 介绍了让 Claude 响应失败检查的自动修复能力，并说适当的改动可以启用准备就绪后合并；她强调自动合并不是默认设置，应取决于风险。

她的团队使用具有全新上下文的独立 Claude 会话进行审查，而不是使用编写代码的会话；另外还有其他智能体复核发现的错误。她说，人工审查随风险变化：小型文档或文案修改可能不需要人工，普通产品改动需要一名审查人，风险较高的改动需要两名。

Hallie 描述了一个编排会话：它将较大请求拆成任务、启动独立会话、跟踪结果，并将未完成的工作退回。她以仍处于测试阶段的 Claude Code projects 为例：用户只与一个协调会话交流，而不必逐个管理工作会话。

协调会话可以使用擅长规划和判断结果的模型，工作会话则使用适合实现的模型。Hallie 说，这种项目设置还会自动管理上下文，减少人们决定何时压缩或清除上下文的需要。

她的结论是，过去的职责并未消失，而是转移了：模型引导工作，自动模式处理审批，拒绝规则和环境限制操作，测试、钩子和 CI 检查结果。她建议先配置 CI、网络访问、密钥和设置脚本，再尝试更大的任务，观察会话在哪里仍需要干预。