Claude Code 最佳实践（拼车版实战手册）

Anthropic 官方那篇 Best practices for agentic coding 写得很实在，但它默认你已经掏了官方账号、解决了 base URL 问题、不在国内用。这篇是把那套模式翻译到「OpenClaw 拼车 + 国内网络环境」下能直接抄的版本——重点放在「怎么让 Claude Code 一次跑对、token 不浪费」，而不是把官方文档再讲一遍。

如果你还没接好通道，先一行命令搞定：

curl -fsSL https://cp.bizq.net/setup.sh | bash -s -- claude-max-20x

下面进入正题。

1. CLAUDE.md：写护栏，不是写手册

CLAUDE.md 是 Claude Code 启动时自动塞进上下文的特殊文件。它在你每次会话里都吃 token，所以写法直接决定你拼车包月里有多少额度浪费在喂上下文。

该往里塞什么

• 仓库的非显然约定（分支命名、rebase 还是 merge、提交信息格式）
• 必跑的本地命令（pnpm typecheck、make test、自定义 CLI 包装器）
• 项目里特有的坑（某个 ORM 在某种情况下会静默吞错）
• 代码风格里你被 Claude 反复冒犯过的那些点

不要塞的

• 整个 README 的内容（Claude 会按需读文件，没必要塞进系统提示）
• @-提及 一堆外部 markdown（每次会话都会把这些文件全文展开）
• 「绝不使用 X」式的纯否定约束——智能体会卡在「我必须用 X 但被禁止」的死循环。永远配套提供「优先使用 Y」

最小可用模板

# Bash commands
- pnpm build: 编译 ts 项目
- pnpm typecheck: 类型检查
- pnpm test --filter <pkg>: 跑单包测试
 
# Code style
- 用 ES module（import/export），禁止 require
- 解构导入：import { foo } from 'bar'
- 涉及金额一律用 bigint，禁止浮点
 
# Workflow
- 改完一组代码必须跑 typecheck
- 优先跑单测试用例，不要全量测试套件
- 复杂改动必须先用 plan mode 出方案再动手

CLAUDE.md 放在哪里

monorepo 用户特别注意：在 apps/web 启动 Claude Code 时，apps/web/CLAUDE.md、CLAUDE.md（根）会叠加进上下文，所以根文件保持精简、子包写专属的。

按 # 键给 Claude 下指令时它会自动写进 CLAUDE.md 的相关位置——这是日常迭代它的最快方式。

2. 权限配置：把审批从工作流里拿掉

默认情况下 Claude Code 对所有写操作都会弹出权限请求。真实工作流里这是最大的体验杀手——一个改动可能触发 20 次 yes/no。

四种管理方式按推荐度排序：

# 1. 持久化白名单（提交到 git，团队共享）
.claude/settings.json
{
  "permissions": {
    "allow": [
      "Edit",
      "Bash(git commit:*)",
      "Bash(git push:*)",
      "Bash(pnpm:*)",
      "WebFetch(domain:docs.openclaw.ai)"
    ]
  }
}
 
# 2. 个人白名单（跨项目）
~/.claude.json
 
# 3. 单次会话
claude --allowedTools Edit,View,"Bash(git commit:*)"
 
# 4. 交互式会话内
/permissions add Edit

危险但好用的 YOLO 模式

claude --dangerously-skip-permissions

跳过所有审批，适合修 lint、跑批量重构、生成样板代码。但前提是你跑在沙箱里——容器、虚拟机、或者至少是一个能整体回滚的 git worktree。我自己跑大批量任务时几乎全用 --dangerously-skip-permissions，但永远在隔离的 worktree 里（参考第 6 节）。

3. 探索 → 计划 → 编码 → 提交

这套四步循环适用 80% 的真实任务。每一步对应一种心智状态，混着干就会出问题。

步骤 1 — 探索（不要写代码）

让 Claude 读相关文件、文档、URL，明确禁止它动笔：

读一下 src/auth/* 和 docs/auth-flow.md，理解当前登录流程是怎么走的。先不要写代码。

复杂问题让它派 sub-agent 去查细节，主上下文保持干净。

步骤 2 — 计划（触发深度思考）

现在制定一个把 session 存储从 cookie 迁移到 Redis 的方案。think harder。

四档思考预算：think < think hard < think harder < ultrathink，越往后越烧 token。拼车用户的甜点是 think harder——足够想清楚复杂方案，又不至于一个问题烧掉 5 万 token。

让它把方案写进 plan.md 或 GitHub issue，回滚时有据可查。

步骤 3 — 编码（让它边写边自验）

按 plan.md 实现。每写完一个模块跑一次 typecheck，过了再继续。

步骤 4 — 提交 + PR

跑完所有测试。生成 commit 和 PR 描述。

第 1、2 步是关键——跳过它们 Claude 会直接写代码，然后你花 3 倍时间修方向错误。

4. TDD：把测试当成对智能体的合同

代理式编程里 TDD 比传统 TDD 更值。原因：测试用例是机器可验证的目标，Claude 能在不和你交互的情况下自己验证对错。

我在做 TDD。第一步：根据下面的输入输出对，写测试。先不要实现。
- 输入: { amount: 100, currency: 'USD' }
- 输出: { ok: true, fxApplied: 0.0143 }
- 输入: { amount: -1 }
- 输出: { ok: false, error: 'NEGATIVE_AMOUNT' }

明确告诉它「在做 TDD」很关键——不然它会直接写带 mock 的实现糊弄过去。

四步流：

1. 写测试 → 确认全失败 → 提交测试
2. 写实现 → 跑测试 → 改 → 跑测试，循环到全过
3. 派一个 sub-agent 检查实现是不是过拟合了测试
4. 提交实现

第 3 步特别重要。Claude 会非常擅长「让测试通过」，但代价可能是写了一堆 hack。让一个独立 Claude 实例去 review，它没有「让测试过」的执念，能挑出问题。

5. 视觉迭代：截图 + Puppeteer MCP

UI 任务给 Claude 视觉反馈能力，效果会指数级提升。

# 装 Puppeteer MCP
claude mcp add puppeteer --command "npx @modelcontextprotocol/server-puppeteer"

工作流：

1. 给视觉 mock（拖拽、cmd+ctrl+shift+4 截屏粘贴、文件路径）
2. 让 Claude 实现
3. 让它自己截图实现结果
4. 对比 mock，迭代

实现这个登录页（设计稿见 design/login.png）。实现完调用 puppeteer 截图当前结果，对比设计稿，修改差异，再截图，循环到接近为止。

第 1 版通常一般，第 3-4 版往往超出预期。

6. 多 Claude 并行：worktree 是最便宜的并发

单个 Claude 串行做事是新手用法。最快的工作流是 3-4 个 Claude 同时跑不同任务。

git worktree 模式

# 主分支留着写代码
cd ~/project
 
# 起新 worktree
git worktree add ../project-auth feature-auth
git worktree add ../project-billing feature-billing
git worktree add ../project-review-only review
 
# 每个目录起一个 Claude
(cd ../project-auth     && claude)  # 写认证
(cd ../project-billing  && claude)  # 写支付
(cd ../project-review-only && claude)  # 专门 review 上面两个的代码

每个 worktree 独立工作目录，共享 git 历史。Claude 之间互不干扰，你只需要在终端 tab 间切换，批准/拒绝权限请求。

为什么不用 sub-agent？

Claude Code 内置 sub-agent 的问题是强制人类工作流——你必须事先定义好 PythonTester、CodeReviewer 这些角色。worktree + 多实例的方式让主 Claude 自己决定怎么编排，更灵活。

唯一例外是 Task(...) 工具，它生成主 Claude 的克隆，继承全部上下文，没有「角色僵化」的问题。我个人只用 Task(...)，不创建固化的子智能体。

7. 上下文管理：不要相信 /compact

长会话 token 会被无关讨论塞满。处理方式按优先级：

/context 命令查看当前上下文占用。单仓库里我观察到的稳态是 base 20K tokens 左右，加任务后涨到 100-150K。超过 180K 就该 /clear，否则模型推理质量肉眼可见下降。

8. 无头模式：把 Claude 塞进流水线

# -p：one-shot，输出后退出
claude -p "把 src/foo.py 从 React class component 改成 hooks"
 
# JSON 输出，方便管道
claude -p "总结这次提交" --output-format stream-json | jq
 
# 批量
for f in $(find src -name '*.py'); do
  claude -p "给 $f 加 type hints" --allowedTools Edit
done

OpenClaw 拼车通道在 -p 模式下完全可用——它走的是同一个 auth profile，不需要单独配。一个常见用法是 pre-commit 钩子里跑 lint：

# .git/hooks/pre-commit
git diff --cached | claude -p "审查这次改动有没有明显的 bug 或风格问题。只输出 OK 或具体问题列表。" --allowedTools "Bash(git:*)"

9. 拼车场景下的特殊技巧

按模型分配 profile 的配置例：

{
  "models": {
    "fallbacks": {
      "anthropic:claude-opus-4-7":   { "profile": "anthropic:carpool" },
      "anthropic:claude-sonnet-4-6": { "profile": "anthropic:carpool" },
      "anthropic:claude-haiku-4":    { "profile": "anthropic:default" }
    }
  }
}

跑用量统计看哪个模型烧 token 烧得多：

openclaw carpool usage --by-model

10. 常见反模式

• 写 50 个 slash command → 你创造了一个比 CLI 还难学的 DSL。slash command 应该是个人快捷方式，不是团队规范
• 给 sub-agent 写一堆系统提示 → 等于在限制 Claude 的智能。让主 Claude 用 Task(...) 动态决策更好
• CLAUDE.md 写到 30KB → 每次启动都吞 30K token。13KB 是经验上的软上限
• 依赖 /compact → 用「文档化并清除」替代
• 生产环境后端跑拼车 → 拼车不保 SLA，用官方 API。拼车的甜点是个人和小团队开发场景

立即开始

curl -fsSL https://cp.bizq.net/setup.sh | bash -s -- claude-max-20x

更多细节：cp.bizq.net

相关文章

• OpenClaw Claude Code 拼车配置指南 — 一键接入完整流程
• Claude Code 完整指南 — 从安装到精通的全景
• Claude Code 深度指南 — 高级特性与生态实战
• Claude Code 拼车最佳实践 — 服务器、时区、稳定性