《Claude Code 从入门到精通》试读篇：当 Claude 理解错了怎么办（四）

前端达人

发布于 2026-04-02 21:12:02

1510

文章被收录于专栏：前端达人前端达人

阅读时长：约15分钟 · 难度：★★☆☆☆ 适合人群：已经开始用 Director Mode，但偶尔遇到 Claude "做歪了"的开发者学完之后：你能快速判断偏差类型，用最少的轮次把结果修正到位

做好了心理准备，但还是翻车了

《Claude Code 从入门到精通》试读篇：Claude Code 是什么？你可能从第一步就用错了

《Claude Code 从入门到精通》试读篇：你的第一次 Director Mode 体验（二）

你按第03课的模板写了一个很完整的 prompt。四个要素都有，目标清晰，约束明确。

发出去，等了两分钟，Claude 做完了。

你一看——不对。

不是完全不对，是七八成对，但有些地方明显不是你想要的。

这时候大部分人的反应是两种极端：

极端A：算了，我自己来改吧。（放弃 Claude，退回手动模式）

极端B：把整个 prompt 改了重新发，每次都从零开始。（时间全浪费了）

两种都不对。

极端A的问题是：你花了2分钟等 Claude 生成了80分的结果，然后扔掉这80分从零开始手写。那你用 Claude Code 干什么呢？

极端B的问题是：每次从头来，Claude 也从头来，之前做对的部分全部白费。而且你改了 prompt 之后，之前对的地方这次可能又不对了——按下葫芦浮起瓢。

正确的做法是纠错，不是重来，也不是放弃。

纠错是一项独立的能力。prompt 写得好是"进攻能力"，纠错做得好是"防守能力"。这节课教你防守。

先调整一个预期

在讲具体方法之前，先说一个很多人不愿意面对的事实：

Claude 第一次就100%做对，是小概率事件。

不是 Claude 不行，是软件开发本身就是迭代的过程。你跟一个真人同事说"给这个接口加输入验证"，他第一次提交的 PR 你就完全满意、不需要任何修改的概率有多大？

大概率也是要改一两轮的。

区别在于：跟真人同事，你习惯了 code review + 修改这个流程；跟 Claude，你却期望"一步到位"。

放下"一步到位"的执念，接受"80分→纠正→95分"的流程，你的效率反而更高。 因为 Claude 生成80分的代码只要2分钟，你纠正到95分再花5分钟，总共7分钟。你自己从零写到95分，可能要40分钟。

好，心态调好了，讲方法。

三种理解偏差：先判断是哪种

Claude 做出来"不对"，不外乎三种原因。判断是哪种，纠正方式完全不同。

用错了纠正方式，比不纠正更浪费时间。

偏差类型1：方向对了，细节错了

症状：整体思路没问题，代码结构合理，但某些具体实现不符合你的预期。

常见场景：

你让它写分页接口，它用了 OFFSET 分页，但你项目统一用游标分页
你让它写测试，测试逻辑对了，但命名风格跟你团队不一样
你让它加错误处理，逻辑对了，但错误码用的不是你们约定的那套
你让它写 TypeScript，但它给了一些 any 类型，你们项目禁止 any

这种偏差最常见，大约占所有"不对"的 60-70%。也最好修。

纠正方式——追加指令，不要重来：

分页实现改成游标方式，参照 src/modules/user/user.controller.ts
里 getUserList 的分页逻辑。其他部分不动。

关键词是 **"其他部分不动"**。明确告诉 Claude 只改你指出的地方，别动已经对的部分。不说这句，它有时候会"顺便"把你已经满意的代码也重构一遍——然后你又多了一堆东西要检查。

再看一个例子：

你让 Claude 给项目加 Docker 部署配置，它写了 Dockerfile 和 docker-compose.yml。整体没问题，但它把 Node.js 版本写成了 18，而你们项目固定用 20。

❌ 错误的纠正方式（从头来）：
"重新写一个 Dockerfile，Node.js 用 20 版本，然后……"
（你又要重新描述所有需求）

✅ 正确的纠正方式（追加）：
"Dockerfile 里的 Node.js 版本从 18 改成 20，
 基础镜像用 node:20-alpine。其他配置不动。"

原则：方向对、细节错 → 追加指令修细节，说"其他不动"。

偏差类型2：方向就是歪的

症状：整个实现思路跟你想的不一样。不是细节问题，是根本的技术方案或架构选择不对。

常见场景：

你想给现有 REST 接口加权限控制，它新建了一套中间件框架
你想优化数据库查询性能，它把查询逻辑全改成了 Redis 缓存
你想加一个简单的配置开关，它搞了一整套 feature flag 系统
你想修一个 CSS 布局问题，它把你的 Flex 布局全重写成 Grid

这种偏差的根源是 prompt 有歧义。 你说的话有多种理解方式，Claude 选了你不想要的那种。

纠正方式——先叫停，说清楚哪里理解错了，再让它重做：

停一下。我不需要新建中间件框架。

我的意思是：在现有的路由配置里，用我们已有的 authGuard
给这几个接口加上角色校验。

具体来说：
- /api/admin/* 下的接口需要 admin 角色
- /api/manager/* 下的接口需要 manager 或 admin 角色
- 其他接口保持现状

不要改现有的中间件结构，只在路由层加 guard。

注意这个纠正 prompt 的四步结构：

先否定错误方向："我不需要新建中间件框架"——让 Claude 明确知道上一个方案被否决了
再给出正确方向："在现有路由配置里用 authGuard"——给它一个新的起点
补充具体细节：路由规则——上一轮 prompt 里可能就是缺了这些才导致歧义
加约束堵死老路："不要改现有中间件结构"——防止它又往那个方向走

再看一个例子：

你让 Claude 优化一个列表页的加载速度，它直接把整个页面改成了 SSR（服务端渲染）。技术上确实能解决问题，但你的项目是纯前端 SPA，根本没有 SSR 的基础设施。

停一下。项目是纯前端 SPA，不能引入 SSR。

优化方向改为：
1. 列表数据做分页加载，首屏只请求第一页
2. 图片做懒加载
3. 列表组件用虚拟滚动（项目已有 react-virtualized 依赖）

不要改项目的渲染架构。

原则：方向歪了 → 不要在错误方向上修修补补，直接否定+纠正+补信息。

偏差类型2的关键心法：不要试图把歪的方案"修正"成对的方案。一个用错了架构的实现，你逐行去改，改到最后可能比从头写还费劲。果断叫停，从正确的方向重新来，反而更快。

偏差类型3：做了你没让它做的事

症状：你要的它做了，但它还"顺手"做了一堆你没要求的事情。

常见场景：

你让它加一个字段，它顺手重命名了三个现有字段——"帮你优化命名"
你让它修一个 Bug，它顺手改了旁边函数的代码风格
你让它写一个工具函数，它顺手把项目里其他地方用到类似逻辑的代码也全替换了
你让它加个接口，它顺手帮你"升级"了 Express 的版本

这不是理解错了，是过度发挥。 Claude 看到了可以"优化"的地方，就主动动手了。出发点是好的，但在你没有预期的情况下，这些改动会带来风险——尤其是那些它觉得"顺手"的重命名和重构，很可能影响到你没有关注的其他模块。

纠正方式——撤回多余改动 + 以后在约束里预防：

撤回对 username 和 phone 字段的重命名，
那两个字段不需要改，外部有很多地方在引用。

只保留新增 last_login_at 字段的改动。

然后在以后的 prompt 里养成一个习惯——**在约束条件里加一句"不要修改本次需求范围外的代码"**。

这句话能砍掉 Claude 80% 的过度发挥。如果你想更严格，可以写"严格只修改我指定的文件和函数，其他文件不要动"。

原则：做多了 → 明确撤回多余部分，然后在约束里加"只改我说的"。

快速判断流程图

遇到结果不对，用这个流程3秒做判断：

Claude 的输出不对
     │
     ├─ 整体思路和方案选择是对的？
     │      │
     │      ├─ 是 → 偏差类型1（细节错了）
     │      │       → 追加指令改细节，说"其他不动"
     │      │
     │      └─ 不是 → 方案完全跑偏了？
     │              │
     │              ├─ 是 → 偏差类型2（方向歪了）
     │              │       → 叫停，否定旧方向，给新方向
     │              │
     │              └─ 方案是对的，但多做了你没要的
     │                      → 偏差类型3（过度发挥）
     │                      → 撤回多余改动，下次加约束
     │
     └─ 完全看不懂它在做什么 / 代码根本跑不起来
            → 大概率是 prompt 太模糊了
            → 回到第03课，用四要素重写 prompt

建议把这个流程图截图保存。前两周你可能需要对着它走，两周后就变成条件反射了。

什么时候该修，什么时候该重来

上面三种偏差都是"可以修"的。但有些时候，修不如重来。

怎么判断？看两个信号。

重新开始的信号

信号1：连续纠正3轮以上，结果还是不对。

如果你追加了3轮指令，问题不但没解决还越改越乱，说明第一轮的基础就是歪的。后续所有的纠正都是在一个歪的地基上盖楼。这时候果断开一个新对话，用你在纠正过程中获得的认知重新写一个更好的 prompt。

信号2：Claude 创建了大量你不需要的文件和目录。

如果它按照自己理解的架构创建了一堆新文件，你想把它拉回到现有架构上，难度跟推倒重来差不多。特别是当这些新文件之间有复杂的引用关系时——你删一个文件，其他文件的 import 全挂了。

信号3：你自己的需求在纠正过程中变了。

做着做着你发现"其实我不想要这个功能了，我想要另一个"。这种情况下，之前的代码就是包袱，不要试图改造它，直接从新的需求出发。

追加指令的信号

整体方向对，只是局部细节需要调整
已经生成了大量代码，重来成本明显高于修补
你能用一两句话说清楚要改什么
每一轮纠正之后，结果确实在变好（不是在原地打转）

记住一个数字：3轮。 3轮以内能修好的，就追加。3轮还修不好的，强烈建议重来。

完整纠错链案例：3轮从翻车到上线

看一个真实的纠错全过程。不是一帆风顺的成功故事，是一路修正最终做对的完整链路。

任务：给内容管理后台加批量操作功能

第1轮——Director Mode prompt

给后台的文章列表页加批量操作功能：
批量删除、批量上架、批量下架。
要有全选和反选，操作前要有确认弹窗。

Claude 的输出：做了一个完整的前端组件，包含全选/反选、确认弹窗、三种操作按钮和 API 调用。功能完整，代码能运行。

我的检查：打开代码看了看——

问题1：它直接在组件里用 fetch() 写了 API 调用。但我们项目统一走 service 层，所有接口调用在 src/services/ 下管理，组件里只调 service 方法。

问题2：确认弹窗用的是 window.confirm。我们项目有自己的 Modal 组件，UI 风格统一，window.confirm 太丑了，跟后台其他弹窗不一致。

判断：偏差类型1——方向对、细节错。两个细节都是"没遵循项目规范"，追加指令就行。

第2轮——追加纠正

两个地方需要改：

1. API 调用不要直接写在组件里，
   移到 src/services/article.service.ts 里，
   参照 userService 的写法（导出异步方法，组件里只调用 service）

2. 确认弹窗用项目里的 Modal 组件（src/components/Modal），
   不用 window.confirm。Modal 的使用方式参照
   src/pages/user/UserList.tsx 里删除用户时的弹窗。

其他部分保持不动。

Claude 的输出：改好了。API 抽到了 service 层，弹窗换成了 Modal 组件，其他代码没动。

再检查一遍：又发现一个新问题。

问题3：批量删除的接口调用，它设计成了循环逐条调用 DELETE /api/articles/:id。如果选中了100篇文章，就发100个请求。这在网络上和服务端都扛不住。

这个问题第1轮我没注意到，因为它藏在 service 方法的实现里。

判断：还是偏差类型1。方向没问题，就是接口设计不合理。

第3轮——继续追加

批量操作的接口改成一次性提交，不要逐条调用。

后端已有批量接口 POST /api/articles/batch，
请求体格式是 { action: 'delete' | 'publish' | 'unpublish', ids: string[] }。

把三个操作都改成调用这个接口，一次请求传所有选中的文章 ID。

Claude 的输出：改成了统一的批量接口调用。三个操作都走 /api/articles/batch，只是 action 参数不同。

最终检查：

✅ 全选/反选逻辑正确
✅ 确认弹窗用的 Modal 组件，风格一致
✅ API 调用在 service 层，组件只调 service
✅ 批量操作走统一接口，一次请求
✅ 代码风格跟项目一致

可以提 PR 了。

复盘这个纠错链

第1轮：Director Mode prompt → 拿到 80 分的结果
第2轮：纠正 2 个细节（代码组织 + UI 组件） → 提升到 90 分
第3轮：纠正 1 个接口设计问题 → 提升到 95 分
总对话轮数：3 轮
总耗时：约 8 分钟

几个关键经验：

每一轮的纠正都是精准的——不是"这不对，重新做"，而是"这里不对，按这个标准改，其他不动"。每句话都有信息量。

没有重新开始——虽然修了3轮，但每一轮的改动范围都很小，总体代码在持续变好。因为整体方向从第1轮就是对的，不需要推倒。

每一轮暴露的问题都是你"忘了说"的规范——第1轮你忘了提 service 层规范和 Modal 组件，第3轮你忘了提批量接口的设计。这些"忘了"不是你的错，是因为这些规范"活在你的脑子里"，你觉得理所当然，但 Claude 不知道。

核心教训：这些反复出现的"忘了说的规范"，不应该每次都用人脑记住。它们应该被写进一个地方，让 Claude 每次自动读取。

这个地方就是 CLAUDE.md——第08课的主题。到了那一课，你会学到怎么把项目的所有规范固化成一个文件，彻底终结"忘了提"导致的返工循环。

六个纠错常用句式

给你6句直接能用的纠错模板，覆盖90%的纠正场景：

🔧 细节修正（类型1）：
"[具体哪里]改成[具体怎样]，参照[项目中哪个文件]的写法。其他不动。"

🔧 多处细节（类型1）：
"以下N个地方需要改：1. …… 2. …… 其他部分保持不动。"

🛑 方向纠正（类型2）：
"停一下。我不需要[它做的方案]。我的意思是[你要的方案]。不要改[要保护的部分]。"

🛑 方向纠正+补信息（类型2）：
"方向不对。不要[错误方向]，改成[正确方向]。补充一下背景：[它缺少的上下文]。"

↩️ 撤回多余（类型3）：
"撤回对[具体内容]的修改，那部分不需要改。只保留[你要的改动]。"

↩️ 预防过度发挥（约束句）：
"严格只修改我指定的文件和函数，不要改动需求范围外的任何代码。"

课后实操：故意翻车一次

这次的练习跟前几课不一样——我要你故意写一个不完整的 prompt，然后练习纠错。

步骤

1. 写一个故意缺信息的 prompt

在你的项目里找一个你熟悉的模块，写一个只有目标、没有上下文和约束的 prompt。比如：

给用户模块加一个导出功能

就这一句，发出去。

2. 观察 Claude 的输出

它一定会做出来，但大概率有你不满意的地方。拿出纸笔（或者开个备忘录），记下来：

哪些地方做对了？（先肯定好的部分）
哪些地方不是你想要的？
每个"不对"的地方属于哪种偏差类型？

3. 用今天学的方法纠正

类型1（细节错了）→ 追加指令，用纠错句式模板
类型2（方向歪了）→ 叫停、纠正方向、补信息
类型3（做多了）→ 撤回多余部分

4. 复盘

纠正完之后，问自己两个问题：

你用了几轮才达到满意的结果？
每一轮纠正时"忘了说"的那些信息，下次写 prompt 能不能一开始就写上？

这个练习的意义不是教你写烂 prompt——而是让你建立对偏差类型的直觉判断。 以后 Claude 做出来不对，你能一秒钟分类，然后用最高效的方式纠正，不浪费一句话。

🎓 地基篇完结：你已经超过了 80% 的用户

到这里，地基篇4课全部学完了。我们回顾一下你学到了什么：

第01课 → 你知道了 Claude Code 的真实定位（不是键盘，是团队）
第02课 → 你亲手体验了 Director Mode 的效率差距
第03课 → 你掌握了四要素 Prompt 框架（目标+上下文+质量标准+约束）
第04课 → 你学会了纠错的完整方法论（三种偏差类型+判断流程）

如果你认真做了每课的课后实操，你现在已经能独立用 Director Mode 完成日常开发任务了。

这件事本身就已经让你超过了 80% 的 Claude Code 用户——他们还停留在一步步给指令的操作者模式里。

但说实话——地基篇只是"能用"的水平。

🚀 核心技能篇预告：从"能用"到"用得好"

接下来的5课，是整个合集信息密度最高、实战价值最大的部分。

第05课：目标优于指令——Director Mode 第一支柱

为什么"告诉 Claude 你要什么"比"告诉它怎么做"效果好3倍？不是玄学，是有具体原因的。这节课用5个完整的开发场景，逐字演示怎么把"指令型 prompt"改写成"目标型 prompt"——功能开发、Bug修复、代码重构、安全审查、性能优化，每个场景都给你改写前后的完整对比和效果差异。

第06课：让 Claude 自己分配任务——并行 Agent 策略

这是 Director Mode 最强大的能力——让 Claude 同时做5件事。但不是所有任务都能并行。这节课给你一个判断工具：什么任务能并行、什么不能、部分并行怎么处理。学完之后，你一个人的产出效率可以接近一个3人小组。

第07课：结果验证——你最不能省的一步

"Claude 写的代码看起来没问题"和"Claude 写的代码确实没问题"之间，隔着一套验证流程。安全漏洞、边界情况、性能隐患、代码风格——这节课给你一份验收清单，以及怎么在 prompt 里就内置验证要求，让 Claude 在写完之后自己先验一遍。

第08课：CLAUDE.md——让 Claude 永远记住你的规矩

还记得你在第04课（本课）的纠错案例里"忘了说"的那些规范吗？service 层规范、Modal 组件、批量接口格式……这些"每次都要重复告诉 Claude"的东西，全部写进一个 CLAUDE.md 文件，Claude 每次启动自动读取。这节课给你一份完整的 CLAUDE.md 模板和3个行业变体（前端项目/后端API/全栈应用），拿过去改改就能用。

第09课：10个高频场景 Prompt 模板库

这是整个合集最"拿来即用"的一课。10个开发者最常遇到的场景——新功能开发、Bug修复、代码重构、写测试、安全审查、性能优化、API设计、数据库变更、文档生成、代码迁移——每个场景一个经过打磨的 prompt 模板。你只需要把里面的项目名、文件路径、业务细节替换成你自己的，直接发给 Claude 就能用。

地基篇教你"怎么开始"，核心技能篇教你"怎么做好"。

如果说地基篇让你的效率从1x变成了2x，核心技能篇的目标是让你变成5x。

不夸张——当你掌握了并行策略、验证流程、项目规范固化和场景化模板之后，你一个人能稳定输出以前3-5个人的工作量。这不是理论推演，是后面每一课都会用真实案例证明的。

核心技能篇即将发布，敬请关注。