Agentic Coding 最佳实践：CLAUDE.md、并行会话与上下文管理

这篇回答了一个问题：同样用 Claude Code，为什么有人只能「盯着跑」，有人却能「放手跑」。

最值得拿走的是两条主线：一是给 Claude 一个它能自己跑的验证检查——测试、构建退出码或截图比对——让 Agent 循环自己闭合，你从验证者变成例外处理者；二是把上下文窗口当最稀缺资源来管——/clear、子代理调研、自动压缩都是为此服务。最容易误用的是 CLAUDE.md：写得越长越没用，规则被淹没后 Claude 会直接无视，宁可十行以内、只写代码推不出来的约定。

相比站内已有的 Agent 概念介绍，这篇把原则落到了具体按键、命令与配置文件的写法，且全部来自 Anthropic 内部团队的实战沉淀。中文读者落地时还需叠加国内语境：gh、aws 等 CLI 依赖与权限白名单要结合内网网络和认证体系重建，不能照搬原文的开箱假设。

读完今天就做一件事：为你最常用的 Claude Code 会话写一份十行以内的 CLAUDE.md，并在提示里固定加一句「完成后运行测试并贴出输出」。

—— FDEChina编辑部 · 实战派

Claude Code 是一个 Agent 化的编程环境（agentic coding environment）。与「回答完问题就干等」的聊天机器人不同，Claude Code 能读你的文件、运行命令、直接修改代码，并且在你旁观、随时纠偏、或彻底放手走开的情况下自主推进问题。

这改变了你的工作方式。你不再自己写代码、再让 Claude 来复查，而是描述你想要什么，由 Claude 想明白怎么构建——探索、规划、实现，都由它来做。

但这种自主性带着学习曲线。Claude 在一些约束下工作，你需要先理解它们。

本指南汇总了在 Anthropic 内部团队以及众多工程师的各种代码库、语言与环境中被反复验证有效的模式。想了解 Agent 循环（agentic loop）在底层的运转方式，可阅读《How Claude Code works》。

大多数最佳实践都建立在同一条约束之上：Claude 的上下文窗口（context window）填满得很快，而且随着窗口被填满，模型表现会下滑。

上下文窗口里装着你的整段对话：每一条消息、Claude 读过的每个文件、每条命令的输出。它填满的速度超出多数人的预期——一次调试会话或一轮代码库探索，就可能生成并消耗数以万计的 token。

这件事之所以重要，是因为 LLM 的性能会随上下文变满而退化。窗口接近写满时，Claude 可能开始「忘掉」较早的指令，或犯更多错误。上下文窗口是最值得花力气管理的资源。想直观看到一个会话如何被填满，可以观看官方的交互式演示，了解启动时加载了什么、每次读文件消耗多少。你还可以用自定义状态栏（status line）持续跟踪上下文用量，并参考《Reduce token usage》来降低 token 消耗。

给 Claude 一个能验证自身工作的手段

给 Claude 一个它自己能跑的检查：测试、构建、可以比对的截图。这是「你盯着的会话」与「你可以走开的会话」之间的分界线。

Claude 在「看起来做完了」的时候就会停下。如果没有一个它能运行的检查，「看起来做完了」就是唯一可用的信号，而你本人就成了验证闭环：每一个错误都要等你亲自发现。给 Claude 一个能产出通过与不通过的东西，闭环就自己转起来了——Claude 做完活、跑检查、读结果、继续迭代，直到检查通过。

这个检查可以是任何能在对话里返回可读信号的东西：一套测试、构建退出码、linter、把输出与固定样例（fixture）做 diff 的脚本，或是与设计稿比对的浏览器截图。在 Claude 的检查通过之后，你可以亲自跑一次 /verify，对照运行中的应用确认改动。

策略	改前	改后
给出验证标准	「实现一个校验邮箱地址的函数」	「写一个 validateEmail 函数。示例测试用例：[email protected] 为 true，非法输入为 false，[email protected] 为 false。实现完成后运行测试」
用视觉方式验证 UI 改动	「把仪表盘做得好看点」	「[粘贴截图] 按这个设计实现。对结果截图，与原图对比。列出差异并修复」
解决根因而非症状	「构建挂了」	「构建报了这个错：[粘贴报错]。修好它，并验证构建通过。处理根因，不要把报错压下去」

检查一旦存在，接下来要决定它以多硬的方式卡住任务的停止点：

在单条提示内：让 Claude 在同一条消息里跑检查并迭代，就像上表那样。
贯穿整个会话：把检查设为 /goal 的达成条件。一个独立的评估器会在每一轮之后重新检查，Claude 会持续工作直到目标达成。如果 Claude 停滞不前，Claude Code 最终会在目标仍然挂起的情况下停止运行——详见 /goal 评估机制的工作方式。
作为确定性闸门：一个 Stop 钩子（hook）会把你的检查当脚本运行，并在检查通过前阻止本轮结束。连续被拦截 8 次后，Claude Code 会覆盖钩子并结束本轮。
引入第二意见：让一个验证子代理（subagent），或一个会自查自身发现的动态工作流，用全新的模型实例去尝试反驳已有结论——干活的不给自己打分。

每一种做法都是在用配置成本换注意力。提示词版本今天就能用在任何任务上；而 /goal 和 Stop 钩子版本，才能让一次无人值守的运行在没有你的情况下正确收尾。

让 Claude 出示证据，而不是口头宣称成功：测试输出、它跑过的命令及返回结果，或者结果截图。审证据比自己重跑验证更快，而且适用于你根本没盯着的会话。

先探索，再规划，后编码

把研究和规划与实现分开，避免解错题。

让 Claude 一上来就写代码，很可能写出解决错误问题的代码。用规划模式（plan mode）把探索与执行分开。

推荐的工作流分四个阶段：

1. 探索：连按 Shift+Tab 直到状态栏显示 ⏸ plan mode on 进入规划模式，或用 claude –permission-mode plan 启动会话。Claude 会读文件、回答问题，但不做任何修改。

claude (plan mode)

read /src/auth and understand how we handle sessions and login.
also look at how we manage environment variables for secrets.

2. 规划：让 Claude 制定一份详细的实现计划。

claude (plan mode)

I want to add Google OAuth. What files need to change?
What's the session flow? Create a plan.

按 Ctrl+G 可以在你的文本编辑器中打开这份计划，在 Claude 继续之前直接编辑它。

3. 实现：批准计划或按 Shift+Tab 退出规划模式，然后让 Claude 编码，并对照计划自查。

claude

implement the OAuth flow from your plan. write tests for the
callback handler, run the test suite and fix any failures.

4. 提交：让 Claude 用有信息量的提交信息做 commit 并创建 PR。

claude

commit with a descriptive message and open a PR

规划模式有用，但也有开销。对于范围明确、改动很小（改个错别字、加一行日志、重命名一个变量）的任务，直接让 Claude 干就行。规划最适合这几种情形：你对方案拿不准、改动会波及多个文件、或者你对要改的代码并不熟悉。如果你能用一句话描述出 diff，那就跳过规划。

在提示词里给出具体上下文

指令越精确，需要返工的次数越少。

Claude 能推断意图，但它不会读心。引用具体文件、讲明约束、指出可参考的示例模式。

策略	改前	改后
指明任务范围。说清哪个文件、什么场景、测试偏好	「给 foo.py 加测试」	「为 foo.py 写一个测试，覆盖用户已登出的边界情况。不要用 mock」
指出来源。把能回答问题的一手来源指给 Claude	「为什么 ExecutionFactory 的 API 这么奇怪？」	「翻一下 ExecutionFactory 的 git 历史，总结它的 API 是怎么演化成现在这样的」
引用已有模式。把代码库中现成的模式指给 Claude	「加一个日历组件」	「先看首页现有组件是怎么实现的，理解其中的模式，HotDogWidget.php 是个好例子。照这个模式实现一个新的日历组件，支持选择月份、前后翻页选年份。除了代码库已有的库，不要引入其他依赖，从零构建」
描述症状。给出症状、可能的位置，以及「修好了」长什么样	「修一下登录的 bug」	「用户反馈会话超时后登录失败。检查 src/auth/ 里的认证流程，尤其是 token 刷新。先写一个能复现问题的失败测试，再修复它」

模糊的提示并非一无是处——当你在探索阶段、且纠偏成本不高时，一句「你觉得这个文件有什么可以改进的？」反而能挖出你根本想不到要问的问题。

提供富内容

用 @ 引用文件、粘贴截图或图片，或者直接把数据管道式地喂进去。

用 @ 引用文件，而不是口头描述代码在哪。Claude 会在回答前读取该文件。
直接粘贴图片。复制粘贴或拖拽图片到提示框。
给出文档与 API 参考的 URL。用 /permissions 把常用域名加入白名单。
管道式喂数据：运行 cat error.log | claude，把文件内容直接送进来。
让 Claude 自取所需。告诉它用 Bash 命令、MCP 工具或读文件的方式自己拉取上下文。

配置你的环境

几个设置步骤就能让 Claude Code 在你所有会话中的表现明显提升。关于扩展能力全景及各自的适用场景，参见《Extend Claude Code》。

写一份有效的 CLAUDE.md

运行 /init 可以基于当前项目结构生成一份 CLAUDE.md 起步文件，之后持续打磨。

CLAUDE.md 是一个特殊文件，Claude 在每次对话开始时都会读它。把常用 Bash 命令、代码风格、工作流规则写进去，这让 Claude 获得它无法仅从代码推断的持久上下文。

CLAUDE.md 没有规定格式，但请保持简短、人类可读。例如：

# Code style
- Use ES modules (import/export) syntax, not CommonJS (require)
- Destructure imports when possible (eg. import { foo } from 'bar')

# Workflow
- Be sure to typecheck when you're done making a series of code changes
- Prefer running single tests, and not the whole test suite, for performance

运行 /context 确认 Claude 已加载该文件。CLAUDE.md 每个会话都会加载，所以只放普遍适用的内容。只偶尔用到的领域知识或工作流，交给 skills（技能）——Claude 会按需加载，不给每段对话增加负担。

保持精炼。对每一行都问一句：「删掉这行，Claude 会犯错吗？」如果不会，删。臃肿的 CLAUDE.md 会让 Claude 忽视你真正的指令！

✅ 该写	❌ 不该写
Claude 猜不到的 Bash 命令	Claude 读代码就能自己搞明白的东西
与默认值不同的代码风格规则	Claude 已经掌握的语言标准约定
测试指令与偏好的测试运行器	详细的 API 文档（改为放链接）
仓库协作礼仪（分支命名、PR 约定）	经常变化的信息
你项目特有的架构决策	冗长的解释或教程
开发环境的怪癖（必需的环境变量）	逐文件的代码库说明
常见的坑或反直觉的行为	「写干净的代码」这类不证自明的要求

如果 Claude 在你明令禁止的情况下反复做某件事，多半是文件太长、规则被淹没了。如果 Claude 问的问题 CLAUDE.md 里明明有答案，则可能是措辞含糊。把 CLAUDE.md 当代码对待：出问题时就复查、定期修剪、通过观察 Claude 的行为是否真的改变来测试每次修改。对于已入库的 CLAUDE.md，运行 /doctor，Claude 会为它可以从代码库自行推导出的内容提出删减建议。

如果 Claude 总是跳过某一条指令，可以只给那一行加「IMPORTANT」之类的强调。如果处处强调，就没有重点。把 CLAUDE.md 提交进 git，让团队共同维护——这个文件的价值会随时间复利增长。

CLAUDE.md 支持用 @path/to/import 语法引入其他文件。关于引入规则与 CLAUDE.md 的存放位置，参见《CLAUDE.md files》。

配置权限

想在少被打断的同时不放弃控制，可以用 /permissions 预先授权你信任的工具，并用 /sandbox 让沙箱化命令免询问执行。想亲自审批每一次编辑和命令时，切回 Manual 模式。

在 Pro、Max 与 Team 套餐上，auto 模式是交互式终端与 VS Code 会话的内置默认权限模式：一个独立的分类器模型替你审查大多数操作，只拦截看起来有风险的动作，例如权限范围升级、未知基础设施，或由恶意内容驱动的行为。

Manual 模式是其他套餐的内置默认模式：Claude Code 在可能修改系统的动作之前会先询问——写文件、Bash 命令、MCP 工具。这很安全，但很磨人。到第十次确认时，你其实是在连点而不是在审。两个工具能砍掉 Manual 模式下的多数打断，并且在 auto 模式下同样适用：

权限白名单：为你确认安全的具体工具开绿灯，比如 npm run lint 或 git commit
沙箱化：启用操作系统级隔离，限制文件系统与网络访问，让 Claude 在划定边界内更自由地工作

更多内容参见官方文档中的权限模式、权限规则与沙箱化说明。

用好 CLI 工具

在与外部服务交互时，让 Claude Code 使用 gh、aws、gcloud、sentry-cli 这类 CLI 工具。

CLI 是与外部服务交互时上下文效率最高的方式。如果你用 GitHub，安装 gh CLI。Claude 知道如何用它建 issue、开 PR、读评论。没有 gh 时 Claude 也能调 GitHub API，但未认证的请求经常撞上速率限制。

Claude 也很擅长自学它不认识的 CLI 工具。试试这样的提示：Use ‘foo-cli-tool –help’ to learn about foo tool, then use it to solve A, B, C.

连接 MCP 服务器

运行 claude mcp add 加上服务器名称和 URL 或命令，即可连接 Notion、Figma 或你的数据库等外部工具。例如：claude mcp add –transport http notion https://mcp.notion.com/mcp。

有了 MCP 服务器，你可以让 Claude 从 issue 跟踪器读需求来实现功能、查询数据库、分析监控数据、整合 Figma 设计稿、自动化工作流。

设置钩子（hooks）

必须每次都发生、没有任何例外的事情，交给钩子。

钩子会在 Claude 工作流的特定节点自动运行脚本。与 CLAUDE.md 里「建议式」的指令不同，钩子是确定性的，保证动作一定发生。

Claude 可以替你写钩子。试试「写一个钩子，在每次文件编辑后运行 eslint」或「写一个钩子，禁止向 migrations 目录写入」。也可以直接编辑 .claude/settings.json 手工配置，运行 /hooks 查看已配置的钩子。

创建技能（skills）

在 .claude/skills/ 下创建 SKILL.md 文件，为 Claude 注入领域知识与可复用工作流。

Skills 用项目、团队或领域特有的信息扩展 Claude 的知识。相关时 Claude 会自动应用，你也可以用 /skill-name 直接调用。

在 .claude/skills/ 下建一个含 SKILL.md 的目录即可创建技能：

.claude/skills/api-conventions/SKILL.md

---
name: api-conventions
description: REST API design conventions for our services
---
# API Conventions
- Use kebab-case for URL paths
- Use camelCase for JSON properties
- Always include pagination for list endpoints
- Version APIs in the URL path (/v1/, /v2/)

技能也可以定义可直接调用的可复现工作流：

.claude/skills/fix-issue/SKILL.md

---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Analyze and fix the GitHub issue: $ARGUMENTS.

1. Use `gh issue view` to get the issue details
2. Understand the problem described in the issue
3. Search the codebase for relevant files
4. Implement the necessary changes to fix the issue
5. Write and run tests to verify the fix
6. Ensure code passes linting and type checking
7. Create a descriptive commit message
8. Push and create a PR

运行 /fix-issue 1234 即可调用。对有副作用、只想手动触发的工作流，用 disable-model-invocation: true。

创建自定义子代理（subagents）

在 .claude/agents/ 里定义专门化的助手，Claude 可以把隔离型任务委托给它们。

子代理运行在各自的上下文中，拥有各自的可用工具集。适合要读大量文件、或需要专门聚焦的任务，同时不会弄乱你的主对话。

.claude/agents/security-reviewer.md

---
name: security-reviewer
description: Reviews code for security vulnerabilities
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review code for:
- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorization flaws
- Secrets or credentials in code
- Insecure data handling

Provide specific line references and suggested fixes.

明确告诉 Claude 使用子代理：「Use a subagent to review this code for security issues.」

安装插件（plugins）

运行 /plugin 浏览插件市场。插件无需配置即可加入技能、工具与集成。

插件把技能、钩子、子代理和 MCP 服务器打包成单个可安装单元，来自社区与 Anthropic。如果你写强类型语言，装一个代码智能（code intelligence）插件，让 Claude 获得精确的符号导航和编辑后的自动错误检测。

关于在技能、子代理、钩子与 MCP 之间如何取舍，参见《Extend Claude Code》。

高效沟通

把你会问另一位工程师的问题抛给 Claude；对较大的功能，先让 Claude 采访你并写出一份规格说明（spec），再动手实现。

向代码库提问

把你会问资深工程师的问题拿来问 Claude。

接手一个新代码库时，用 Claude Code 来学习和探索。你可以问它那些本来会问同事的问题：

日志系统是怎么工作的？
怎么新增一个 API 端点？
foo.rs 第 134 行的 async move { … } 是干什么的？
CustomerOnboardingFlowImpl 处理了哪些边界情况？
为什么第 333 行调的是 foo() 而不是 bar()？

这种用法是很高效的入职（onboarding）工作流，能缩短上手时间、减轻其他工程师的负担。不需要任何特殊提示技巧，直接问就行。

让 Claude 采访你

较大的功能，先让 Claude 采访你。用一个极简提示开场，让 Claude 用 AskUserQuestion 工具向你提问。

Claude 会问到你可能还没想过的事：技术实现、UI/UX、边界情况与取舍。发送前把 [brief description] 换成你的功能描述。

I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.

Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.

规格完成后，开一个全新会话去执行它。新会话上下文干净，可以完全聚焦实现；你手里也多了一份可引用的书面规格。

最有用的规格是自足的：点明涉及的文件与接口、声明哪些不在范围内、并以一个端到端验证步骤收尾来证明功能可用。把规格打磨精确所花的时间，比盯着实现过程所花的时间回报更高。

管理你的会话

对话是持久的，也是可逆的。好好利用这一点！

尽早、频繁地纠偏

一旦发现 Claude 跑偏，立刻纠正。

最好的结果来自紧密的反馈循环。虽然 Claude 偶尔能一次做对，但快速纠错通常更快得到更好的方案。

Esc：在 Claude 执行动作的中途按 Esc 停下。上下文保留，你可以重新定向。
Esc 两连按或 /rewind：打开回滚菜单，恢复到之前的对话与代码状态，或从选中的消息起重新摘要。
「撤销刚才的改动」：让 Claude 回退它刚做的修改。
/clear：在不相关的任务之间重置上下文。夹带无关上下文的长会话会拉低表现。

如果在同一个会话里你已就同一问题纠正了 Claude 两次以上，说明上下文已被失败的尝试塞满。运行 /clear，带着你学到的教训换一条更具体的提示重新开始。一个带着更好提示的干净会话，几乎总是胜过拖着层层纠错的长会话。

激进地管理上下文

在不相关的任务之间用 /clear 重置上下文。

当接近上下文上限时，Claude Code 会自动压缩（compact）对话历史，保留重要的代码与决策，腾出空间。

长会话中，Claude 的上下文会被无关对话、文件内容和命令输出填满，这会拉低表现，有时还会让 Claude 分心。

在任务之间频繁使用 /clear，彻底重置上下文窗口
自动压缩触发时，Claude 会摘要最重要的内容，包括代码模式、文件状态与关键决策
想要更多控制权，运行 /compact <instructions>，比如 /compact Focus on the API changes
只想压缩部分对话时，用 Esc 两连按或 /rewind，选中某个消息检查点，选择 Summarize from here（从这里开始摘要）或 Summarize up to here（摘要到这里）。前者压缩该点之后的消息并保留更早的上下文；后者压缩较早的消息、完整保留近期内容。参见回滚菜单的摘要选项。
在 CLAUDE.md 里定制压缩行为，例如「When compacting, always preserve the full list of modified files and any test commands」，确保关键上下文在摘要后幸存
对不需要留在上下文里的问题，用 /btw。答案不会进入对话历史，你可以查个细节而不撑大上下文。

用子代理做调研

用「use subagents to investigate X」委托研究任务。它们在独立的上下文里探索，让你的主对话保持干净、专注实现。

既然上下文是根本约束，就用子代理把调研挡在主上下文之外。Claude 调研代码库时要读大量文件，全部计入你的上下文。子代理运行在独立的上下文窗口里，只回报摘要：

Use subagents to investigate how our authentication system handles token
refresh, and whether we have any existing OAuth utilities I should reuse.

Claude 实现完之后，你也可以用子代理做验证。参见下文「加入对抗式评审环节」一节。

用检查点回滚

你发出的每一条提示都会生成一个检查点。你可以把对话、代码或两者恢复到任何之前的检查点。

Claude 会在每次修改前自动快照文件，因此检查点可以恢复它们。双击 Esc 或运行 /rewind 打开回滚菜单：可以只恢复对话、只恢复代码、两者都恢复，或从选中的消息开始重新摘要。详见《Checkpointing》。

你不必步步谨慎，可以让 Claude 大胆尝试有风险的做法。不行就回滚，换条路再试。检查点随对话保存，即使关掉终端、之后恢复会话，也照样能回滚。

注意：检查点只跟踪通过 Claude 文件编辑工具做的改动。经由 Bash 命令或外部进程的改动不会被捕获。它不能替代 git。

恢复会话

用 /rename 给会话命名，把它们当分支用：每条工作线拥有自己的持久上下文。

Claude Code 在本地保存对话，当一个任务跨越多次工作时，你不必重新解释背景。运行 claude –continue 从上次中断处继续，或 claude –resume 从列表中挑选。给会话起描述性名字（比如 oauth-migration），方便日后查找。恢复、分支与命名的全部控制项见《Manage sessions》。

自动化与规模化

当你和单个 Claude 配合已经高效，就用并行会话、非交互模式和扇出（fan-out）模式把产出翻倍。

运行非交互模式

在 CI、pre-commit 钩子或脚本中使用 claude -p “prompt”。加 –output-format stream-json –verbose 可获得流式 JSON 输出。

用 claude -p “your prompt” 可以非交互地运行 Claude，不进入交互式提示。除非传入 –no-session-persistence，这次运行仍会创建一个可恢复的会话。非交互模式是把 Claude 接入 CI 流水线、pre-commit 钩子或任何自动化流程的方式。输出格式让结果可以被程序解析：纯文本、JSON 或流式 JSON。

# One-off queries
claude -p "Explain what this project does"

# Structured output for scripts
claude -p "List all API endpoints" --output-format json

# Streaming for real-time processing
claude -p "Analyze this log file" --output-format stream-json --verbose

第一条输出纯文本；json 格式返回一个带 result 字段的 JSON 对象；stream-json 每行打印一个 JSON 对象，以一个 init 事件开头。

并行运行多个 Claude 会话

并行运行多个 Claude 会话，加速开发、跑隔离实验，或启动复杂工作流。

按你自己愿意承担多少协调工作来选并行方式；当会话之间需要互相传递发现时，再加上消息机制：

Worktrees：在隔离的 git checkout 中运行独立的 CLI 会话，编辑互不冲突
跨会话消息：让你自己运行的多个会话互相传递发现
桌面应用：可视化管理多个本地会话，每个都在自己的 worktree 里
Claude Code on the web：在云端运行会话，默认跑在 Anthropic 托管的基础设施上
Agent view（研究预览）：运行 claude agents 派发在后台持续运行的会话，并在一块屏幕上统览
Agent teams（实验性，默认关闭）：多会话自动协同，共享任务、消息与一个 team lead

除了并行干活，多会话还能支撑以质量为导向的工作流。新鲜的上下文让代码评审更客观，因为 Claude 不会偏向自己刚写的代码。

例如，用「写作者/评审者」模式：

会话 A（写作者）	会话 B（评审者）
Implement a rate limiter for our API endpoints	Review the rate limiter implementation in @src/middleware/rateLimiter.ts. Look for edge cases, race conditions, and consistency with our existing middleware patterns.
Here’s the review feedback: [Session B output]. Address these issues.

测试也可以照搬：让一个 Claude 写测试，另一个写代码去通过它们。

跨文件扇出

循环调用 claude -p 处理每个任务。批量操作用 –allowedTools 限定权限。

大型迁移或批量分析可以把工作分给许多并行的 Claude 实例。在 git 仓库中运行 /batch <instruction>，Claude 会把改动拆给 5 到 30 个子代理，每个子代理在自己的 worktree 里工作并各开一个 PR。想用自己的脚本驱动扇出，就循环调用 claude -p：

第 1 步：生成任务清单——让 Claude 把待迁移的文件列表写进文件，供下一步循环读取，提示如：list all 2,000 Python files that need migrating and save the list to files.txt

第 2 步：写一个遍历清单的脚本

for file in $(cat files.txt); do
  claude -p "Migrate $file from Python 2 to Python 3. Return OK or FAIL." 
    --allowedTools "Edit,Bash(git commit *)"
done

第 3 步：先在几个文件上测试，再全量运行——根据前两三个文件暴露的问题打磨提示，然后跑全量。–allowedTools 限制了 Claude 能做什么，这在无人值守运行时尤其重要。

也可以把 Claude 接入现有的数据/处理管道：

claude -p "<your prompt>" --output-format json | your_command

开发期用 –verbose 便于调试，上生产后关掉。

用 auto 模式自主运行

想要不被打断的执行加上后台安全检查，用 auto 模式。分类器模型在命令运行前审查，拦截权限范围升级、未知基础设施和恶意内容驱动的行为，同时让常规工作无需确认直接推进。

claude --permission-mode auto -p "fix all lint errors"

当分类器在带 -p 标志的非交互运行中反复拦截动作时，Claude Code 不会中止运行。后果与阈值详见 auto 模式回退机制的说明。

加入对抗式评审环节

在把任务标记为完成之前，让一个子代理在全新上下文里评审 diff 并报告缺口。

Claude 无人值守工作得越久，在你认可成果之前，一道独立检查就越重要。运行在全新子代理上下文中的评审者只看得到 diff 和你给它的标准，看不到产出改动的推理过程，因此它是对结果本身做评价。

要做正确性检查，运行内置的 /code-review 技能，它会在全新子代理中评审当前 diff 的 bug 并把发现返回会话。要对照计划检查 diff，就自己写评审提示。写清要检查的工作、要对照的计划，以及什么才算发现：

Use a subagent to review the rate limiter diff against PLAN.md. Check that
every requirement is implemented, the listed edge cases have tests, and
nothing outside the task's scope changed. Report gaps, not style preferences.

评审者以子代理身份运行，实现会话会直接收到这些缺口，可以修复并再次评审，省去你在窗口之间复制粘贴发现。

一个被要求找缺口的评审者通常总会报出一些，哪怕工作本身没问题——因为它被要求干这个。逐条追着改会导致过度工程：多余的抽象层、防御性代码、为不可能发生的情况写的测试。告诉评审者只标记影响正确性或既定需求的缺口，其余按可选项处理。

避开常见失败模式

这些都是常见错误，早识别早省时间：

大杂烩会话。你从一个任务开始，中途问了个不相干的问题，又回到第一个任务。上下文塞满了无关信息。
解法：不相关的任务之间用 /clear。
反复纠正。Claude 做错了，你纠正，还是错，再纠正。上下文被失败的尝试污染。
解法：两次纠正失败后，/clear，带着学到的教训写一条更好的初始提示。
过度膨胀的 CLAUDE.md。文件太长，Claude 无视其中一半，重要规则淹没在噪音里。
解法：无情修剪。如果 Claude 不需要这条指令也能做对，删掉它，或改写成钩子。
信任但不验证。Claude 产出一个看起来可信的实现，但没处理边界情况。
解法：永远提供验证手段（测试、脚本、截图）。无法验证的东西不要上线。
无限探索。你让 Claude 去「研究」某事却不限定范围。它读了几百个文件，把上下文塞满。
解法：把调研范围收窄，或用子代理，别让探索吃掉主上下文。

培养你的直觉

本指南的模式不是铁律。它们是普遍有效的起点，但未必在每种情形下都最优。

有时你应该让上下文积累，因为你正深陷一个复杂问题，历史信息很宝贵。有时你应该跳过规划让 Claude 自行摸索，因为任务本身就是探索性的。有时模糊的提示恰恰是对的，因为你想先看 Claude 如何理解问题，再做约束。

留意什么有效。当 Claude 产出很棒时，记住你做了什么：提示的结构、提供的上下文、所处的模式。当 Claude 挣扎时，问问为什么：上下文太吵了？提示太空了？任务大到一轮做不完？

假以时日，你会长出任何指南都写不出来的直觉：知道什么时候该具体、什么时候该开放，什么时候规划、什么时候探索，什么时候清空上下文、什么时候任其积累。