无招胜有招：Anthropic 内部专家的 Claude Code 工作流完全拆解

埃兰德欧神

发布于 2026-01-07 18:59:02

1.3K0

文章被收录于专栏：开源地带开源地带

最近看到 Anthropic 内部“Claude Code 之父” Boris Cherny 分享他的使用技巧，我第一反应是：这哥们肯定配了一堆骚操作吧？结果点开一看，傻眼了——人家开场第一句就是：

“我的配置可能出乎你意料地原装。Claude Code 开箱即用效果就很好，我个人没做太多定制。”

这就像你去问武林高手用什么屠龙刀，人家告诉你“我就用超市买的菜刀”。但仔细一琢磨，这才是真高手的境界。今天就跟大家唠唠 Boris 分享的 9 条实战技巧，每一条都朴实无华，但背后的思路值得好好品味。

1. 核心理念：别费劲找“最佳实践”了

Boris 说得很直白：Claude Code 团队故意把工具设计成“可以随便折腾”，团队内部每个人用法都完全不同。这意味着啥？没有标准答案。

“使用 Claude Code 没有唯一正确的方式。适合自己的节奏最重要。”

很多人（包括我）刚接触新工具时，总想先研究透“正确用法”再开始干活。但这种心态本身就是效率杀手。工具是为人服务的，不是人为工具服务。你习惯终端就用终端，喜欢网页就用网页，爱配置就配置，懒得折腾就开箱即用——都行。

这让我想起以前折腾 Vim 配置，花三天研究插件，结果写代码还不如直接用 VSCode 香。工具是用来解决问题的，不是用来炫技的。

2. 多 Agent 并行：同时开十几个 Claude 干活

Boris 的日常操作是这样的：

终端开 5 个 Claude Code 实例（标签页编号 1-5）
网页版再跑 5-10 个任务
早上用手机 Claude 启动几个任务，晚点回来看结果

这种“多线程”工作方式的核心是：让 AI 自己跑，你去忙别的。启动任务、给个方向，等它需要你确认时再切回来。

这跟传统的“人敲一行、AI 补几行”完全是两种节奏。很多人还停留在“盯着 AI 写代码”的阶段，但真正高效的用法是：你是项目经理，Claude 是打工人，你分配好任务就行了。

说实话，我现在也还不太习惯同时开太多任务，总担心“失控”。但想想看，我们平时不也是同时处理好几个需求吗？只不过以前是你自己写，现在是委派给 AI 罢了。今年得练练这个能力。

3. 模型选择：为啥用慢的 Opus 而不是快的 Sonnet?

Boris 所有任务都用 Opus 4.5 加 thinking 模式。有人肯定会问：Opus 不是更慢吗？

他的回答很实在：虽然单次响应慢点，但纠错次数少得多，综合下来反而更快。

写代码不能图快，得质量高。如果一个快模型让你来回纠正三次，不如用个慢模型一次搞定。时间成本不只是模型响应时间，还有你的注意力和精力成本。

就像我以前写前端组件，总想着“快速迭代”，直接写 inline style，结果后期维护各种样式冲突，反而要花更多时间重构。如果一开始慢一点，认真设计好 CSS 架构，后面反而省时间。有时候，“慢”才是真的快。

唯一的问题就是 Opus 成本更高。但如果你算上返工时间和精力损耗，这笔账可能还是划算的。

4. CLAUDE.md：团队共享的“项目记忆”

CLAUDE.md 是个放在项目根目录的特殊文件，Claude Code 启动时会自动读取，把里面内容当“背景知识”。你可以理解为：给 AI 写的项目说明书。

Boris 团队的做法很绝：

整个团队共用一个 CLAUDE.md，提交到 Git
每周都有人往里加东西
规则超简单：每次看到 Claude 做错了，就把“别这样做”写进去

更绝的是，他们在代码审查时会 @.claude，让 Claude 自己把新规则加到 CLAUDE.md 里（通过 GitHub Action 实现）。

这就是 Dan Shipper 说的“复利工程”——每一次纠错都变成团队资产。传统开发里，老员工教新人的经验只能口口相传，现在这些经验直接固化成 AI 的“肌肉记忆”了。

我自己的项目里也开始这么干了。比如我用 Appwrite 做后端，每次遇到权限配置的坑，就往 CLAUDE.md 里补一条：“Appwrite 的角色权限要在创建 Document 时指定，不能事后修改”。下次 Claude 就不会再犯同样的错。

如果你还没用过 CLAUDE.md，强烈建议试试。最简单的起步方式是运行 /init 命令，Claude 会自动分析项目结构生成初始版本，然后你边用边补充就行。

5. Plan 模式：先想清楚再动手

Boris 说他大多数会话都从 Plan 模式开始（按两下 Shift+Tab 切换）。

Plan 模式下，Claude 不会直接改代码，而是先给你一个执行计划。你可以来回讨论、修改计划，直到满意为止，然后切到自动接受模式让它一次性完成。

“好的计划真的很重要。”

这个习惯其实是把软件开发的经典智慧搬到了 AI 协作里：先设计再编码。很多人用 AI 写代码的问题是直接开干，结果方向错了返工成本很高。花几分钟对齐计划，能省几小时的返工。

这让我想起之前做一个活动页面，直接让 Claude 开写，结果做到一半发现响应式布局的逻辑不对，又得推倒重来。如果一开始花 5 分钟讨论清楚“移动端优先还是桌面端优先、断点怎么设计”，就不会浪费那么多时间了。

6. '/'命令和 Agent：自动化重复劳动

Boris 把每天要用几十次的操作做成了命令。比如 /commit-push-pr，一键完成提交、推送、创建 PR。

命令本质上是放在 .claude/commands/ 目录下的 Markdown 文件，可以提交到 Git 让整个团队共享。

除了斜杠命令，他还用 sub Agent——独立的 Claude 实例，专门干某类活。比如：

code-simplifier Agent：在主 Claude 完成工作后自动简化代码
verify-app Agent：专门负责端到端测试

这两个功能的共同点是：把你反复做的事情固化下来。你不用每次都重复解释，也不用记住各种命令细节。

我自己也搞了个 /deploy-supabase 命令，一键部署数据库迁移+更新 Edge Functions。以前每次部署都得记一堆命令，现在直接一个斜杠搞定。

另外，Boris 还用 PostToolUse Hook 来格式化 Claude 生成的代码，避免后续 CI 过程中出现格式错误。这种"最后 10% 的打磨"交给自动化，人就可以专注在更重要的事情上。

如何创建自定义命令

第一步：创建命令目录和文件

# 项目级命令（仅当前项目可用） mkdir -p .claude/commands  # 个人命令（所有项目可用） mkdir -p ~/.claude/commands  # 创建一个命令文件 touch .claude/commands/commit-push-pr.md

第二步：编写命令内容

命令文件由两部分组成：Frontmatter（元数据）和 Prompt（提示内容）

--- description: 自动提交代码、推送到远程、创建 PR
---  请按以下步骤操作： 1. 运行 git add . 暂存所有更改 2. 生成合适的 commit message 并提交 3. 推送到远程仓库 4. 创建 Pull Request，标题和描述要清晰 5. 输出 PR 链接

保存后，就可以用 /commit-push-pr 调用了！

使用参数：如果命令需要参数，用 $ARGUMENTS 占位符：

--- description: 部署指定环境
---  部署到 $ARGUMENTS 环境： 1. 检查环境配置 2. 运行部署脚本 3. 验证部署结果

使用：/deploy staging 或 /deploy production

创建 Sub-Agent 更简单

不用手写配置，直接用交互式命令：

/agents

Claude 会引导你：

起个名字（如 test-writer）
描述它的职责（如"专门写单元测试"）
选择它能用哪些工具

创建完成后，用 @test-writer 就能调用它了。

7. 安全与集成：权限配置和 MCP 服务器

Boris 不用 --dangerously-skip-permissions 这个"危险"选项。相反，他用 /permissions 命令预先批准一些常用的安全命令，避免每次都弹确认框。

更强大的是 MCP 服务器集成(Model Context Protocol)。通过 MCP, Claude Code 可以直接：

搜索和发送 Slack 消息
跑 BigQuery 查询回答数据问题
从 Sentry 拉错误日志

这意味着 Claude Code 不只是个编程工具，而是能调用你整个工具链的"全能助手"。

想象一下：你在写代码时发现一个 bug，直接让 Claude 去 Sentry 查相关错误日志、分析根因、修复代码、跑测试、发 Slack 通知团队——全程自动化。这才是 AI 协作的终极形态。

我最近也在琢磨怎么把 Claude 接到我的 Appwrite 项目里，让它直接查数据库、看日志、改配置。这样遇到线上问题时，不用自己手忙脚乱翻日志了。

安装 MCP 服务器的基本命令

claude mcp add <服务器名称> <启动命令>

示例 1：GitHub 集成

# 让 Claude 管理 GitHub（需要先设置 GITHUB_TOKEN 环境变量） claude mcp add github -e GITHUB_TOKEN=your_token_here -- npx -y @modelcontextprotocol/server-github

管理已安装的 MCP 服务器

# 查看所有已安装的 MCP 服务器 claude mcp list  # 删除某个 MCP 服务器 claude mcp remove <服务器名称>

配置工具权限

MCP 服务器安装后，还需要授权 Claude 使用它的工具：

/permissions

在交互界面中：

选择要批准的工具（如 github__create_pr、filesystem__read_file）
可以批准单个工具，也可以用通配符批准一类工具（如 github__*）
预先批准后，Claude 就不会反复弹确认框了

8. 长任务处理

对于跑很久的任务，Boris 有几个策略：

让 Claude 完成后自动用后台 Agent 验证结果（可以在提示词里要求，或用 Stop Hook 触发）
用 ralph-wiggum 插件——本质上是个 Bash 死循环，不停地把同一个任务说明书喂给 AI，让它一遍又一遍改进，直到彻底完成
在沙箱环境里用 --permission-mode=dontAsk，让 Claude 不被权限确认打断，自己跑到底

注：Hooks 是 Claude Code 的"钩子"机制，让你在 Claude 执行操作的特定时刻插入自定义逻辑。Stop Hook 就是在 Claude 完成响应、准备交还控制权时触发。

核心思路是：既然是长任务，就别让它等你。给它足够的自主权和自我纠错能力。

这就像你交代下属做一个复杂项目，你不可能每个细节都盯着。你得给他明确的验收标准，让他自己检查、自己迭代，最后交给你的是成品而不是半成品。

ralph-wiggum 是什么？

一个让 Claude Code 自动循环执行任务的插件。它会拦截 Claude 的"退出"动作，自动重新喂给它原始任务——直到任务真正完成或达到最大迭代次数。就像一个永不放弃的打工人。

插件名来自《辛普森一家》里那个"屡败屡战"的角色 Ralph Wiggum——体现了"持续迭代直到成功"的哲学。

安装 ralph-wiggum

# 从官方插件市场安装 /plugin marketplace add https://github.com/anthropics/claude-plugins-official /plugin install ralph-wiggum

基本使用语法

/ralph-wiggum:ralph-loop "<任务描述>" --max-iterations <次数> --completion-promise "<完成标记>"

实战例子：

/ralph-wiggum:ralph-loop "实现用户登录功能，要求：
1. 写单元测试
2. 实现登录逻辑
3. 跑测试直到全部通过
4. 完成后输出 <promise>COMPLETE</promise>" \ --max-iterations 20 \ --completion-promise "COMPLETE"

⚠️ 重要提醒

必须设置 --max-iterations：否则会无限循环，烧光你的 token！
定义清晰的完成条件：用 <promise>完成标记</promise> 包裹，让 Claude 知道什么时候该停
Token 消耗警告：一个 50 次迭代的循环可能消耗 $50-100+ 的 API 费用，建议：
- 先用小任务测试（max-iterations=5）
- 明确任务边界，避免无意义的重复
- 在提示词里写清楚：“如果 15 次迭代后还没完成，输出当前进度和遇到的问题”

适用场景

需要多轮测试-修复循环的功能开发
代码质量迭代优化（重构直到达标）
自动化测试覆盖率提升
过夜任务：睡前启动，早上看结果

9. 最重要的一条：给 Claude 验证能力

Boris 把这条放在最后，说这可能是获得好结果最重要的因素。

“如果 Claude 能验证自己的工作，最终产出质量能提升 2 到 3 倍。”

他举了个例子：他们提交到 claude.ai/code 的每一个改动，Claude 都会用 Chrome 扩展自己测试——打开浏览器、测试 UI、发现问题就迭代，直到功能正常、体验合理。

验证方式因场景而异：可能是跑一个 bash 命令，可能是跑测试套件，可能是在浏览器或手机模拟器里测试应用。形式不重要，重要的是：让 AI 有反馈闭环。

这个道理其实很朴素。人类工程师也是靠"写代码—测试—看结果—修改"这个循环来保证质量的。AI 也一样。如果它只能写不能测，就像闭着眼睛做事，质量全靠运气。

我最近做了个小实验：让 Claude 写一个表单组件，第一次没让它验证，交付的代码有三个 bug；第二次让它写完后自己在浏览器里测试，结果一次性就对了。这就是反馈闭环的威力。

Boris 的建议是：投入精力把验证机制做扎实。这是回报率最高的投资。

三种常见验证方式

方式 1：跑测试命令

最简单直接的验证——让 Claude 写完代码后自己跑测试：

# 在提示词里明确要求 "实现登录功能，完成后运行 npm test 验证，如果有失败的测试就修复，直到全部通过。"

方式 2：浏览器测试

对于前端功能，让 Claude 自己打开浏览器验证：

"实现响应式导航栏，完成后：
1. 启动开发服务器
2. 用 Chrome 打开页面
3. 测试桌面端、平板、手机三种尺寸
4. 如果有布局问题就修复"

配合 MCP 的浏览器自动化工具效果更好。

方式 3：自动化脚本

用 Shell 脚本定义验收标准：

#!/bin/bash # .claude/verify.sh  echo "运行代码检查..." npm run lint || exit 1  echo "运行单元测试..." npm test || exit 1  echo "检查测试覆盖率..." npm run coverage -- --threshold 80 || exit 1  echo "✓ 所有验证通过！"

提示词："完成后运行 .claude/verify.sh 验证代码质量"

在提示词中明确验证要求

实现 [功能名称]。完成后必须验证：  1. 运行 npm test，所有测试通过 2. 运行 npm run lint，无代码规范问题 3. 手动测试核心流程：[列出关键场景] 4. 如果任何验证失败，分析原因并修复 5. 重复验证直到全部通过  输出最终验证结果。

使用 Stop Hook 自动化验证

Stop Hook 可以在 Claude 完成任务后自动触发验证：

# .claude/hooks/stop.py import subprocess import sys  def main():     # 运行测试     result = subprocess.run(["npm", "test"], capture_output=True)          if result.returncode != 0:         print("❌ 测试失败，继续修复...")         sys.exit(1)  # 阻止退出，让 Claude 继续工作          print("✅ 验证通过！")     sys.exit(0)  # 允许退出  if __name__ == "__main__":     main()