技术实战

别让 Claude Code 一路狂奔：高手都在盯这 5 个地方

Claude Code 的进阶用法不是把权限开大，而是建立一套可中断、可回滚、可验证的工作流。

⏱️ 约 18 分钟阅读
🏷️ Claude Code AI 编程 开发工作流 软件工程

Claude 修一个 bug，顺手改了 12 个文件。

它删了旧组件，换了依赖，重写了一段状态管理。终端里日志飞快滚动，看起来很努力，也很专业。

你隐约觉得不对，但没按 Esc。

十分钟后，测试挂了，页面也挂了。最麻烦的是，你已经看不清它到底从哪一步开始跑偏。

很多人用 Claude Code 的进阶方式，恰好是错的：把权限开大，把确认关掉，把任务丢进去，然后等它“一路跑完”。这不是高手，这是把方向盘交出去。

Claude Code 真正好用的地方，不是它能连续工作，而是你能在它工作时不断校准。

真正的进阶，不是放手，而是会接管。

Claude Code 控制回路

先理解它为什么会跑偏

Anthropic 的 Cal 在官方最佳实践分享里提到一个很关键的心智模型：Claude Code 很像一个“只用终端的同事”。

它不是靠提前索引整座代码库，然后从向量数据库里召回文件。按照官方分享里的说法，它更像一个新同事进入项目：用搜索、glob、grep、find 之类的方式，一点点探索代码库，看到结果后再决定下一步搜哪里。

这套方式很灵活，但也有代价。

它会不断读文件、跑命令、改代码，上下文越来越长，判断会受当前看到的信息影响。如果你一开始没给规则，中途不看计划，最后也不跑测试，它当然可能越走越偏。

所以 Claude Code 的进阶，不是让它更自由。

而是给它一条轨道。

第一个地方：CLAUDE.md，不是备忘录，是项目规则

很多人知道 /init 可以生成 CLAUDE.md，但写完就放在那里了。

这很浪费。

官方分享里说得很清楚：当你启动 Claude Code 时，如果当前工作目录里有 CLAUDE.md，它会被放进上下文里，作为开发者留给 Claude 的重要指令。

这不是“给 Claude 留一句备注”。

这是你给它的项目规则。

CLAUDE.md 里至少应该有三类信息：

类型应该写什么例子
项目结构模块在哪里，测试在哪里，入口在哪里src/app 是路由，src/lib 放业务逻辑
运行方式怎么启动、测试、构建npm test、npm run typecheck、npm run lint
工程约束不能做什么，修改前要注意什么不要引入新状态库；改 API 前先看兼容层

一个实用模板：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# Claude 工作规则

## 项目结构
- src/app：页面和路由
- src/components：可复用组件
- src/lib：业务逻辑
- tests：单元测试和集成测试

## 常用命令
- 开发：npm run dev
- 测试：npm test
- 类型检查：npm run typecheck
- Lint：npm run lint

## 修改原则
- 不要一次性大重构
- 每次修改后先跑测试
- 新增依赖前必须说明理由
- 如果发现需求不清楚，先提问，不要猜

注意最后两条。

CLAUDE.md 最有价值的地方，不是告诉 Claude “项目是什么”，而是告诉它“什么事情不要做”。

AI 写代码最危险的时刻，往往不是它不会写，而是它太会写：为了修一个小 bug，顺手把你半个项目“优化”了。

第二个地方：权限，别把所有按钮都点成允许

Claude Code 的默认交互里，读文件和搜索这类动作通常比较顺畅；一旦涉及写文件、跑 bash、做可能改变机器状态的操作，就会触发确认。

很多人嫌烦，看到确认框就一路 yes。

这会很快。

也会很危险。

官方分享里提到，可以通过权限管理加速工作流，比如某些你反复确认的低风险命令，可以配置为总是允许。典型例子是：

1
2
3

npm test
npm run lint
npm run typecheck

这些命令不改变代码，允许它们自动跑，问题不大。

但下面这些就不要轻易放行：

1
2
3
4
5

rm -rf
npm install <new-package>
git push
数据库迁移命令
修改生产配置的脚本

权限管理的原则很简单：

  • 读操作，可以放宽
  • 测试和检查，可以自动
  • 写文件，要看上下文
  • 装依赖、删文件、推远端，必须人工确认

Claude Code 最怕的不是慢，是一路跑错。

你为了省几个确认，把高风险动作都放行，最后省下来的时间会在回滚时全部还回去。

第三个地方：/compact，不是垃圾清理，是换班交接

长会话里，Claude 的上下文会越来越满。

官方分享里提到，Anthropic 的模型上下文窗口可以到 200,000 tokens，但这不代表你应该一直塞到满。Claude Code 底部会出现上下文警告，这时候你通常有两个选择：

1
2

/clear
/compact

区别很大。

/clear 更像清桌子。除了类似 CLAUDE.md 这样的基础规则，前面的对话会被清掉。

/compact 更像换班交接。Claude 会总结之前做了什么、现在进度到哪、下一步应该怎么接，然后用这份总结作为后续会话的种子。

什么时候用 /compact？

  • 一个功能做到一半，但上下文快满了
  • Claude 已经探索了很多文件，你不想重新解释
  • 修 bug 过程很长，中途有关键发现
  • 需要把同一个任务接着做下去

什么时候用 /clear？

  • 前面的方向错了，不想污染后续判断
  • 任务已经结束，准备开始另一个完全不同的任务
  • Claude 被错误假设带偏了，需要干净上下文

不要把 /compact 当成“压缩一下省 token”。

它真正的价值是：让下一轮 Claude 不从零开始，也不背着一堆脏上下文继续跑。

第四个地方：Plan + To-do，不看这个就别说自己在协作

进阶用户和普通用户最大的区别，不是 prompt 写得更长。

是他们会让 Claude 先暴露计划。

官方给的建议很直接：不要只说“修这个 bug”，而是说：

1
2
3

我遇到一个 bug。
请先搜索相关文件，判断原因，然后给我一个修复计划。
在我确认之前，不要修改代码。

这句话的关键不是礼貌，而是顺序：

  1. 先搜索
  2. 再判断
  3. 再给计划
  4. 最后才写代码

Claude 做大任务时会生成 to-do list。你要盯这个列表。

如果你看到它的第二步已经不对，比如：

1
2
3

- 重构认证模块
- 替换状态管理库
- 修改数据库 schema

而你只是让它修一个按钮点击 bug，那就该按 Esc。

不是等它做完再骂它。

是当它开始跑偏时就拦住。

官方分享里还提到，Esc 不只是停止执行。你可以中途打断，然后告诉 Claude：“这个方向不对，调整 to-do list。”甚至可以通过连续按两次 Esc 回到之前的对话位置。

这才是 Claude Code 里最容易被低估的能力。

不是让 AI 一直干。

而是你能随时接管。

第五个地方：Smart Vibe Coding，快但别瞎跑

“Vibe Coding”这个词现在很流行，但它很容易被误解成：我说一句，AI 做完。

官方分享里更推荐的是 Smart Vibe Coding。

重点不是 vibe，而是 smart。

具体做法很工程化：

  • 让 Claude 小步修改，不要一次性大重构
  • 每一步跑测试
  • 跑 TypeScript 检查
  • 跑 lint
  • 定期 commit
  • 发现方向不对，随时回滚

这听起来不酷，但很有用。

一个更稳的 prompt 可以这样写：

1
2
3
4
5
6
7
8

帮我修复这个登录页按钮点击无响应的问题。
要求：
1. 先定位原因，不要直接改代码
2. 给出修复计划
3. 每次只改一个小点
4. 修改后运行 npm test 和 npm run typecheck
5. 如果需要新增依赖，先说明理由
6. 修复完成后总结改了哪些文件

这比“帮我修一下”强太多。

因为你把验收标准、执行粒度、风险边界都写进去了。

让 AI 写代码可以快，但让它小步验证才稳。

MCP 和 CLI：扩展能力，不是堆插件

Claude Code 很擅长终端。

所以官方分享里的建议也很实际：如果某个外部工具本身就有成熟 CLI，比如 GitHub 的 gh，优先考虑直接安装 CLI，让 Claude 使用它。

只有当内置工具和 CLI 都不够时，再考虑 MCP server。

这个顺序很重要：

1
2
3

先用内置工具
再用成熟 CLI
最后再上 MCP

MCP 很强，但不是越多越好。

每多接一个服务，就多一层权限、多一层上下文、多一个可能出错的地方。尤其是 Gmail、Notion、Drive 这类带个人数据的服务，不要为了“高级感”随手接进去。

如果你只是想让 Claude 操作 GitHub issue，gh 可能比一个 MCP server 更简单、更稳定，也更容易审计。

Headless Automation：可以用，但别急着塞进 CI

官方分享里提到，Claude Code 可以程序化使用，比如接进 GitHub Actions、CI/CD 之类的地方。Anthropic 自己也在探索这种 headless automation。

这件事很诱人。

但我的建议是：先别急着把它放进关键链路。

更合理的落地顺序是：

  1. 本地手动跑，确认工作流稳定
  2. 半自动：让 Claude 生成报告、检查 PR、给建议
  3. 低风险自动化：只读分析，不直接改代码
  4. 高风险自动化：必须有人审核，不能自动合并

CI/CD 里的 Claude Code，适合先做“副驾驶”，不适合一上来当“驾驶员”。

比如你可以让它：

  • 总结 PR 改动
  • 找明显风险点
  • 解释测试失败原因
  • 生成迁移 checklist

但不要一开始就让它在 CI 里自动修复、自动提交、自动推送。

那不是自动化成熟，是事故预备。

一套可复制的 Claude Code 工作流

把前面这些合起来，真实项目里可以这样用：

1
2
3
4
5
6
7

1. 启动前：确认 CLAUDE.md 里有项目规则和测试命令
2. 提需求：要求 Claude 先搜索、再出计划
3. 执行中：盯 to-do list，不对就 Esc
4. 每一步：跑测试、typecheck、lint
5. 中途上下文变长：用 /compact 做交接
6. 方向错了：/clear 或回滚到最近 commit
7. 任务结束：让 Claude 总结修改文件和风险点

如果你愿意，可以把这段直接放进自己的 CLAUDE.md：

1
2
3
4
5
6
7
8

## Claude 执行任务时必须遵守
- 复杂任务先搜索相关文件，再给计划，不要直接改代码
- 计划确认后再执行
- 大任务拆成小步骤，每一步完成后更新 to-do list
- 修改后运行 npm test、npm run typecheck、npm run lint
- 如需新增依赖或大规模重构，必须先说明理由
- 如果发现原计划不合理，先停下并解释，不要自行扩大范围
- 任务完成后总结改动文件、验证结果和潜在风险

这段话不花哨，但能救命。

写在最后

Claude Code 的能力很强，但它不是一个你可以完全放任的黑盒。

你越是把它用在真实项目里，越要有控制回路：规则、计划、权限、测试、回滚。

不要迷信一路自动执行。

真正会用 Claude Code 的人，不是看它在终端里表演，而是知道什么时候让它跑，什么时候让它停，什么时候让它重新计划。

你不是观众，你是驾驶员。