前两天，Boris再次公开了Claude Code团队的10个内部技巧。这次的分享比年初那次更硬核，干货浓度高到离谱。我花了整整一个下午消化这些内容，又在实战中验证了几天，决定把最有价值的部分提炼出来，分享给正在使用或准备入坑Claude Code的朋友们。
我第一次看到Claude Code 的创建者 Boris Cherny 在X上分享那些技巧时，正在为一个繁琐的重构任务焦头烂额。
说实话，当时我对Claude Code的认知还停留在帮我写段代码的层面。看完他的分享后，我才发现——原来我连这个工具的入门级玩法都没摸透。
前两天，Boris再次公开了Claude Code团队的10个内部技巧。这次的分享比年初那次更硬核，干货浓度高到离谱。
我花了整整一个下午消化这些内容，又在实战中验证了几天，决定把最有价值的部分提炼出来，分享给正在使用或准备入坑Claude Code的朋友们。
让效率翻倍的并行工作流
Boris在文中提到了一个让我醍醐灌顶的概念：同时开启3到5个git worktree，让每个worktree都跑着独立的Claude会话。
说实话，我最初的理解是多开几个窗口而已。但真正实践后才意识到，这完全是两种工作模式。
传统的单会话开发像是solo演唱，而多worktree并行更像是组建了一支乐队——每个乐手各司其职，整体产出成倍增长。
团队里有人给worktree起了简洁的别名，比如za、zb、zc。听起来有点极客，但切换效率确实惊人。
我现在也养成了给不同任务分配独立worktree的习惯：一个专攻新功能开发，一个用来review和调试，另一个专门处理技术债务。这种物理隔离让每个Claude会话的上下文都异常清晰，再也不用担心任务之间互相干扰。
还有一个细节让我印象深刻：有些人专门留了一个分析用worktree，只用来查看日志和跑查询。
这让我意识到，Claude Code不仅能写代码，在数据分析场景下的表现同样出色。
团队甚至把BigQuery的查询功能封装成了Skill，有位成员坦言自己已经六个月没亲手写过一行SQL了。
与Claude对话的正确方式
如果说并行工作流是器的层面的优化，那么与Claude的交互方式则直接决定了道的高度。
团队成员反复强调一个原则：任何复杂任务，都应该从Plan Mode开始。
这让我想起自己之前的踩坑经历——总是急于让Claude直接写代码，结果往往是写到一半发现方向错了，推倒重来浪费了大量时间。
现在我养成了一个习惯：动手实现之前，先让Claude给出完整的技术方案，用人类工程师的视角review一遍，确认无误后再开始编码。
CLAUDE.md这个文件我之前也存在误区，总觉得放几个技术栈说明就够了。
团队里有个工程师的做法让我深受启发：他每次纠正Claude的错误后，都会加上一句"把这条更新到CLAUDE.md里"。
听起来简单，但长期坚持下来，这份文档会变成一份不断进化的最佳实践指南。
CLAUDE.md的本质是训练数据的本地化定制，你给它喂什么样的规则，它就会变成什么样的助手。
关于Prompt技巧，团队分享了一个让我受益匪浅的思路：挑战Claude。
他们会让Claude针对代码改动提出质疑，在通过测试之前不要提交PR。这相当于给代码审查加了一道AI防线，而且这个审查员永远不会疲劳走神。
结语
写到这里，我想起Boris在原文里说的一句话：使用Claude Code没有所谓的唯一正解。
那些技巧不是圣经，而是指南。团队成员之间用法也各不相同，有人偏爱worktree，有人喜欢多个checkout目录。关键是理解背后的逻辑，然后找到最适合自己的工作流。
技术工具的价值，从来不在于它本身有多强大，而在于使用它的人能把它用得多顺手。这些技巧如是，Claude Code本身也如是，对吧？
