Anthropic 自己怎么用 Claude Code：12 个真实技巧

Claude Code 的母公司是 Anthropic。要学 Claude Code，最值得看的不是二手提示词合集，而是 Anthropic 自己的官方博客、研究文章和产品文档。

我把几篇一手资料放在一起读了一遍：Claude Code 最佳实践、Anthropic 团队如何使用 Claude Code、Anthropic 内部 AI 工作方式研究、context engineering，以及 Anthropic 关于 agent tools 的工程博客。读完最大的感受是：Claude Code 的关键不是“让 AI 写更多代码”，而是让它进入一个可验证、可回退、可管理上下文的工程循环。

下面是从这些真实资料里提炼出的 12 个技巧。

1. 先给 Claude 一个能自证结果的检查

Anthropic 的最佳实践把“验证”放在最前面：给 Claude 一个它能运行的检查，例如测试、构建、lint、截图对比或脚本输出。

原因很简单：如果没有检查，Claude 只能停在“看起来完成了”。一旦有了测试或构建结果，它就能自己读失败信息、修改代码、再运行，形成闭环。

一个更好的提示词不是：

修复登录 bug。

而是：

用户反馈 session 过期后登录失败。请检查 src/auth/ 下的 token refresh 流程。
先写一个能复现问题的失败测试，再修复它。最后运行相关测试并给出结果。

这条技巧也解释了为什么 Claude Code 特别适合“可被机器判定”的任务：测试通过、构建成功、截图差异消失、脚本输出匹配，都是比“我觉得好了”更可靠的停止条件。

2. 大任务用“探索 → 计划 → 实现 → 提交”

Anthropic 建议把研究和实现分开。大任务不要一上来就让 Claude 改代码，而是先进入计划阶段，让它读代码、找路径、解释风险。

我会把它拆成四段：

探索：只读代码，不修改文件。
计划：让 Claude 写出涉及文件、改动步骤、测试策略和风险。
实现：按计划编码，并运行检查。
提交：生成清晰 commit message 或 PR 描述。

如果只是改文案、加日志、重命名变量，就不必强行计划。Anthropic 的意思不是“凡事都要流程化”，而是：不确定、跨文件、不熟悉的任务，先计划；能一句话描述 diff 的小任务，直接做。

3. 提示词要给“边界”，不只是给“目标”

Claude 能推断意图，但不能读心。Anthropic 的例子里，好的提示词通常包含四类信息：

具体文件或目录
触发问题的场景
约束和不该改的范围
验收方式

比如“加一个 calendar widget”太空。更好的写法是：

参考 home page 里现有 widget 的实现方式，HotDogWidget.php 是一个好例子。
请实现 CalendarWidget，让用户选择月份，并能前后翻年份。
不要引入新库，沿用现有组件和样式模式。实现后运行相关测试。

这不是啰嗦，而是在帮 Claude 少走弯路。提示越具体，后续纠偏越少。

4. 把项目规则写进 `CLAUDE.md`，但一定要短

Claude Code 会在会话开始时读取 CLAUDE.md。Anthropic 建议用 /init 生成初稿，再逐步修剪。

适合写进去的内容包括：

常用构建和测试命令
项目特殊代码风格
分支、提交、PR 习惯
容易踩坑的环境变量或本地开发要求
只有团队知道的架构约定

不适合写进去的是长篇教程、详细 API 文档、文件逐个解释，以及 Claude 读代码就能知道的东西。

我的理解是：CLAUDE.md 不是知识库，而是“长期有效的项目操作系统”。如果删掉某条规则不会导致 Claude 犯错，就删掉它。

5. 把上下文当成预算，而不是垃圾桶

Anthropic 的 context engineering 文章讲得很清楚：上下文窗口越满，模型越容易失焦。Claude Code 的很多能力，其实都是围绕“怎样让上下文保持高信号”设计的。

实操上有几条：

不相关任务之间用 /clear
长任务用 /compact 保留关键决策和文件状态
大范围调查交给 subagent，别污染主会话
不要把整份文档都塞进提示词，给路径、URL 或文件名，让 Claude 按需读取
让 Claude 用 grep、glob、head、tail 这类工具逐步找信息

Anthropic 称这种方式为 just-in-time context：不是把所有材料预先塞进去，而是在需要时动态读取。

6. 两次纠偏还不对，就清空重来

Anthropic 在常见失败模式里提到一个很真实的问题：你纠正 Claude，一次不行，再纠正一次，第三次上下文里已经塞满了失败路径。

这时继续纠缠，往往不如 /clear 后重写一个更好的初始提示。

我的经验是，新提示应该带上刚才学到的信息：

重新开始。刚才失败的原因是实现误改了 billing 模块。
这次只允许修改 src/auth/session.ts 和对应测试。
目标是修复 session 过期后的 token refresh。
先写 failing test，再实现，最后运行 auth 相关测试。

Claude Code 的优势不是“永远一次做对”，而是重启成本低。别舍不得重开局。

7. 用 subagent 做调查，也用它做反向审查

Anthropic 建议用 subagent 隔离上下文。它可以先去调查认证流程、数据库 schema、历史 commit，再把结论报告给主会话。

更重要的是，任务完成后可以让另一个 subagent 做 adversarial review：

Use a subagent to review this diff against PLAN.md.
Check whether every requirement is implemented, edge cases have tests,
and nothing outside the task scope changed. Report correctness gaps only.

这里的关键词是“correctness gaps only”。否则审查代理会为了找问题而找问题，最后把实现推向过度工程。

8. 自动模式适合边缘任务，不适合核心判断

Anthropic 团队自己的 PDF 里提到 Claude Code 团队会用 auto-accept mode 做快速原型：让 Claude 写代码、跑测试、循环迭代，然后人类接手最后 20% 的判断和精修。

但他们也强调要分清场景。产品边缘、低风险、容易回退的任务适合更自动；核心功能、架构决策、涉及安全或数据的地方，需要更近距离监督。

实践前先做三件事：

从干净的 git 状态开始
小步提交 checkpoint
确保有测试或脚本能验证结果

自动化不是信任的替代品，它只是把人类注意力从敲代码转移到审查边界和验收结果。

9. 选择“容易验证”的任务委托给 Claude

Anthropic 内部研究里，一个反复出现的判断标准是：任务是否容易验证。

适合委托的任务通常是：

低复杂度、低上下文
自包含、边界明确
重复、无聊、阻力大
结果容易用测试或人工快速 sniff-check
低风险，失败也容易回滚

不适合完全放手的任务通常是：

高层设计
需要组织背景和产品品味的判断
安全、隐私、生产事故等高风险场景
你自己也无法判断对错的陌生核心模块

这比“Claude 能不能做某事”更重要。真正的问题是：你能不能有效监督它做这件事。

10. 把它当作“多次试验机器”

Anthropic 的数据科学和 ML 工程团队有一个很生动的建议：保存状态，让 Claude 跑一段时间；如果结果不好，与其纠缠，不如回到干净状态重新试。

这背后的思想是：Claude Code 的成本结构更像实验，而不是手工雕刻。你可以让它尝试 A 方案、B 方案、C 方案，然后比较结果。

如果你发现它把方案做复杂了，直接打断：

Stop. Why are you doing this?
Try a simpler approach that changes fewer files.

Anthropic 的经验是，模型容易倾向复杂解，但对“更简单”的明确要求反应很好。

11. 让 Claude 使用 CLI 和 MCP，而不是只靠聊天

Claude Code 强在能操作环境。Anthropic 建议把常用 CLI 工具接好，例如 gh、云服务 CLI、监控工具、数据库工具等。

对于外部系统，可以用 MCP server 连接 Notion、Figma、数据库或内部工具。关键不是工具越多越好，而是工具要高信号、边界清晰。

Anthropic 在 agent tools 文章里反复强调：工具太多、功能重叠、返回低价值字段，都会浪费上下文并误导 agent。好的工具应该像人类工作流一样切任务，而不是机械包一层 API。

比如：

用 search_logs 代替一次性 read_all_logs
用 get_customer_context 代替分散的 customer、transactions、notes 查询
用 schedule_event 代替 list users、list events、create event 三个低层工具

Claude Code 不是只吃 prompt 的工具。它吃的是整个工作环境。

12. 并行跑多个 Claude，但用 worktree 隔离

Anthropic 的最佳实践也提到并行会话：多个 Claude 可以同时探索不同文件、不同方案或不同 issue。

但并行的前提是隔离。最实用的方式是 git worktree：每个 Claude 在自己的 checkout 里改代码，避免互相覆盖。

适合并行的场景：

三个候选实现方案
多个独立 bug
一个 agent 做实现，另一个 agent 做测试补全
一个 agent 调查历史原因，另一个 agent 改当前代码

这也是 Claude Code 和普通聊天机器人的差别：它不是单线程问答，而是可以被组织成工程流水线。

一套我会直接复制的 Claude Code 工作流

如果把 Anthropic 的建议压缩成一个日常模板，我会这样用：

请先探索，不要修改文件。
目标：实现 [功能/修复 bug]。
范围：只关注 [目录/文件]，不要改 [排除范围]。
请找出现有模式、风险点、需要改动的文件，并写 PLAN.md。
计划里必须包含测试方式和验收标准。

确认计划后：

按 PLAN.md 实现。
先写或更新测试，再改代码。
完成后运行相关测试和构建。
如果失败，请根据错误继续修复，直到通过。
最后总结改了哪些文件、验证命令和结果。

完成后：

Use a subagent to review the diff against PLAN.md.
Only report correctness gaps, missing requirements, missing edge-case tests,
or out-of-scope changes. Do not report style preferences.

这套流程并不花哨，但它抓住了 Anthropic 官方资料里最稳定的几个原则：任务有边界、上下文要干净、结果可验证、审查要独立、失败可回退。