核心理念：没有标准答案
Boris 开场就说：他的配置可能出乎意料地"原装"。Claude Code 开箱即用效果就很好，他个人没做太多定制。那些最佳实践——Skills、Plugins——作为开发者，他们早就把这些内置为产品功能了。
Claude Code 团队内部每个人的用法都完全不同，这是刻意为之的设计。所以不必费力去寻找"唯一正确"的用法，适合自己的节奏最重要。
多 Agent 并行：同时开十几个 Claude
Boris 的日常工作节奏是：终端里开 5 个 Claude Code 实例，标签页编号 1 到 5，开着系统通知，哪个需要输入就跳过去处理。同时在 claude.ai/code 网页版上跑 5 到 10 个任务。终端和网页可以互相"交接"——用 & 把本地会话转到网页，用 --teleport 在两边来回切换。每天早上还会从手机端启动几个任务，晚点再回来看结果。
这种"多线程"工作方式的核心逻辑是：Claude Code 擅长自主执行，很多任务不需要你盯着。启动任务、给个方向，让它跑着，自己去忙别的。这跟传统的"人敲一行代码、AI 补几行"完全是两种节奏，对使用者的任务拆解和上下文切换能力要求更高。
模型选择：为什么坚持用 Opus
Boris 所有任务都用 Opus 加 thinking 模式，这是他用过最好的编程模型。
很多人会问：Opus 不是比 Sonnet 更慢吗？他的回答是：虽然单次响应慢一点，但需要纠正的次数少得多，工具调用也更准确，最终综合效率反而更高。写代码不能只求响应速度——如果一个快模型需要你来回纠正三次，不如用慢模型一次搞定。时间成本不只是模型响应时间，还有你的注意力和精力。唯一的代价是 Opus 的 API 成本更高。
CLAUDE.md：把纠错变成团队资产
CLAUDE.md 是 Claude Code 的特殊配置文件，放在项目根目录，每次启动时自动读取，相当于给 AI 写的项目说明书——架构、规范、注意事项。
Boris 团队的做法是：整个仓库共用一个 CLAUDE.md，提交到 Git，所有人一起维护，每周都有人更新。规则很简单：每次看到 Claude 做错了什么，就把"别这样做"写进去。 在代码审查时，他还会在同事的 PR 里通过 Claude Code 的 GitHub Action 让 Claude 自动把新规则加到 CLAUDE.md。
这种做法被称为"复利工程"：每一次纠错都变成团队资产，让 AI 越来越懂你的项目。
如果还没用过 CLAUDE.md，最简单的起步方式是运行 /init 命令，Claude 会自动分析项目结构生成初始版本，之后边用边补充。
Plan 模式：先想清楚再动手
Boris 大多数会话都从 Plan 模式开始。在 Claude Code 中按两下 Shift+Tab 即可切换。
Plan 模式下，Claude 不会直接改代码，而是先输出执行计划。你可以来回讨论、修改计划，满意后切到自动接受模式，Claude 通常能一次性完成。
这是把软件开发的经典智慧搬到 AI 协作里：先设计再编码。很多人用 AI 写代码的问题是直接开干，方向错了返工成本极高。花几分钟对齐计划，能省几小时的返工。
自动化重复工作：斜杠命令与子 Agent
Boris 把每天要用几十次的操作做成了斜杠命令，比如 /commit-push-pr 一键完成提交、推送、创建 PR。
斜杠命令本质上是 Markdown 文件，放在 .claude/commands/ 目录下，支持自然语言指令，还能嵌入 bash 脚本预先获取信息，减少模型来回调用次数。这些命令可以提交到 Git，团队共享。
除了斜杠命令，他还用子 Agent——独立的 Claude 实例，专门处理某类任务。比如：
- code-simplifier：主 Claude 完成工作后自动简化代码
- verify-app：专门负责端到端测试
他还使用 PostToolUse Hook 来格式化代码，处理 Claude 自动生成代码中最后 10% 的格式问题，避免 CI 阶段的格式报错。
安全与集成：权限配置和 MCP
Boris 不用 --dangerously-skip-permissions。他用 /permissions 命令预先批准常用的安全命令，避免每次弹确认框，配置保存在 .claude/settings.json 里，团队共享。
更强大的是 MCP（Model Context Protocol）服务器集成。通过 MCP，Claude Code 可以直接：
- 搜索和发送 Slack 消息
- 跑 BigQuery 查询回答数据问题
- 从 Sentry 拉错误日志
团队把 Slack 的 MCP 配置也提交到仓库，所有人开箱即用。Claude Code 不只是编程工具，而是能调用整个工具链的全能助手。
长任务处理：让 Claude 自己验证
对于长时间运行的任务，Boris 有三个策略：
- 后台 Agent 验证：让 Claude 完成后自动用后台 Agent 验证结果，可以在提示词里要求，也可以用 Stop Hook 确定性地触发
- ralph-wiggum 插件：本质是一个 Bash 循环——
while true不停地把任务说明书喂给 AI，让它一遍遍改进，直到彻底完成 - 沙箱环境免打扰：在沙箱里用
--permission-mode=dontAsk或--dangerously-skip-permissions，让 Claude 不被权限确认打断
核心思路：既然是长任务，就别让它等你，给它足够的自主权和自我纠错能力。
最重要的一条：给 Claude 验证能力
Boris 把这条放在最后，也认为这是获得好结果最重要的因素：如果 Claude 能验证自己的工作，最终产出质量能提升 2 到 3 倍。
他们提交到 claude.ai/code 的每一个改动，Claude 都会用 Chrome 扩展自己测试——打开浏览器、测试 UI、发现问题就迭代，直到功能正常。验证方式因场景而异：跑 bash 命令、跑测试套件、在浏览器或手机模拟器里测试应用。形式不重要，重要的是让 AI 有反馈闭环。
这个道理很朴素：人类工程师靠"写代码—测试—看结果—修改"的循环保证质量，AI 也一样。如果它只能写不能测，质量全靠运气。
Boris 没有炫耀复杂的定制配置，用的就是官方功能。区别在于他真正理解这些功能背后的逻辑，然后组合成高效工作流：并行是因为 Claude 能自主执行；用 Opus 是因为综合效率更高；CLAUDE.md 是把纠错变成资产；Plan 模式是先想后做；斜杠命令和子 Agent 是自动化重复劳动；验证机制是给 AI 反馈闭环。
如果你刚开始用 Claude Code，先把基础用好：学会并行、学会规划、学会积累 CLAUDE.md、学会给 AI 验证手段。等真正遇到瓶颈了，再去折腾高级配置不迟。