Claude Code 官方最佳实践

原文：raw/sources/anthropic-claude-code-best-practices.md（code.claude.com 官方文档《Best practices for Claude Code》，原 engineering blog 文章的现行版）。关于 Claude Code 的一手使用方法论。

一个底层约束推出全部实践

多数最佳实践基于同一约束：上下文窗口很快填满，且性能随填满而退化。上下文是最重要的待管理资源——与 context engineering 一文的“attention budget”相呼应。

关键实践

• 给 Claude 可运行的验证手段：测试、构建退出码、linter、截图对比。没有 check，“看起来完成”就是唯一信号，人就成了验证环节；有了 pass/fail 信号，循环自己闭合。让 Claude 出示证据（测试输出、命令及返回）而非口头宣称成功。
• 先探索、后规划、再编码、最后提交：用 plan mode 分离研究与执行，避免解决错误的问题。但小任务直接做——“如果一句话能描述 diff，就跳过规划”。
• 提示词给足具体上下文：指定文件、约束、可参照的既有模式；模糊提示只在探索期有用。
• CLAUDE.md 要短：每行自问“删掉它 Claude 会犯错吗？“不会就删。臃肿的 CLAUDE.md 会让真正重要的规则被噪音淹没。领域知识放 skills 按需加载，不要常驻。
• 激进管理上下文：不相关任务之间 /clear；同一问题纠正两次后，清空重来 + 更好的初始提示，几乎总是优于在污染的上下文里继续纠缠。
• 用 subagent 做调查：探索类工作放独立上下文跑，只回传摘要，保住主对话的上下文预算。见 subagent。
• 规模化：claude -p 非交互模式接入脚本/CI；多会话并行（worktrees）；Writer/Reviewer 模式——新鲜上下文做审查不会偏袒自己刚写的代码；对抗性审查：任务完成前让 fresh subagent 只看 diff 和标准做审查，但要告诫审查者只报影响正确性的问题，否则会为找而找、导致过度工程。

常见失败模式

kitchen sink session（上下文塞满无关信息）、反复纠正（失败尝试污染上下文）、过度指定的 CLAUDE.md、trust-then-verify gap（貌似合理但没验证）、无边界探索。

对本知识库的印证

本项目多处直接应用此文：lint.mjs 就是“可运行的验证手段”；操作 skills 而非塞满 CLAUDE.md；红队审计即“对抗性审查”的应用。