Claude Code 这类终端里的 AI 编程工具，上手很容易，用出稳定产出却要先把几件基础的事做对。这篇是实践路线的梳理，讲从单人配置到团队协作、再到生产级落地的几个关键动作，以及最常见的几个误区。

环境与第一条指令

装好之后第一件事不是开写，而是给每个项目准备一个 CLAUDE.md。它和 README 不同——README 是给人看的，CLAUDE.md 是给 Claude 的指令文件，写清楚命名规则、测试命令、风格偏好，还有它以前踩过的坑。

# CLAUDE.md
- 构建：make test 跑单测，make lint 跑格式检查
- 约定：金额字段一律用分（int），不要用浮点
- 禁止：不要直接改 migrations/ 下的历史文件
- 已知坑：生成的 import 常把 src 写成相对路径，写完记得跑一遍 gofmt

关键的一条习惯：当 Claude 出了错，不要只修这一处输出，要顺手让它把这条教训写进 CLAUDE.md。这样同一个错不会再犯第二次，团队里一个人的教训能救所有会话。

复杂任务先计划

Claude 写代码很强，但它并不天然理解你的业务意图。直接丢一句"帮我加个登录"上去，它会顺着自己的理解往下写，返工往往发生在实现到一半才发现方向错了的时候。

对于多文件改动、不熟悉的模块，先走计划模式：让它先读相关代码、说清现状，再列出要改哪些文件、为什么、怎么验收，你看过方案再让它动手。反过来，如果一句话就能描述清楚改动——比如"把变量名 x 改成 userId"——就没必要走计划，那点开销比直接改还大。计划的价值也不在文档漂亮，而在逼你在动手前把验收标准想清楚——它同时是后面 review 和返工的参照。

把重复流程固化

团队里反复做的事，不该每次重新解释一遍。斜杠命令和钩子是两条固化的路。

斜杠命令放在 .claude/commands/ 下，跟着仓库走。比如一个 /commit-push-pr 把提交、推送、建 PR 串成一步，命令里还能先跑 bash 把最近的测试结果、改动文件拉进来当上下文。

钩子则是在 Claude 生命周期的固定节点跑一段 shell。最有价值的是 PostToolUse——每次它改完文件自动跑格式化，CI 里因为格式问题挂掉的次数能少一大半。其他还有 SessionStart（会话开始时加载最近提交和待办）、PermissionRequest（把审批推给团队负责人）。

权限上有一条常见的误区：图省事开 --dangerously-skip-permissions 等于把所有审批全关掉。更稳的做法是用白名单，把 git log、bun run 这类只读或安全的命令放行，写文件、动配置的仍然要确认。

上下文是最大的约束

Claude Code 的上下文窗口大但有限，而且塞满噪声之后输出质量会明显下降。几个习惯能保住上下文干净：

  • 无关任务之间用 /clear 隔开，别让上一个调试会话的上下文渗进下一个功能。
  • 长会话用 /compact 压缩，保住关键信息。
  • 需要大范围搜代码时，交给子代理去搜，让主会话只聚焦当前任务。
  • 会话起个名字，方便以后接着干，而不是从头解释一遍。

团队落地先试点

团队铺开之前，先让两三个开发跑一个完整 sprint 做试点，量几个数：每周每人产出多少 PR、从提 issue 到合并的周期、CI 失败率、代码评审的返工时间。有数据再决定要不要全员铺开，而不是凭感觉。

共享配置靠 git：CLAUDE.md、.claude/settings.json、.claude/commands/、.mcp.json 都提交进仓库，每个成员拿到一样的体验；个人偏好放 .claude/settings.local.json 并加进 .gitignore。团队的最小 MCP 配置是接一个 GitHub，其余按技术栈加。

模型选择上有一条朴素的经验：重活、架构决策、边界情况用最强的模型加思考模式，慢一点但返工少；改名、提文件这类琐碎的小活交给轻量模型，省下的时间比省下的钱更值。别一刀切地所有任务都用最强档。

Claude Code 的价值不在它单次写得多快，而在团队知识能沉淀、能复用。把 CLAUDE.md 当成活文档、把重复流程固化下来、用数据驱动铺开节奏，这条路才走得稳。