30天，259个PR，497次提交，+40K/-38K行代码。
这是Boris Cherny上个月的数据。
Boris是谁？Claude Code的创建者，Anthropic的工程师。当一个产品的创建者分享他自己的使用方法时，这些技巧的含金量不言而喻。
更有意思的是，Boris说：”我的设置可能出乎意料地普通（surprisingly vanilla）。Claude Code开箱即用就很强，我个人不怎么定制它。”
普通？
让我们看看这个”普通”的设置如何让他达到如此惊人的生产力。我结合了Boris的技巧和另一位重度用户Sankalp的经验（他在12月写了近万字的使用心得），整理出这份Claude Code进阶指南。
如果你已经在用Claude Code，但感觉还没发挥它的全部潜力，这篇文章会改变你的看法。
在讲具体技巧前，我们需要先转变思维。
大多数人这样用Claude Code：
打开Claude → 问问题 → 等回答 → 继续问 → 等回答...
就像用搜索引擎，一问一答。
Boris这样用：
同时开10-15个Claude会话
├── 终端：5个（编号1-5，系统通知）
├── 网页：5-10个（claude.ai/code）
└── 手机：早上启动几个，稍后查看
他说：
“不要把AI当工具用，要当成可调度的能力（capacity you schedule）”
什么意思？
想象你是项目经理，手下有10-15个实习生。你不会让他们闲着等你问问题，而是：
实习生A：重构auth模块
实习生B：写API文档
实习生C：修复那3个bug
实习生D：补充测试用例
实习生E：代码review
...
每个人都在并行工作，你只需要偶尔查看进度。
Boris就是这样用Claude的。
他会用&把本地会话切换到网页继续跑，用--teleport在本地和网页间传送，甚至在手机上启动后台任务，等有空再查看结果。
这不是”用AI”，这是“管理AI团队”。
很多人为了省钱或求快，选择Sonnet。
Boris的选择：只用Opus 4.5 + thinking模式。
为什么？
“虽然Opus更大更慢，但因为需要更少指导、tool use更好，最终反而更快。”
直觉上的误区：
Sonnet：快 → 应该总时间短？
Opus：慢 → 应该总时间长？
实际情况：
Sonnet：
├── 生成代码快（1分钟）
├── 但需要纠正（5分钟）
├── 再纠正（3分钟）
├── 又出bug（5分钟）
└── 总时间：14分钟
Opus 4.5：
├── thinking慢（2分钟）
├── 生成代码（2分钟）
├── 一次做对（0分钟纠正）
└── 总时间：4分钟
Sankalp的观点也一致：
“速度不是token/秒，速度是完成任务的迭代次数。快速迭代8次 > 慢速迭代3次。”
类比一下：武侠小说里，速度型选手往往能打败力量型选手，因为攻击次数多。
Boris的标准工作流：
1. 启动Claude → Shift+Tab两次 → 进入Plan模式
2. 和Claude讨论实现方案
3. 来回修改计划，直到满意
4. 切换到auto-accept edits模式
5. Claude一次完成（90%+成功率）
关键点：
“A good plan is really important!”
为什么计划这么重要？
想象盖房子：
没计划：
拿起砖就砌 → 发现门的位置不对 → 拆掉重来
→ 窗户太小 → 再拆 → 浪费时间
有计划：
先画图纸 → 确认布局 → 一次施工完成
Plan模式做什么： – 澄清需求（你想要什么） – 确定技术方案（用什么实现） – 识别风险点（可能出什么问题） – 规划文件变更（改哪些文件）
计划阶段多花5分钟，执行阶段节省30分钟。
Boris每天要用几十次的命令：/commit-push-pr
传统做法：
你：帮我提交这些改动
Claude：好的，commit message写什么？
你：就写"修复auth bug"
Claude：好的，要push吗？
你：要
Claude：要创建PR吗？
你：要
（来回对话5-6轮）
有了slash command：
你：/commit-push-pr
Claude：已完成commit、push和PR创建
Boris的技巧： 在command里用inline bash预计算信息（git status, git diff等），这样Claude不需要来回询问，直接执行。
放哪里：
项目级：.claude/commands/commit-push-pr.md
全局级：~/.claude/commands/commit-push-pr.md
git追踪，团队共享！
类比： 就像IDE的code snippet，输入缩写自动补全整段代码。
Boris团队的做法：
.claude/CLAUDE.md
├── git追踪（check into git）
├── 整个团队贡献（每周多次更新）
└── Claude犯错 → 立即加规则
在PR中使用：
代码review时，Boris会在同事的PR上打tag：
@.claude 把这个规则加到CLAUDE.md里
使用Claude Code的GitHub Action自动处理。
这是什么理念？
Dan Shipper提出的Compounding Engineering（复利工程）：
传统开发：
每个人踩同样的坑 → 各自解决 → 知识流失
复利工程：
踩坑 → 记录到CLAUDE.md → 全团队受益
→ 知识积累 → 团队越来越强
CLAUDE.md就是团队的”制度记忆”。
Boris创建的Sub-agents：
code-simplifier → 简化Claude生成的代码
verify-app → 端到端测试Claude Code
...其他自动化工作流
使用场景：
每个PR都要做的事：
1. 写代码
2. 简化代码
3. 跑测试
4. 验证UI
传统：每次都要提醒Claude做这些
Sub-agents：自动触发
与slash commands的区别： – Slash commands：简单的命令执行 – Sub-agents：复杂的多步骤工作流
位置：.claude/agents/your-agent.md
类比： Slash commands = 按钮 Sub-agents = 完整的自动化脚本
问题： Claude生成的代码90%格式正确，但10%可能导致CI失败（格式检查不通过）。
Boris的解决方案：
PostToolUse hook
├── Claude完成编辑
├── 自动运行prettier/black
└── 格式统一，CI通过
为什么不让Claude直接格式化？ – Claude已经做得很好了 – Hook处理最后10%的边角情况 – 更快、更可靠
位置：.claude/hooks/PostToolUse.sh
很多人为了避免权限提示，直接用：
claude --dangerously-skip-permissions
危险！ 这等于给Claude root权限。
Boris的做法：
/permissions # 预先允许安全命令
配置：
// .claude/settings.json
{
"allowedPrompts": [
{"tool": "Bash", "prompt": "run tests"},
{"tool": "Bash", "prompt": "git operations"},
{"tool": "Bash", "prompt": "npm commands"}
]
}
git追踪，团队共享，只允许已知安全的操作。
类比：
– --dangerously-skip = 给陌生人你家钥匙
– /permissions = 给陌生人门禁卡（只能进特定房间）
Boris团队集成的工具：
Slack MCP → 搜索和发送消息
BigQuery CLI → 运行分析查询
Sentry → 抓取错误日志
GitHub → 创建issue、PR
配置：
// .mcp.json
{
"mcpServers": {
"slack": {...},
"bigquery": {...}
}
}
git追踪，团队共享。
效果：
你：Slack上有人报了什么bug？
Claude：（自动搜索Slack）找到3个bug报告...
你：这个错误在Sentry有多少次？
Claude：（自动查Sentry）过去7天出现127次...
Claude成了你的智能助手，自动使用所有工具。
场景： 任务要跑很久（比如重构整个模块），你不想一直盯着屏幕。
方案A – 提示验证：
你：重构auth模块，完成后用background agent验证
Claude：好的（自动在完成后验证）
方案B – Hook验证：
Stop hook → 任务完成时自动触发验证
方案C – Ralph Wiggum插件：
自动监控Claude，出问题就提醒你
沙盒模式：
# 让Claude不受打扰地工作
claude --permission-mode=dontAsk
类比： – 方案A：告诉员工”做完发我消息” – 方案B：定时检查进度 – 方案C：项目经理随时监督
Boris的金句：
“Probably the most important thing — give Claude a way to verify its work. It will 2-3x the quality.”
Boris的实战案例：
每次改动claude.ai/code：
1. Claude写代码
2. 用Chrome扩展测试UI
3. 发现问题 → 迭代修复
4. 再测试 → 直到完美
为什么有效？
没有反馈循环：
Claude写代码 → 你手动测试 → 发现bug
→ 再让Claude改 → 可能改出新bug
→ 质量不稳定
有反馈循环：
Claude写代码 → 自动测试 → Claude看到结果
→ 自己发现问题 → 自己修复
→ 质量稳定提升
不同领域的验证方式： – 后端：运行测试套件 – 前端：浏览器自动化测试 – CLI工具：运行bash命令 – 移动应用：模拟器测试
重点：
“投资让验证rock-solid（坚如磐石）”
新功能（最近上线）：
claude --continue --fork-session
使用场景：
主会话：正在重构auth模块
├── 方案不确定
├── fork一个session
├── 实验不同方案
└── 选最好的merge回主会话
好处： – 不丢失主线程 – 可以同时探索多个想法 – Compaction前保存好状态
类比： Git的分支功能，但是for对话。
Boris的做法：
写完代码 → Claude用Chrome扩展测试
→ 看UI效果 → 迭代改进
为什么这样做？
传统流程：
Claude写代码 → 你测试 → 发现问题
→ 描述给Claude → Claude修复
（你是瓶颈）
自动化流程：
Claude写代码 → Claude测试 → Claude看结果
→ Claude修复 → 直到完美
（无需你介入）
工具： – Chrome扩展（前端） – Playwright（E2E测试） – 手机模拟器（移动端）
Boris团队的做法：
.claude/
├── CLAUDE.md # git追踪 ✓
├── commands/ # git追踪 ✓
├── agents/ # git追踪 ✓
├── settings.json # git追踪 ✓
└── .mcp.json # git追踪 ✓
为什么这么做？
新人onboarding：
传统：学习1-2周才上手
Git追踪：clone代码就能用，配置一致
团队协作：
传统：各人配置不同，容易出问题
Git追踪：所有人用同样的配置
知识积累：
传统：知识在个人脑子里
Git追踪：知识固化在代码仓库
Compounding Engineering再次发挥作用。
Sankalp是另一位Claude Code重度用户，他在12月写了一篇近万字的使用心得。
有个概念Boris没提到，但非常重要：Context Engineering（上下文工程）。
定义：
“What configuration of context is most likely to generate our model’s desired behavior?”
（什么样的上下文配置最可能产生我们想要的模型行为？）
通俗解释：
Claude的context window就像电脑内存： – Opus 4.5有200K context（约15万字） – CLAUDE.md占用”常驻内存” – 写得越多，留给实际任务的空间越少
大多数人的问题：
CLAUDE.md (20K tokens):
├── 通用规则: 5K
├── SQL知识: 3K ← 今天不用数据库，也占着
├── 前端规范: 4K ← 今天不写前端，也占着
├── API设计: 3K ← 今天不写API，也占着
└── 其他: 5K
Context使用率：90% → Claude变慢变傻
解决方案：Skills
Sankalp用《黑客帝国》比喻Skills：
Neo：我要学功夫
Matrix：下载中... 完成！
Neo："I know Kung Fu!" （我会功夫了！）
Skills就是这样工作的：
1. CLAUDE.md只写：有sql-database skill可用（50 tokens）
2. Claude需要时，才读取SKILL.md（3K tokens）
3. 临时获得SQL专业知识
4. 用完不占常驻内存
对比：
传统方式：
CLAUDE.md塞满所有知识（20K tokens）
Context使用率：90%
Skills方式：
CLAUDE.md只有meta-data（5K tokens）
按需加载，Context使用率：40%
节省50%+ context，Claude更聪明！
MCP的问题：
每个MCP服务器暴露10-20个工具：
├── dbhub: 2个工具
├── playwright: 8个工具
├── filesystem: 15个工具
└── 总计：25个工具定义 → 占用大量context
Skills的优势：
Skills只暴露meta-data：
├── sql-database: "SQL查询和优化" (50 tokens)
├── frontend-design: "前端UI设计" (50 tokens)
└── 总计：100 tokens
实际内容？需要时才读取！
对比： – MCP = 提前把所有工具放进口袋（重，context bloat） – Skills = 需要什么拿什么（轻，按需加载）
Sankalp的观点：
“MCP不是我的首选，因为token消耗高。Skills的按需加载更智能。”
场景： 你有个SQL skills，但Claude有时忘记使用。
解决方案：
# UserPromptSubmit hook
if [[ $prompt == *"database"* ]] || [[ $prompt == *"SQL"* ]]; then
echo "🔔 提醒：你有sql-database skill可用"
fi
当你提到”database”或”SQL”时，hook自动提醒Claude使用skill。
Sankalp的创意用法：
你：启动background agent监控error.log
Claude：好的，后台运行中...
（你继续开发）
Claude（突然提醒）：刚才发现error.log有新错误！
其他用途： – 监控测试结果 – 监控构建状态 – 监控服务器日志
就像有个24小时值班的助手。
Sankalp的发现：
Explore agent：不继承context（独立搜索）
General-purpose：继承full context
Plan agent：继承full context
为什么Explore不继承？ – 搜索任务通常独立 – 不需要对话历史 – 节省token
进阶技巧：
“Explore返回摘要可能有损，让Opus自己读所有文件更准确。”
原因： – 让所有context互相”attention” – Self-attention机制的优势 – 更好的理解力
看完这13个技巧，你可能会想：这么多东西，从哪开始？
先掌握这3个：
成功率提升50%+
创建1-2个slash commands
做成command
使用Opus 4.5
再学这4个：
踩坑就记录
创建Sub-agents
解放双手
学会用Skills
按需加载 > 一次性加载
反馈循环
最后掌握这3个：
AI是可调度的能力
Hooks + Skills组合
智能触发
Background agents监控
Sankalp有句金句：
“Experience builds judgement and taste – that’s what differentiates professional devs from vibe-coders.”
（经验建立判断力和品味，这是专业开发者和vibe-coder的区别）
什么是Vibe-coder？
Vibe-coder：
├── 让AI写代码
├── 不理解为什么这样写
├── 出问题就重新生成
└── 碰运气
Professional Dev：
├── 用AI加速实现
├── 理解技术方案
├── 建立判断力
└── 把控质量
Claude Code的正确姿势： – AI负责实现（速度） – 你负责方向（判断） – AI + 你 = 10倍生产力
不是： – ❌ AI替代你思考 – ❌ AI做所有决定 – ❌ 你变成代码搬运工
而是： – ✅ AI放大你的能力 – ✅ 你专注高价值工作 – ✅ 更快更好地交付
如果只能做一件事，做什么？
行动1：进入Plan模式
下次用Claude Code时：
1. Shift+Tab两次
2. 和Claude讨论计划
3. 计划满意后再执行
这一个改变，成功率提升50%。
行动2：创建第一个slash command
找一个你每天重复的操作：
提交代码？
运行测试？
创建PR？
花10分钟做成command，节省以后每天的时间。
行动3：试试Opus 4.5
如果你在用Sonnet：
试用Opus 4.5一天
对比速度和质量
看是否值得
记住：时间 > 金钱。
Boris Cherny用30天完成259个PR的秘密，不是什么高深技术，而是：
从会用到精通Claude Code，不是学会100个快捷键，而是理解这些核心理念。
现在，轮到你了。
打开Claude Code，进入Plan模式，开始你的第一个高效实践。
30天后，也许你也能交出让自己惊讶的成绩单。
参考资料： – Boris Cherny Twitter Thread – Sankalp的Claude Code 2.0使用心得 – Claude Code官方文档
本文写作过程中使用了Claude Code，从素材收集到正文撰写，全程AI辅助完成。这本身就是”用AI写AI”的最佳实践。