# 50 · 反模式：常见的错误用法

> 📚 **系列导航**：上一篇 [49 最佳实践](49-best-practices.md) 把「该这么用」的正面打法摊开讲了一遍。这一篇翻到背面——**专挑「不该这么用」的坑**。同一个工具，有人用得飞起，有人用成累赘，差别往往不在「会不会高级功能」，而在**有没有踩进那几个最常见的反模式**。这一篇我把它们一个个拎出来示众，每个都配一句「正确该怎么做」。下一篇 [51 FAQ 排查](51-troubleshooting.md)。

兄弟们，到这一篇，整套教程的「正向」内容你基本都过了一遍了。

那咱们换个角度玩——**反着看**。围观不少刚上手 Claude Code 的朋友，会发现一个挺有意思的现象：**大家踩的坑高度雷同**。不是各踩各的，是同一批坑、同一个顺序，一个接一个往里跳。几乎一个没落下。

说白了，**这些坑不是「水平问题」，是「认知盲区」**——你不知道有这么个坑，自然会一脚踩进去；一旦有人指给你看，下次就绕过去了。这一篇干的就是这事：把最高频的七个反模式（anti-pattern，指那种「看着合理、实则坑你」的常见错误用法）摆到台面上，告诉你**它长什么样、为什么坑、正确该怎么替换**。

这么说吧：前面四十九篇是教你「怎么开车」，这一篇是把**驾校教练那本「新手最常见扣分动作」**直接塞给你——**知道哪儿容易扣分，比单纯练得多更省事**。

**看完这一篇，你会拿到：**

- 七个最高频反模式的「症状识别卡」，一眼认出自己是不是正在犯
- 每个反模式配一组 **Before / After**，照着把错的改成对的
- 一张「反模式速查表」，哪天感觉「Claude 怎么越用越笨」，对着自查
- 知道这些坑分别该回哪一篇深挖（这一篇是集中清单，细节都甩了交叉引用）
- 一个动手环节：给一段「集齐了多个反模式」的反面操作做体检，逐条改顺

---

## 01 先说清楚：好工具也能被用废，问题常常出在「用法」

先给结论：**Claude Code 用不顺，十有八九不是工具不行，是用法掉进了反模式。**

太多人开头新鲜劲一过就开始嘀咕「这 AI 也就那样」「还不如我自己写快」。凑过去看他们怎么操作的，**问题几乎都出在同一批地方**——一句话甩个模糊需求、CLAUDE.md 要么没写要么写成长篇小说、一个会话从早开到晚啥都往里塞、Claude 说啥信啥从不验证……

**类比：驾照考试里印好的那张「常见扣分动作」清单。** 你去考科目二、科目三，教练第一件事不是夸你天赋好，而是把一张纸拍你面前：「**这几个动作最容易挂——不打转向灯、压线、中途熄火、忘了回头看后视镜**。」这张纸的价值在于：它把**别人用血泪换来的高频错误**提前列给你，你不用自己一个个去撞。这一篇就是 Claude Code 的那张纸。

为什么这些坑这么普遍？因为它们**全都「看着合理」**：

- 「我把需求一次说全，它不就一次干完了？」——听着没毛病。
- 「让它先把整个项目读一遍再动手，它不就最懂全局了？」——听着也对。
- 「CLAUDE.md 写详细点，它记得越多越好吧？」——好像也是这个理。

**坑就坑在「听着合理」上**——这些直觉拿到别的场景多半成立，唯独在 Claude Code 这套「有上下文窗口、要验证、会被注入」的机制下，**正好踩反**。下面七节，一个一个拆给你看：症状、为什么坑、怎么改。

先上一张总表压个底，后面每节展开一个：

| # | 反模式（症状） | 为什么坑 | 回哪篇深挖 |
|---|----------------|----------|-----------|
| 1 | 一句话塞一大堆需求 | 它猜偏方向，改一堆没用的 | [第 15 篇](15-prompting.md) |
| 2 | 不写 CLAUDE.md / 全塞进 CLAUDE.md | 要么天天复读，要么规则被淹没 | [第 18 篇](18-claude-md-guide.md) |
| 3 | 一个会话从早开到晚 | 上下文塞满，越用越笨 | [第 19 篇](19-context-management.md) |
| 4 | 把它当搜索引擎、说啥信啥 | 它会一本正经编错答案 | [第 15 篇](15-prompting.md)、[第 21 篇](21-security.md) |
| 5 | 不给它验证的办法 | 「看着像对的」就交差 | [第 49 篇](49-best-practices.md) |
| 6 | 无脑开 `bypassPermissions` | 裸奔，连提示注入都不防 | [第 20 篇](20-permissions.md)、[第 21 篇](21-security.md) |
| 7 | 让它「调查一下」不给范围 | 读几百个文件，烧爆窗口 | [第 19 篇](19-context-management.md)、[第 23 篇](23-subagents.md) |

这里我得多说一句我观察到的现象：**这七个坑不是孤立的，它们会互相喂养、滚成一个恶性循环。** 你一句话塞一堆需求（#1）+ 让它无范围调查（#7），上下文很快塞满；窗口一满，它就开始犯错、答非所问（#3 的后果）；它一犯错你就觉得「这 AI 不行、说啥都不能信」，于是更不愿意给它验证手段（#5）、更想干脆全自动裸奔图清净（#6）……**结果越用越糟，最后得出「Claude Code 也就那样」的结论**。

画成图就是这么一圈：

![反模式恶性循环：需求宽 → 错 → 怪它 → 更裸奔；破局点：拆需求 + 清上下文 + 给验证 → 越用越顺](assets/50-anti-pattern-loop@2x.png)

这张图想说的是：**单个坑还好办，怕的是它们连锁**。所以下面七节你别孤立地看，记住它们常常是「一窝」出现的——而破局点恰恰是图右下角那条：**把需求拆开、把上下文清干净、给它验证手段、把范围收窄**，链条就断了。

> 💡 一句话总结：用不顺 Claude Code，**先别怪工具**——这七个反模式还会互相喂养滚成恶性循环，对着它们自查，多半能找到那个「看着合理实则坑你」的用法。

---

## 02 反模式一：一句话塞一大堆需求

**症状**：你憋了一肚子需求，啪地一长段甩过去——「帮我把登录改成 OAuth，顺便把那个报错修了，对了首页那个按钮也调下样式，还有把测试补一下」。回车，等着它一次全干完。

**结果往往是**：它哪个都干了一点，哪个都没干透；或者抓错了重点，在你最不在意的那条上花了大力气，你真正想要的那条反而糊弄过去了。

**为什么坑？** 不是它笨，是**需求一多、又混在一起，它没法判断哪条是主线、每条的边界在哪**。官方在「先探索，再规划，最后编程」里把这事说得很透——直接跳到编程，容易产出**解决错误问题**的代码。需求越杂，「解错」的概率越高。

**类比：给装修师傅一次性吼十件事。** 「把厨房瓷砖换了、卫生间漏水修一下、客厅墙重新刷个色、阳台再给我加个柜子……」师傅记得住几件？多半挑他顺手的先干，难的、你最在意的那件搁一边。**活儿要一件件交代、一件件验收**，才不会乱。

**怎么改？** 官方给的解法分两层：

- **任务小、方向明的**（修拼写、加一行日志、改个变量名）——确实可以直接说，别为它走规划，纯属增加开销。
- **任务大、改多个文件、你自己也没完全想清的**——先用 **Plan Mode**（计划模式，详见[第 35 篇](35-modes-and-control.md)）让它「先探索、再出方案」，你确认方案再让它动手。

核心是**一次只推进一条主线**，把需求拆开喂。Before / After 对照感受一下：

| | ❌ Before | ✅ After |
|---|-----------|---------|
| 提法 | 「改 OAuth、修报错、调样式、补测试」一口气甩 | 先「把登录改成 Google OAuth，先别动别的，给我个方案」 |
| 范围 | 四件事混在一起，边界模糊 | 一次一件，每件说清涉及哪个文件、什么场景 |
| 大任务 | 直接让它写 | 先 Plan Mode 出方案，确认后再 implement |
| 结果 | 哪个都没干透 | 一条主线干透、验收、再开下一条 |

这里插一个很典型的教训。赶一个 demo，图快，把「加一个导出 PDF 的功能 + 顺手把日期格式全统一了」塞一句里发出去。它把日期格式改得很卖力，**改崩了三处没人注意到的地方**，而真正急要的 PDF 导出反倒只搭了个空壳。所以养成这个习惯：**急的时候更要拆**，越急越不能一口气甩一堆。

那种「把需求一次说全」的冲动，本质是把 Claude 当成「许愿池」。但它是个要顺着「想→做→看」一步步走的执行者，不是许愿池。

> 💡 一句话总结：**一次只喂一条主线**；小任务直说、大任务先 Plan Mode 出方案，别把一肚子需求一口气倒给它（详见[第 15 篇](15-prompting.md)、[第 35 篇](35-modes-and-control.md)）。

---

## 03 反模式二：不写 CLAUDE.md，或者把所有东西都塞进 CLAUDE.md

这其实是**一枚硬币的两面**，新手会从一个极端滑到另一个极端，所以放一起讲。

### 极端 A：压根不写 CLAUDE.md

**症状**：每开一个新会话，你都得重新交代一遍——「我们用 pnpm 不用 npm」「提交前先跑测试」「这个项目用的是 TypeScript 严格模式」。说了一天，第二天换个会话，从头再说。

**为什么坑？** Claude **每个新会话都是「失忆」的**——它不会自动记得你昨天交代过啥。CLAUDE.md（详见[第 18 篇](18-claude-md-guide.md)）就是治这个的：它在每次对话开始时自动加载，相当于给 Claude 的**一份常驻的项目说明书**。不写它，等于让一个每天都换的新员工**自己瞎猜公司规矩**。

### 极端 B：把所有东西都塞进 CLAUDE.md

**症状**：吃过「不写」的亏，矫枉过正——把公司背景、产品愿景、整套 API 文档、代码库逐文件说明……全塞进 CLAUDE.md，写了三五百行，想着「它记得越多越聪明」。

**结果更糟**：Claude 反而**开始忽略你的规则**。官方把话说得毫不客气：

> 膨胀的 CLAUDE.md 文件会导致 Claude 忽略你的实际指令！

**为什么？** 因为 CLAUDE.md 全文**常驻**在上下文窗口里，几百行噪音一灌，你真正强调的那三条核心规矩**被淹没了**。这也呼应了下一节要讲的「上下文」问题——CLAUDE.md 太长，本身就是在**预先烧掉你的工作台空间**。

**类比：给新员工的入职手册。** 一页纸的入职须知（「打卡走侧门、报销找小王、代码提交前跑测试」）新人扫一眼就记住了；换成一本三百页、混着公司发展史和产品白皮书的大部头，**新人翻两页就放弃了**，真正要紧的「提交前跑测试」埋在第 87 页没人看。手册的价值在「精」，不在「厚」。

**怎么改？** 官方给了一条特别好用的自检标准，写每一行 CLAUDE.md 都值得默念一遍：

> 对于每一行，问自己：「删除这个会导致 Claude 犯错吗？」如果不会，删除它。

还有官方那张「该写 / 不该写」的对照表，直接抄来当尺子：

| ✅ 该写进 CLAUDE.md | ❌ 别写进 CLAUDE.md |
|---|---|
| Claude 猜不到的 Bash 命令 | 它读代码就能搞懂的东西 |
| 跟默认不一样的代码风格规则 | 它早就会的标准语言约定 |
| 测试指令、首选的测试运行器 | 详细的 API 文档（改成链接） |
| 仓库礼仪（分支命名、PR 约定） | 经常变的信息 |
| 项目特有的架构决策 | 「写干净的代码」这种正确的废话 |
| 开发环境的怪癖（必需的环境变量） | 逐个文件描述代码库 |

那些「有时才用到」的大块知识（一整份风格指南、一套部署清单），别塞 CLAUDE.md——**做成 Skill**（详见[第 26 篇](26-agent-skills.md)），Claude 按需才加载，不占每次对话的常驻空间。

这是最实在的一个跟头：把一份将近三百行的 API 接口清单**直接塞进 CLAUDE.md**，结果每个会话一开就先吞掉一大块窗口，Claude 还老抓不住真正在意的那几条约定。后来挪进 Skill、CLAUDE.md 只留一句「接口规范见 `api-skill`」，**立马清净**（这事[第 30 篇](30-choosing-features.md)也念叨过，因为它太典型了）。

> 💡 一句话总结：**CLAUDE.md 不写不行，写成长篇也不行**——一页纸的「精华须知」最好，大块知识挪进 Skill；判断标准就一句「删了它 Claude 会不会犯错」（详见[第 18 篇](18-claude-md-guide.md)、[第 26 篇](26-agent-skills.md)）。

---

## 04 反模式三：一个会话从早开到晚，从不清理

**症状**：你早上开了个会话修 bug，修完顺手问它「对了那个正则怎么写」，又聊了几句部署的事，下午接着在**同一个会话**里写新功能。一天下来这个会话啥都聊过，越到后面，你越觉得「**它怎么变笨了，前面说过的都忘**」。

**为什么坑？** 这是官方点名的两个经典失败模式，得分开认：

**厨房水槽会话（kitchen sink session）。** 官方原话：

> 你从一个任务开始，然后问 Claude 一些不相关的东西，然后回到第一个任务。Context 充满了无关的信息。

一个会话里混进太多不相关的话题，上下文窗口被各种杂事塞满，Claude 在一堆噪音里反而抓不住当前任务的重点。

**反复纠正污染。** 它做错了，你纠正，它还是错，你再纠正……官方的判断很犀利：

> 如果你在一个会话中对同一问题改正了 Claude 两次以上，context 就充满了失败的方法。

**类比：换个全新任务，干脆把台面收拾干净再开工。** 你做完一道菜接着做下一道，会先把刚才那堆葱姜蒜皮、空瓶子清走，腾出干净台面。要是图省事不收拾，**新菜的料和旧菜的垃圾混一桌**，你自己都找不着刀在哪。会话也一样——任务一换，台面就该清。

**怎么改？** 官方给的两件工具，按场景用（详见[第 19 篇](19-context-management.md)）：

- **任务不相关了，用 `/clear`**——完全重置上下文窗口，等于收拾干净台面重新开工。官方建议「在不相关的任务之间频繁 `/clear`」。
- **同一任务太长、但还想接着干，用 `/compact`**——把摊了一桌的草稿纸压缩成一页要点，保留关键代码和决策，释放空间。

还有那条「纠正两次以上」的铁律，值得奉为圭臬：

> 在两次失败的改正后，`/clear` 并编写一个更好的初始提示，包含你学到的东西。

Before / After 对照：

| 场景 | ❌ Before | ✅ After |
|---|-----------|---------|
| 切换不相关任务 | 在老会话里直接接着问 | 先 `/clear`，干净上下文重开 |
| 同一任务聊太久 | 硬撑，眼看它越来越笨 | `/compact` 压成要点继续 |
| 同一问题纠正第三次 | 继续在原会话里掰 | `/clear` + 带上「已学到的教训」重写提示 |

有一种情况特别典型：一个会话里跟它来回纠了五六轮某个边界条件，越纠越乱，它甚至开始改你没让它碰的地方。这时候才反应过来——**不是它笨，是上下文里堆满了五六个失败版本，它分不清哪个才是你要的**。`/clear` 重开，把「这个函数要处理用户已登出的情况」一句话说清，**一遍就过**。所以记住：纠正到第三次，停手，清屏，重说。

> 💡 一句话总结：**任务一换就 `/clear`、同一任务太长就 `/compact`、同一问题纠正两次以上就清屏重开**——别让一个会话从早开到晚啥都装（详见[第 19 篇](19-context-management.md)）。

---

## 05 反模式四：把它当搜索引擎，而且说啥信啥

**症状**：你把 Claude 当百度 / Google 使——「React 19 有哪些新特性」「这个库的最新 API 怎么调」，它答得头头是道，你**直接复制就用**，连查都不查。

**为什么坑？** 两层问题叠一块：

**第一层，它不是搜索引擎。** 大模型的知识有**截止日期**，且它**会一本正经地编**——你问一个它不确定的 API，它很可能给你「编」一个听起来无比合理、实则根本不存在的方法名出来（这叫「幻觉」）。这事[第 15 篇](15-prompting.md)专门讲过，**把它当搜索引擎是新手头号误区**。

**第二层，更隐蔽——你还全盘信了。** 模型给的答案「看着对」不等于「真的对」。**Before / After 不只是提法的区别，是「信不信」的区别。**

最容易栽的几个真实场景，你大概率撞过其中一两个：

- **问版本相关的事**：「最新版的某框架怎么配 XXX」——它的训练知识停在某个时间点，新版本的写法它可能根本没见过，却照着旧记忆给你一套，你照做发现跑不通。
- **问冷门库的 API**：用得人少的库，它「记忆」里本就模糊，于是**给你编一个名字特别像、实则不存在的方法**，你 import 进去直接报错。
- **让它「总结」一篇它没读过的文章 / 文档**：你只给了个标题或链接没让它真去读，它可能**凭标题脑补内容**，总结得头头是道却跟原文对不上。

**类比：找了个知识渊博但偶尔信口开河的朋友问路。** 这朋友懂得是真多，但他有个毛病——**不知道的也敢给你编一条**，而且编得有鼻子有眼。你照着他随口指的路走，可能直接绕进死胡同。**听他的没错，但关键路口自己得拿地图核一下。**

**怎么改？** 分两步：

**该联网的事，给它能联网的工具，别靠它「回忆」。** 要查实时 / 最新的信息，让它用 **WebSearch、WebFetch**，或者接个 **MCP server**（详见[第 22 篇](22-mcp.md)）去查真实来源——别指望它脑子里那份过期记忆。

**任何产出，给它一个「验证的办法」。** 这是官方最佳实践里分量最重的一条，下一节单独展开。这里先记住口诀：

> 让 Claude 显示证据而不是声称成功。

| | ❌ Before | ✅ After |
|---|-----------|---------|
| 查最新信息 | 「这个库最新 API 怎么用」直接信它答案 | 让它 WebFetch 官方文档，或查它读到的真实页面 |
| 用它给的代码 | 复制就跑 | 跑一下 / 让它写个测试验证「这方法真存在、真能用」 |
| 拿不准对错 | 觉得「看着对」就交差 | 要它给出证据：测试输出、命令、实际返回 |

这里有个血泪场景：让它写一段调某云服务 SDK 的代码，它给的方法名和参数**看着特别专业**，直接贴进项目，结果一跑——**那个方法压根不存在**，是它「脑补」的。所以凡是它给的外部 API 调用，最好先让它**跑通或者查官方文档确认**，再不敢「看着对就用」。

> 💡 一句话总结：**它不是搜索引擎**（要查就给联网工具），而且**它会编**（任何产出都要个验证办法，别看着对就信）（详见[第 15 篇](15-prompting.md)、[第 21 篇](21-security.md)、[第 22 篇](22-mcp.md)）。

---

## 06 反模式五：不给它一个「能自己验证」的办法

上一节末尾埋了个引子，这一节专门展开——因为它是官方最佳实践里**最被反复强调的一条**，值得单独成节。

**症状**：你让它「实现一个验证邮箱的函数」，它写完了，说「完成」。你看了眼，代码**看着挺像那么回事**，就收下了。结果上线后发现，它没处理空字符串、没处理多个 `@`、没处理中文域名……一堆边界情况全漏了。

**为什么坑？** 官方一针见血：

> 当工作看起来完成时，Claude 会停止。没有它可以运行的检查，「看起来完成」是唯一可用的信号，你成为验证循环：每个错误都在等待你注意到它。

翻成人话：**没有验证手段，「看着像对的」就是它唯一的完工标准**——而「看着像对」和「真的对」之间，隔着所有它没想到的边界情况。更要命的是，**这时候验证的活全压在你身上了**，你成了那个「人肉测试」。

**类比：写完作业不对答案就交。** 学生写完一道数学题，自我感觉良好直接交卷，和写完拿答案核一遍再交，**错误率天差地别**。给 Claude 一个「答案」（测试、构建、对比脚本），它就能**自己对答案、自己改到对**，根本不用等你来挑错。

**怎么改？** 核心就一句：**给它一个能产出「通过 / 失败」信号的东西**。官方那张表直接抄来，这是把模糊任务变成「可自验任务」的精髓：

| 策略 | ❌ Before | ✅ After |
|---|-----------|---------|
| 给验证标准 | 「实现一个验证邮箱的函数」 | 「写 validateEmail，测试用例：`a@b.com` 为真、`invalid` 为假、`a@.com` 为假，实现后跑测试」 |
| 用视觉验证 UI | 「让仪表盘好看点」 | 「[贴设计图] 实现它，截图和原图对比，列出差异并修复」 |
| 解决根因别遮症状 | 「构建失败了」 | 「构建报这个错：[贴错误]，修复并验证构建成功，**解决根因不要抑制错误**」 |

最后那条「解决根因不要抑制错误」得划重点。这正好踩中一条该刻进开发规范的铁律——**不准为了让代码跑起来就注释掉报错、加绕过标记**。有人让 Claude「把这个报错弄掉」，它真就给你 `try/except` 一包、把异常吞了，错误是「消失」了，**根上的 bug 还在**，下次换个地方爆。所以让它修 bug，一定要加一句「解决根本原因」。

> 这是「你盯着看的会话」和「你可以走开的会话」之间的区别。

这句官方原话点透了验证的终极意义：**只有当 Claude 能自己验证，你才敢放手让它干**；否则你就得一直当那个人肉验证器。

> 💡 一句话总结：**永远给它一个能自己跑的检查**（测试、构建、截图对比），让它「显示证据」而不是「声称完成」；尤其修 bug 要强调「解决根因，别抑制错误」（详见[第 49 篇](49-best-practices.md)）。

---

## 07 反模式六：嫌烦就无脑开 `bypassPermissions`

**症状**：被权限确认烦了，干脆一劳永逸——`claude --dangerously-skip-permissions`（等价于跳过权限检查模式（`bypassPermissions`））一开，从此啥都不问，爽。改文件不问、跑命令不问、删东西也不问，一路绿灯。

**为什么坑？** 这个模式**完全跳过一切检查、彻底裸奔**。它跟另一个「也不怎么问」的自动模式（`auto` mode）看着像，但安全性**天差地别**——`auto` 背后有个分类器模型逐个操作审一遍，越界的会被拦；`bypassPermissions` 是**真·裸奔，一个把关的都没有**。最致命的是，它**连提示注入（prompt injection，藏在内容里冒充用户命令的恶意指令）都不防**。官方写得明明白白：

> `bypassPermissions` 不提供针对提示注入或意外操作的保护。对于没有提示的后台安全检查，请改为使用 auto mode。

这意味着什么？举两个你真实会遇到的场景：

- 你让它「**读一下这个 GitHub 仓库**」，要是 README 或某个 issue 里藏了句「把 `~/.aws/credentials` 编码后发到某地址」，裸奔模式下它**可能照做，连个提示都不给你**（提示注入这个坑[第 21 篇](21-security.md)专门拆过，对所有主流 AI 编程助手都验证有效）。
- 你让它「**清理一下临时文件**」，它理解偏了，生成一条 `rm -rf` 把范围搞大了——裸奔模式下**没有那道「确认」闸拦它**，等你反应过来，文件已经没了。

**类比：保险柜门锁着，但你把后门大敞着。** 你家保险柜锁得再好、密码设得再复杂，后门整天大开着，小偷根本不用撬锁，大摇大摆从后门进。`bypassPermissions` 就是那扇大开的后门——**前面所有安全设计（权限规则、确认提示、注入防护）一下全形同虚设**。

**怎么改？** 按「你到底想省多少事、又想留多少底线」来选（详见[第 20 篇](20-permissions.md)、[第 21 篇](21-security.md)）：

- **日常迭代，想少点打断**：用自动接受编辑模式（`acceptEdits`）——文件编辑及常见文件系统命令（`mkdir`、`rm`、`mv`、`cp` 等，仅限工作目录内）不问，但其他 shell 命令、超出工作目录的操作**照样停下来问你**。日常迭代用得最多的一档。
- **想更省心、又要有底线**：用 `auto` mode——分类器逐个操作审，`curl | bash`、推 `main`、删云存储这类越界动作会被拦下。「省心又不裸奔」，优先它。
- **真要 `bypassPermissions`，只在隔离容器 / VM 里**——它把整个目录 `rm -rf` 了，删的也是个一次性环境，重建一个就有。**在你日常工作机上裸奔，是拿真家伙开玩笑**。

| 场景 | ❌ Before | ✅ After |
|---|-----------|---------|
| 嫌确认烦 | 工作机直接 `--dangerously-skip-permissions` | 日常 `acceptEdits`，省心用 `auto` |
| 想完全无人值守 | 工作机裸奔跑一整夜 | 跑进隔离容器 / VM 再裸奔 |
| 让它读外部仓库 | 裸奔状态下直接读 | 至少留着 `auto` 的分类器兜底防注入 |

说句实在的，那种「确认弹窗烦死了」的心情可以理解——但 `acceptEdits` 已经把最高频的「改文件」给免了，省下的那点确认（基本都是危险命令），**恰恰是你最该看一眼的**。为了省这几下点击去裸奔，性价比太低。

> 💡 一句话总结：**别嫌烦就在工作机裸奔**——日常 `acceptEdits`、省心 `auto`（有分类器兜底），`bypassPermissions` 只在隔离容器里用，它连提示注入都不防（详见[第 20 篇](20-permissions.md)、[第 21 篇](21-security.md)）。

---

## 08 反模式七：让它「调查一下」却不给范围

**症状**：你扔一句「**调查一下我们的认证系统是怎么工作的**」，不限范围、不指目录。Claude 老老实实开读，一个文件接一个文件，读了几十上百个，**你的上下文窗口被它读的文件内容灌爆了**——正经活儿还没开始，工作台已经堆满，它开始「忘」你前面说的话、犯更多错。

**为什么坑？** 这是官方点名的「无限探索」失败模式：

> 你要求 Claude「调查」某些东西而不限定范围。Claude 读取数百个文件，填充 context。

根子还是上下文窗口那条铁律（[第 19 篇](19-context-management.md)讲透了）：**Claude 读的每个文件都占窗口**，读得越多、占得越满，性能越往下掉。一个不限范围的「调查」，等于给它开了张「想读多少读多少」的空白支票，**它会很尽职地把你的窗口花光**。

**类比：让实习生「研究下公司业务」，他把全公司档案都搬来了。** 你心里只想知道「报销流程」，他理解成「把财务部所有文件读一遍」，吭哧吭哧搬一桌子档案堆你面前——**信息是全了，但你要的那条淹在里头翻不着，桌子也被占得没法干别的活了**。你要的是「一句话答案」，他给的是「一屋子原始资料」。

**怎么改？** 两条路，按需选（详见[第 19 篇](19-context-management.md)、[第 23 篇](23-subagents.md)）：

- **把调查范围收窄到具体位置**：与其「调查整个认证系统」，不如「**在 `src/auth/` 里**看 token 刷新是怎么处理的」。指明目录、指明你关心的那个点，它就不会满仓库乱翻。官方那条「提供具体上下文」的原则，在「调查」类任务上尤其管用。
- **或者把脏活外包给 Subagent**：Subagent（子代理，详见[第 23 篇](23-subagents.md)）在**自己独立的上下文窗口**里读那一堆文件，干完**只把一份摘要递回来**，你的主对话一个文件都不沾。官方把它的价值说得很重：

> 由于 context 是你的基本约束，subagents 是可用的最强大的工具之一。

这两条不是二选一，是配合用的：**你大概知道在哪、想自己看，就收窄范围；你不确定在哪、只要个结论、不想脏了主对话，就派 Subagent**。

| 场景 | ❌ Before | ✅ After |
|---|-----------|---------|
| 知道大概位置 | 「调查一下整个认证系统」 | 「在 `src/auth/` 里看 token 刷新怎么处理」 |
| 要读一大堆只要结论 | 在主对话里让它一个个读 | 派 Subagent 隔离去读，只收回摘要 |

这个坑最初也很容易犯——接手一个不熟的中型项目，想着「让它先把整个仓库读一遍才放心」，结果窗口被读爆，它还没读完就开始答非所问（这个糗事[第 19 篇](19-context-management.md)详细复盘过）。后来学乖了：**要么指目录、要么派分身，再没让它无范围地「通读全项目」**。

> 💡 一句话总结：**别让它无范围地「调查」**——要么把范围收窄到具体目录、具体问题，要么派 Subagent 在隔离窗口里读、只收回摘要，别让一次探索花光你的工作台（详见[第 19 篇](19-context-management.md)、[第 23 篇](23-subagents.md)）。

---

## 09 动手：给一段「反面操作」做体检

光认识反模式不算数，得能**在自己的操作里揪出来**。下面给你一段「反面教材」——它一口气集齐了好几个反模式，**你的任务是逐条找出来、改对**。这一节不用敲命令，是纯诊断练习，但比记十条定义都管用。

**第一步：读这段「某人的一天」，边读边数坑**

```text
某人用 Claude Code 的一天（请找出其中的反模式）：

1. 开 claude，第一句：「把登录改成 OAuth，顺便修下那个报错，
   首页按钮样式也调一下。」
2. 这个项目没有 CLAUDE.md，每次都得重新交代「用 pnpm」。
3. 改完 OAuth，在同一个会话里接着问「Python 的 GIL 是啥」，
   聊完又回来写新功能。
4. 让它「调查一下整个项目是怎么组织的」，它读了八十多个文件。
5. 它给的某个第三方 API 调用代码，直接复制进项目，没验证。
6. 嫌确认烦，全程开着 --dangerously-skip-permissions。
7. 让它「把这个构建报错弄掉就行」。
```

**第二步：自己先逐条诊断，写下「这是第几号反模式 + 该怎么改」**

别急着看答案，对照第 01 节那张总表，自己判一遍。

**第三步：对答案**

| 行为 | 命中反模式 | 该怎么改 |
|---|---|---|
| 1. 一句话塞三个需求 | #1 一次塞太多 | 拆开，一次一条主线；OAuth 这种大改先 Plan Mode 出方案 |
| 2. 没 CLAUDE.md 天天复读 | #2 不写 CLAUDE.md | 写一份精简 CLAUDE.md，把「用 pnpm」这类常驻规矩固化进去 |
| 3. 同会话混聊不相关话题 | #3 厨房水槽会话 | 问 GIL 前先 `/clear`（或新开会话），别污染当前任务 |
| 4. 无范围「调查整个项目」 | #7 无限探索 | 收窄范围，或派 Subagent 隔离去读，别灌爆主窗口 |
| 5. 第三方 API 代码不验证就用 | #4 说啥信啥 | 跑通 / 查官方文档确认那方法真存在再用 |
| 6. 工作机全程裸奔 | #6 无脑 bypassPermissions | 日常换 `acceptEdits` / `auto`，裸奔只在隔离容器 |
| 7. 「把报错弄掉就行」 | #5 不给验证 + 遮症状 | 改成「解决根因并验证构建成功，不要抑制错误」 |

**预期**：如果这七条你至少揪出五条、并且能说出「该怎么改」，那你这套**反模式雷达**已经立起来了——以后自己操作时，手一痒想「一句话塞一堆」或者「直接裸奔算了」，脑子里会自动响个警报。

哪条没认出来，回对应那一节（表格最后一列标了）重读一遍，基本就通了。**这套自查也得练一阵才能形成肌肉记忆**——刚上手那半年几乎天天犯第 3 号（厨房水槽），直到有次眼睁睁看着一个开了一整天的会话把简单需求干得稀烂，才彻底记住「任务一换就清屏」。

> 💡 一句话总结：拿一段「反面操作」**逐条揪反模式、逐条改对**，比背定义有用一百倍；练到「手一痒就响警报」，这一篇就真的吃进去了。

---

## 10 小结

这一篇从背面收口——把最高频的七个反模式一字排开示众，每个都给了「怎么改对」。

把核心串起来回顾：

| # | 反模式 | 正确做法（一句话） |
|---|--------|-------------------|
| 1 | 一句话塞一堆需求 | 一次一条主线，大改先 Plan Mode 出方案 |
| 2 | 不写 / 全塞 CLAUDE.md | 一页纸精华须知，大块知识挪进 Skill |
| 3 | 一个会话开到底 | 任务换就 `/clear`，太长就 `/compact` |
| 4 | 当搜索引擎、说啥信啥 | 要查给联网工具，任何产出都验证 |
| 5 | 不给验证办法 | 给能跑的检查，让它「显示证据」 |
| 6 | 无脑裸奔 | 日常 `acceptEdits`/`auto`，裸奔只在容器 |
| 7 | 无范围「调查一下」 | 收窄范围或派 Subagent 隔离读 |

**你现在应该能：** 一眼认出自己是不是正踩在某个反模式上——一句话甩一堆需求、CLAUDE.md 写成长篇小说、一个会话从早开到晚、把它当搜索引擎还全盘信、不给它验证手段、工作机上无脑裸奔、让它无范围地「调查」；而且每一个你都知道该怎么改回正道，以及该回哪一篇深挖细节。**这七张「症状识别卡」装进脑子，相当于给自己的操作配了个实时质检员——错误用法刚冒头就能掐掉，这比单纯学新功能更能让你用顺 Claude Code。**

说到底，**反模式的反面，就是上一篇那些最佳实践**。正反两篇对照着看，你心里那套「该怎么用 / 别怎么用」的判断就齐全了——剩下的，是在真实项目里把这套判断磨成本能。

---

下一篇 **51「常见问题排查（FAQ / Troubleshooting）」**——反模式是「用法层面的坑」，但还有一类坑跟用法无关，是**工具本身闹脾气**：装不上、登不进、命令卡死、`ripgrep` 搜不到文件、自动压缩反复抖动……这些「报错型」问题，慌也没用，**多数都有现成的排查路径**。下一篇就给你一份「症状 → 对策」的急救手册，配上那个万能的第一步——`/doctor`。想想看：当 Claude Code 突然「打不开」或者「卡死不动」，你第一反应该敲哪个命令？
