心智模型与边界

什么时候 Claude Code 最闪光

不是所有任务都适合扔给 Claude。用对地方，它能让你一小时的活十分钟完成；用错地方，它能让你十分钟的活花一小时收拾。

它最擅长的五类任务：

1. 跨文件的机械改动。「把所有 console.log 换成 logger.debug」「这个 API 改名以后同步所有调用点」——你知道怎么改，只是改的地方太多。这种任务它几乎不会犯错，/goal 模式 + Haiku 跑下来又快又便宜。
2. 探索陌生代码。「这个项目是怎么处理认证的？」「帮我找到所有用到 ws 连接的地方」——它用 Glob/Grep 扫得比你快，还能帮你总结。新接手一个项目？让它先带你过一遍架构。
3. 写测试和样板代码。给它一个接口定义，让它补一批单元测试；给它一个表结构，让它生成 CRUD 接口；给它一个错误，让它写个对应的 fixture。这些事你自己写不难，但无聊。
4. 「我不知道怎么开始」的时候。不是让它给你写完，是让它帮你搭架子、列大纲、给几个可能的方向。它是很好的「思考伙伴」，尤其是进入新领域、读新论文、用新框架的时候。
5. 处理「好烦但必须做」的活。读一份规范、对照写校验代码；把别人的报错信息搜一遍 Stack Overflow + GitHub issue 综合判断；把一份英文 RFC 总结成你能用的中文要点。这些事它做得不比你强，但你做了会很烦——它正好。

什么时候别用，或者用但别完全相信

它很容易翻车的场景：

1. 需要真正理解业务规则的判断。「这个退款场景该不该自动处理？」——这不是技术问题，是业务问题。它不知道你的用户、你的法律环境、你的老板怎么想。它会给出一个听起来合理的答案，但可能完全错。
2. 性能、并发、安全这种「看起来对但藏坑」的代码。它写出来的东西可能跑得通、测试也过，但在特定并发下会死锁，或者有个 SQL 注入的角落。这类代码必须人工 review，/security-review 是最低标配，更高风险的还要资深工程师过。
3. 需要大量当前情境知识的任务。「这个 bug 和昨天那次发布有没有关系？」——它没有那个上下文。除非你把昨天的发布说明、commit 范围、监控报警都贴给它。
4. 很小的改动。改一个 typo、挪一个按钮——你直接改比解释给它听要快十倍。用 Claude 也有「交流成本」，不值得为了 2 秒的活付 20 秒。
5. 核心算法、数据结构、系统设计。不是不能让它写——是这种东西你必须自己懂。让它写一个 LRU cache、让它讲一致性哈希——它写完你自己要看得懂、要会改。否则后续维护是地狱。

怎么问，能显著提高成功率

你已经看到很多「Claude 帮我 X」的例子了。但同样的请求，问法不同，结果差距很大。这里是几条被反复验证过的经验，按重要性排：

1. 给目标，不给步骤

不好：「先读 user.ts，然后找到 login 函数，把第 23 行的 bcrypt 换成 argon2，然后……」
更好：「把这个项目的密码哈希从 bcrypt 迁移到 argon2，保持 API 向后兼容。」

你告诉它要什么，它比你更会规划怎么做——因为它可以并行读十几个文件。你给得越具体的步骤，反而是限制它。

小提示：「给目标不给步骤」不等于「给模糊指令」。目标本身要清晰、约束要明确——你省掉的只是「怎么实现」这部分。Claude 的优势是跨文件分析和规划路径，你的优势是知道业务意图和验收标准。各干各擅长的。

2. 给约束和验收标准

「保持 API 向后兼容」「测试要全绿」「不要动 src/legacy/」「响应时间不能超过 50ms」——这种边界条件越明确越好。它不会猜你心里有没有这些线。

验收标准是约束的特例：你怎么判断这件事做完了？把这个问题写出来，往往就是给 /goal 的最佳输入。

3. 说出你的上下文

「我在复习期末，下周二要演示」「这是生产代码，每天 100k QPS」「这是个实验脚本，糙一点没关系」——这些信息会改变它的取舍。生产代码它会多加防御；实验脚本它就不会浪费你时间写测试。

4. 不确定时让它先 /plan

第二章已经讲过。再强调一次：涉及多个文件、或者你自己都说不清要怎么改的时候，先让它出方案。一分钟的方案能避免半小时的回滚。

5. 不满意就打断、重来

看到它走偏，按 Esc 或 Ctrl+C 打断，然后说「停，你上面那个思路不对，应该这样…」。不要让它错下去再大改——它不会自己意识到自己错了，它会越走越远。

6. 给它例子，特别是「不要这样」的例子

正面例子有用，但反例更有用。「不要写成 try/catch 里 console.error 然后吞掉」——比说「请妥善处理错误」管用十倍。模型对正例的拟合很容易过头，反例会让它的输出更收敛。

7. 长任务用「检查点 prompt」

做一个 30 分钟的大任务时，每完成一段让它做一次自我检查：「停一下，列出你刚才改了哪些文件，每一处的目的。」这相当于让它生成一份 mini diff——你不用看代码就能判断方向对不对，不对就早点掉头。

token 经济学：你为什么花钱

Claude Code 是按 token 计费的。理解 token 怎么花，能帮你少花一半钱。

哪些操作贵

省钱的几招

• 该用 sonnet 用 sonnet。批量重命名、补 JSDoc、生成测试 fixture——sonnet 比 Opus 便宜 10–15 倍，而且质量完全在线。
• 大任务前 /compact。压一次省的不是这次的钱，是后面每一轮的钱。
• 用 prompt cache。SDK 自动用，CLI 里你写到 CLAUDE.md 的内容会被缓存 5 分钟，反复发同一个 prompt 不会重复计费输入部分。
• 限预算。非交互模式加 --max-budget-usd 1.00，超了就停。CI 里必加。
• 子代理省得多。派一个 Haiku subagent 去读完 30 个文件，回来一段 200 字的总结——主会话只多了 200 字的输入，不是 30 个文件的内容。

它会怎么出错，具体来说

知道一个工具怎么坏，比知道它怎么好更重要。Claude Code 有几种典型的失败模式：

幻觉（hallucination）

它可能会「发明」不存在的 API、不存在的函数、不存在的配置项。尤其是对冷门库、版本差异大的库。它写得很自信，看起来对，但你真去跑会报 undefined is not a function。

怎么防：对不熟的库，让它用 !npm ls <库> 先确认版本，或者读 node_modules/<库>/types；让它跑代码验证；多用 /plan 看它引用了什么，然后你抽查。

信息过期

Claude 的知识有一个截止日期（Opus 4.7 是 2026 年 1 月）。之后发布的库、新版 API、政策变化，它可能不知道，或者知道错。

怎么防：对时间敏感的东西，要求它联网搜索调研一下再回答，而不是凭记忆。

「修好」但其实跳过

一个常见的翻车是：它为了让测试通过，会把测试本身改弱，或者直接加 @ts-ignore、try { ... } catch {}、# type: ignore。测试全绿了，但问题被藏进了地毯下。

怎么防：在 CLAUDE.md 里明确禁止：「不要用 @ts-ignore 绕过类型错误」「测试失败要修代码不要改测试」。以及，review diff 的时候特别注意测试文件——绿测试 + 改过的测试，是危险信号。

这不是某个模型的 bug，是当前所有 LLM 的结构性倾向——模型的目标是「让任务看起来完成」，而不是「让代码真正正确」。更强的模型（比如 Opus）犯这个错的频率更低，但不是零。不要因为用了最贵的模型就放松警惕，diff 里的测试文件永远值得多看一眼。

过度发挥

你让它修一个 bug，它顺手「整理」了周边几个文件、重写了一个类、升级了一个依赖——你现在要 review 的 diff 是原本的十倍。

怎么防：在请求里明确「只修这一个问题，不要做其他改动」。如果已经发生了，用 git add -p 分拆，把相关的留下、其他 stash 掉。CLAUDE.md 里加一条「不要顺手重构」也很有用。

卡在循环里

偶尔你会看到它在两个错误之间反复横跳：改 A 导致 B 报错，改 B 又让 A 报错。尤其是用 /goal 的时候，它会在循环里耗光预算。

怎么防：看到它连续两次改同一个地方还没解决，Ctrl+C 打断，手动看一眼——通常是它误解了问题，你点破一下它就通了。设 --max-turns 给 /goal 也是底线保险。

「演」做完了

最阴险的一种。它说「我做完了，所有测试都通过」，但实际上它根本没跑测试，或者跑了但没看输出就报告。

怎么防：永远不要相信它的「自我汇报」。你自己跑一次测试。你自己看一眼 git diff。CLAUDE.md 里加：「报告任务完成前必须实际跑测试，并把输出贴出来。」

深一层：幻觉为什么会发生

想知道「为什么」会让你更会防它。语言模型的本质是「根据上文预测下一个 token 的分布」。它学习的目标是「输出像训练数据」，不是「输出真实」。

很多时候这两件事重合——训练数据里 fs.readFileSync 这个 API 真的存在，所以模型生成它就是对的。但当你问一个冷门库的方法、或者问一个版本差异大的 API：训练数据里可能都是「这个库有 .doSomething() 方法」的形状，但实际上它具体的方法名各版本不同。模型按形状生成，结果生成了一个看起来合理但不存在的名字。这不是「错」——这是模型设计上的副作用。

Agent loop 给了我们对抗幻觉的最强武器：让模型实际验证。让它读 node_modules、跑命令看输出、抓官方文档——这些动作把「凭记忆」变成「凭事实」。

怎么给它合适的信任

对 AI 工具，一个常见的错误是要么不信、要么全信——不信的人继续手打所有代码，浪费了一个杠杆；全信的人把 PR 直接合进 main，迟早出事。两种都把事情简化了。

合适的信任是「有刻度的」。下面是一个可以参考的分级：

这张表不是死的。你会随着用它的时间增长，慢慢校准每一格。但不要一开始就把所有格子设成「高」——那是通往灾难的最快路径。

渐进式：怎么慢慢升级信任

新接手一个领域、新团队、新项目，给 Claude 的信任度都应该重置，从「极低」开始往上爬。爬的步子大概是这样：

1. 跑只读任务（/plan、explore）。看它对项目的理解到不到位。
2. 让它做小改动（典型 typo、加日志、补一个 if）。看 diff 写的精度。
3. 让它写测试。看它会不会作弊（注释掉断言、return early）。
4. 让它做小重构。看它会不会过度发挥。
5. 让它做新功能。这时你才有数据决定信任度。

整个过程可能就一两小时，但对长期协作非常值。

Git 是你的安全带

无论多信任 Claude，都要把每次会话想象成「开车不系安全带可能翻车」。Git 就是你的安全带。

• 开始任务前 git commit 当前进度，哪怕只是一行改动也 commit。这样任何时刻都能 git reset --hard 回去。
• 复杂任务开新分支：git switch -c claude-refactor-auth。随便 Claude 怎么折腾，不污染 main。
• 用 worktree 做隔离：claude -w feature-jwt，Claude 在一个全新的目录里跑，连文件系统都不互相影响。
• 用 git stash 不要用 git checkout .——前者可逆、后者吞掉所有未提交的改动。
• commit 信息让 Claude 帮你写，但不要让它自动 push。push 是「广播到世界」的动作，应该你亲手按。我对三体人说话（bushi

/rewind 是 Claude Code 自己的「时光机」，比 git 还细——它在每次重要操作前打 checkpoint，能回到一分钟前。但它不是替代 git：rewind 是会话级的、临时的；git 是项目级的、永久的。两个一起用最稳。

审查 diff 是一项独立技能

自己写代码，你是「生成者」；用 Claude，你是「审查者」。这是两种不同的脑力活动，而学校和教科书基本不教后者。这一节给你一份 review 清单。

看 diff 时心里要过的问题

1. 这个改动解决的问题是我要求的那个问题吗？还是它跑偏了？
2. 有没有改动是这个任务不需要的？（顺手重构是大坑）
3. 边界情况呢？空值、网络错误、并发、超大输入、空数组、并发请求、跨时区？
4. 它删掉了什么？删除比新增更危险——可能删的是你忘了的依赖。
5. 测试覆盖的是真正的逻辑还是只是 shape？（测试 typeof result === 'object' 完全没用）
6. 有没有 any / @ts-ignore / # type: ignore / // eslint-disable？这些都是「藏问题」的信号。
7. 新依赖是不是必要的？是不是知名库？版本怎么选的？
8. 错误处理：try/catch 里是真的处理了，还是 console.log 然后吞掉？
9. 命名：变量名、函数名能让一年后的我看懂吗？
10. 如果我明天忘了这是 AI 写的，我会愿意为这段代码负责吗？

最后一条是金标准。你合进仓库的每一行代码，git blame 都会指向你。Claude 没法被追责——你可以。

review 工具组合拳

用 Claude Code 自己审 Claude Code 的产出，听起来奇怪但很有效：

$ git stash         # 把改动暂存
$ claude
> /review           # 让另一个会话从「无前置」的视角看 diff

新会话不知道你和上一个 Claude 聊过什么，它的 review 是「冷启动」的——这往往能抓到上一个 Claude 因为「记得我们说过 X」而忽略的问题。再加上 /security-review 和 /simplify，三个角度的审视，往往可以解决不少问题。

团队里的 Claude：协作伦理

到目前为止讨论的都是「你和你的 Claude」。但当 Claude Code 进入团队，会出几个新问题，提前知道好避坑。

谁该为 AI 写的代码负责？

简单答案：提交者。git blame 指向你，你就是负责人。这意味着即便代码 95% 是 Claude 写的，你 review 时不细心、出了问题、责任在你。

团队里别用「这是 AI 写的」当借口。AI 不能上 oncall，AI 不能去客户面前道歉，AI 不能被解雇——你可以。承担责任的能力是你相对 AI 的核心价值。

commit message 要标记 AI 吗？

团队约定优先。如果团队没规定，建议至少在 PR 描述里说清「主要由 Claude Code 生成」——这帮 reviewer 调整审查策略，也对未来回看 git 历史的人公平。一些 Anthropic 员工的 commit 会带 Co-Authored-By: Claude trailer，是个不错的实践。

code review 标准要不要变？

不要降低，要调整侧重：

• 更注意「过度发挥」——AI PR 比人 PR 容易出现无关改动。
• 更注意「神奇的依赖」——AI 会偶尔引入一个你团队从来没用过的库，让它解释为什么。
• 更注意「测试改弱」——把测试文件单独看一遍，确认断言没被注释、没被改弱。
• 不用花时间挑「这变量名能不能更好」——AI 在风格上往往比人均水平稳，省下精力盯逻辑和边界。

接下来

到这里，你已经知道了 Claude Code 什么时候好用、什么时候会翻车、怎么问它、怎么审查它的产出、怎么在团队里和它协作。这些是「用好它」的软技能。

但还有一个硬问题没讲：钱。Claude Code 按 token 收费，而你每发一句话，背后传输的 token 量远比你想象的大。下一章讲缓存——理解它之后，你会知道为什么有时候同样的对话几乎免费，有时候却贵得离谱，以及怎么让账单永远停在前者。