终于有人把 Claude Code 怎么用讲清楚了：最佳实践全在这

用 Claude Code 的人很多，但用对的人不多。

同样的工具，有人拿来一键生成代码翻车，有人却能用它稳定交付复杂项目。差距在哪？往往不是工具本身，而是用法。

Tech with Mak（@techNmak）最近在 X 上发了一条重磅整理，把 Claude Code 团队（负责人 Boris Cherny 亲自下场）和社区高手们的最佳实践，浓缩成了一张 cheatsheet。这条推文 940 赞、169 转发，堪称"一图流"的 Claude Code 圣经。

今天就把这张图和背后的全部要点，合并整理成一篇完整的实战指南。

Claude Code 最佳实践完整 cheatsheet

上图是原推文附带的完整 cheatsheet 长图，下方正文是对它的逐条拆解和扩展。建议保存这张图随时查阅。

一、官方最佳实践：来自 Boris Cherny 团队的 25 条心法

这些直接来自 Claude Code 的开发团队，他们自己天天用，踩过的坑比谁都多。

核心工作流

1. 永远用 plan 模式，给 Claude 验证的方法

Always use plan mode, give Claude a way to verify

这是排在第一条的铁律。Plan 模式（Shift+Tab 按两次进入）让 Claude 先想后写，先出一份书面计划，你审过它才动手。Boris Cherny 反复强调：不要让 Claude 一上来就写代码。

而且，计划里必须包含验证方式，它怎么知道自己做对了？这跟前面几篇文章讲的"loop 四问"里的"验证"完全一致。

2. 让 Claude 用 AskUserQuestion 工具来"采访"你

Ask Claude to interview you using AskUserQuestion tool

不要你自己费劲描述需求，反过来，让 Claude 主动问你。它会用 AskUserQuestion 一次问一个问题，逼你把模糊的需求说清楚。这正是 Matt Pocock 的 /loop-me 和 /grilling 的核心思路：盘问式需求澄清。

3. 用 Git Worktree 做并行开发

Use Git Worktrees for parallel development

这是 Boris 团队最推崇的技巧之一。开 3-5 个 worktree，每个跑一个独立的 Claude 会话，同时推进多个功能。有的工程师甚至给它们起 shell 别名（za、zb、zc）快速切换。一个 worktree 跑崩了不影响别的，上下文还互不污染。

4. /loop ，排程最长 7 天的周期任务

/loop - schedule recurring tasks for up to 7 days

Claude Code 可以排程周期性任务，最长 7 天。比如"每天早上 review 一次生产日志""每晚补一次文档"，把它变成 loop，让它自己跑。

5. 代码审查，用全新上下文窗口抓原 agent 漏掉的 bug

Code Review - fresh context windows catch bugs the original agent missed

这是一个反直觉但极重要的洞察：让一个全新的、干净的上下文窗口来做 code review，能抓出原来写代码的 agent 漏掉的 bug。因为原 agent 有"确认偏误"，自己写的自己看不出问题。这正是前面 Loop Library 讲的"builder-reviewer 双角色"思路。

6. 分阶段、带门禁的计划，每阶段配测试

Make phase-wise gated plans with tests for each phase

把大任务拆成阶段，每个阶段有"门禁"（gate），必须通过测试才能进入下一阶段。这是软件工程的经典做法，现在用 AI 一样适用。

7. 用跨模型（Claude Code + Codex）来审查你的计划

Use cross-model (Claude Code + Codex) to review your plan

让一个模型写、另一个模型审。Claude 出计划，Codex 来挑刺。不同模型的盲点不一样，交叉验证能堵住单模型的漏洞。这也是社区里专门有"Cross-Model Workflow"的原因。

配置与文件

8. CLAUDE.md 每个文件控制在 200 行以内

CLAUDE[.]md should target under 200 lines per file

CLAUDE.md 是 Claude 的"项目记忆"，但不是写得越多越好。太长它反而会忽略（后面"十亿美元问题"会专门讲这个）。单文件控制在 200 行内，多了就拆分。

9. 用 commands（命令）做工作流，而不是 sub-agents

Use commands for workflows instead of sub-agents

需要固定工作流时，做成 command（/xxx），而不是 sub-agent。command 更轻、更可控、更可复用。

10. 用"带 skill 的功能专属 sub-agent"，而不是泛化的"QA 工程师"

Have feature-specific sub-agents with skills instead of general QA or backend engineer

如果要用 sub-agent，让它专精某个功能（带特定 skill），而不是做一个啥都管的"通用 QA"。专精的比通用的靠谱得多。

11. 小任务用原味 Claude Code，比复杂工作流更好

Vanilla Claude Code is better than complex workflows for smaller tasks

别过度工程化。小任务直接用原生 Claude Code 就行，套一堆工作流反而碍事。工具要匹配任务规模。

调试与排障

12. 卡住时，截图分享给 Claude

Take screenshots and share with Claude when stuck

卡住了别干瞪眼，截图发给 Claude。它能"看"图，UI 上的问题、报错弹窗、设计稿，给它看比描述强一百倍。

13. 用 MCP 让 Claude 看到 Chrome 控制台日志

Use MCP to let Claude see Chrome console logs

接个 MCP（Model Context Protocol），Claude 就能直接读到浏览器控制台的日志。前端调试时，它能看到真实的报错，不用你复制粘贴。

14. 让 Claude 把终端命令当后台任务跑，方便调试

Ask Claude to run terminal as background task for better debugging

长跑的命令（比如 dev server、watch 任务），让它当后台任务跑，别阻塞主流程。这样调试体验好得多。

15. 跨模型做 QA，比如 Codex 审计划和实现

Use cross-model for QA - e.g. Codex for plan and implementation review

跟第 7 条呼应，QA 环节也用跨模型。Claude 写，Codex 审，堵漏。

上下文管理（最关键的一组）

16. 上下文腐烂（context rot）在 30-40 万 token 时开始发作，别让会话飘过这个量

Context rot kicks in around 300-400k tokens, don't let sessions drift past that

这是全文最重要的技术洞察之一。Claude 的上下文窗口虽然大，但质量会随长度衰减，到了 30-40 万 token，它开始"忘事"、跑偏、前后矛盾。所以别让单个会话无限长，到了量就该开新会话。

17. Rewind 大于"再纠正"，回退到失败尝试之前，而不是污染上下文

Rewind > correct, /rewind back to before the failed attempt instead of polluting context

这是第 16 条的对策。当 Claude 一次尝试搞砸了，不要在那个失败的基础上继续让它修（那会让上下文里堆满失败痕迹），而是用 /rewind 回退到失败之前，干干净净重来。保持上下文干净，比反复打补丁强。

18. /schedule ，云端周期任务，机器关了也跑

/schedule - cloud-based recurring tasks that run even when your machine is off

跟 /loop 不同，/schedule 是云端排程，你的电脑关了它也在云端跑。适合定时巡检、定时报告这类任务。

19. 用 Auto 模式替代 dangerously-skip-permissions，让模型分类器判断每条命令是否安全

Auto mode instead of dangerously-skip-permissions, a model-based classifier decides if each command is safe

别用危险的 dangerously-skip-permissions（等于把所有权限都放开）。用 Auto 模式，一个基于模型的分类器逐条判断命令安不安全，该问就问，该放就放。安全性和效率兼顾。

20. 在每个 skill 里建一个"Gotchas（坑）"小节，把 Claude 的失败点积累下来

Build a Gotchas section in every skill, add Claude's failure points over time

这是"经验沉淀"的最佳实践。每个 skill（技能）都配一个 Gotchas 节，记录 Claude 在这个 skill 上反复栽过的跟头。随着时间积累，skill 会越来越聪明。

二、社区工作流：六大派系

除了官方心法，推文还整理了社区里最火的几个工作流框架。这些都是高星仓库，可以直接拿来用。

Superpowers（234K 星）

brainstorming → git worktrees → subagent-driven development → TDD

最全的框架之一。从头脑风暴开始，进 worktree 并行，用 subagent 分工，全程 TDD（测试驱动）。适合中大型项目。

Everything Claude Code（219K 星）

/ecc:plan → /tdd → /code-review → /security-scan → merge

一套完整的命令链：先规划、再 TDD 开发、code review、安全扫描、最后合并。每一步都是独立命令，可单独用也可串起来。

Matt Pocock Skills（138K 星）

/grill-with-docs → /to-prd → /triage → /tdd → /handoff

Matt Pocock（就是前面 /loop-me 那位）的技能集。先带文档盘问需求，转成 PRD（产品需求文档），分类，TDD 开发，最后交接。重点在需求澄清。

Spec Kit（114K 星）

specify → clarify → plan → tasks → implement → analyze

规格驱动开发。先把需求规格化，澄清，规划，拆任务，实现，分析。强调"先有规格再有代码"。

gstack（112K 星）

office-hours → CEO/eng/design reviews → spec → qa → ship → canary

模拟一个完整的团队流程：开个"办公时间"讨论，过 CEO/工程/设计三轮评审，写规格，QA，发布，灰度。像一个虚拟团队。

其他值得关注的工作流

Cross-Model Workflow（Claude Code + Codex），专门做跨模型协作的
RPI（Research Plan Implement），研究、规划、实现三段式
Ralph Wiggum Loop，专门跑自治任务的循环

三、五个"十亿美元问题"

推文特别点出了五个"值十亿美元的问题"，这些是真正困扰 Claude Code 用户的、没有标准答案的开放难题。能解决任何一个，都是真本事。

问题 1：CLAUDE.md 里到底该放什么、不该放什么？

What exactly should you put inside CLAUDE[.]md, and what should you leave out?

放太多它会忽略，放太少它不懂你的项目。这个度的拿捏，是门学问。

问题 2：什么时候该用 command、agent、还是 skill？

When should you use command vs agent vs skill?

三者各有适用场景，没有一刀切的答案。这本身就是个需要经验积累的判断。

问题 3：为什么 Claude 会忽略 CLAUDE.md 里的指令，哪怕你用全大写写了 MUST？

Why does Claude still ignore CLAUDE[.]md instructions, even when they say MUST in all caps?

这是无数人抓狂的问题。大写 MUST 没用，它忽略就是忽略。背后是上下文优先级和注意力分配的复杂机制。

问题 4：能不能把代码库转成规格，再让 AI 从规格单独生成出完全一样的代码？

Can we convert a codebase into specs and have AI regenerate the exact same code from those specs alone?

这是"规格驱动开发"的终极理想，如果可行，意味着代码可以完全由规格定义和再生。

问题 5：该用 Claude Code 内置的 plan 模式，还是自己搭一个规划命令？

Should you rely on Claude Code's built-in plan mode, or build your own planning command?

内置的方便，自己搭的灵活。怎么选，取决于你的项目复杂度和定制需求。

四、日常习惯

最后是三个简单但重要的日常习惯：

1. 每天更新 Claude Code

Update Claude Code daily

工具迭代极快，每天都有改进。保持更新才能享受最新能力。

2. 每天早上先读 changelog

Start your day by reading the changelog

更新了什么、修了什么、加了什么，读 changelog 是最快跟上工具演化的方式。

3. 关注 Reddit 的 r/ClaudeAI 和 r/ClaudeCode

Follow r/ClaudeAI, r/ClaudeCode on Reddit

社区里最新的玩法、踩坑、技巧都在这。比官方文档更接地气。

五、怎么把这些用起来

读到这里你可能觉得信息量爆炸。别慌，给你一个落地的优先级：

第一优先（今天就用）：

复杂任务先开 plan 模式
会话长了（接近 30 万 token）开新会话
失败了用 /rewind 回退而不是硬修
卡住了截图给 Claude 看

第二优先（这周就配）：

试试 Git Worktree 并行开发
把 CLAUDE.md 精简到 200 行内
给 skill 加一个 Gotchas 小节

第三优先（有空再玩）：

挑一个社区工作流（推荐从 Spec Kit 或 Matt Pocock Skills 开始）
试试跨模型（Claude + Codex）审查
玩玩 /loop 和 /schedule 周期任务

六、这套实践背后的统一逻辑

把这 25 条 + 6 个工作流 + 5 个问题全看完，你会发现它们都指向几个共同的核心理念：

第一，上下文是王。 plan 模式、worktree、rewind、context rot、200 行 CLAUDE.md，全是在管理上下文。Claude Code 的成败，70% 取决于你能不能让上下文保持干净、聚焦、不腐烂。

第二，验证胜于信任。 给 Claude 验证方法、分阶段配测试、跨模型 review、fresh context 审查，全是在建立"不靠感觉、靠证据"的验证机制。这正是 Loop Library 那套"loop 四问"的核心。

第三，专精胜于通用。 功能专属 sub-agent、Gotchas 积累、匹配任务规模，别追求一个万能 agent，而要养一群各有所长的专家。

第四，分工胜于独干。 builder-reviewer 双角色、跨模型、社区工作流的流水线，把"一个 agent 啥都干"换成"多个角色各司其职"。

这四条，跟前面我们拆过的 Codex 橙皮书"标准六步法"、Loop Library 的 loop 设计、senda 的"配置即文件"，本质上是同一套哲学，用工程纪律约束 AI 的自由度，让它的产出可验证、可复现、可信任。

七、怎么拿

官方 CLI 仓库：github.com/anthropics/claude-code
官方文档：code.claude.com/docs
社区工作流（按星数从高到低）：Superpowers / Everything Claude Code / Matt Pocock Skills / Spec Kit / gstack
原图保存：本文开头的 cheatsheet 长图，建议存下来随时查

一句话总结：Claude Code 的强大不在工具本身，而在用法。 这套从官方团队和社区高手身上萃取的最佳实践，就是那个"用法"的完整答案。把它当 checklist，一条条对照自己的习惯，你的 AI 编程效率会上一个台阶。

本文基于 Tech with Mak（@techNmak）的 X 推文整理，原文 https://x.com/techNmak/status/2068884177383047439 。内容综合了 Claude Code 团队（Boris Cherny 等）的官方实践和社区工作流。cheatsheet 长图来自原推文配图。

推荐配合阅读：

《Codex 橙皮书》第四篇"标准六步法"，和本文的 plan/验证理念一脉相承
《Loop Library》的 loop 四问，本文"验证胜于信任"的理论基础
CJ Zafir 的 Codex 电池优化 prompt，本文"可验证可撤销"的实战案例

本文是第二大脑 vault 的 raw 阅读笔记（2026-06 编译），观点与数字以写作时点为准。全系列背景见《把 18 篇文章喂给 Claude，编译出一座第二大脑》。

相关：Claude Code 速查表。anthropics/claude-code 仓库发布时已 15.3 万星（笔记写作时 58K）。

字节笔记本