最近我用 Claude Code CLI 的频率越来越高。

先说一个前提：这里聊的是 Claude Code CLI 这套工作流，不是说模型只能用 Claude。Claude Code 本身限制不少，个人长期用下来费用也不低，国内账号可用性也不稳定。轻度尝鲜问题不大，一旦放进日常开发，成本、额度和可用性都会变成现实问题。

所以我也会关注 cc switch 这类工具，用来切换其他模型或 provider。需要的话直接看项目 README，或者搜最新教程就行。

这篇主要记录最近留下来的几个经验：首次 Prompt 怎么写，无头模式什么时候用，Plan 模式怎么多迭代几轮，长任务怎么管 session 和上下文，复杂 review 怎么拆给多个 agent，以及 MCP、hooks、浏览器工具这些能力什么时候真的有用。

1. Claude Code CLI 工作流

AI 对我来说，已经不只是代码补全或局部代码生成了。它现在可以参与一个真实开发任务的完整链路：读项目、拆需求、做计划、改文件、跑测试、看日志、做 review。需要的时候还能接 MCP、操作浏览器，或者把复杂任务拆给多个 agent。

国内外很多互联网公司都在推，我的公司也不例外。

一个真实任务通常不是“帮我写一个函数”这么简单。它可能会持续几个小时，甚至几天。中间会有方案调整、上下文变长、测试失败、review 反馈、临时分支和回滚考虑。Claude Code CLI 比较适合我的地方，就是它能把这些动作串起来，而不是只停留在一次对话里。

2. Prompt 和无头模式：第一次描述要尽量清楚

首次 Prompt 很重要，尤其是无头模式。

无头模式没有太多来回追问的空间。模型拿到什么输入，就会基于这一次输入直接给结果。所以这种场景里，Prompt 要尽量写清楚：你要它做什么、输入是什么、输出格式是什么、不要做什么。

例如一次性分析项目，可以这样写：

claude -p "阅读当前项目结构，帮我总结主要模块、潜在风险和下一步建议。输出用 Markdown 列表。"

session 会话里的要求可以稍微放松一点，因为你可以继续补充、追问、纠偏。但也不要只写“帮我优化一下”。至少要说清楚优化什么、范围在哪里、什么不能动。

如果需求还没想清楚，我通常会先用 Gemini、ChatGPT 或其他模型整理一版 Prompt，再自己确认一遍。

我经常会这样问：

我准备让 Claude Code 修改一个项目，但需求还比较散。
请帮我整理成适合 coding agent 执行的 Prompt。
 
请包含：
1. 目标
2. 背景
3. 约束
4. 执行步骤
5. 验收标准
6. 明确不要做的事情
 
要求语言直接，不要写成产品宣传文案。

这样真正进入 Claude Code 时，需求已经被整理过一轮，agent 不容易跑偏。

3. Plan 模式不要只看第一版，要多轮迭代

Plan 模式最容易被低估的一点是：它不是为了让 AI 立刻给一个完美方案，而是先把需求、改动范围、风险和验证方式写出来。

在 Claude Code CLI 里，可以直接输入：

/plan

进入 Plan 模式后，它不会直接改文件，而是先给方案。你可以继续追问，要求它收敛方案，或者补充新的约束。等方案确认后，再批准它退出 Plan 模式，回到可以编辑文件、运行命令的执行状态。

我一般不会直接接受第一版 plan。第一版通常能覆盖大方向，但不一定是最小改动，也不一定考虑了回滚和验证。真正有价值的是后面的两三轮追问。

比如先让它给多个方案：

先不要写代码。请给我 3 个方案：
 
1. 最小改动方案
2. 长期可维护方案
3. 风险最低方案
 
每个方案说明：
- 改动范围
- 可能影响的文件
- 主要风险
- 验证方式
- 如果出问题怎么回滚
 
最后给出你的推荐，但不要直接开始执行。

然后继续收敛：

基于你推荐的方案，再收敛一版。
 
要求：
- 尽量减少文件改动
- 不引入新依赖
- 保留清晰的回滚点
- 标出最容易出问题的 3 个点
- 明确哪些地方需要测试

这个过程很像跟同事做方案评审。真正节省时间的不是让 AI 立刻写代码，而是在写代码前，把明显会踩坑的地方先暴露出来。

还有一个很小的体感：/plan 和后面的执行阶段可以放在一起理解。

比如我只输入了一句不完整的“如何在 Claude Code”，Plan 模式不会急着往下编答案，而是先把问题拆成几件事：这句话缺少后半句，可能是在问安装、常用命令、配置、MCP，或者 API/SDK；如果要回复，应该先承认问题不完整，再给几个常见方向。

这和真正开始执行时的感觉很像，只是阶段不同。/plan 更像先把边界画出来，确认“到底要做什么、不要做什么、怎么验证”；确认之后再让它改文件、跑命令、做检查。前者挡住模糊需求，后者负责落地。

我现在会更愿意把这一步保留下来。尤其是需求还没说完整的时候，让它先 plan 一轮，往往比直接让它动手更稳。看起来慢了一步，实际是少返工。

4. 长任务怎么不中断：/rename、resume、/compact 和 /effort

Claude Code 适合做长期任务，一个原因是它不要求每次都从零开始。

我通常会在任务进入正轨后给 session 起名：

/rename 优化tgbot

后面继续时直接恢复：

claude -r 优化tgbot

这看起来只是一个小命令，但对持续几小时甚至几天的任务很重要。否则每次重新打开工具，都要重新解释项目背景、目标、限制和进度。

上下文管理也很关键。上下文不是越长越好。

一个任务推进久了之后，Claude Code 可能已经看过很多文件、日志、方案和中间结论。信息越多，响应不一定越稳。我的习惯是在一个阶段完成后手动 /compact，把当前阶段压缩成更稳定的上下文，再进入下一阶段。

简单问题可以把 effort 调低，让响应更快：

/effort low

遇到设计、排查、review 这类需要深挖的问题，再把 effort 调高。

5. 复杂需求怎么拆：/branch、Team 模式和多 Agent Review

如果一个任务有两条路线都值得试，我会用 /branch 做分叉。它有点像在当前 session 上做一次 A/B 实验。

/branch

更复杂的任务，我不太喜欢让一个 agent 从头干到尾。

一个 agent 很适合保持主线，但它也容易带着同一套假设一路做下去。代码 review、风险检查、测试补充这类事情，反而适合拆给多个 agent，从不同角度看同一份改动。

例如一次代码 review，可以这样分配：

请用多个 agent review 这次改动：
 
1. 业务逻辑 reviewer：检查需求是否实现、边界条件是否遗漏
2. 安全 reviewer：检查权限、输入校验、敏感信息
3. 测试 reviewer：检查关键路径是否有测试覆盖
4. 性能 reviewer：检查是否引入明显性能问题
 
最后汇总成一份 review 报告，按严重程度排序。

也可以让主 agent 自己判断是否需要拆分：

这是一个比较复杂的任务。请你先判断是否需要多个 agent 并行。
 
如果需要，请先拆分角色和任务边界，再分别执行。
每个 agent 输出自己的结论，最后由主 agent 汇总方案和风险。

这类场景可以归到 Team 模式里理解：复杂需求可以并行执行多个 agents，agents 之间也可以互相通信。

Team 模式官方文档

6. MCP 不只是接工具：用 Pencli / Pencil 画思维图、导图和流程图

MCP 最有意思的地方，不是“又多接了一个工具”，而是让 Claude Code 能把思考结果落到外部系统里。

比如 Pencli / Pencil 这类工具，可以用来画思维图、导图和流程图。我更喜欢在需求分析和方案设计阶段用它：先让 Claude Code 把模块关系、任务拆解、调用流程整理出来，再生成一张图。

可以这样让它生成一张流程图：

请基于当前方案，整理一张流程图：
 
- 展示用户请求从入口到数据库写入的完整路径
- 标出权限校验、异常处理和日志记录的位置
- 标出可能失败的位置
- 标出需要测试覆盖的节点
- 用 Mermaid 或 Pencil 可识别的结构表达
 
不要写实现代码。

我比较推荐把 MCP 当成“工作流扩展”，而不是见一个接一个。尤其是能访问浏览器、仓库、接口、本地文件的 MCP，一定要确认来源和权限。

7. 浏览器工具：让 Claude Code 参与前端检查和页面验证

浏览器工具适合把 Claude Code 从代码层带到页面层。

比如前端改完后，不只是让它读代码，还可以让它打开页面、检查 console、操作表单、验证交互路径。agent-browser、chrome-devtools-mcp 这类工具适合做页面检查、本地调试、表单验证和简单的视觉回归排查。

我会在这些场景里用浏览器工具：

• 改完页面后，让它检查 console error
• 验证一个表单能不能完整提交
• 检查登录态、跳转和错误提示
• 让它对照需求走一遍核心路径

图片粘贴也很实用。在 macOS 里，可以用 ctrl + v 把图片贴进 Claude Code，让它结合截图分析问题。

配合 Browserbase Skills 用会更舒服。

8. Hooks、notify 和 /loop：把重复动作自动化

hooks 是 Claude Code 里很容易被低估的能力。

前面的能力更多是在“对话里提效”，hooks 则是把一些固定动作塞进工作流。比如执行 bash 前改写命令，减少高 token 输出；长任务结束后发通知；或者周期性跑某些检查。

比如 rtk 这类 hook 可以在执行 bash 时做 rewrite，把一些高 token 输出的命令改得更短，从而节省上下文。示例配置大概长这样：

{
  "matcher": "Bash",
  "hooks": [
    {
      "type": "command",
      "command": "/Users/waylen/.claude/hooks/rtk-rewrite.sh"
    }
  ]
}

notify hook 很适合长任务。跑测试、构建、批量 review 时，不用一直盯着终端，结束后让系统通知你。

/loop 更适合分钟级的周期任务，比如定期检查日志、重复跑某个验证命令、观察某个状态变化。它不适合拿来做特别精细的秒级调度。

9. 我推荐的入门学习路径

如果你刚开始用 Claude Code CLI，我建议不要一上来就研究所有配置。

可以按这个顺序来：

1. 先学会把需求整理成清楚的 Prompt
2. 用无头模式处理一次性任务，练习把输入和输出说清楚
3. 再用 Plan 模式多问几轮，不急着写代码
4. 学会 /rename、resume 和 /compact，让任务能持续推进
5. 开始用 /branch 尝试不同方案
6. 做 review 时引入多个 agent
7. 前端项目再接浏览器工具
8. 需要画图和外部系统时，再接 MCP，比如 Pencli / Pencil
9. 最后再研究 hooks、notify、/loop 和 cc switch

相关链接

• Claude Code 官方文档
• Claude 速查表
• cc switch
• Pencil / Pencli 文档
• claude-mem
• superpowers