ClaudeCode团队内部有一个工程师叫Boris，他分享了团队怎么用ClaudeCode的清单，一共十条。

看完之后你会发现：原来还能这么用。更重要的不是技巧本身，而是这些技巧背后整个团队工作方式的变化。

---

技巧1：同时跑3-5个窗口——把AI当"施工队"

具体做法

不要只开一个Claude对话，要同时开3-5个。

团队的做法：

• 用Git每个窗口一个独立的工作目录
• 运行各自的Claude绘画
• 用Bash别名一键切换

有人甚至专门有一个只读的分析窗口，专门看日志、数据库查询，无需做任何代码改动。

背后的认知转变

以前	现在
串行思维：想好→写→改→测	并行思维：A组实现功能，B组写测试，C组做代码审查
你是一个人在写代码	你在管理一支"施工队"

警告

上下文切换的成本是真实存在的。

开了五个窗口，每次切回来都要重新理解这个对话走到哪里了。

如果你的项目不够复杂，或者你还没有建立清晰的任务分工，多开窗口只会让你更乱，不会更快。

这个技巧是给有架构意识的工程师用的，不是给所有人的。

---

技巧2：Plan不只是用来开始，更是用来"重启"

团队的独特用法

有一个人让Claude写好计划之后，再单独开一个Claude对话，让第二个Claude扮演资深工程师来review这个计划。

把规划过程变成对抗性的，而不是合作性的。

更关键的用法

当任务进行到一半出问题了，别继续硬推，要切回Plan Mode，重新规划。

常见错误

很多人用ClaudeCode遇到问题的时候，下意识的反应就是再追加一条指令去试一试。

结果：越补越乱，上下文变成一团烂泥。Claude开始瞎说，你还以为是模型问题，但其实是流程问题。

Plan的本质

Plan是一个"认知锚点"。

它强迫你在行动之前先搞清楚方向。遇到障碍就重新定位——这是软件工程里"停下来思考比盲目行动更快"的经典原则。

Claude总是在生产输出，你会以为是在进展，但可能只是在原地打转。

---

技巧3：让Claude自己写规则——最有洞察的一条

具体做法

每次Claude犯了一个错误，你纠正完以后，在Prompt结尾加一句：

“把这条经验更新到你的CLAUDE.md里面，以后不要再犯。”

CLAUDE.md是ClaudeCode的项目配置文件，相当于给AI的行为手册。你可以在里面写规则、写禁忌、写代码风格的要求。

团队的激进做法

他们让AI自己写这个手册——犯一次错，记一条。

一个工程师甚至专门维护了一个notes目录，每做一个项目就去更新一次。CLAUDE.md指向的是这个目录。

这意味着什么

你在做的事情不只是用Claude完成任务，而是在训练一个越来越了解你项目的协作者。

今天花五分钟维护这个文件，未来每个对话都会变得更加省事。

陷阱

CLAUDE.md不能无限长。

文档太长，规则就被稀释了。Claude读到后面却会忘到前面——这是真实的上下文窗口限制导致的行为特征。

原则：定期精简。当你发现Claude开始犯同一个错误，先去检查规则是否清晰，而不是一直往里加新条目。

---

技巧4：SlashCommand是可复用的思维结晶

具体做法

团队用SlashCommand来封装高频操作。

示例1：/timestep
每次对话结束前找出并清理重复代码。

示例2：context-stamp命令
自动拉取最近七天的消息、Drive文档、Tasks和Git提交，汇总成一份上下文，让Claude在新的对话里快速了解最近发生了什么。

背后的工程哲学

如果一件事你做了不止一遍，就把它变成一个可重复的流程。

这不是新观点，这是软件工程里"自动化一切重复"的基本原则。

只是现在这个原则的适用范围大幅拓展了：以前主要用在代码上，现在同样适用于你和Claude的交互方式本身。

门槛

你需要先对自己的工作流程有清晰的认知，知道什么是真正重复的操作，然后才有东西可以封装。

如果你刚开始用ClaudeCode，先把工具用熟，别急着封装命令。

---

技巧5：用CLI工具，不要过度依赖MCP

团队的做法

团队用MCP去集成，让Claude直接读写。

但有人持不同意见：能用CLI解决的就用CLI，不要上MCP。

方案	优点	适用场景
CLI	更简单、更容易调试、行为一致	读多写少的工作流
MCP	双向通信	需要实时交互的场景

核心观点

越复杂的集成，失败的方式就越多。

刚开始用AI工具的时候，你的主要精力应该用在让AI产出更有价值的东西上面，而不是让各种集成不出bug。

先把简单路走通，再去考虑复杂的集成。

---

技巧6：把Claude当成学习工具，不只是执行工具

被严重低估的用法

• 让Claude生成代码的可视化图表和交互式HTML探索器，帮助你理解一个陌生代码库
• 让Claude画出某个领域里的知识结构、知识盲区和范围边界

核心认知

大多数人把ClaudeCode当成一个写代码的工具。

但它同样可以是一个帮你思考的工具。

你可以让它：

• 解释一个你不熟悉的架构决策
• 画出某个系统里数据流动的路径
• 梳理一个模块的前置依赖

这些事情不产出代码，但能帮你建立理解。理解是写出好代码的前提。

---

技巧7：图片和截图是被忽视的上下文

具体做法

在Prompt里直接附上截图、架构图或文档的图片。

为什么有效？

方式	效果
文字描述一个UI bug	需要200字
一张截图	0个字，Claude直接读图

适用场景

• Bug报告：直接截图，不用描述"左边有个按钮，点击后……"
• 架构讨论：画一张草图，拍张照片传进去
• 需求澄清：直接贴设计稿或原型图

---

技巧8：让Claude自己学习CLI工具

遇到Claude不认识的CLI工具，怎么办？

错误做法：自己查文档，然后告诉Claude。

正确做法：直接让Claude自己学。

提示词模板

“使用 -cli -help 来了解这个工具，然后用它完成ABC三个任务。”

Claude会自己去读help输出，自己理解语法，自己执行命令。

甚至对你公司内部的私有工具也适用——只要工具有help文档，Claude就会学会用它。

这意味着什么

Claude是一个会学习的执行者，而不是一个只能用预制知识的助手。

你不需要事先教会它一切，只需要给它学习的路径。

---

技巧9：并行不等于更快，任务分配才是核心

团队的警告

不要让多个Agent同时修改同一个文件。

原因：最后写入者获胜——其中一个Agent的工作会被覆盖掉，什么提示也没有。

建议

阶段	推荐并行任务
刚开始	PR Review、Bug调查、文档整理（不会互相覆盖）
有经验后	并行实现代码（建立清晰的任务隔离习惯）

核心含义

多Agent的协同需要的是任务设计，不是把任务拆开扔给几个窗口就完事了。

你需要像管理团队一样去思考：

• 谁负责什么？
• 哪些任务有依赖？
• 哪些可以真正独立运行？

---

技巧10：一定要经常更新

为什么重要？

小版本更新经常会包含非常有用的改动。

版本更新	改动内容
某版本	加了对大PDF文件的分页支持，解决上下文窗口溢出问题
另一版本	改了大型工具输出的存储方式，大幅减少上下文占用

这些改动不会出现在头条新闻里，但实实在在地影响你的日常体验。

---

十条技巧背后的线索

这些技巧看起来很散，但背后有一条一致的线索：

ClaudeCode团队把这个工具当成一个可以被塑造的协作者，而不是一个固定的工具。

技巧	本质
技巧1	并行管理，不是串行操作
技巧2	Plan是认知锚点，不是一次性规划
技巧3	CLAUDE.md可以被训练
技巧4	SlashCommand可以被定制
技巧5	简单优于复杂
技巧6	Claude是思考伙伴，不只是执行工具
技巧7	图片是高效的上下文载体
技巧8	Claude可以自主学习
技巧9	任务设计决定并行效率
技巧10	持续更新，持续优化

每一条技巧都在往同一个方向走：让你和Claude之间的协作关系随着时间越来越顺、越来越高效、越来越符合你的项目特点。

这个才是真正值得学的东西——不是任何一个具体的快捷键，而是这种持续优化人机协作界面的思维方式。