Claude Code 创始人亲授：10 条进阶秘籍（附 12 条工作流 Prompt 清单）

开篇：先用 30 秒把它讲明白

很多人用 Claude Code，用到最后会变成两种极端：

要么把它当 Copilot，问一句、改一点。

要么把它当“万能黑盒”，一句话丢进去，等它自己跑完，然后再花更久去收拾输出。

创始人 Boris Cherny 的这套“10 条进阶秘籍”，其实是在纠正这两种用法。

核心思想很朴素：把 Claude 当成一个能被调度的同事，用流程跑工程问题。

你不需要写更花的提示词。你需要更像一个工程师下任务。

先给我的结论

这 10 条可以归成 4 个关键词：

1. 1. 并行：用 git worktree 让多个任务同时推进。
2. 2. 先计划：复杂任务先 Plan Mode，不要硬推。
3. 3. 沉淀规则：把反复纠错写进 CLAUDE.md，让它下次别再踩。
4. 4. 减少切换成本：技能化、MCP、子代理，把“人肉搬运”交给系统。

最后我把官方文档的 Common workflows 又整理成一份可复制的 12 条工作流清单，放在文末做附录。

太长不看版（10条 + 1个附录）

• • 1）同时开 3 到 5 个 git worktree，一个任务一个 worktree，一个 Claude 会话一份干净上下文。
• • 2）复杂任务先 Plan Mode，把验收和验证步骤也写进计划里。
• • 3）每次 Claude 犯错，你纠正完就让它更新 CLAUDE.md，形成“项目宪法”。
• • 4）每天重复超过一次的事，做成 skills 或 slash command。
• • 5）修 bug 时少微操：给它复现入口与证据，直接说“去修 failing CI tests”。
• • 6）Prompt 进阶靠三招：让它当 reviewer、让它证明能跑、让它推翻重做更优雅解。
• • 7）终端体验也算生产力：/statusline 把上下文和分支钉在状态栏里。
• • 8）子代理用来分工，必要时用 hooks 把权限请求做成自动化守门。
• • 9）把数据分析交给 Claude：能用 CLI/MCP 拉数据的，都能“问一句就出结论”。
• • 10）用 Claude 学习：解释模式、HTML 讲解、ASCII 图、间隔复习 skill。
• • 附录）官方文档 12 条常用工作流 Prompt 清单。

01｜并行：一个任务一个 worktree

Claude Code 团队内部最推的第一条，是“同时开 3 到 5 个 worktree”。

你可以把它理解成：把并行能力交给 Git，把上下文隔离交给 worktree。

# 新建 worktree + 新分支
git worktree add ../project-feature-a -b feature-a

# 或者基于已有分支建 worktree
git worktree add ../project-bugfix bugfix-123

进入各自 worktree 后分别开 Claude，会天然得到两个收益：

• • 每个会话的上下文更干净，不会互相污染。
• • 一个任务卡住，你不会被迫停工，可以切去另一个任务继续推进。

做得再激进一点，可以给 worktree 配 shell alias（例如 za、zb、zc），一键跳转。

02｜Plan Mode：越复杂越要先做设计评审

Plan Mode 更像是用来减少返工的。安全只是副产品。

团队里很常见的做法是：

• • 一个 Claude 先写 plan。
• • 再开第二个 Claude，用“Staff Engineer”的视角评审这份 plan。
• • 一旦执行偏离预期，立刻切回 Plan Mode 重新规划，不要硬推。

你可以直接这样开：

claude --permission-mode plan

然后让它按结构出计划：

> 先只读分析现状，不要改文件。
> 请按这个结构给计划：
> 1) 现状摘要（含关键文件列表）
> 2) 目标与非目标
> 3) 实施步骤（按 PR 切分）
> 4) 风险清单（每条对应规避方式）
> 5) 验证清单（命令级别）
> 6) 回滚方案

这里的关键点是：把“验证步骤”也写进计划里。

很多失败不是代码写错，是验证没跟上。

03｜CLAUDE.md：把纠错写成规则

Boris 给的做法非常直接：

每次 Claude 犯错，你纠正完就补一句：

> 更新 CLAUDE.md，确保以后不再犯同样的错误。

这句话的含义是：把你刚才的“口头经验”变成可复用的系统约束。

团队里还有一个技巧我很喜欢：

• • 让 Claude 为每个任务维护一个 notes 目录。
• • 每次 PR 合并后更新 notes。
• • 再让 CLAUDE.md 引用这些 notes。

这样 CLAUDE.md 负责规则，notes 负责证据与上下文。

04｜Skills：每天重复超过一次，就做成技能

这条很像工程管理里的那句老话：重复劳动超过两次就值得自动化。

团队给的例子很实在：

• • 做一个 /techdebt 命令，每次会话结束扫一遍重复代码。
• • 做一个一键同步上下文的命令，把过去 7 天的 Slack、Drive、Asana、GitHub 记录导出成一个“上下文快照”。
• • 按岗位做垂直 Agent，比如 analytics engineer 风格的 agent，专门写 dbt、跑分析、评审代码、在开发环境验证变更。

你不需要一次性做大而全。

先从最烦的重复活开始。

05｜修 bug：少微操，多给证据

团队对“修 bug”这件事的态度很明确：

把上下文切换成本干掉，把微操干掉。

三种典型用法：

1）如果你有 Slack MCP，把 bug 讨论串直接贴给 Claude，只说一个词：

fix

2）如果是 CI 爆了，就别指导它怎么修，直接下任务：

> Go fix the failing CI tests.

3）如果是线上或分布式问题，就把 Docker logs 当证据给它，让它先讲清根因，再给排查路径。

你要的是“让它把问题跑通”，不是“你替它写 plan，然后让它照抄”。

06｜Prompt 进阶：让它当 reviewer，而不是当打字员

这一条的精髓是：把 Claude 拉到“审查与证明”的位置上。

三个很狠但很好用的口令：

a）让它拷问你

> 对我这些代码变更进行严厉拷问。在我通过你的测试之前，不要创建 PR。

b）让它证明能跑

> 向我证明这行得通。请对比 main 分支和当前 feature 分支的行为差异，列出你验证了什么。

c）让它推翻重做

> 基于你现在掌握的所有信息，废掉目前的方案，去实现一个更优雅的解法。

这三句的共同点是：你在要求“可验证的交付”，而不是“看起来像对的输出”。

07｜终端与环境：把上下文成本钉在你眼前

团队提到一个很细但很关键的点：终端体验会直接影响你写 Prompt 的质量。

他们很喜欢 Ghostty，也会用 tmux、标签页命名和颜色标记来管理并行任务。

最推荐的一个动作是：用 /statusline 把关键信息固定在状态栏里。

比如始终显示：

• • 当前上下文用量
• • 当前 Git 分支

另外一个很现实的建议是用语音听写。

说话速度通常比打字快，你的描述也更完整。

08｜子代理与 hooks：分工 + 守门

子代理的价值就两点：

1）需要更多推理算力时，直接在请求末尾加一句：

use subagents

2）把独立子任务 offload 给子代理，主会话保持干净，别让“碎细节”把上下文挤爆。

团队还提到一个更进阶的玩法：

通过 hooks 把权限请求路由给更强模型，让它扫描潜在注入攻击，并自动批准安全请求。

这类自动化很强，但也更敏感。

我的建议是：先在非生产环境把流程跑顺，再考虑自动批准。

09｜数据分析：让 Claude 直接跑 CLI 拉指标

团队的用法是让 Claude Code 调用 bq（BigQuery CLI）即时拉取并分析指标。

他们把 BigQuery skill 放进代码库，团队成员直接在 Claude Code 里跑分析查询，甚至“半年没写过 SQL”。

这一招并不只适用于 BigQuery。

只要你的数据源有 CLI、MCP 或 API，都可以做同样的事情：

• • 让它拉数据
• • 让它解释波动
• • 让它把结论写成可复用的分析模板

10｜学习：让 Claude 讲清楚“为什么”

团队给了 4 个学习向技巧，都是那种你用一次就会形成习惯的：

1）在 /config 里开 Explanatory 或 Learning 输出风格，让它解释每一步改动背后的原因。

2）让它把陌生代码生成一份 HTML 演示文档，用“幻灯片”的方式讲清结构。

3）让它画 ASCII 架构图，尤其适合协议、链路和复杂数据流。

4）做一个间隔复习（spaced repetition）的学习 skill：你先讲理解，它追问补缺口，然后把结果记录下来。

你会明显感觉到：学习成本从“读文档”变成“对话式复盘”。

这 10 条背后的共同模型

我更愿意把它看成一套组合拳：

1. 1. 空间换时间：worktree 并行。
2. 2. 设计重于编码：Plan Mode 先行。
3. 3. 构建数字记忆：CLAUDE.md 持续迭代。
4. 4. 工具化与自动化：skills、MCP、子代理降低切换成本。

把它跑顺，你会从“让 AI 帮我写代码”，变成“我在调度一个工程系统”。

附录｜12 条工作流 Prompt 清单（Common workflows，可直接复制）

这 12 条来自官方文档 Common workflows，我按“从读仓库到交付”的顺序整理了一版。

1）读仓库拿地图

> give me an overview of this codebase
> explain the main architecture patterns used here
> what are the key data models?

2）找相关代码

> find the files that handle user authentication
> how do these authentication files work together?
> trace the login process from front-end to database

3）修 bug（带复现入口）

> I'm seeing an error when I run npm test
> suggest a few ways to fix the @ts-ignore in user.ts
> update user.ts to add the null check you suggested

4）重构（保持行为不变）

> find deprecated API usage in our codebase
> refactor utils.js to use ES2024 features while maintaining the same behavior
> run tests for the refactored code

5）用子代理分工

> /agents
> use the code-reviewer subagent to check the auth module
> have the debugger subagent investigate why users can't log in

6）Plan Mode（只读分析再给计划）

claude --permission-mode plan
> Analyze the authentication system and suggest improvements

7）写测试（先找缺口）

> find functions in NotificationsService.swift that are not covered by tests
> add tests for the notification service
> run the new tests and fix any failures

8）创建 PR

> /commit-push-pr
> summarize the changes I've made to the authentication module
> enhance the PR description with more context about the security improvements

9）补文档

> find functions without proper JSDoc comments in the auth module
> add JSDoc comments to the undocumented functions in auth.js
> check if the documentation follows our project standards

10）用图片做上下文

> What does this image show?
> Here's a screenshot of the error. What's causing it?
> Generate CSS to match this design mockup

11）用 @ 引用文件/目录/MCP 资源

> Explain the logic in @src/utils/auth.js
> What's the structure of @src/components?
> Show me the data from @github:repos/owner/repo/issues

12）当成命令行组件：pipe in/out + 控制输出格式

cat build-error.txt | claude -p 'concisely explain the root cause of this build error' > output.txt
cat data.txt | claude -p 'summarize this data' --output-format text > summary.txt