https://x.com/i/article/2121069162252673024

重新思考 Claude Code 的最佳实践：Anthropic Lydia Hallie 在 AIE Code Summit 2026 上的演讲

Anthropic 技术团队成员 Lydia Hallie，负责 Claude Code 的开发者关系。这次她在 AI Engineer Code Summit 的演讲「Rethinking Claude Code Best Practices」，主题是：模型变好了，过去一年往 Claude Code 里叠加的许多做法，现在反而在拖后腿；她要讲的是面向 Claude 5.5 系列模型的最佳实践，哪些还值得保留，哪些不必再费心。

她自己的日常主力是 Claude Opus 5.5。演讲当周早些时候，Anthropic 发布了 Claude Fable 5.2。在她看来，这类更新模型更擅长长任务、理解代码库，Fable 也更会核验自己的输出。工作方式如果还停留在今年早些时候，就会跟不上了。

会话形态变了，人的位置也变了

Hallie 回顾说，今年早些时候的典型会话还很短。当时常用的是 Opus 4.5 这一档模型，以当时的标准已经很好用，但会更早停下来，人也要不断纠正、不断提醒，还要在 CLAUDE.md 里加上「重要」和感叹号一类的强调。那时还没有自动权限模式（auto mode），要么每条命令都手工批准，要么走风险更高的「跳过权限检查」。人几乎还在每一步里。

现在 Anthropic 内部已不是「一次开一两个会话」。她描述的是几十个会话同时跑，一跑就是数小时，过程中自己核验结果，有的还会编排其他会话。人不再盯着几乎每一步，而更像是在管理大批会话。

她提到公司 10 月 13 日的工程博客 《Redesigning source control at Anthropic》：Anthropic 每天合入的代码变更，从 5 月大约 2500 个，到 9 月超过 3 万个。Hallie 引用它，是为了说明开发者必须重新想清楚注意力该放在哪里。

她的判断是：今年早些时候的最佳实践，核心是引导会话、批准或拒绝命令、限制输出，以及亲手启动会话。人一旦从这些环节里退出来，就要由模型、运行时和它所在的环境接上。接下来最要紧的是两个问题：同时跑这么多会话、又不再逐条批准时，代码质量靠什么保住；会话连续跑数小时、人又不在旁边时，安全靠什么保住。

先换默认值：少写说明书，把审批交给分类器

她建议先把会话改成今天的默认配置：模型换成 Opus 5.5，权限改成 auto mode。Anthropic 在 8 月把 auto mode 设成了默认权限模式。官方产品文章 《Auto mode is now the default in Claude Code》 写道：自 8 月 14 日起，Pro、Max 和 Team 计划的新会话默认进入 auto mode。新模型更善于理解意图和代码库，中途不必再那么频繁地纠正，也不必再批准每一条命令。

CLAUDE.md 也要跟着改。对今天的模型来说，「重要」「绝对不要」和一串感叹号往往不再需要，甚至会把模型带偏，工具调用变多，效果变差。现在这份文件只应留下模型从代码里看不见的信息：某个服务仍在使用一处遗留来源、但代码里没有直接引用，这类背景值得保留；技术栈是什么、该去哪里找文件，通常不必再写。Hallie 推荐用 /doctor prompt-audit，按特定模型检查 CLAUDE.md 和 skills，标出为旧模型写的、或已经不再需要的指令，这也与官方 最佳实践文档 一致。

auto mode 本身是一层单独的分类器，几乎会审查「在项目里读文件或改文件」之外的操作：放行自认为安全的命令，例如跑测试、装依赖；对没有把握的命令则拦住。默认只信任当前文件夹和当前仓库，所以如果要向另一个部署仓库推送，分类器仍可能拦截，人就又回到循环里。她说，多数情况下默认值已经够用；若即便开了 auto mode 仍要频繁点批准，应先看设置，用自然语言写明信任哪些仓库、存储桶和域名，以及哪些操作应始终允许、哪些绝不能做。官方文档把这项配置写在 autoMode.environment，也提供 /auto-mode-setup 来起草。默认值换成之后，引导和大部分批准都可以交出去；更难的是人不在场时，怎样仍然经得起检验。

分类器不是保证：规则在前，环境兜底

Hallie 提醒，升级模型和打开 auto mode，仍然只是在「跟模型合作」。多数时候它会按你说的做，但这不是保证。她引用 8 月发表的一项研究：面对一条明显危险的命令，只有约 14% 的人拦住了它，auto mode 拦住了 89%，因此大约每 10 条里仍会漏过 1 条。

这组数字可以在上述官方产品文里对上。公司通过研究供应商聘请了 1053 名付费专业测试者，在专门搭建的测试环境里工作，并不是在他们自己的代码库里；每段会话中途，会把其中一条权限提示换成一条明显危险的命令，但并不会真的执行，只是改了测试者看到的文本。结果是：人拦住了 13.6%（143/1053），auto mode 拦住了 89%（937/1053）。会话越长，人的表现越差：前段大约拦住 17%，在已经处理 50 条以上提示之后降到大约 5%，而 auto mode 并不随会话变长而下滑。Hallie 用「约 14%」和「约十分之一仍会通过」来概括，和原文一致。

若要的是「保证不会发生」，只能写进运行时去强制执行。这正是权限规则仍然重要的原因。项目里如果有针对某类工具调用的拒绝规则（deny rule），Claude Code 会在 auto mode 分类器看到它之前先检查；一旦匹配到，分类器根本不会再看。官方权限文档也写明：拒绝规则和 PreToolUse hooks 在分类器之前生效，在所有权限模式里都有效。

那什么该写成规则，什么可以交给已经变强的模型？判断标准很具体：如果 Claude 这次做错了，你还能收回来吗？写错了代码还可以回退，这类事可以留给模型；如果它丢掉了未提交的修改，或者读走了密钥、密钥已经进了会话记录，就应该写成规则。例如，默认情况下 auto mode 可以批准读取 .env；官方文档也写着这一点。若希望它永远读不到这个文件，就应加上拒绝规则，这样即使用 cat 也打不开。

权限规则只能决定一条工具调用启不启动，不能限制它启动之后能碰到什么。她举了 npm test 的例子：auto mode 会放行这条常见测试命令，但脚本跑起来时会执行你没写过的代码，比如依赖，或者 Claude 临时写来做检查的脚本。一旦其中有被篡改的部分，它仍可能打开 .env 或 SSH 密钥，再发到你没见过的服务器。即便人还在逐条批准，面对「只是跑测试」也往往会直接点同意。所以不能简单禁止这条命令，又必须限制它的副作用，也就是限制运行环境。

在本地机器上，可以把这类命令放进沙箱，由操作系统控制它能读哪些文件、能写哪些目录、能访问哪些主机，对子进程同样生效。沙箱打开后，文件和网络限制会被交给操作系统，依赖再去打 .env 就会被拦住。她也提醒：默认情况下沙箱仍可能读到机器上的不少内容，若在意 SSH 密钥，还要另加规则；未批准的主机也访问不了。更重要的是，沙箱只管 shell 命令及其子进程，文件工具、MCP 服务器和 hooks 仍在沙箱外。官方 沙箱环境说明 也写明：内置 Bash 沙箱只约束 shell；要把这几类一并关进边界，需要沙箱运行时、容器、虚拟机，或云端会话。

因此，她更推荐把整段会话放到「本来就不存在那些本地秘密」的地方，也就是 Claude 的云端会话：独立机器、一份全新的仓库副本，笔记本合上也能继续跑，这正适合一跑数小时的任务。若中途仍需要 API 密钥，可以做成网络密钥（network secret）：会话可以提示缺少密钥并使用它，但密钥值不会送给模型。默认网络访问也只开放软件包仓库和 GitHub 一类地址，其他域名要明确加进环境。官方 云端会话文档 也写明，这类凭证由代理在请求离开会话后再附加。

她还补了一句很关键的话：这台机器是一次性的，但从里面出去的东西不是，比如已经推送的提交，或通过连接器发出的消息。所以即便在云端，仍应开着 auto mode，并把拒绝规则提交进仓库，让规则跟着代码走，以便拦住强制推送或提交里夹带密钥这类事。

人不在场时，靠能判对错的检查点

安全之外，还要确认 Claude 做的是你真正要的事。人在循环里时，质量感来自已经看过每一处改动、批准过每一条命令；现在它在后台跑数小时，人不会再读完每一个文件。她举的例子是把认证迁移到新 API：模型很能理解目标，但沿途仍有许多小决定。同一条提示，一次运行可能迁过去却留下旧 API，一次可能只迁新登录，另一次可能把所有人登出。这些看起来都说得通，所以要沿途设置核验点，让 Claude 持续核验自己的结果。核验点可以是任何能给出通过或失败的东西：测试、构建、截图，都可以。若某次运行会把所有人登出，它过不了第一道检查，就得另找办法。

设置方式也分层次。最简单的是写在提示里：说明怎样算做完，让它拆成带测试的任务；她还喜欢要求它出示实际输出，因为当时你并不在场。但提示同样不是保证。必须执行的检查，她会用 hooks，也就是 Claude Code 在特定时机运行的脚本：例如每次改文件后跑 linter，要把某项任务标为完成时跑相关测试，整个会话要结束时再跑完整测试套件。失败了，它就得回去修，直到通过。

这里有一个容易忽略的细节：多数测试工具失败时的退出码是 1，任务仍可能被标为完成。要把失败送回给 Claude 去修，脚本应使用退出码 2。官方最佳实践和 hooks 文档都写明：Stop hook 在 Claude 试图结束回合时运行脚本，若以退出码 2 退出，就会阻止结束并把原因反馈给模型，让它继续工作。

有了一个自己放心交给它单独跑的会话之后，才适合同时开更多。每个会话有自己的机器，不必再那么操心本地的 worktree；但若每个会话仍由你启动、仍由你审完，人其实还在「开场」和「收场」里。她认为这时最该先补上的是 CI：这些会话最终都会开出拉取请求，CI 用同一套检查覆盖每一个，而不论会话当初如何配置。打开自动修复后，Claude 还能在检查失败时回去改，避免把评审时间花在检查本已能抓住的问题上。对一部分变更，也可以在检查全部通过后自动合并，但她强调这不是默认，要看风险。

她还介绍了自己团队的做法：每个拉取请求都会先由 Claude 审一遍，但不是写代码的那个会话，而是带着全新上下文，并另有一组智能体复核它找出的每个缺陷。人要审多少，取决于风险：文档或文案一类较小的改动，自动化检查通过后可以不再经人手；普通产品改动也许只需一名审阅者；风险较高的可能需要两名。这是她对团队流程的描述，并非产品默认策略。

从自己开会话，到让一个编排会话去开

再往前一步，不必再亲手启动每一个会话。她坦言自己不擅长频繁切换上下文，同时管理太多会话并不总是顺利。替代办法是只保留一个主会话做编排：告诉它要完成什么，由它拆分任务、为每个任务启动其他会话，并跟踪返回结果。这些新会话在 Claude Code 里称为 threads。人只需和这一个主会话对话。

主会话本身并不写代码，因此更适合用擅长决定下一步、并判断返回结果够不够的模型，她点名的是 Fable；具体干活的线程则适合用 Opus 5.5。若返回的结果其实还没做完，编排会话会把它打回去，直到真正完成并通过各项检查。这种结构也不必再自己管理上下文，或想着何时压缩、清空。她把这套做法对应到仍处于测试阶段的 Claude Code Projects。官方文档确认它目前是公开测试版，面向 Pro、Max 和 Ultra 计划逐步放开：项目里有一个负责协调的长会话，以及它启动的多条并行线程，通常是云端会话，两边的模型也可以分别指定。文档默认两边都用 Opus；Hallie 给出的是另一种分工：判断用 Fable，执行用 Opus 5.5。

回看那些旧的最佳实践，它们并没有消失，只是换了位置。模型负责引导，auto mode 负责批准，拒绝规则和环境限制可能发生的事，测试、hooks 和 CI 负责检查，最终 Claude 也可以自己把会话拉起来。人真正留下来的，是启动第一个会话，以及审阅最终结果。

若要在自己的环境里尝试，她的建议很具体：先交给 Claude 一件比平常大得多的任务，确认 CI 真能抓住你在意的问题，再配置好环境，包括网络访问、密钥和启动脚本，然后在云端启动，观察会话卡在哪里、你还在哪些环节里。卡住的地方，就是下一步该交出去的地方。