Claude Code 用成这样，你早该知道的 5 个操作

CLAUDE.md 决定了 CC 的能力下限，操作习惯决定了效率上限。本文不讲配置，讲五个我用了几个月才悟出来的操作习惯------把 CC 当 Unix 管线用、开多个分身并行干活、该 /clear 时别犹豫、先写 spec 再写代码、加个 ignore 文件立省 70% token。每个都能立刻在终端里试。

---

大多数人用 Claude Code 的方式是这样的：打开终端，敲需求，等结果，改错了就纠正，纠正完继续改。三个月后还是这个姿势。

问题不在 CC 不够强。你的 CLAUDE.md 可能已经配得很好了------技术栈、编码规范、禁止事项都写得明明白白。但操作习惯还停在第一天。

我今天不讲配置（上一篇写过了），讲五个操作层面的东西。每个都是那种"早该知道但一直没人告诉你"级别的。

---

一、把 CC 当 Unix 管线用，别当聊天窗口

我刚用 CC 的时候，跟大多数人一样：把它当成终端里的 ChatGPT。聊一句，它干一句。出错了，手动复制错误日志贴回去。需要分析代码，先 cat 出来，选中，粘贴。

直到有一天我看到了这个：

mvn test 2>&1 | claude -p "分析失败原因，修复代码，再跑一次验证"

我当时愣了好几秒。

不是"还能这样"，是"我为什么一直没这样"。CC 的设计哲学不是聊天机器人------它的 PM 在 Latent Space 访谈里说得直白：Claude Code 是 Unix 工具，不是产品。 它跟 grep、awk、sed 是一类东西，只不过它的输入是自然语言。

管道符直接把标准输入喂给 CC，不需要手动搬运。几个我每天在用的场景：

# 跑完测试自动修
./mvnw test -pl order-service 2>&1 | claude -p "分析失败用例并修复代码，修完重新跑"

# git diff 转 commit message
git diff HEAD~3 | claude -p "写一段中文 commit message，Conventional Commits 格式"

# 日志排查一把梭
tail -200 app.log | claude -p "找出所有 ERROR，分析根因，给出修复建议"

顺手说三个配合细节：

• -p 非交互模式 加 --allowedTools 精确控制权限。只让它跑 Maven 和编辑文件：--allowedTools "Bash(mvn:*),Edit"。别给它全局 bash 权限------它真的会顺手干别的
• --output-format json 输出结构化结果。claude -p "列出所有 REST 接口" --output-format json 一行命令，接口清单直接喂给文档生成工具
• ! 前缀零 Token 执行 ：!./mvnw clean compile 这种纯构建命令，前面加 ! 不耗 token。不用跟 CC 废话，跑就完了

你把 CC 当聊天窗口，它就只是聊天窗口。你把它当管线工具，它就是你的自动化流水线。

---

二、开分身------你不该只有一个 CC

我之前的习惯：一个终端窗口，一个 CC session，从头干到尾。重构订单模块的时候想顺便查一下支付模块的调用链------在主 session 里说了一句"帮我看看支付模块怎么串起来的"。CC 出去搜了一圈，带回来一堆上下文，把我正在写的重构逻辑冲得七零八落。

后来看了 Anthropic 官方最佳实践才搞懂：Subagents 在独立的上下文窗口里运行。 探索代码库这种事，丢给 subagent 做，结果只返回摘要给主 session。主 session 干净，subagent 也干净。

实操：

主窗口：重构 OrderService，拆分为三个小 Service
  ├── subagent 1：查支付模块的完整调用链，给我一个 mermaid 图 + 关键文件列表
  ├── subagent 2：审查当前改动的事务边界，只报告问题不修改代码
  └── subagent 3：跑 mvn verify，只报告失败的测试和覆盖率缺口

三个分身并行跑，互不污染。主窗口的上下文一直干干净净，"聊着聊着 CC 开始忘事"的问题基本消失。

还有个高级玩法叫 Writer/Reviewer 模式------官方的建议。Session A 写代码，Session B 独立审查（不知道 A 是怎么写的，不带偏见），然后 A 按 B 的意见改。等于你自己有了个 code review 搭档。

最典型的翻车现场：主 session 已经聊了 40 轮，上下文快满了，这时候你说"顺便帮我查一下认证模块怎么实现的"。CC 在拥挤的上下文里搜索，结果残的残、漏的漏。正确做法：新开 subagent，独立上下文，干净利落。

一个 CC 是助手，三个 CC 是团队。

---

三、纠错超过两次，该 /clear 了

有一次我让 CC 重构一个 Service 类。过程是这样的：

• "重构 OrderService" → CC 改了支付逻辑
• "别动支付逻辑" → CC 又改了优惠计算
• "也别动优惠计算，只拆方法" → CC 开始改 Controller 层的参数校验
• 我血压开始升高

事后看，问题不在 CC。"别动支付"这条指令写进上下文之后，CC 的行为就变了------它开始花大量的注意力绕开支付模块，同时还要满足"重构 OrderService"这个原始目标。两个约束在上下文里打架，CC 越改越歪。

Anthropic 官方文档给这种现象起了个名字：kitchen sink session------厨房水槽 session，什么东西都往里丢。他们直说这是"最高频的失败模式"。

规则很简单：纠正超过两次，直接 /clear。 别修修补补。把你前两次纠正的内容写进新 prompt，重来。干净的一轮对话，比一个塞满了纠正指令的长 session，效率高得多。

/clear 的时机，我自己的判断标准就四条：

• CC 开始改你没提到的文件 → /clear
• CC 忘了你五分钟前说的约束 → /clear
• 同一个问题 CC 问了第三次 → /clear
• 换话题了（刚改完 Controller 参数校验，现在要优化 SQL）→ 必须 /clear

/compact 是压缩上下文，/clear 是重置上下文。compact 是缓兵之计，clear 才是正解。

纠错超过两次还不 /clear，你花的 token 有一半是在买 CC 的幻觉。

---

四、先写 spec，再让 CC 写代码

有个反直觉的事：AI 时代，spec 不但没死，反而更重要了。

我踩过这个坑。需求："帮我写一个用户下单接口，支持会员折扣和优惠码，折扣叠加不超过 30%。"

CC 哗啦啦生成 400 行。会员折扣对了，但优惠码被算在了折扣后的金额上，叠加逻辑完全跑偏。改了 5 轮才对齐------不是因为 CC 笨，是因为我脑子里"叠加不超过 30%"这几个字，跟 CC 理解的完全不是一个东西。

后来我试了另一种方式。先写 30 行 OpenAPI spec：

POST /api/orders:
  requestBody:
    customerId: string
    items: array<OrderItem>
    promoCode: string | nullable
  responses:
    201:
      memberDiscount: integer (0..subtotal * 0.1)
      promoDiscount: integer
      total: integer (subtotal - memberDiscount - promoDiscount, >= subtotal * 0.7)
    400:
      error: { code: string, message: string }

把这个 spec 丢给 CC，一句话："按这个 spec 实现 Spring Boot Controller，加上 @Validated 参数校验和统一异常处理。"

一次过，改了不到 10%。Controller 骨架、参数校验注解、异常码、返回格式------全部对齐项目规范。我只填了优惠叠加的核心计算逻辑------那 20% 才是真正值钱的。

spec 驱动好用的原因没那么玄：你写 total >= subtotal * 0.7 这条约束的时候，脑子里"不超过 30%"这五个字才变成了一道数学题。写之前 CC 跟你对齐的是模糊的汉字，写之后对齐的是确定的范围。它不可能再算错。

三个坑踩过了，直接列：

1. 模糊 spec 是幻觉工厂 。discount: number 和 discount: integer (0..subtotal * 0.1) 生成的代码质量天差地别
2. CC 会偷偷加需求 。给 public 端点加鉴权、给简单查询加缓存------都是 spec 没说清楚惹的。所以 spec 要写明"不做什么"：此接口无需认证
3. 永不无条件信任生成代码。SQL 字符串拼接、密码明文存日志------CC 不会恶意写这些，但你 spec 里没说"不许"

模糊的 spec 只是把需求沟通成本从"跟人吵"变成了"跟 AI 吵"。

---

五、你每次聊天都在为 target 目录买单

这个最隐蔽。我用了两个月才发现。

Java 项目 mvn compile 完，target/ 目录轻松几百 MB。几千个 class 文件、jar 包、surefire 测试报告------全是编译产物。CC 搜索代码的时候，会扫项目下所有未 ignore 的文件。没错，包括 target/ 里的东西。

你让它"查一下全局异常处理怎么串的"，它去 target/classes/com/example/exception/ 里读了一套跟 src/ 一模一样的 class 文件，白白烧 token。

解法只有一行------创建 .claudeignore，语法跟 .gitignore 完全一样：

target/
.gradle/
build/
*.log
logs/
.idea/
*.iml

加完这个文件，实测能砍掉最多 70% 的无效 Token。一个中等规模 Spring Boot 项目，效果立竿见影。

这事有意思的地方在于：.claudeignore 在官方文档里是有的，但大多数前端教程不提它------因为 node_modules 已经在 .gitignore 里了。Java 的 target/ 是编译产物，很多人没意识到 CC 会扫它。

你每跟 CC 聊一次天，都在为 target 目录里的垃圾买单。一个文件，立省 70%。

---

组合起来

五个技巧不是孤立的，是一套操作流：

• 启动项目时 ：.claudeignore 先把噪音挡住（技巧 5）
• 接到任务时：花 15 分钟写 spec，别直接开始（技巧 4）
• 执行过程中 ：管道符 -p 模式跑验证闭环（技巧 1）
• 复杂任务：subagent 拆分并行，别让一个窗口扛所有事（技巧 2）
• 跑偏了 ：纠正两次 → 果断 /clear（技巧 3）

全用上之后，CC 跟你协作的体验会从"一个不太靠谱的下属"变成"一个跟得上你思路的搭档"。

怎么开始？按这个顺序一个一个加：.claudeignore（零成本，立竿见影）→ /clear 习惯（省 token）→ 管道符（改变心智模型）→ spec 先行（改变开发流程）→ subagent 分治（高级玩法）。

一次只加一个，用到肌肉记忆再加下一个。

CLAUDE.md 决定了 CC 的能力下限，这些操作习惯决定了它的效率上限。下限靠写，上限靠练。