开篇：先用 30 秒把它讲明白
很多人用 Claude Code，用到最后会变成两种极端：
要么把它当 Copilot，问一句、改一点。
要么把它当“万能黑盒”，一句话丢进去，等它自己跑完，然后再花更久去收拾输出。
创始人 Boris Cherny 的这套“10 条进阶秘籍”，其实是在纠正这两种用法。
核心思想很朴素：把 Claude 当成一个能被调度的同事，用流程跑工程问题。
你不需要写更花的提示词。你需要更像一个工程师下任务。
先给我的结论
这 10 条可以归成 4 个关键词：
-
1. 并行：用 git worktree让多个任务同时推进。 -
2. 先计划：复杂任务先 Plan Mode，不要硬推。 -
3. 沉淀规则：把反复纠错写进 CLAUDE.md，让它下次别再踩。 -
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. 空间换时间：worktree 并行。 -
2. 设计重于编码：Plan Mode 先行。 -
3. 构建数字记忆： CLAUDE.md持续迭代。 -
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 database3）修 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 suggested4）重构（保持行为不变）
> find deprecated API usage in our codebase
> refactor utils.js to use ES2024 features while maintaining the same behavior
> run tests for the refactored code5）用子代理分工
> /agents
> use the code-reviewer subagent to check the auth module
> have the debugger subagent investigate why users can't log in6）Plan Mode（只读分析再给计划）
claude --permission-mode plan
> Analyze the authentication system and suggest improvements7）写测试（先找缺口）
> find functions in NotificationsService.swift that are not covered by tests
> add tests for the notification service
> run the new tests and fix any failures8）创建 PR
> /commit-push-pr
> summarize the changes I've made to the authentication module
> enhance the PR description with more context about the security improvements9）补文档
> 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 standards10）用图片做上下文
> What does this image show?
> Here's a screenshot of the error. What's causing it?
> Generate CSS to match this design mockup11）用 @ 引用文件/目录/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/issues12）当成命令行组件：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