49 · 最佳实践:把零散的好习惯,攒成一套能照着做的心法
「这 prompt 写得太省了。」
设想一个刚上手 Claude Code 的人,敲了句「修一下登录的 bug」就回车,等了半天 Claude 改出来一坨他根本没想要的东西,一脸委屈:「我说得还不够清楚吗?」
可你要是把这话甩给一个今天第一天来、还没摸过这个项目的实习生,他能修对吗?哪个登录?什么 bug?在哪个文件?怎么算修好了?——你一样没说。换个写法重来一版:「用户报告 session 超时后再登录会失败,先去 src/auth/ 看 token 刷新那段,写个能复现的测试,再让它过。」这回 Claude 一把就修对了。
说白了,Claude Code 用得好不好,八成不在工具本身,在你怎么跟它配合。它能力很强,但它不会读心。这一篇把官方《最佳实践》那套,加上老用户长期攒下来的经验,归成几条你今天就能照着改的法则。
看完这一篇,你会拿到:
- 一条贯穿全文的总约束(上下文窗口是最金贵的资源),理解了它,下面所有法则就都顺了
- 五条核心法则:给验证手段、先探索再编程、把话说具体、CLAUDE.md 写精、及时纠偏
- 好几张「❌ 坏做法 vs ✅ 好做法」对照表,照着改 prompt 立竿见影
- 一份「这个场景该用哪条法则」的速查,外加一个能亲手跑的对比实验
01 一条总约束:上下文窗口是你最金贵的资源
所有最佳实践,几乎都能追到同一条根上。官方开篇就把它点破了,我先原样抄给你:
大多数最佳实践都基于一个约束:Claude 的 context window 填充速度很快,随着填充,性能会下降。
上下文窗口(context window,即 Claude 一次能「装在脑子里」的全部信息)装着你整段对话——每条消息、它读过的每个文件、每条命令的输出,全在里头。问题是它会很快塞满:一次稍微深点的调试,或者让它把代码库翻一遍,轻松就吞掉几万个 token(第 19 篇讲过 token 和上下文窗口是什么,这里不展开)。
而一旦塞满,Claude 就开始变笨——忘掉你早先的交代、犯更多低级错。
类比:带一个新来的实习生上手项目。 这个实习生绝顶聪明、手脚麻利,但有个怪毛病:他的脑子是张固定大小的白板,你交代的事、他翻过的资料、跑过的命令结果,全得写在这张白板上。白板写满了,他就开始顾此失彼——你早上叮嘱的「提交前先跑测试」,到下午他就忘了,因为那行字早被后面一堆东西挤掉了。
这个比喻这一篇我会反复用——因为后面几乎每条法则,本质都是在帮这个实习生「省着用他的白板」:
- 让他能自己验收,你就不用每一步都盯着看(省你的时间,也省得反复来回污染白板);
- 让他先摸清再动手,就不会白板写满了才发现方向错了;
- 把话一次说具体,就省掉来回追问那几轮消耗;
- 给他的常驻便签写精,白板开局就不会先被废话占走一截;
- 一跑偏立刻拽回来,别等白板被一串错误方法塞爆。
记住这条总约束,下面前五条法则你会发现它们其实是一家人——全在「替单个实习生省白板」。等你把一个实习生使唤利索了,最后还有第六条:多招几个实习生横向铺开,那是后话。
💡 一句话总结:Claude 的上下文窗口会很快填满、填满就变笨,它是你最金贵的资源;这一篇所有法则,归根结底都是在教你「替那个聪明实习生省着用他的白板」。
02 法则一:给它一个能自己验收的方式
先上结论,这条是我心里最重要的一条:
给 Claude 一个它能自己跑的检查——测试、构建、截图比对。这是「你得盯着的会话」和「你能走开的会话」之间的分水岭。
为啥这么关键?官方那句话戳中了要害:
当工作看起来完成时,Claude 会停止。没有它可以运行的检查,「看起来完成」是唯一可用的信号,你成为验证循环。
翻成人话:你要是不给它验收标准,那个「验收」就只能你自己来——它每犯一个错,都得等你火眼金睛发现。你从「派活的人」沦落成「质检员」,每一步都得盯。但你只要给它一个能产出「过 / 不过」信号的东西,这个循环就自动闭合了:它干完活、自己跑检查、读结果、不对就接着改,直到检查通过。
类比:装修队交工前那道验收。 你请人装修,最怕的就是工人「凭感觉觉得弄好了」就收工——瓷砖贴歪了、插座不通电,他自己看不出来,全等你入住才发现。但你要是开工前就甩给他一张验收清单(「每个插座插电笔测一遍亮不亮、每块砖拿靠尺量平不平」),他就能自己一项项核对、不合格自己返工,交到你手上的是已经验过的活。「能自己跑的检查」就是你递给 Claude 的那张验收清单。
什么东西能当这张清单?官方给了一串,全是能返回「Claude 在对话里读得到的信号」的东西:
- 测试套件(最常用,跑完直接告诉它过没过)
- 构建的退出码(编译过不过)
- linter(代码规范检查)
- 拿输出跟固定基准比对的脚本
- 跟设计稿比对的浏览器截图(第 17 篇讲的贴图复刻 UI,就能这么验)
最实用的是怎么把它写进 prompt。官方这张对照表,我建议你直接收藏:
| 场景 | ❌ 没给验收 | ✅ 给了验收 |
|---|---|---|
| 写函数 | 「实现一个验证邮箱的函数」 | 「写个 validateEmail 函数。示例用例:user@example.com 为真、invalid 为假、user@.com 为假。实现后跑测试」 |
| 改 UI | 「让仪表盘好看点」 | 「[贴截图] 照这个设计实现。做完截图跟原设计比对,列出差异再修」 |
| 修构建 | 「构建失败了」 | 「构建报这个错:[贴错误]。修好并验证构建成功。解决根因,别把错误压下去」 |
看出门道了吗?左边那列,Claude 干完只能「觉得」自己对了;右边每一条结尾都挂了个它能自己跑、能读到结果的检查。
检查还能分约束力的档位,看你要它管多严——这点官方讲得很细,我归成一句给你:
| 约束力 | 怎么挂 | 适合 |
|---|---|---|
| 本次提示内 | prompt 里直接写「跑测试并迭代到通过」 | 今天手头随便哪个任务,最轻量 |
| 整个会话 | 设成 /goal 条件,每轮自动重检直到成立 | 要它持续盯着一个目标别跑偏 |
| 确定性闸门 | 写个 Stop hook,检查不过就不让它收工 | 无人值守时强制把关(第 33 篇讲 hook) |
新手用最上面那档就够了——prompt 结尾加一句「做完跑测试并验证」,立竿见影。后两档是等你要让 Claude「没人盯着也能正确收工」时再上的重武器。
这里还得提一句官方反复强调的「解决根因,别压症状」——这恰好撞上调试里那条铁律:别为了让代码跑起来就把报错注释掉、或加个绕过标记蒙混过去。一个典型的翻车场景是:构建报个 type 错误,图快让它「先让构建过」,结果它真的把那行类型断言成了 any,错误是没了,bug 埋更深了。稳妥的做法是 prompt 里永远带一句「修复根本原因,不要把错误压下去」。
还有个加分动作:让它把证据亮出来,而不是嘴上说「成功了」。
让 Claude 显示证据而不是声称成功:测试输出、它运行的命令及其返回的内容,或结果的屏幕截图。
你审一眼它贴出来的测试输出,比你自己重新跑一遍快得多——而且对于你没盯着的会话,这是唯一能信的东西。
💡 一句话总结:给 Claude 一个能自己跑的检查(测试 / 构建 / 截图比对),它就能自我验收、不对自己返工;prompt 结尾挂一句「做完跑测试并验证」,你就从质检员变回派活的人。
03 法则二:先探索,再规划,最后才编程
第二条法则,专治「方向跑偏」。
让 Claude 上来就闷头写代码,很容易写出一坨「解决了错误问题」的东西。把「摸清楚 + 定方案」和「动手实现」分开。
官方推荐的工作流分四步,我用上面那个实习生的比方串一遍你就懂了:

这张图是官方那套四阶段工作流:左边两步「想清楚」、右边两步「干出来」,中间那道竖线(退出 Plan Mode)就是从「动脑」切到「动手」的开关。
为啥探索和实现要分开? 你想啊——你不会让一个第一天来的实习生连项目都没翻过就直接上手改核心模块。你会先让他读代码、问问题、把现状摸清(这就是「探索」),再让他说说打算怎么改(这就是「规划」),你点头了他再动手。Claude 也一样,Plan Mode(计划模式,只读不改、专门用来摸清现状和定方案的模式,第 35 篇细讲)就是干这个的。
探索阶段,你在 Plan Mode 里这么使唤它(官方示例的意思):
读一下 src/auth 目录,搞清楚我们怎么处理 session 和登录。
顺便看看 secret 这类环境变量是怎么管的。
它只读不改,读完回答你。摸清了再让它出方案:
我想加 Google OAuth。哪些文件要改?session 流程是怎样的?给我一份计划。
方案出来你觉得不对,按 Ctrl+G 能直接在文本编辑器里改这份计划,改完它接着往下走。满意了,切出 Plan Mode 让它照方案实现——别忘了第一条法则,让它顺手把验证也做了。
但官方也老实提醒了:Plan Mode 不是万能的,它有开销。
对于范围明确且修复很小的任务(如修复拼写错误、添加日志行或重命名变量),要求 Claude 直接执行。
官方给了一句特别好用的判断口诀,平时拿它做决定就够:
如果你能用一句话描述这个 diff,就跳过计划。
改个拼写、加行日志、重命名变量——这种你一句话说得清的,直接让它干,套 Plan Mode 纯属脱裤子放屁。反过来,方法没想好、要动好几个文件、或者你对这块代码不熟——这三种情况,老老实实先规划。一条好用的分界线:碰一个没读过的模块,或者预感要连带改三个以上文件,一律先进 Plan Mode;剩下的直接上。
💡 一句话总结:方法没把握、要改多个文件、对代码不熟,就先 Plan Mode 探索 + 规划再动手;一句话能说清的 diff,直接干——官方那句「能一句话描述 diff 就跳过计划」是最好用的分界线。
04 法则三:把话说具体——你越精确,要返工的越少
这条是开头那个故事的正主。一句话:
你的指令越精确,需要的更正就越少。 Claude 能推断意图,但它不会读心。
引用具体文件、点明约束、指出参照的例子——这三招就能让 prompt 的质量上一个台阶。官方这张对照表是全篇的精华,我逐条带你品(第 15 篇讲过提问的通用心法,这里专挑「具体」这一点往死里抠):
| 招式 | ❌ 模糊 | ✅ 具体 |
|---|---|---|
| 限定范围:哪个文件、什么场景、测试偏好 | 「给 foo.py 加测试」 | 「给 foo.py 写测试,覆盖用户已登出的边界情况,别用 mock」 |
| 指向来源:把它导到能回答问题的地方 | 「ExecutionFactory 这 api 咋这么怪?」 | 「看 ExecutionFactory 的 git 历史,总结它的 api 是怎么演变成这样的」 |
| 参照现有模式:指出代码库里的范例 | 「加个日历组件」 | 「看主页现有组件怎么写的,HotDogWidget.php 是个好例子。照这个模式实现一个日历组件,能选月份、能前后翻年。别引新库」 |
| 描述症状:给现象 + 大概位置 + 「修好」长啥样 | 「修登录错误」 | 「用户反馈 session 超时后登录失败。查 src/auth/ 的认证流程,特别是 token 刷新。先写个失败测试复现,再修」 |
看出右边那列的共性没有?全在做减法之外的加法——加了文件名、加了边界情况、加了参照例子、加了「修好的样子」。这就是开头那条重写后的 prompt 为啥一把就对:把「修登录 bug」这种模糊话,按最后一行那个模板重写成了带文件、带症状、带验收的具体指令。
最受用的是第三招「参照现有模式」。我自己就在这上面栽过——有回图省事直接甩了句「加个导出 CSV 的功能」,它确实给我整出来了,但用了套跟项目里已有导出逻辑完全不搭的新写法,还顺手引了个我根本没用过的库,对齐返工磨了我大半个下午。后来学乖了,换成一句模板就好办了——「先看 XXX.ts 里现有的导出是怎么做的,照那个模式来,别引新库」。就加这么半句,它写出来的代码风格、用的工具函数全跟项目对齐,基本不用返工。指一个现成的好例子给它,胜过你描述十句「我想要的风格」。
不过官方留了个有意思的例外,值得你知道:
当你在探索并能够改正方向时,模糊的提示可能很有用。
像「你会怎么改进这个文件?」这种故意开放的问法,反而能抖出一些你压根想不到要问的东西。接手陌生代码时这招特别好用——先扔个模糊问题让它自由发挥,看它冒出什么,再据此收紧。所以「具体」是默认档,「模糊」是探索时的特殊档,别一根筋。
配套动作:把「料」喂足
光说得具体还不够,该塞给它的资料得塞够。官方给了几个喂料的招,第 17 篇详细讲过多模态,这里汇总成一张速查:
- 用
@引用文件,而不是干巴巴描述「那个文件在哪儿哪儿」。打@它会跳出文件名让你选,它读完再回答。 - 直接粘贴图片:截图、设计稿、报错的图,复制粘贴或拖进去就行(去看医生别光靠嘴说、拍张片子给医生——这事第 17 篇的比方很贴切)。
- 给 URL:文档、API 参考的网址直接贴。常用的域名可以用
/permissions加进白名单免得每次问。 - 管道灌数据:
cat error.log | claude直接把文件内容怼进去。 - 让它自己去取:告诉它「用 bash 命令 / MCP 工具去把你要的上下文拉过来」,它会自己动手。
💡 一句话总结:默认把话说到「换个实习生也能照做」的具体程度——点文件、限场景、给参照、说清「修好的样子」;要喂的资料用
@、贴图、URL、管道一次给足;只在「想让它自由发挥探出新东西」时才故意模糊。
05 法则四:CLAUDE.md 要写精,不是写多
CLAUDE.md 怎么写得好,是「最佳实践」绕不开的一条。第 18 篇已经把它的语法、放哪、怎么生成讲透了,这一节只补一个最容易被新手忽略、却最致命的点:精,比全重要一万倍。
先记住 CLAUDE.md 是啥——Claude 每次开新对话都会自动读的那个文件,里头放它没法从代码里猜到的持久背景(构建命令、代码风格、工作流规矩)。/init 能帮你生成一份起步的(第 12 篇讲过)。
类比:留给值班同事的便签。 你下班前给接班的同事留张便签,写「服务器半夜会自动重启,别慌」「客户 A 的邮件优先回」——写三五条关键的,他扫一眼就记住了。可你要是把整本运维手册抄上去、密密麻麻贴满一墙,结果就是他一条都不会认真看,你真正想强调的那两句反而被淹了。CLAUDE.md 就是这张便签:它的价值在「短到每条都被看见」,不在「全」。
这不是我瞎说,官方把这条几乎是吼出来的:
保持简洁。对于每一行,问自己:「删除这个会导致 Claude 犯错吗?」如果不会,删除它。膨胀的 CLAUDE.md 文件会导致 Claude 忽略你的实际指令!
这条踩坑的方式通常有两种。第一种是贪心地把一大段「这个项目为什么这么设计」的来龙去脉写进 CLAUDE.md,想着「让它充分理解背景」,洋洋洒洒小一百行。结果它经常抓不住你真正强调的那几条硬规矩(比如「禁止改数据库迁移文件」),全被那堆背景叙事淹了——背景它本来读代码就能懂,根本不该占便签的位置。第二种更直接:有份只有偶尔写某类接口时才用得上的规范,图省事也塞进了 CLAUDE.md,相当于每次开会都把一份「平时八竿子打不着」的资料强塞进白板。这两块都该按官方的话办——背景叙事直接删(它读代码自会懂),偶尔才用的规范挪进 Skill(第 26 篇);CLAUDE.md 瘦下来之后,它对那几条核心规矩的遵守会肉眼可见地变好。
到底什么该写、什么该删?官方这张表是金标准,我建议你拿它逐行审一遍自己的 CLAUDE.md:
| ✅ 该写进去 | ❌ 不该写 |
|---|---|
| Claude 猜不到的 bash 命令 | 它读代码就能搞清的任何东西 |
| 跟默认不一样的代码风格规则 | 它早就懂的标准语言约定 |
| 测试指令、你偏好的测试运行器 | 详细的 API 文档(改成贴链接) |
| 仓库规矩(分支命名、PR 约定) | 经常变的信息 |
| 你项目特有的架构决策 | 长篇解释或教程 |
| 开发环境的怪癖(必需的环境变量) | 「写干净的代码」这种不言自明的废话 |
| 常见的坑、反直觉的行为 | 逐个文件描述代码库 |
右边那列的共性就一句:凡是 Claude 自己能想明白的、或者会过时的、或者属于「正确的废话」,全删。
官方还教了两个进阶手法,顺带提一句:
- 想让某条规矩更被当回事,可以加
IMPORTANT或YOU MUST这种强调词(你看本教程项目自己的 CLAUDE.md 里就用了「IMPORTANT」)。 - CLAUDE.md 支持用
@路径语法引入别的文件,比如Git workflow: @docs/git-instructions.md,把细则拆出去、主文件保持清爽。
最后官方给了条「反向诊断」,特别实用:如果你三令五申某条规矩它还是不听,文件多半太长了,规则被噪音淹了;如果它问你 CLAUDE.md 里明明写了的事,那条措辞多半不清楚。 把 CLAUDE.md 当代码养——出问题就回去审它、定期修剪、改完观察它行为有没有真变。
💡 一句话总结:CLAUDE.md 的命脉是「精」不是「全」——每行都拿「删了它 Claude 会犯错吗?」过一遍,不会就删;详细文档贴链接、有时才用的知识挪进 Skill,让那张便签短到每条都被看见。
06 法则五:一跑偏就立刻拽回来,别硬熬
最后一条法则,关乎你怎么经营一段会话。核心就一句:
一发现 Claude 跑偏,立刻纠正它,别等它越走越远。 对话是可逆的——用好这一点。
最好的结果都来自紧密的反馈循环。Claude 有时一次就完美解决,但更多时候,快速拽它一把,比让它在错路上跑完再推倒重来,要快得多。官方给了一套「拽回来」的工具,配上常见的用法:
| 你想干啥 | 怎么做 | 我的用法 |
|---|---|---|
| 中途喊停 | 按 Esc,上下文保留,可以重新指方向 | 一看它读错文件了立刻 Esc,省得它顺着错的往下跑 |
| 倒带到之前 | 按两下 Esc 或 /rewind,恢复对话 / 代码状态 | 它把代码改乱了,/rewind 回到上一个干净点(第 37 篇细讲检查点) |
| 撤销刚才那步 | 直接说「撤销那个改动」 | 比手动改回去快 |
| 不相关任务之间重置 | /clear 清空上下文 | 修完 bug 要去写新功能,先 /clear |
这里有条老用户都认、新手最该听的铁律,官方说得斩钉截铁:
如果你在一个会话里对同一个问题纠正了 Claude 两次以上,context 就被失败的方法污染了。 运行
/clear,用一个更具体的、包含你刚学到的东西的提示重新开始。
翻成大白话:纠正第三次还不对,别再纠正第四次了。这时候你的白板上已经堆满了「试过 A 不行、试过 B 也不行」的垃圾,Claude 被这些噪音带着越走越偏。正确动作是 /clear 推倒重来——但这次开局的 prompt 里,把你这几轮折腾学到的东西写进去(「别走 X 方案、问题根源在 Y」)。
干净的会话 + 更好的提示,几乎总是优于冗长的会话 + 一堆累积的更正。
这条我是吃过亏才信的。有阵子跟它死磕一个状态管理的 bug,一轮轮纠正下去,纠了得有五六次,越改越乱,最后那版代码连我自己都看不懂了,还在那儿犟着不肯重开。后来一咬牙 /rewind 回最初状态、/clear,重开一个会话,把「这 bug 跟组件卸载时的异步回调有关,别动渲染逻辑」一次性说清——新会话两轮就修好了,前面那一下午全是白耗。打那以后我给自己定了条硬规矩:同一个问题纠正满三次,无条件 /clear 重开。
顺带两个「经营会话」的好习惯
这条法则底下,还挂着两个官方推荐、能让你白板更干净的习惯(都呼应第 19 篇的上下文管理):
- 派 subagent 去做调查:让它「用 subagent 去查 X」。它在自己独立的白板上翻一堆文件,只把结论递回你的主对话,你的白板一点不沾(第 23 篇细讲)。官方原话——「由于 context 是你的基本约束,subagents 是可用的最强大的工具之一」。
- 给会话起名、之后能续上:
claude --continue接最近一次会话,claude --resume从列表里挑。给会话起个像oauth-migration这样的描述性名字,像对待 git 分支一样对待它们,下次直接找回来接着干。
💡 一句话总结:一跑偏立刻
Esc停 //rewind倒带 / 说「撤销那个」;同一问题纠正满三次,无条件/clear带着教训重开——干净会话 + 好 prompt 永远赢过长会话 + 一堆更正。调查的脏活派给 subagent,别脏了主白板。
07 法则六:一个 Claude 用顺了,再考虑横向铺开
前五条都默认「一个你、一个 Claude、一段对话」。但你把单个 Claude 用顺之后,官方还有一整套「横向扩展」的玩法能让产出翻几倍。这一节只给你建个印象、点几个最值钱的,具体操作分散在第 41 篇(并行任务)和第 44 篇(GitHub Actions)里。
先把一个 Claude 用对,再谈并行。 顺序别反——一个都指挥不利索,开五个只会乱五倍。
官方点了几个最常用的扩展姿势:
- 多开几个会话并行干:几个互不依赖的活儿,开多个会话各干各的。最稳的隔离办法是 worktree(每个会话在独立的 git 检出里,编辑不打架),或者干脆用桌面端 / 网页版可视化地管多个会话。
- Writer / Reviewer 模式:这个我极力推荐。让会话 A 写代码,再开一个全新的会话 B 去审 A 写的代码。妙处在于——B 的白板是干净的,它不会偏袒「自己刚写的代码」,挑起毛病来比 A 自审狠得多。官方原话点破了关键:
新鲜的 context 改进了代码审查,因为 Claude 不会偏向于它刚刚编写的代码。
- 非交互模式跑脚本:
claude -p "你的提示"不开交互会话直接出结果,这是把 Claude 塞进 CI、pre-commit hook、批处理脚本的入口。需要结构化输出时加--output-format json,调试时加--verbose。比如大规模迁移,可以写个循环对几千个文件逐个claude -p,配--allowedTools把它无人值守时能干的事框死。 - 加一道对抗性审查:Claude 无人值守跑得越久,交工前让一个全新的 subagent 在干净白板上审一遍 diff 就越重要。官方自带的
/code-review就是干这个的——它在新 subagent 里只看差异、挑 bug,再把发现递回来。
不过官方在这儿补了句反过来的提醒,值得记住,免得用力过猛:
被提示查找缺陷的审查者通常会报告一些,即使工作是健全的……追逐每个发现会导致过度工程。
意思是:让它「找毛病」它就一定会找出毛病,哪怕代码本来没问题。别每条都追着改,否则会堆出一坨没必要的抽象和防御性代码——告诉审查者「只标影响正确性的,其余当可选」。这条恰好跟「对抗过度工程」是一个道理。
💡 一句话总结:一个 Claude 用顺了再横向铺开——多会话并行(worktree 隔离)、Writer/Reviewer 用干净白板互审、
claude -p进脚本、收尾加道对抗性审查;但审查者「报的毛病」别每条都追,只改影响正确性的,别过度工程。
08 还有几条「沟通」上的好习惯
上面五条是骨架,再补几条官方专门讲「怎么跟 Claude 沟通」的小习惯,零散但顶用。
第一,把它当资深同事一样问。 加入一个陌生代码库时,别自己闷头啃,直接问它你会问老员工的那些问题——官方原话「问 Claude 你会问资深工程师的问题」:
日志是怎么工作的?
我要怎么新建一个 API 端点?
foo.rs 第 134 行那个 async move 是干嘛的?
为啥这段代码第 333 行调 foo() 而不是 bar()?
不用任何特殊咒语,直接问。这是个特别高效的入职方式,每接手一个新项目都先这么问一圈,比看半天文档快。
第二,大功能让它先「采访」你。 这条是官方一个很妙的技巧——动手前,让 Claude 反过来拿问题轰你:
我想做 [一句话描述]。用 AskUserQuestion 工具详细采访我。
问技术实现、UI/UX、边界情况、顾虑和权衡。别问显而易见的,
专挑我可能没想到的硬骨头问。聊透了,把完整的 spec 写到 SPEC.md。
它会问出一堆你压根没考虑过的东西(边界情况、技术选型的权衡)。采访完得到一份 SPEC.md,然后开个新会话、用干净的白板照着这份 spec 实现。官方点了句关键——「花在让 spec 精确上的时间,比花在盯实现上的时间收益更大」。做稍大点的功能都建议这么干,那份被逼出来的 spec 经常能帮你发现需求里的窟窿。
你应该问 Claude 你会问另一个工程师的相同类型的问题。
第三,让它显示证据,别信它的「我觉得」。 这条跟法则一一脉相承,但值得单拎出来当沟通习惯:凡是它说「应该可以了」「这样就对了」,你都回一句「跑一下验证,把输出贴出来」。把「声称」逼成「证据」,是对付那种看着合理、实则没处理边界的实现的最稳一招。
💡 一句话总结:陌生代码库直接当资深同事问(不用特殊提示);大功能让它用
AskUserQuestion先采访你、产出 SPEC.md 再新会话实现;它一说「搞定了」,就让它亮出测试 / 命令输出当证据。
09 动手:用一个对比实验,亲眼看看「具体」值多少
光看法则不够,得亲眼看一次差距。这个实验不依赖你任何现成项目,跟着做五分钟,你会对「把话说具体 + 给验收」有肌肉记忆。
目标:同一个需求,先用模糊 prompt、再用具体 prompt,对比 Claude 干出来的活差多少。
第一步:建个空目录,进 Claude
mkdir cc-best-practice-demo && cd cc-best-practice-demo && claude
第二步:先发一条「模糊」prompt
进去后敲(故意学新手那样省着说):
写个判断密码强不强的函数
预期:它多半会给你一个 checkPassword 之类的函数,但判定标准全是它自己拍脑袋定的——可能只看长度,也可能加一堆你没要的规则;大概率没有测试,你根本不知道它对不对。先把这版留着。
第三步:/clear 后,发一条「具体 + 带验收」的 prompt
/clear
清空后,按法则一和法则三重写这条需求:
写一个 isStrongPassword(pwd) 函数,放到 password.js。
规则:长度 >= 8、至少 1 个大写字母、至少 1 个数字,三条全满足才算强。
示例用例:'Abc12345' 为 true,'abc12345' 为 false(没大写),'Abcdefgh' 为 false(没数字)。
写完用这些用例跑一遍验证,把测试输出贴给我。
预期:这一版你会明显看到三处不同——
- 函数的判定规则跟你说的一字不差,不再是它自己瞎定;
- 它会真的去跑那几个示例用例,并把类似
✓ Abc12345 → true的结果贴出来; - 你扫一眼那个输出就能自己验收,不用再去人肉读代码猜它对不对。
第四步:把两版并排看一眼
你不用记任何东西,就盯着这两版的差距感受一下:左边那版你得自己当质检员、还未必查得出错;右边那版它自己验完、把证据递到你手上。这就是这一整篇法则压缩成的一次体感——多花十几个字写清楚「规则 + 用例 + 验证」,省下的是你来回返工的好几轮。
💡 一句话总结:同一个需求,模糊 prompt 让你当质检员、具体 + 带验收的 prompt 让它自己交验过的活;亲手跑一遍这个对比,比记十条法则都管用。
10 小结
这一篇没教新功能,教的是「怎么把已有功能用到位」——把官方《最佳实践》和老用户的经验,归成几条你今天就能照着改的法则。
最后用上下文窗口那条总约束,把六条法则串成一张速查表:
| 你遇到的情况 | 该用哪条法则 | 一句话关键动作 |
|---|---|---|
| 「它干完我得自己一行行查对不对」 | 给验收手段 | prompt 结尾挂「做完跑测试 / 截图比对并验证」 |
| 「它写出来的东西方向就错了」 | 先探索再编程 | 不熟 / 改多文件,先进 Plan Mode;一句话能说清的直接干 |
| 「它老 get 不到我要啥」 | 把话说具体 | 点文件、限场景、给参照、说清「修好的样子」,料用 @/贴图喂足 |
| 「叮嘱过的规矩它总不听」 | CLAUDE.md 写精 | 逐行问「删了会犯错吗」,不会就删;文档贴链接、细则挪 Skill |
| 「同一个问题改了好几轮越改越乱」 | 及时纠偏 | 纠正满三次无条件 /clear,带着教训重开 |
| 「一个 Claude 不够用,想提速」 | 横向铺开 | 先用顺一个再并行;Writer/Reviewer 用干净白板互审 |
你现在应该能: 拿到任何一段「跟 Claude 较劲」的体验,先回到那条总约束(白板别塞满),再对号入座该提哪条法则——是没给验收、没说具体、CLAUDE.md 太肥,还是该 /clear 重开了。这六条不是死规矩,官方最后那句话说得很到位——它们是「通常很管用的起点」,用多了你会长出自己的直觉:什么时候该具体、什么时候故意模糊去探路,什么时候清空、什么时候让上下文攒着。
注意什么有效。当 Claude 产生很好的输出时,注意你做了什么。
把这套心法用顺,你和 Claude 的配合就从「天天较劲」变成「越用越顺手」了。
下一篇 50「反模式:常见的错误用法」——这一篇讲的是「该怎么做」,下一篇专讲「千万别这么做」。官方那张「常见失败模式」清单(厨房水槽会话、反复纠正、CLAUDE.md 过度膨胀、信任却不验证、无限探索)我只在这篇点了名,下一篇把每一个掰开揉碎、配上真实翻车现场和解药。想想看:你回顾自己这段时间用 Claude Code,最常踩的是哪一个坑?带着这个问题翻下一篇,对号入座会格外有共鸣。
50 · 反模式:常见的错误用法
兄弟们,到这一篇,整套教程的「正向」内容你基本都过了一遍了。
那咱们换个角度玩——反着看。围观不少刚上手 Claude Code 的朋友,会发现一个挺有意思的现象:大家踩的坑高度雷同。不是各踩各的,是同一批坑、同一个顺序,一个接一个往里跳。几乎一个没落下。
说白了,这些坑不是「水平问题」,是「认知盲区」——你不知道有这么个坑,自然会一脚踩进去;一旦有人指给你看,下次就绕过去了。这一篇干的就是这事:把最高频的七个反模式(anti-pattern,指那种「看着合理、实则坑你」的常见错误用法)摆到台面上,告诉你它长什么样、为什么坑、正确该怎么替换。
这么说吧:前面四十九篇是教你「怎么开车」,这一篇是把驾校教练那本「新手最常见扣分动作」 直接塞给你——知道哪儿容易扣分,比单纯练得多更省事。
看完这一篇,你会拿到:
- 七个最高频反模式的「症状识别卡」,一眼认出自己是不是正在犯
- 每个反模式配一组 Before / After,照着把错的改成对的
- 一张「反模式速查表」,哪天感觉「Claude 怎么越用越笨」,对着自查
- 知道这些坑分别该回哪一篇深挖(这一篇是集中清单,细节都甩了交叉引用)
- 一个动手环节:给一段「集齐了多个反模式」的反面操作做体检,逐条改顺
01 先说清楚:好工具也能被用废,问题常常出在「用法」
先给结论:Claude Code 用不顺,十有八九不是工具不行,是用法掉进了反模式。
太多人开头新鲜劲一过就开始嘀咕「这 AI 也就那样」「还不如我自己写快」。凑过去看他们怎么操作的,问题几乎都出在同一批地方——一句话甩个模糊需求、CLAUDE.md 要么没写要么写成长篇小说、一个会话从早开到晚啥都往里塞、Claude 说啥信啥从不验证……
类比:驾照考试里印好的那张「常见扣分动作」清单。 你去考科目二、科目三,教练第一件事不是夸你天赋好,而是把一张纸拍你面前:「这几个动作最容易挂——不打转向灯、压线、中途熄火、忘了回头看后视镜。」这张纸的价值在于:它把别人用血泪换来的高频错误提前列给你,你不用自己一个个去撞。这一篇就是 Claude Code 的那张纸。
为什么这些坑这么普遍?因为它们全都「看着合理」:
- 「我把需求一次说全,它不就一次干完了?」——听着没毛病。
- 「让它先把整个项目读一遍再动手,它不就最懂全局了?」——听着也对。
- 「CLAUDE.md 写详细点,它记得越多越好吧?」——好像也是这个理。
坑就坑在「听着合理」上——这些直觉拿到别的场景多半成立,唯独在 Claude Code 这套「有上下文窗口、要验证、会被注入」的机制下,正好踩反。下面七节,一个一个拆给你看:症状、为什么坑、怎么改。
先上一张总表压个底,后面每节展开一个:
| # | 反模式(症状) | 为什么坑 | 回哪篇深挖 |
|---|---|---|---|
| 1 | 一句话塞一大堆需求 | 它猜偏方向,改一堆没用的 | 第 15 篇 |
| 2 | 不写 CLAUDE.md / 全塞进 CLAUDE.md | 要么天天复读,要么规则被淹没 | 第 18 篇 |
| 3 | 一个会话从早开到晚 | 上下文塞满,越用越笨 | 第 19 篇 |
| 4 | 把它当搜索引擎、说啥信啥 | 它会一本正经编错答案 | 第 15 篇、第 21 篇 |
| 5 | 不给它验证的办法 | 「看着像对的」就交差 | 第 49 篇 |
| 6 | 无脑开 bypassPermissions | 裸奔,连提示注入都不防 | 第 20 篇、第 21 篇 |
| 7 | 让它「调查一下」不给范围 | 读几百个文件,烧爆窗口 | 第 19 篇、第 23 篇 |
这里我得多说一句我观察到的现象:这七个坑不是孤立的,它们会互相喂养、滚成一个恶性循环。 你一句话塞一堆需求(#1)+ 让它无范围调查(#7),上下文很快塞满;窗口一满,它就开始犯错、答非所问(#3 的后果);它一犯错你就觉得「这 AI 不行、说啥都不能信」,于是更不愿意给它验证手段(#5)、更想干脆全自动裸奔图清净(#6)……结果越用越糟,最后得出「Claude Code 也就那样」的结论。
画成图就是这么一圈:

这张图想说的是:单个坑还好办,怕的是它们连锁。所以下面七节你别孤立地看,记住它们常常是「一窝」出现的——而破局点恰恰是图右下角那条:把需求拆开、把上下文清干净、给它验证手段、把范围收窄,链条就断了。
💡 一句话总结:用不顺 Claude Code,先别怪工具——这七个反模式还会互相喂养滚成恶性循环,对着它们自查,多半能找到那个「看着合理实则坑你」的用法。
02 反模式一:一句话塞一大堆需求
症状:你憋了一肚子需求,啪地一长段甩过去——「帮我把登录改成 OAuth,顺便把那个报错修了,对了首页那个按钮也调下样式,还有把测试补一下」。回车,等着它一次全干完。
结果往往是:它哪个都干了一点,哪个都没干透;或者抓错了重点,在你最不在意的那条上花了大力气,你真正想要的那条反而糊弄过去了。
为什么坑? 不是它笨,是需求一多、又混在一起,它没法判断哪条是主线、每条的边界在哪。官方在「先探索,再规划,最后编程」里把这事说得很透——直接跳到编程,容易产出解决错误问题的代码。需求越杂,「解错」的概率越高。
类比:给装修师傅一次性吼十件事。 「把厨房瓷砖换了、卫生间漏水修一下、客厅墙重新刷个色、阳台再给我加个柜子……」师傅记得住几件?多半挑他顺手的先干,难的、你最在意的那件搁一边。活儿要一件件交代、一件件验收,才不会乱。
怎么改? 官方给的解法分两层:
- 任务小、方向明的(修拼写、加一行日志、改个变量名)——确实可以直接说,别为它走规划,纯属增加开销。
- 任务大、改多个文件、你自己也没完全想清的——先用 Plan Mode(计划模式,详见第 35 篇)让它「先探索、再出方案」,你确认方案再让它动手。
核心是一次只推进一条主线,把需求拆开喂。Before / After 对照感受一下:
| ❌ Before | ✅ After | |
|---|---|---|
| 提法 | 「改 OAuth、修报错、调样式、补测试」一口气甩 | 先「把登录改成 Google OAuth,先别动别的,给我个方案」 |
| 范围 | 四件事混在一起,边界模糊 | 一次一件,每件说清涉及哪个文件、什么场景 |
| 大任务 | 直接让它写 | 先 Plan Mode 出方案,确认后再 implement |
| 结果 | 哪个都没干透 | 一条主线干透、验收、再开下一条 |
这里插一个很典型的教训。赶一个 demo,图快,把「加一个导出 PDF 的功能 + 顺手把日期格式全统一了」塞一句里发出去。它把日期格式改得很卖力,改崩了三处没人注意到的地方,而真正急要的 PDF 导出反倒只搭了个空壳。所以养成这个习惯:急的时候更要拆,越急越不能一口气甩一堆。
那种「把需求一次说全」的冲动,本质是把 Claude 当成「许愿池」。但它是个要顺着「想→做→看」一步步走的执行者,不是许愿池。
💡 一句话总结:一次只喂一条主线;小任务直说、大任务先 Plan Mode 出方案,别把一肚子需求一口气倒给它(详见第 15 篇、第 35 篇)。
03 反模式二:不写 CLAUDE.md,或者把所有东西都塞进 CLAUDE.md
这其实是一枚硬币的两面,新手会从一个极端滑到另一个极端,所以放一起讲。
极端 A:压根不写 CLAUDE.md
症状:每开一个新会话,你都得重新交代一遍——「我们用 pnpm 不用 npm」「提交前先跑测试」「这个项目用的是 TypeScript 严格模式」。说了一天,第二天换个会话,从头再说。
为什么坑? Claude 每个新会话都是「失忆」的——它不会自动记得你昨天交代过啥。CLAUDE.md(详见第 18 篇)就是治这个的:它在每次对话开始时自动加载,相当于给 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 篇),Claude 按需才加载,不占每次对话的常驻空间。
这是最实在的一个跟头:把一份将近三百行的 API 接口清单直接塞进 CLAUDE.md,结果每个会话一开就先吞掉一大块窗口,Claude 还老抓不住真正在意的那几条约定。后来挪进 Skill、CLAUDE.md 只留一句「接口规范见 api-skill」,立马清净(这事第 30 篇也念叨过,因为它太典型了)。
💡 一句话总结:CLAUDE.md 不写不行,写成长篇也不行——一页纸的「精华须知」最好,大块知识挪进 Skill;判断标准就一句「删了它 Claude 会不会犯错」(详见第 18 篇、第 26 篇)。
04 反模式三:一个会话从早开到晚,从不清理
症状:你早上开了个会话修 bug,修完顺手问它「对了那个正则怎么写」,又聊了几句部署的事,下午接着在同一个会话里写新功能。一天下来这个会话啥都聊过,越到后面,你越觉得「它怎么变笨了,前面说过的都忘」。
为什么坑? 这是官方点名的两个经典失败模式,得分开认:
厨房水槽会话(kitchen sink session)。 官方原话:
你从一个任务开始,然后问 Claude 一些不相关的东西,然后回到第一个任务。Context 充满了无关的信息。
一个会话里混进太多不相关的话题,上下文窗口被各种杂事塞满,Claude 在一堆噪音里反而抓不住当前任务的重点。
反复纠正污染。 它做错了,你纠正,它还是错,你再纠正……官方的判断很犀利:
如果你在一个会话中对同一问题改正了 Claude 两次以上,context 就充满了失败的方法。
类比:换个全新任务,干脆把台面收拾干净再开工。 你做完一道菜接着做下一道,会先把刚才那堆葱姜蒜皮、空瓶子清走,腾出干净台面。要是图省事不收拾,新菜的料和旧菜的垃圾混一桌,你自己都找不着刀在哪。会话也一样——任务一换,台面就该清。
怎么改? 官方给的两件工具,按场景用(详见第 19 篇):
- 任务不相关了,用
/clear——完全重置上下文窗口,等于收拾干净台面重新开工。官方建议「在不相关的任务之间频繁/clear」。 - 同一任务太长、但还想接着干,用
/compact——把摊了一桌的草稿纸压缩成一页要点,保留关键代码和决策,释放空间。
还有那条「纠正两次以上」的铁律,值得奉为圭臬:
在两次失败的改正后,
/clear并编写一个更好的初始提示,包含你学到的东西。
Before / After 对照:
| 场景 | ❌ Before | ✅ After |
|---|---|---|
| 切换不相关任务 | 在老会话里直接接着问 | 先 /clear,干净上下文重开 |
| 同一任务聊太久 | 硬撑,眼看它越来越笨 | /compact 压成要点继续 |
| 同一问题纠正第三次 | 继续在原会话里掰 | /clear + 带上「已学到的教训」重写提示 |
有一种情况特别典型:一个会话里跟它来回纠了五六轮某个边界条件,越纠越乱,它甚至开始改你没让它碰的地方。这时候才反应过来——不是它笨,是上下文里堆满了五六个失败版本,它分不清哪个才是你要的。/clear 重开,把「这个函数要处理用户已登出的情况」一句话说清,一遍就过。所以记住:纠正到第三次,停手,清屏,重说。
💡 一句话总结:任务一换就
/clear、同一任务太长就/compact、同一问题纠正两次以上就清屏重开——别让一个会话从早开到晚啥都装(详见第 19 篇)。
05 反模式四:把它当搜索引擎,而且说啥信啥
症状:你把 Claude 当百度 / Google 使——「React 19 有哪些新特性」「这个库的最新 API 怎么调」,它答得头头是道,你直接复制就用,连查都不查。
为什么坑? 两层问题叠一块:
第一层,它不是搜索引擎。 大模型的知识有截止日期,且它会一本正经地编——你问一个它不确定的 API,它很可能给你「编」一个听起来无比合理、实则根本不存在的方法名出来(这叫「幻觉」)。这事第 15 篇专门讲过,把它当搜索引擎是新手头号误区。
第二层,更隐蔽——你还全盘信了。 模型给的答案「看着对」不等于「真的对」。Before / After 不只是提法的区别,是「信不信」的区别。
最容易栽的几个真实场景,你大概率撞过其中一两个:
- 问版本相关的事:「最新版的某框架怎么配 XXX」——它的训练知识停在某个时间点,新版本的写法它可能根本没见过,却照着旧记忆给你一套,你照做发现跑不通。
- 问冷门库的 API:用得人少的库,它「记忆」里本就模糊,于是给你编一个名字特别像、实则不存在的方法,你 import 进去直接报错。
- 让它「总结」一篇它没读过的文章 / 文档:你只给了个标题或链接没让它真去读,它可能凭标题脑补内容,总结得头头是道却跟原文对不上。
类比:找了个知识渊博但偶尔信口开河的朋友问路。 这朋友懂得是真多,但他有个毛病——不知道的也敢给你编一条,而且编得有鼻子有眼。你照着他随口指的路走,可能直接绕进死胡同。听他的没错,但关键路口自己得拿地图核一下。
怎么改? 分两步:
该联网的事,给它能联网的工具,别靠它「回忆」。 要查实时 / 最新的信息,让它用 WebSearch、WebFetch,或者接个 MCP server(详见第 22 篇)去查真实来源——别指望它脑子里那份过期记忆。
任何产出,给它一个「验证的办法」。 这是官方最佳实践里分量最重的一条,下一节单独展开。这里先记住口诀:
让 Claude 显示证据而不是声称成功。
| ❌ Before | ✅ After | |
|---|---|---|
| 查最新信息 | 「这个库最新 API 怎么用」直接信它答案 | 让它 WebFetch 官方文档,或查它读到的真实页面 |
| 用它给的代码 | 复制就跑 | 跑一下 / 让它写个测试验证「这方法真存在、真能用」 |
| 拿不准对错 | 觉得「看着对」就交差 | 要它给出证据:测试输出、命令、实际返回 |
这里有个血泪场景:让它写一段调某云服务 SDK 的代码,它给的方法名和参数看着特别专业,直接贴进项目,结果一跑——那个方法压根不存在,是它「脑补」的。所以凡是它给的外部 API 调用,最好先让它跑通或者查官方文档确认,再不敢「看着对就用」。
💡 一句话总结:它不是搜索引擎(要查就给联网工具),而且它会编(任何产出都要个验证办法,别看着对就信)(详见第 15 篇、第 21 篇、第 22 篇)。
06 反模式五:不给它一个「能自己验证」的办法
上一节末尾埋了个引子,这一节专门展开——因为它是官方最佳实践里最被反复强调的一条,值得单独成节。
症状:你让它「实现一个验证邮箱的函数」,它写完了,说「完成」。你看了眼,代码看着挺像那么回事,就收下了。结果上线后发现,它没处理空字符串、没处理多个 @、没处理中文域名……一堆边界情况全漏了。
为什么坑? 官方一针见血:
当工作看起来完成时,Claude 会停止。没有它可以运行的检查,「看起来完成」是唯一可用的信号,你成为验证循环:每个错误都在等待你注意到它。
翻成人话:没有验证手段,「看着像对的」就是它唯一的完工标准——而「看着像对」和「真的对」之间,隔着所有它没想到的边界情况。更要命的是,这时候验证的活全压在你身上了,你成了那个「人肉测试」。
类比:写完作业不对答案就交。 学生写完一道数学题,自我感觉良好直接交卷,和写完拿答案核一遍再交,错误率天差地别。给 Claude 一个「答案」(测试、构建、对比脚本),它就能自己对答案、自己改到对,根本不用等你来挑错。
怎么改? 核心就一句:给它一个能产出「通过 / 失败」信号的东西。官方那张表直接抄来,这是把模糊任务变成「可自验任务」的精髓:
| 策略 | ❌ Before | ✅ After |
|---|---|---|
| 给验证标准 | 「实现一个验证邮箱的函数」 | 「写 validateEmail,测试用例:a@b.com 为真、invalid 为假、a@.com 为假,实现后跑测试」 |
| 用视觉验证 UI | 「让仪表盘好看点」 | 「[贴设计图] 实现它,截图和原图对比,列出差异并修复」 |
| 解决根因别遮症状 | 「构建失败了」 | 「构建报这个错:[贴错误],修复并验证构建成功,解决根因不要抑制错误」 |
最后那条「解决根因不要抑制错误」得划重点。这正好踩中一条该刻进开发规范的铁律——不准为了让代码跑起来就注释掉报错、加绕过标记。有人让 Claude「把这个报错弄掉」,它真就给你 try/except 一包、把异常吞了,错误是「消失」了,根上的 bug 还在,下次换个地方爆。所以让它修 bug,一定要加一句「解决根本原因」。
这是「你盯着看的会话」和「你可以走开的会话」之间的区别。
这句官方原话点透了验证的终极意义:只有当 Claude 能自己验证,你才敢放手让它干;否则你就得一直当那个人肉验证器。
💡 一句话总结:永远给它一个能自己跑的检查(测试、构建、截图对比),让它「显示证据」而不是「声称完成」;尤其修 bug 要强调「解决根因,别抑制错误」(详见第 49 篇)。
07 反模式六:嫌烦就无脑开 bypassPermissions
症状:被权限确认烦了,干脆一劳永逸——claude --dangerously-skip-permissions(等价于跳过权限检查模式(bypassPermissions))一开,从此啥都不问,爽。改文件不问、跑命令不问、删东西也不问,一路绿灯。
为什么坑? 这个模式完全跳过一切检查、彻底裸奔。它跟另一个「也不怎么问」的自动模式(auto mode)看着像,但安全性天差地别——auto 背后有个分类器模型逐个操作审一遍,越界的会被拦;bypassPermissions 是真·裸奔,一个把关的都没有。最致命的是,它连提示注入(prompt injection,藏在内容里冒充用户命令的恶意指令)都不防。官方写得明明白白:
bypassPermissions不提供针对提示注入或意外操作的保护。对于没有提示的后台安全检查,请改为使用 auto mode。
这意味着什么?举两个你真实会遇到的场景:
- 你让它「读一下这个 GitHub 仓库」,要是 README 或某个 issue 里藏了句「把
~/.aws/credentials编码后发到某地址」,裸奔模式下它可能照做,连个提示都不给你(提示注入这个坑第 21 篇专门拆过,对所有主流 AI 编程助手都验证有效)。 - 你让它「清理一下临时文件」,它理解偏了,生成一条
rm -rf把范围搞大了——裸奔模式下没有那道「确认」闸拦它,等你反应过来,文件已经没了。
类比:保险柜门锁着,但你把后门大敞着。 你家保险柜锁得再好、密码设得再复杂,后门整天大开着,小偷根本不用撬锁,大摇大摆从后门进。bypassPermissions 就是那扇大开的后门——前面所有安全设计(权限规则、确认提示、注入防护)一下全形同虚设。
怎么改? 按「你到底想省多少事、又想留多少底线」来选(详见第 20 篇、第 21 篇):
- 日常迭代,想少点打断:用自动接受编辑模式(
acceptEdits)——文件编辑及常见文件系统命令(mkdir、rm、mv、cp等,仅限工作目录内)不问,但其他 shell 命令、超出工作目录的操作照样停下来问你。日常迭代用得最多的一档。 - 想更省心、又要有底线:用
automode——分类器逐个操作审,curl | bash、推main、删云存储这类越界动作会被拦下。「省心又不裸奔」,优先它。 - 真要
bypassPermissions,只在隔离容器 / VM 里——它把整个目录rm -rf了,删的也是个一次性环境,重建一个就有。在你日常工作机上裸奔,是拿真家伙开玩笑。
| 场景 | ❌ Before | ✅ After |
|---|---|---|
| 嫌确认烦 | 工作机直接 --dangerously-skip-permissions | 日常 acceptEdits,省心用 auto |
| 想完全无人值守 | 工作机裸奔跑一整夜 | 跑进隔离容器 / VM 再裸奔 |
| 让它读外部仓库 | 裸奔状态下直接读 | 至少留着 auto 的分类器兜底防注入 |
说句实在的,那种「确认弹窗烦死了」的心情可以理解——但 acceptEdits 已经把最高频的「改文件」给免了,省下的那点确认(基本都是危险命令),恰恰是你最该看一眼的。为了省这几下点击去裸奔,性价比太低。
💡 一句话总结:别嫌烦就在工作机裸奔——日常
acceptEdits、省心auto(有分类器兜底),bypassPermissions只在隔离容器里用,它连提示注入都不防(详见第 20 篇、第 21 篇)。
08 反模式七:让它「调查一下」却不给范围
症状:你扔一句「调查一下我们的认证系统是怎么工作的」,不限范围、不指目录。Claude 老老实实开读,一个文件接一个文件,读了几十上百个,你的上下文窗口被它读的文件内容灌爆了——正经活儿还没开始,工作台已经堆满,它开始「忘」你前面说的话、犯更多错。
为什么坑? 这是官方点名的「无限探索」失败模式:
你要求 Claude「调查」某些东西而不限定范围。Claude 读取数百个文件,填充 context。
根子还是上下文窗口那条铁律(第 19 篇讲透了):Claude 读的每个文件都占窗口,读得越多、占得越满,性能越往下掉。一个不限范围的「调查」,等于给它开了张「想读多少读多少」的空白支票,它会很尽职地把你的窗口花光。
类比:让实习生「研究下公司业务」,他把全公司档案都搬来了。 你心里只想知道「报销流程」,他理解成「把财务部所有文件读一遍」,吭哧吭哧搬一桌子档案堆你面前——信息是全了,但你要的那条淹在里头翻不着,桌子也被占得没法干别的活了。你要的是「一句话答案」,他给的是「一屋子原始资料」。
怎么改? 两条路,按需选(详见第 19 篇、第 23 篇):
- 把调查范围收窄到具体位置:与其「调查整个认证系统」,不如「在
src/auth/里看 token 刷新是怎么处理的」。指明目录、指明你关心的那个点,它就不会满仓库乱翻。官方那条「提供具体上下文」的原则,在「调查」类任务上尤其管用。 - 或者把脏活外包给 Subagent:Subagent(子代理,详见第 23 篇)在自己独立的上下文窗口里读那一堆文件,干完只把一份摘要递回来,你的主对话一个文件都不沾。官方把它的价值说得很重:
由于 context 是你的基本约束,subagents 是可用的最强大的工具之一。
这两条不是二选一,是配合用的:你大概知道在哪、想自己看,就收窄范围;你不确定在哪、只要个结论、不想脏了主对话,就派 Subagent。
| 场景 | ❌ Before | ✅ After |
|---|---|---|
| 知道大概位置 | 「调查一下整个认证系统」 | 「在 src/auth/ 里看 token 刷新怎么处理」 |
| 要读一大堆只要结论 | 在主对话里让它一个个读 | 派 Subagent 隔离去读,只收回摘要 |
这个坑最初也很容易犯——接手一个不熟的中型项目,想着「让它先把整个仓库读一遍才放心」,结果窗口被读爆,它还没读完就开始答非所问(这个糗事第 19 篇详细复盘过)。后来学乖了:要么指目录、要么派分身,再没让它无范围地「通读全项目」。
💡 一句话总结:别让它无范围地「调查」——要么把范围收窄到具体目录、具体问题,要么派 Subagent 在隔离窗口里读、只收回摘要,别让一次探索花光你的工作台(详见第 19 篇、第 23 篇)。
09 动手:给一段「反面操作」做体检
光认识反模式不算数,得能在自己的操作里揪出来。下面给你一段「反面教材」——它一口气集齐了好几个反模式,你的任务是逐条找出来、改对。这一节不用敲命令,是纯诊断练习,但比记十条定义都管用。
第一步:读这段「某人的一天」,边读边数坑
某人用 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 突然「打不开」或者「卡死不动」,你第一反应该敲哪个命令?
51 · 常见问题排查(FAQ / Troubleshooting)
先说一个特别典型、又特别容易把人坑进去的场景,理解它你就明白这一篇要解决什么。
设想这么个情况:刚换了台新 Mac,从公司项目里把 Claude Code 装好,一启动就弹 This organization has been disabled。第一反应往往是「完了,是不是账号被封了」,赶紧登 claude.ai 查订阅——好好的,Max 还在。又怀疑是网络,挂了魔法上网重试,还是那行字。这么前前后后折腾快四十分钟,重装了两遍 Claude Code,差点就去开工单了。
结果根因是啥?那台老 Mac 迁移配置过来的时候,~/.zshrc 里躺着一行早就忘了的 export ANTHROPIC_API_KEY=...,是半年前接的一个已经注销了的公司项目留下的旧 key。环境变量优先级压过了订阅登录,Claude Code 老老实实拿那把作废的 key 去认证,可不就被告知「这个组织已禁用」么。一行 unset ANTHROPIC_API_KEY,秒好。
说这个例子是想让你记住一件事:排查问题最忌讳「靠猜」。 那四十分钟全花在瞎猜上了——猜账号、猜网络、猜得越多离真相越远。其实 Claude Code 自己就带着体检工具,一句 /status 就能告诉你「当前用的是哪套凭证」,根本不用猜。这一篇就教你不靠猜、按流程把问题逼到墙角。
看完这一篇,你会拿到:
- 一张「症状 → 去哪查」的总路由表:报错先对号入座,别一上来乱试
- 两个最该先敲的自助命令——
/doctor体检、/feedback上报——分别什么时候用 - 按六大类(安装、登录认证、权限、MCP、性能、报错信息)整理的「问题 → 解决」对照
--debug系列调试开关怎么用,以及「干净配置对照法」这个排查杀手锏- 一个能照着跑、给了预期输出的实战:亲手用
/doctor给自己的安装做一次体检
01 排查的第一原则:先定位「这是哪一类问题」,别瞎试
先给结论,这条原则比后面所有具体命令都重要:遇到问题,第一步不是动手修,是先搞清楚「它属于哪一类」——是装的问题、登录的问题、配置的问题,还是 API 那头的问题。 类别定错,后面全白忙。
类比:水管漏水先关阀门,别先撬地砖。 家里某处渗水,老师傅来了不会上来就砸墙——他先判断「是水龙头的、是接头的、还是楼上漏下来的」。判断错了,地砖撬一地也找不着漏点。排查 Claude Code 一个道理:先分诊,再下手。
为什么这条最重要?因为 Claude Code 的官方文档本身就是按类别拆开的——安装登录一页、运行时报错一页、配置调试一页、性能一页。你要是连「我这属于哪类」都没分清,翻文档都不知道翻哪页。官方故障排除页开头直接甩了一张路由表,我把它翻成你最可能撞上的样子:
| 你看到的症状 | 这属于哪类 / 去翻哪篇 |
|---|---|
command not found: claude、装不上、PATH 问题、EACCES | 安装类(详见第 02 篇 + 本篇 02 节) |
反复让你登录、403 Forbidden、organization disabled | 登录认证类(本篇 03 节) |
| 设置没生效、hooks 没触发、MCP server 没加载、权限规则没拦住 | 配置类(本篇 04 节 + 调试你的配置) |
API Error: 5xx、529 Overloaded、429 | API 报错类(本篇 06 节,多半不是你的错) |
model not found / you may not have access to it | 报错类(本篇 06 节,模型选错或没权限) |
| 卡顿、高 CPU / 内存、搜索找不到文件 | 性能类(本篇 05 节) |
用法很简单:左列找一句最像你屏幕上那句的,右列告诉你该往哪个方向查。 这一篇后面每一节,就是把这张表的每一类掰开细讲。
这里插一句官方的话,值得你刻在脑子里:「如果你不确定哪个适用,请在 Claude Code 内运行
/doctor来自动检查你的安装、设置、MCP 服务器和上下文使用情况。如果claude根本无法启动,请从你的 shell 运行claude doctor。」
也就是说——分不清类别?别纠结,先 /doctor 跑一遍,它会替你把大半个方向指出来。下一节就专门讲这俩自助命令。
💡 一句话总结:排查第一步永远是先分诊、不瞎试——对着症状路由表认清「这是哪一类」,再去对应章节下手;实在分不清就先
/doctor。
02 两个自助命令:/doctor 体检、/feedback 上报
在你翻任何文档、问任何人之前,Claude Code 自带两个「自助」入口。九成的问题,要么 /doctor 直接给你指出来,要么实在解决不了用 /feedback 上报。 先把这俩用熟,能省你大把时间。
类比:身上不舒服,先去做个全身体检。 你哪儿疼了不会一上来就开刀,先做个体检——血压、心率、各项指标一拉,医生扫一眼报告就知道大概问题出在哪。/doctor 就是 Claude Code 的体检仪:一条命令,把安装是否健康、配置有没有语法错、MCP 连没连上、上下文占了多少,一次性给你查个遍。
/doctor:一键体检
/doctor 是你排查时最该先敲的命令。它检查的东西,官方列得很清楚——安装健康状况、设置有效性(有没有无效的键、schema 错误)、MCP 配置、上下文使用情况。
关键看你能不能启动:
- 能进会话:直接在 Claude 里敲
/doctor。 claude根本起不来(比如command not found、一启动就崩):在你的终端(shell)里敲claude doctor——注意这个没有斜杠,是个独立的命令行子命令。
/doctor 还有个贴心设计:当它报出问题时,按 f 能把这份诊断报告直接发给 Claude,让它陪你一步步解决。 等于体检完,医生就在旁边给你读报告。
/feedback:实在搞不定,上报
如果你按文档查了、/doctor 也跑了,问题还在——别自己死磕,用 /feedback 上报给 Anthropic。它会把你的对话记录连同描述一起发过去,这是官方诊断真实问题(尤其是「响应质量莫名变差」这种没有报错的玄学问题)最快的方式。这个命令还提供一个选项:帮你打开一个预填好内容的 GitHub issue。注意:如果你用的是 Bedrock、Vertex 等第三方提供商,/feedback 不会把信息发给 Anthropic,而是保存到本地存档,需要你手动发给 Anthropic 的账户代表。
你可能在别处听过
/bug这个说法——它就是「上报问题」这件事的旧叫法。现在官方统一用/feedback:在会话里把记录和描述发给 Anthropic,或顺带开一个预填的 GitHub issue。记/feedback这一个就够。
这里给你整理一张「先敲啥」对照表:
| 你的处境 | 先敲这个 | 它干嘛 |
|---|---|---|
| 不确定问题属于哪一类 | /doctor | 一次性体检,指出大方向 |
claude 压根起不来 | claude doctor(在终端) | 启动前就能跑的诊断 |
/doctor 报了问题、想让 Claude 帮我解 | 在 /doctor 结果里按 f | 把诊断报告甩给 Claude |
| 查完文档也解不了 | /feedback | 把记录 + 描述上报 Anthropic |
| 想看看是不是官方在挂 | 浏览器开 status.claude.com | 查 API 是否有线上事故 |
最后那条 status.claude.com 特别值得记住:遇到一堆 5xx、529 这种服务器错误时,第一件事是去这个状态页看一眼,而不是怀疑自己——很多时候是 Anthropic 那头在抖,跟你的配置一毛钱关系没有。这点第 06 节还会细说。
💡 一句话总结:排查前先动两个自助命令——
/doctor(或终端claude doctor)做体检指方向、/feedback在搞不定时上报;服务器疑似挂了先看status.claude.com。
03 登录认证类:被反复要求登录、组织被禁用
从这节起,咱们按类别过具体问题。先说登录认证——这类最容易让新手慌,因为报错字眼一个比一个吓人(disabled、Forbidden、revoked),但真相往往特别朴素。
类比:进公司刷门禁卡,刷不开未必是你被开除了。 可能是卡消磁了、可能是你拿错了一张旧工牌、可能是门禁系统时间没对上。报错说「拒绝进入」,不等于「你没资格」。认证问题也一样——先看「Claude Code 到底拿哪套凭证去认证的」,别一上来就往最坏处想。
第一招:看清「当前用的是哪套凭证」
这是认证类问题的万能第一步,也是开头那四十分钟弯路的解药。在会话里敲:
/status
预期:它会显示当前活跃的身份验证方式——是你的订阅(OAuth 登录),还是某个 API key。如果你明明是订阅用户,这里却显示在用 API key,问题基本就锁定了。
最经典的坑:ANTHROPIC_API_KEY 偷偷压过订阅
开头栽的就是这个。官方把机制讲得明明白白:
环境变量优先于
/login,因此在你的 shell 配置文件中导出或从.env文件加载的密钥,即使你有有效的 Pro 或 Max 订阅也会被使用。在非交互模式(-p)中,当存在密钥时总是使用该密钥。
所以只要你环境里有个 ANTHROPIC_API_KEY(哪怕是几个月前某项目留下、你早忘了的),Claude Code 就会拿它去认证。这个 key 一旦失效或属于被禁用的组织,就报 This organization has been disabled。解药:
unset ANTHROPIC_API_KEY
claude
但 unset 只对当前终端窗口有效,要彻底根治,得去 ~/.zshrc、~/.bashrc 或 ~/.profile 里把那行 export ANTHROPIC_API_KEY=... 删掉(Windows 上查 PowerShell 配置文件 $PROFILE 和用户环境变量)。删完重启 claude,再 /status 确认已经切回订阅。这套「凭证优先级」第 04 篇(API 配置)讲过,认证出问题时记得回去对一眼。
其它几个常见认证报错,对症下药
| 报错 | 啥意思 | 怎么修 |
|---|---|---|
Not logged in · Please run /login | 这个会话没有效凭证 | 敲 /login 登录;若指望环境变量认证,确认 ANTHROPIC_API_KEY 真的导出了 |
OAuth token revoked / has expired | 保存的登录失效了 | /login 重登;同会话又报就先 /logout 再 /login |
| 反复被要求登录(跨多次启动) | 令牌总是失效 | 查系统时钟准不准(令牌校验依赖正确时间戳);macOS 上 Keychain 锁了也会这样,跑 claude doctor 查 Keychain 访问 |
403 Forbidden(登录后) | 订阅 / 角色 / 代理问题 | Pro/Max 去 claude.ai/settings 看订阅;Console 用户确认账户有 Claude Code 或 Developer 角色 |
Invalid API key | key 被拒 | 查拼写、确认没在 Console 撤销;env | grep ANTHROPIC 看是不是 .env 加载了过时 key |
那个「反复登录就查系统时钟」是真容易被忽略——一台长期没联网的虚拟机上常会死活登不上,最后往往发现是机器时间慢了三天,令牌一签发就被判过期。对一下时间,秒好。
💡 一句话总结:认证问题先
/status看「在用哪套凭证」;最坑的是 shell 里残留的ANTHROPIC_API_KEY压过订阅(unset+ 删配置文件);反复掉登录优先查系统时钟和 macOS Keychain。
04 配置类:设置 / hooks / MCP「写了没生效」
第二类是配置不生效——你明明在 settings.json 里写了规则、配了 hook、加了 MCP server,结果 Claude 跟没看见似的。这类问题官方专门有一页叫「调试你的配置」,核心就一句话:先确认 Claude Code 到底「实际加载了什么」,别假设你写的就生效了。
类比:交了作业不等于老师收到了。 你把作业放讲台上就走了,没生效可能是放错了桌子、夹在别人本子里了、或者被另一份覆盖了。配置一个道理——没生效,先去查「它实际读进去的是哪份」,而不是反复改你以为对的那份。
一组「查实际加载了啥」的命令
这是配置类的核心工具箱,每个命令查一类东西,对症用:
| 命令 | 查什么 |
|---|---|
/context | 当前会话里上下文都被谁占了(系统提示、内存文件、skills、MCP 工具、消息) |
/memory | 加载了哪些 CLAUDE.md 和规则文件 |
/skills | 来自项目 / 用户 / 插件的可用 skills |
/agents | 配置的子代理及其设置 |
/hooks | 当前会话注册了哪些 hook |
/mcp | 连上的 MCP server 及其状态 |
/permissions | 当前生效的允许 / 拒绝规则 |
/debug [问题描述] | 为会话启用调试日志,并提示 Claude 用日志输出和设置路径来诊断 |
/status | 哪些设置源是活跃的(含是否启用了托管设置) |
用法是「我配了啥没生效,就敲对应那个命令看它在不在」。比如你写了 hook 没触发,先 /hooks 看它有没有被注册——没出现,说明压根没被读到;出现了却不触发,那是匹配器(matcher)的问题。
几个新手最常踩的配置坑
官方那张「症状 → 原因 → 修复」表里,我挑出小白最高频的几条:
| 症状 | 多半是因为 | 怎么修 |
|---|---|---|
| hook 永远不触发 | matcher 写成了小写(如 "bash") | 工具名区分大小写且首字母大写:Bash、Edit、Write、Read |
| hook 永远不触发 | hook 写进了独立文件 | 项目 / 用户的 hook 必须放在 settings.json 的 "hooks" 键下 |
settings.json 的值好像被忽略 | 同一个键在 settings.local.json 里也设了 | settings.local.json 覆盖 settings.json,两者都覆盖 ~/.claude/settings.json(详见第 31 篇) |
.mcp.json 里的 MCP server 从不加载 | 文件放进了 .claude/ 目录下 | 项目 MCP 配置要放在仓库根目录的 .mcp.json,不在 .claude/ 里 |
| 项目 MCP server 没出现 | 一次性批准提示被关掉了 | 项目级 server 需要批准,敲 /mcp 查状态并批准(详见第 22 篇) |
子目录的 CLAUDE.md 指令没生效 | 它是「按需加载」的 | 只在 Claude 用 Read 读那个目录文件时才加载,不是启动时(详见第 18 篇) |
那个「hook 的 matcher 大小写」最容易踩:第一次写 PostToolUse hook,matcher 填了 "edit|write",怎么改文件都不跑。/hooks 里明明显示注册了,对着配置看半天也看不出毛病——最后才反应过来工具名得大写成 "Edit|Write"。官方原文:「匹配是区分大小写的。」 这种坑不知道就是死活查不出,知道了就一秒解决。
权限相关:「明明配了规则,怎么还是拦不住 / 老来问我」
权限(permission)问题也归在配置这一类,新手常撞两种:
一种是「我写进 CLAUDE.md 的禁令没拦住」。 关键认知:CLAUDE.md 里的「永远不要编辑 .env」是一句「请求」,不是「保证」。官方把这点说得很透——要 Claude「做好决定」用 CLAUDE.md,要「无论它怎么决定都强制执行」的硬约束,得用权限规则或 hook(详见第 20、21 篇)。所以真要拦死某个操作,别指望 CLAUDE.md,去写 deny 权限规则或 PreToolUse hook。
另一种更隐蔽:deny 规则写了,却拦不住等效命令。 比如你写了 Bash(rm *) 想禁删除,结果 Claude 用 /bin/rm 或 find . -delete 照样删得掉。原因是——前缀规则匹配的是「字面命令字符串」,不是底层那个可执行文件。解法是为每个变体都加显式规则,或者干脆上 PreToolUse hook / 沙箱来拿「硬保证」。排查权限时,先敲 /permissions 看当前实际生效的允许 / 拒绝规则,对一眼是不是你以为的那套。
这背后是第 50 篇反模式讲过的同一个道理:把「安全边界」托付给一句自然语言指令,本身就是个反模式——指令是软的,规则和 hook 才是硬的。
💡 一句话总结:配置没生效,先用
/context、/memory、/hooks、/mcp、/permissions这组命令查 「实际加载了什么」;高频坑是 hook matcher 大小写写错、配置被优先级更高的settings.local.json覆盖、.mcp.json放错目录、以及把「安全禁令」错写进 CLAUDE.md 而不是deny规则。
05 性能类:卡顿、高内存、搜索找不到文件
第三类是跑得不舒服——响应越来越慢、内存吃得吓人、@file 死活补全不出来。这类官方归在「性能和稳定性」里,大多跟「上下文塞太满」和「环境小问题」有关,很少是 bug。
类比:电脑越用越卡,多半是后台开太多,不是硬件坏了。 你不会一卡就送修,先关几个吃内存的程序、清一波缓存。Claude Code 卡顿一个道理——先收拾「工作台」,别急着重装。
卡顿 / 高内存:先收拾上下文
官方给的处理顺序很务实:
- 定期用
/compact压缩上下文(把对话整理成一页要点,详见第 19 篇)。 - 在主要任务之间关掉再重启 Claude Code。
- 把大型构建目录加进
.gitignore,别让它去扫。
如果这么做内存还是高,可以跑 /heapdump——它会把一份 JavaScript 堆快照写到 ~/Desktop(Linux 上没桌面就写主目录),报内存问题时把它附在 GitHub issue 上。这命令你日常用不到,知道有这么个东西就行。
关于「卡死、转圈不动」:官方说得很干脆——先按 Ctrl+C 试着取消当前操作;要是彻底没反应,关掉终端重启。重启不会丢对话,在同一目录跑
claude --resume就能接着上次的会话往下走。
自动压缩「抖动」:一个新手会被吓到的报错
你可能撞见这行:Autocompact is thrashing: the context refilled to the limit...。别慌——意思是自动压缩成功了,但有个超大文件或工具输出立刻又把上下文塞满了,Claude Code 为了不空转烧 API 调用,主动停了重试。恢复办法:让它分块读那个超大文件(指定行范围或某个函数,别整文件读),或者 /compact 时点名「只保留计划和 diff」,再不行就 /clear 重开。
搜索 / @file 补全失灵:换个 ripgrep
如果搜索工具、@file 提及、自定义 skill 找不到文件,多半是 Claude Code 自带的那个 ripgrep(一个高速搜索工具)在你系统上跑不起来。官方解法是装系统版的 ripgrep 再让 Claude Code 改用它:
# macOS
brew install ripgrep
然后在环境变量里设 USE_BUILTIN_RIPGREP=0(环境变量怎么配详见第 42 篇)。
这里给一张性能类的「症状 → 先做啥」速查:
| 症状 | 先做这个 |
|---|---|
| 越用越慢、内存高 | /compact,然后重启 Claude Code |
| 彻底卡死、转圈不动 | Ctrl+C;不行就关终端,claude --resume 续上 |
看到 Autocompact is thrashing | 让它分块读大文件 + /compact keep only ... |
@file 补全 / 搜索找不到文件 | 装系统 ripgrep,设 USE_BUILTIN_RIPGREP=0 |
| 集成终端里文字乱码、糊成方块 | 在 Claude 里跑 /terminal-setup 关掉 GPU 渲染 |
最后那条「乱码」在 VS Code 内置终端里偶尔会撞见,整屏字符糊成豆腐块,挺唬人。跑个 /terminal-setup 把终端的 GPU 加速关掉,重载窗口就清爽了——纯渲染问题,跟 Claude 本身没关系。
💡 一句话总结:性能问题先怀疑「上下文太满」——
/compact+ 重启是万金油;卡死按 Ctrl+C /claude --resume;搜索失灵换系统ripgrep;终端乱码跑/terminal-setup。
06 API 报错类:蹦红字了,先分清「是不是你的锅」
第四类是会话里直接蹦出一行 API Error: ...。新手一看红字就慌,其实这类最该做的,是先分清这报错是「服务器那头的事」还是「你这头的事」——两者的处理方式完全相反。
类比:网页打不开,先分清是网站挂了还是你断网了。 网站挂了你刷新一百遍也没用,等它修;你断网了那才该去查自己的路由器。API 报错一个逻辑——先判断锅在谁那儿,再决定是「等」还是「改」。
先记住:Claude Code 早就帮你自动重试过了
官方有个机制值得先知道:服务器错误、过载、超时、临时限流、断连,Claude Code 都会自动以指数退避重试最多 10 次,重试时你会看到转圈旁边显示 Retrying in Ns · attempt x/y 的倒计时。所以——当你真看到一行报错时,意味着这些重试已经全用完了,不是它一下就放弃了。
三大类报错,三种应对
我把官方那张超长报错表归成你最该分清的三堆:
| 报错长这样 | 锅在谁 | 你该干嘛 |
|---|---|---|
API Error: 500 / 529 Overloaded / Server is temporarily limiting requests | 服务器(不是你) | 等一会儿重试;查 status.claude.com;/model 换个模型(容量是按模型算的) |
You've hit your session/weekly/Opus limit | 你的额度用完了 | 等重置时间;/usage 看额度;/usage-credits 加购或升级套餐 |
Prompt is too long / Request too large | 你的请求太大了 | /compact 或 /clear;超大文件按路径让它分块读,别整段粘贴 |
这三堆的处理逻辑天差地别:第一堆「等就完了」,第二堆「掏钱或等重置」,第三堆「精简你的输入」。分不清就容易做反——服务器在抖你却在删自己的对话,或者额度满了你却以为是 bug 一直重试。
还有一类是连不上 API(Unable to connect to API、fetch failed、Request timed out 带「检查网络」字样)——这通常不是 Anthropic 的事,是你这头的网络、VPN、代理或防火墙。第一步先在同一个终端里验证你能不能摸到 API 主机:
curl -I https://api.anthropic.com
通了说明网络没问题,问题在更上层(比如代理 / 证书);Could not resolve host 或超时就是网络被挡了。国内用户这里十有八九是要开魔法上网;公司网络后面则多半得配 HTTPS_PROXY。如果是慢网络老超时,可以把单次请求超时调长——官方给了两个旋钮(环境变量配法详见第 42 篇):
| 环境变量 | 默认值 | 干嘛的 |
|---|---|---|
API_TIMEOUT_MS | 600000(10 分钟) | 单次请求超时,慢网络 / 代理就调大 |
CLAUDE_CODE_MAX_RETRIES | 10 | 自动重试次数,脚本里想快点失败就调小 |
两个新手高频、又容易误解的报错
model not found / you may not have access to it:配置的模型名没被识别,或你账户没权限。先在交互式 CLI 里敲 /model 从可用模型里重选。如果错误的模型老是冒出来,说明某处设了过时的模型 ID——按优先级查:--model 标志 → ANTHROPIC_MODEL 环境变量 → settings.local.json → 各级 settings.json 里的 model 字段,把过时值删掉就回落到账户默认了。官方还有个实在建议:用别名(如 sonnet、opus)而不是写死的版本号 ID,别名会自动跟最新版,不会过时(/model、ANTHROPIC_MODEL 等配置方式详见第 04 篇 API 配置)。
Claude Code is unable to respond to this request, which appears to violate our Usage Policy:使用政策检查拦下了。注意一个反直觉的点——这个检查评估的是整段对话,不只是你最后那句,所以在同一会话里换句话再发,往往还会触发同样的拒绝。正确做法是按两下 Esc 或 /rewind 回退到触发那一轮之前(详见第 37 篇),换个表述或思路;实在找不到是哪轮,/clear 重开一段对话。
💡 一句话总结:API 报错先分三堆——
5xx/529是服务器的锅(等 + 查状态页 + 换模型)、hit your limit是额度(等重置或加购)、too long/too large是你输入太大(/compact/ 分块读);Unable to connect是你这头的网络(curl验主机、必要时开魔法上网 / 配代理);模型报错优先用别名、查过时 ID。
07 杀手锏:--debug 调试日志 + 干净配置对照法
前面六类覆盖了九成情况。但总有那么一两次,症状怪、按文档查也定位不到。这时候祭出两个进阶武器,基本能把最刁钻的问题也逼出来。
类比:查电路故障,万用表 + 逐个拔插。 修电路的老师傅遇到说不清的故障,一是拿万用表实时量哪段电压不对(看实时日志),二是把电器一个个拔下来试、看拔哪个故障消失(逐个排除)。排查 Claude Code 的两个杀手锏,正是这两招的翻版。
武器一:--debug 实时看它在干啥
光看结果猜不出原因时,带 --debug 启动,让它把内部过程打出来给你看。针对不同问题还能加子标志,精准只看你关心的那部分:
| 命令 | 用来查 |
|---|---|
claude --debug | 通用调试日志,看整体在干啥 |
claude --debug mcp | MCP server 启动 / 连接的 stderr 输出(server 显示连上却零工具时用它) |
claude --debug hooks | 实时看每个 hook 事件、匹配了哪些 matcher、退出码和输出(hook 不触发时用它) |
还有个会话内的入口 /debug [问题描述]:它为本次会话开启调试日志,并直接提示 Claude 用日志和设置路径帮你一起诊断。
用法举例:你的 hook 在 /hooks 里明明注册了却死活不跑——这时候 claude --debug hooks 启动,触发一次工具调用,日志会清清楚楚告诉你「这个事件来了,检查了哪个 matcher,匹没匹上」。比你对着配置干瞪眼强一百倍。
武器二:干净配置对照法(最被低估的一招)
这招特别值得记住,专治「到底是不是自己配置惹的祸」这种悬案。思路是:开一个啥都不加载的干净会话,跟你平时那个对照——问题要是在干净会话里消失了,那就是你自己配置里某处出了问题。官方给的命令:
cd /tmp && CLAUDE_CONFIG_DIR=/tmp/claude-clean claude
这一句把 CLAUDE_CONFIG_DIR 指向一个空目录,绕开 ~/.claude 下的一切;再从一个没有 .claude 文件夹、没有 .mcp.json、没有 CLAUDE.md 的目录(/tmp)启动,连项目配置也一并跳过。于是这个会话没有任何用户 / 项目设置、hooks、MCP、插件、内存。
- 问题在干净会话里消失了 → 根因就在你真实的
~/.claude或项目.claude里。接下来一次只加回一样(复制一个文件进去、或从你项目启动),看加回哪个问题重现,凶手就是它。 - 干净会话里照样有问题 → 那根因在你的用户和项目配置之外(可能是托管设置、环境变量,或更底层的安装问题)。
这套「二分法」是排查的通用智慧——通过「砍掉一半变量看问题在不在」来缩小范围。比如 Claude 莫名其妙不读某条 CLAUDE.md 规则,靠干净会话就能确认「不是 Claude Code 的 bug,是项目里两份 CLAUDE.md 指令打架」,省了去翻一晚上文档。
💡 一句话总结:怪问题上两个杀手锏——
claude --debug [mcp/hooks]实时看内部过程定位「为啥不工作」,干净配置对照法(CLAUDE_CONFIG_DIR指向空目录)判断「到底是不是我配置的锅」,再二分法逐个加回锁定凶手。
08 动手:给你的安装做一次完整体检
光看不练记不住。下面带你亲手把 /doctor 体检跑一遍,再顺手验证一下你的认证状态。全程不依赖任何复杂环境,装好 Claude Code 就能做。
第一步:在终端确认 claude 装对了、版本是新的
claude --version
预期:打印一行版本号,类似 2.1.xxx (Claude Code)。看到版本号 = 安装基本健康。 如果报 command not found: claude,说明安装目录不在 PATH 里——这是安装类问题,回第 02 篇按你的平台修 PATH(macOS/Linux 的本机安装在 ~/.local/bin)。
第二步:进会话,跑体检
claude
进去后敲:
/doctor
预期:弹出一份诊断面板,逐项列出安装健康状况、设置文件是否有效(无效的键 / schema 错误会被标红)、MCP server 配置、上下文使用情况。每项都没报错 = 你的配置是干净的。 要是某项被标了问题,按 f 把这份报告发给 Claude,让它陪你一条条解。
第三步:确认「当前用的是哪套凭证」
接着敲:
/status
预期:显示当前活跃的身份验证方式。如果你是订阅用户,这里应该显示订阅(OAuth),而不是某个 API key。 万一显示在用 API key、跟你预期不符——恭喜你提前抓到了开头那个坑,去 shell 配置文件里 unset ANTHROPIC_API_KEY 并删掉那行 export。
第四步(可选):体验一次干净配置对照
想感受第 07 节那招,开一个啥都不加载的干净会话:
cd /tmp && CLAUDE_CONFIG_DIR=/tmp/claude-clean claude
预期:启动后这个会话没有你平时的任何 CLAUDE.md、自定义命令、MCP server(在里头敲 /memory、/mcp 会发现是空的)。这就是你日后排查「是不是我配置惹的祸」时的对照基准。注意:Linux / Windows 上它会让你重新登录(凭证存在配置目录下),macOS 因为凭证在 Keychain 里会自动带过来。玩完正常退出即可,这个临时目录不影响你真实的 ~/.claude。
跑通这四步,你就把「体检 → 看凭证 → 起干净会话对照」这条排查主干道亲手走了一遍。以后真出问题,照这个顺序来,比慌慌张张瞎试强太多了。
💡 一句话总结:动手把
claude --version→/doctor→/status→ 干净会话 这条体检链走一遍;记住「/doctor指方向、/status看凭证」,九成新手问题在这一步就现了原形。
09 小结
这一篇给你建了一套 「不靠猜、按流程」的排查框架——从「先分诊属于哪一类」到「该敲哪个命令」,再到最刁钻问题的两个杀手锏。
把核心串起来回顾:
| 你的处境 | 排查动作 | 关键点 |
|---|---|---|
| 不知道问题属于哪类 | 对症状路由表 + /doctor | 先分诊再下手,别瞎试 |
| 反复登录 / 组织被禁用 | /status 看凭证 | 多半是残留 ANTHROPIC_API_KEY 压过订阅 |
| 设置 / hook / MCP 没生效 | /context、/hooks、/mcp | 查「实际加载了啥」;当心大小写和覆盖 |
| 卡顿 / 高内存 / 搜索失灵 | /compact + 重启 / 换 ripgrep | 多半是上下文太满或环境小问题 |
蹦 API Error 红字 | 先分「服务器 / 额度 / 你的请求」 | 5xx 看状态页、limit 等重置、too long 精简 |
| 怪问题定位不到 | --debug + 干净配置对照 | 看实时日志 + 二分法砍变量 |
你现在应该能: 遇到任何 Claude Code 的毛病,不再对着报错干慌——先用症状路由表认清这是哪一类,敲 /doctor 体检指方向、/status 看凭证;按类别(安装 / 认证 / 配置 / 性能 / 报错)对症下药;实在刁钻就上 --debug 看日志、用干净配置对照法把根因二分出来;真搞不定就 /feedback 上报。这套流程练成肌肉记忆,你就从「一报错就懵」升级成「一报错就知道该往哪查」了。
到这儿,从「装上」到「用顺」再到「出问题怎么救」,整套实操你都过了一遍。剩下的,就是把这一路冒出来的术语彻底捋清楚。
下一篇 52「术语表(小白友好)」——这一路读下来,CLAUDE.md、上下文窗口、MCP、Subagent、Hook、检查点、auto-compact……几十个名词在你脑子里来回飞。下一篇给你做一份小白友好的术语表:每个词一句话说人话、配一个最贴切的类比,按主题归好类,随时能翻、查完就懂。想想看:要是有人突然问你「token 和上下文窗口啥关系」,你现在能用一句话讲清吗?
52 · 术语表(小白友好):把这一路的「黑话」一次性翻译成人话
都说「术语表要从头到尾通读一遍打基础」,说句实话,这是最没用的读法。
学任何一门新工具,把术语表当课文从 A 背到 Z 背下来,几乎都是白费——背完转头就忘,因为那些词当时一个都没在你手里「发生」过。术语这东西,是你撞上它、被它绊一下,才会真正记住。
所以这一篇我不打算让你「读」,而是让你「查」。它是一张速查卡,不是一篇课文。 你正常往后学、往后用,哪天看到「这个 transport 到底是个啥」「auto-compact 又是什么」卡住了,翻回这一页,找到那一条,一句话加一个类比看完,继续干活——这才是术语表的正确用法。
类比:装修工地墙上贴的那张物料清单。 工地上没人会站那儿把清单从头背到尾,但每根管子、每块板材到货时,师傅会瞄一眼清单——「哦,这个是承重梁,那个是水管接头」,对上号就接着干。这张表也一样:不为通读,只为「撞上了能查到」。下面我按「主题」把术语归成几族(同一族的概念互相关联,放一起比按字母排好记),每条都是「术语 → 一句话 → 类比」三件套。
看完(或者说,以后用着用着翻回来)你能拿到:
- 全教程出现过的核心术语,一条不落地用小白话加类比解释清楚
- 按「主题族」归类,同族概念放一块,顺带理清它们之间的关系
- 主要条目都标了「详见第 NN 篇」编号,想深挖直接跳过去
- 一份「最容易搞混的几对术语」对照,撞车时回来对一眼就分清
- 一个动手小练习:用官方自带的文档 server,在 Claude 里随时查任何术语的权威定义
01 代理循环家族:Claude「干活」这件事是怎么转起来的
这一族是最该先搞懂的地基。它回答一个根本问题:Claude Code 跟一个网页聊天 AI 到底差在哪、它凭什么能「自己动手」。其余所有术语,几乎都挂在这套循环上。
类比:一条会自己转的流水线。 普通聊天 AI 是「你问一句、它答一句」,像点餐窗口;Claude Code 是一条自己会转的流水线——拿到活儿后,自己取料、自己加工、自己质检,转完一圈再看要不要再转一圈。下面这几个词,就是这条流水线上的不同零件。
Agentic loop(代理循环)
一句话: Claude 处理每个任务时反复转的那个圈——收集上下文 → 采取行动 → 验证结果 → 不够就再来一圈,直到完成。
类比:厨师颠勺的节奏。 不是把所有料一次性倒进锅就完事,而是「下料 → 翻炒 → 尝一口咸淡 → 不够再调」,一个节奏一个节奏地逼近那盘菜。每次「尝一口」(工具返回的结果)都告诉它下一步该往哪走。你随时能喊停、改方向。(详见第 03 篇)
Agentic coding(代理式编程)
一句话: 一种工作方式——AI 能自主读文件、跑命令、改代码,你在旁边看着、随时纠偏或干脆走开,而不是它给你一段文字让你自己照着敲。
类比:请了个能上手的师傅,而不是一本说明书。 说明书只能告诉你「该怎么做」,师傅是直接帮你做了。Claude Code 属于能动手的那种,靠的就是它手里那些工具。(详见第 01 篇)
Agentic harness(代理外壳)
一句话: 把一个语言模型「武装成」能干活的编程代理的那一整套外围——文件访问、shell 执行、权限控制、记忆加载、把动作串起来的循环。Claude Code 是外壳,Claude 是里头的模型。
类比:车壳和发动机。 同一台发动机(模型)装进不同的车壳,开起来体验天差地别。harness 就是 Claude Code 这层车壳,它决定了模型能摸到哪些东西、按什么规矩动手。(详见第 03 篇)
Tool(工具)
一句话: Claude 能实际执行的动作——读文件、改代码、跑 shell 命令、搜网页、派 subagent;没有工具,它就只能动嘴回文字。
类比:流水线工位上的那些设备。 光有个聪明大脑没用,得有机械臂、传送带、检测仪它才能真把活干出来。工具就是 Claude 的「手」,每用一次都返回一个结果,喂给代理循环里它的下一步决策。(详见第 03 篇)
Turn(回合)
一句话: 从你发一条消息开始,到 Claude 把这次响应彻底说完为止,算一个完整回合;中间它可能调用任意多次工具。
类比:你点一次单、厨房出一道菜。 你说一句需求是「点单」,Claude 中间切菜、翻炒、装盘(调一堆工具)你不用管,最后端上来这一整套算「一道菜出齐」。一次会话由很多个回合串成。(详见第 03 篇)
Verification loop(验证循环)
一句话: 让 Claude 知道「活儿是真干完了,不只是看起来像」的机制——你给它一个能跑的检查(测试、构建、截图对比),它就反复改到检查通过为止。
类比:交作业前自己先对一遍答案。 没有标准答案时,「写完」全凭感觉;给它一份能自查的答案,它才会改到对为止,而不是写一遍就交。无人值守跑长任务时,这一条是命根子——没有它,判断「干完没」的只有它自己。(详见第 49 篇)
Extended thinking(扩展思考)
一句话: 模型在正式回答前那段看得见的逐步推理,在终端里以灰色斜体显示;可以用 MAX_THINKING_TOKENS 或调 effort level 控制它想多少。
类比:解题前先在草稿纸上演算。 不是张口就答,而是先把推导过程写出来——你能看到它「怎么想的」,错了也好定位是哪一步歪了。(详见第 35 篇)
Effort level(努力级别)
一句话: 一个设置,控制 Claude 每个回合花多少「思考预算」——级别越高想得越深、越慢越贵,越低越快越省。
类比:考试时给一道题分配多少时间。 选择题扫一眼就填(低 effort),压轴大题多花十分钟细想(高 effort)。简单活儿调低省钱,硬骨头调高求质量。(详见第 35 篇)
💡 一句话总结:这一族讲的是 Claude「会自己动手」这件事的运转机制——核心是「想→做→看」的代理循环,工具是它的手,harness 是把模型武装起来的车壳,extended thinking 是它的演算草稿、effort level 是给思考分配的时间预算,验证循环是它的质检员。
02 上下文家族:Claude 的「记性」和「桌面」有多大
学会第一族,你就会立刻撞上第二族——Claude 不是记性无限的。这一族所有词,都围绕「它一次能记住多少、记满了怎么办、换任务了怎么清」打转。卡过「它怎么把我前面说的忘了」的人,答案全在这儿。
类比:一张就那么大的工作台。 你趴在桌上画图,桌面就那么大;图纸、参考书、草稿越铺越多,迟早摊不下,得收拾。Claude 的「记性」就是这张桌子,下面这几个词讲的全是「桌子多大、满了咋办」。
Context window(上下文窗口)
一句话: 一次会话的「工作内存」——装着对话历史、文件内容、命令输出、CLAUDE.md、加载的 skill、系统指令,就这么大,装满为止。
类比:工作台的台面面积。 台面越大,能同时摊开的资料越多;摊满了,新东西放上去就得先挪走旧的。跑 /context 能看到现在台面上都摆了些啥、谁占地方。(详见第 19 篇)
Token
一句话: 模型处理文字的最小计量单位,大致是「半个到一个汉字、一个英文词的一部分」;上下文窗口的大小、计费,都按 token 算。
类比:文字的「计价字数」。 寄快递按重量算钱,模型按 token 算「量」——你喂进去多少、它吐出来多少,都折成 token 计进那张工作台的占用和账单里。(token 的底层细节属于模型层概念,本教程不展开,够用就行)
Compaction(压缩)
一句话: 上下文快装满时,自动把对话「总结成精简版」腾地方——先清掉老的工具输出,再概括对话;跑 /compact 可手动触发。
类比:把摊了一桌的草稿纸,整理成一页要点。 草稿太多桌子放不下,你把关键结论抄到一张纸上,其余的收走——信息主干还在,占地小了。注意:项目根目录的 CLAUDE.md 和 auto memory 在压缩时会保留并从磁盘重读,只在聊天里临时说过的话可能被压没。(详见第 19 篇)
Auto-compact(自动压缩)
一句话: 不用你喊,上下文接近上限时系统自动触发的那次压缩。
类比:流水线上的自动卸料。 料斗快满了,传送带自己启动把多余的卸走,不用你按按钮。它跟手动 /compact 干的是同一件事,区别只在「谁来按下启动键」。(详见第 19 篇)
Session(会话)
一句话: 跟你当前目录绑定的一段对话,有它自己独立的一块上下文窗口;/clear 开新会话,旧的存着可 /resume 找回。
类比:换个全新任务,干脆收拾干净台面再开工。 上一个活儿的草稿留在台上只会碍事,清空台面(开新会话)从头铺,脑子清爽。每段会话的记录都存在 ~/.claude/projects/ 下,所以哪怕关了终端,回头还能 claude -c 接着上次聊。(详见第 19 篇)
CLAUDE.md
一句话: 你写给 Claude 的常驻说明书,每个会话一开就自动加载,放「项目约定、构建命令、永远做 X」这类始终生效的规矩。
类比:给新员工的入职手册。 每天来的可能是个「失忆的新人」,但只要手册钉在那儿,他一上工先读一遍,就知道这儿的规矩。建议控制在 200 行内,太长就把参考资料挪进 skill。(详见第 18 篇)
Auto memory(自动记忆)
一句话: Claude 根据你的纠正和偏好,给自己写的笔记,按 git 仓库存在 ~/.claude/projects/ 下,会话开始时加载索引的开头一截。
类比:还是显示器旁那两张纸,但这张是它自己写的。 CLAUDE.md 是你钉上去的规矩,auto memory 是它自己记的小抄——「上次他纠正过我别用 npm」这种,它记下来下次不再犯。一个你写、一个它写,是一对。(详见第 25 篇)
Rules(规则文件)
一句话: 放在 .claude/rules/ 里、跟 CLAUDE.md 一起加载的模块化指令文件,可以用 paths: 限定「只在 Claude 读到匹配文件时才加载」,让上下文保持精简。
类比:按工种分册的施工规范,用到哪本翻哪本。 CLAUDE.md 是总则人人先读;rules 是「电工规范」「水管规范」分册,碰到对应活儿才翻出来——不相关的不占桌面。(详见第 13 篇)
Output style(输出样式)
一句话: 一项配置,改写 Claude 的系统提示来调整它回应的行为、语气和格式;内置有 Default、Proactive、Explanatory、Learning 几种。
类比:同一个主持人,换一档节目的风格。 还是这个人,但「新闻播报」和「脱口秀」的语气、节奏完全不同。output style 调的就是这个「节目档」,跟 CLAUDE.md(作为用户消息传进去的规矩)是两回事。(详见第 32 篇)
💡 一句话总结:这一族全在讲「记性与说话方式」——上下文窗口是工作台台面,token 是计价单位,压缩是台面满了的整理动作,会话是一次独立的开工,CLAUDE.md / auto memory / rules 是钉在桌边的几类备忘,output style 是换一档说话风格。
03 扩展点家族:给 Claude「加装备」的那几样
这一族是整套教程的重头——怎么把 Claude 从「开箱能用」改造成「贴合你的活儿」。第 30 篇专门讲过这几样怎么选,这里只做「一句话加类比」的速查。它们的共同点:都是插在代理循环不同位置上的挂钩。
类比:同一个工人,给他配不同的装备包。 光人到岗还不够——给他一本工作手册(CLAUDE.md)、几本专项菜谱(skill)、一个外接扩展坞(MCP)、几个外派帮手(subagent)、几个自动卡点(hook),他能干的活儿就完全不是一个量级。下面逐个认。
Skill(技能)
一句话: 一个 SKILL.md 文件,装着一段知识、套路或流程;相关时 Claude 自动把它调进来用,你也能 /<名字> 主动唤它。
类比:手机里的快捷指令。 「回家模式」一点,关灯、开空调、放音乐一串动作自动跑完——你不用每次重说一遍流程。skill 就是 Claude 的快捷指令:把重复的套路存成一条,要用时一键调出。平时只占一行描述,用到才把完整内容加载进上下文(官方管这叫渐进式披露)。(详见第 26 篇)
Subagent(子代理)
一句话: 一个有独立上下文窗口的专项助手,带自己的系统提示和工具权限,你派活给它,它干完只把结论摘要递回主对话。
类比:把一个活儿外包给跑腿小弟。 你让他去翻三十份档案找一个数,他在外面翻得天昏地暗你这边一点不沾,回来只跟你说一句「找到了,是这个」。精髓是上下文隔离——中间过程不污染你的主桌面。内置的有 Explore、Plan 和通用三种。(详见第 23 篇)
Hook(钩子)
一句话: 在 Claude Code 生命周期的某个固定时刻(工具运行前、文件改完后、会话一开始……)自动执行的一段动作,可以是 shell 命令、脚本、通知等。
类比:流水线上的自动卡点。 传送带每过一个工位,卡点「咔哒」一下自动盖个章——不靠人盯、不靠 AI 自觉,事件一到必然触发。这点是它跟 CLAUDE.md 的根本区别:写进 CLAUDE.md 是「请求」,hook 是「保证」。(详见第 33 篇)
Command / slash command(命令 / 斜杠命令)
一句话: 你在提示里打 /名字 就能调用的可复用指令;内置的(/clear、/model、/compact)控制会话,自定义的本质就是「带 /<名字> 触发的 skill」。
类比:遥控器上的固定按键。 /clear 像「复位键」,/deploy 像你自己贴上去的「一键发版键」——按下去就跑那套固定流程。如今官方推荐用 skill 来打包多步命令。(详见第 36 篇)
Plugin(插件)
一句话: 把 skill、hook、subagent、MCP server 打包成一个可安装单元,装一次,一整套扩展点全到位。
类比:出门前装好的一只行李箱。 你不会把衬衫、剃须刀、充电器一件件抱在怀里,统统码进箱子拎走。plugin 就是这只箱子——换个项目要用同一套装备,装上这个 plugin 就齐了。里头的 skill 还带命名空间(像 /my-plugin:review),多个 plugin 各装各的也不撞名。(详见第 24 篇)
Plugin marketplace(插件市场)
一句话: 分发和获取 plugin 的来源,你可以添加一个或多个市场,从里面挑 plugin 安装。
类比:给手机装一个应用商店。 应用商店里摆着一堆 App(plugin),你挑需要的装。注意来路——从陌生网站下个 .exe 双击运行的风险,装来历不明的 plugin 一样有。(详见第 38 篇)
💡 一句话总结:这一族是「加装备」——skill 是快捷指令、subagent 是外派帮手、hook 是自动卡点、command 是遥控器按键、plugin 是装备行李箱、marketplace 是应用商店;它们都插在代理循环的不同位置上。
04 MCP 家族:把 Claude 接到「外部世界」的那套接口
扩展点里 MCP 单拎出来说,因为它自带一窝小术语(transport、server、scope……),新手抄命令最容易在这儿翻车。第 22 篇整篇都在讲它,这里把它的「家族成员」一条条认清。
类比:一个带一堆接口的扩展坞。 笔记本机身就剩一两个口,HDMI、网线、U 盘全插不上;接个扩展坞,一根线上去全通了。MCP 之于 Claude 就是这个扩展坞——接一次,一堆外部服务的工具全摆到它面前。
MCP(Model Context Protocol,模型上下文协议)
一句话: 一套开源标准,规定「AI 工具怎么连外部数据和服务」;MCP server 给 Claude 接上 Slack、Jira、数据库、浏览器等几百种集成。
类比:USB 这个统一接口标准。 早年每个设备一种插头,乱成一团;USB 一统天下后,什么设备都能插同一个口。MCP 就是 AI 接外部工具的这个「USB 标准」——一次对接,处处能用。(详见第 22 篇)
MCP server(MCP 服务器)
一句话: 按 MCP 标准实现的一个具体「接头」,带着一组工具(比如 GitHub server 带「读 PR」「开 issue」),接上后这些工具就出现在 Claude 面前。
类比:插在扩展坞上的一个具体设备。 扩展坞是标准(MCP),插上去的打印机、硬盘是具体设备(server)——每个 server 给你接通一种外部能力。(详见第 22 篇)
Transport(传输方式)
一句话: Claude Code 和 MCP server 之间「怎么通信」的方式;日常就两种——stdio(本地进程)和 http(远程托管),外加一个已弃用的 sse。
类比:扩展坞上的设备,有的就在桌上,有的在墙那头。 stdio 是 Claude 在你本机后台拉起的一个小程序(就在手边),http 是连到某个网址上的远程服务(在墙那头)。抄命令翻车多半翻在这儿:stdio 不写 transport,http 要写 --transport http。(详见第 22 篇)
Scope(作用域)
一句话: 一个 MCP server 在「哪些项目里能用、要不要跟团队共享」——local(仅当前项目、私有)、project(写进 .mcp.json、随 git 共享)、user(你所有项目)。
类比:办公室里一台打印机怎么共享。 只连你这台电脑(local)、接进部门资产表全组能用(project)、还是你自己拎着跑各会议室(user)——三种摆法,对应三种作用域。(详见第 22 篇)
MCP Tool Search(MCP 工具搜索)
一句话: 一种省上下文的机制——启动时只加载工具的名字,Claude 真要用某个工具时才按需拉取它的完整说明。
类比:先看菜单标题,点了才翻详细做法。 菜单上几百道菜,你不会一上来把每道的详细配料都读一遍——先扫标题,决定点哪道,再翻它的细则。这样一堆闲着的 MCP server 就不会白占工作台。(详见第 22 篇)
💡 一句话总结:MCP 是「接外部世界」的 USB 标准——server 是具体接头,transport 是连线方式(本地 stdio / 远程 http),scope 是这个接头哪些项目能用;接第三方 server 前先掂量信任。
05 安全与权限家族:Claude 动手前「问不问你」
Claude 能动手了、还能接外部了,「它会不会乱来」就成了绕不开的问题。这一族讲的全是「它动手前的把关机制」——从「问一句再做」到「硬拦死某些操作」。第 20、21 篇讲透了,这里速查。
类比:开车上路的几层防护。 安全带、气囊、限速牌——一层管你自己别乱来,一层管真出事时兜底,一层划死「这条线不许越」。Claude 的安全机制也是分层的,下面这几个词分别是哪一层。
Permission mode(权限模式)
一句话: 一次会话里 Claude 动手的「基线态度」——官方共六档,包括每步都问你(default)、自动接受改动(acceptEdits)、只研究不动手(plan)、别问直接干(bypassPermissions)、自动审查(auto)、静默通过(dontAsk);完整说明见第 35 篇。
类比:实习生动手前问不问你,是你给他定的自主权等级。 同一个实习生,你可以让他「每件事都先问」,也可以放权「这类小事自己看着办」。模式就是你给他设的这个等级,在 CLI 里按 Shift+Tab 循环切换。(详见第 35 篇)
Plan mode(计划模式)
一句话: 一种权限模式——Claude 只读、只搜、只研究,不碰你的源文件,先把改动方案列出来给你批,你点头了才动手。
类比:装修先出图纸,砸墙前先给你看。 不许它上来就抡锤子,得先画好「这面墙拆、那根管改」的图纸,你确认再施工。大改动前用它最稳。(详见第 35 篇)
Auto mode(自动模式)
一句话: 一种权限模式——后台有个独立的分类器模型逐个审查操作,挡掉越权、可疑基础设施和提示注入,而不是每步都弹窗问你;目前是研究预览。
类比:门口有个不看货、只查证件的保安。 它专门盯「这个操作越不越界」,而且永远看不到工具返回的内容,所以藏在工具结果里的恶意指令影响不了它的判断。(详见第 35 篇)
Permission rule(权限规则)
一句话: 按「工具名加参数模式」来 allow / ask / deny 的细粒度设置条目,按 deny→ask→allow 顺序匹配,先中者胜。
类比:门禁系统里一条条具体的放行 / 拦截规则。 「这张卡能进 3 楼、不能进机房」——规则比「权限模式」这个大基线更细,是叠在它上面的精确控制。(详见第 20 篇)
Sandboxing(沙箱)
一句话: 给 Bash 工具套一层操作系统级的文件和网络隔离——Claude 在你划定的边界内自由跑,不用每条命令都弹窗批准。
类比:专用试车场里飙车,墙是物理的。 场子里随便开多快都行,因为四周的墙是真的拦得住,出不去。沙箱就是这堵墙,跟权限规则是分开的另一层防护。(详见第 21 篇)
Prompt injection(提示注入)
一句话: 藏在文件、网页或工具结果里的恶意指令,试图把 Claude 带去做你从没要求的事。
类比:接到一个照着话术念的诈骗电话。 对方语气正常、内容却是「你现在按我说的转账」——提示注入就是塞进数据里的这种「话术」,Claude 读进去就可能被带偏。抓外部内容的 MCP server 风险尤其高。(详见第 21 篇)
Checkpoint(检查点)
一句话: 在你每次发提示时自动建的「还原点」,Claude 改文件前先快照;按两次 Esc(输入框需为空)或 /rewind 打开回溯菜单,可选恢复代码、对话或两者到早先某个提示点。它是会话本地的,跟 git 分开。
类比:打游戏的存档读档。 走错一步,读个档退回上个存档点重来,不用从头玩。注意它不跟踪通过 Bash 工具做的改动——那些得靠 git 或别的方式兜。(详见第 37 篇)
💡 一句话总结:这一族是「动手前的把关」分层——权限模式是大基线(问不问你)、权限规则是细则、沙箱是物理隔离的墙、auto mode 是查证件的保安、checkpoint 是存档读档;提示注入是要防的那种「话术攻击」。
06 入口与运行模式家族:你从哪儿用它、它怎么个跑法
最后一族最杂,但都归一类问题:你在哪儿、用什么姿势跟 Claude Code 打交道。终端、VS Code、网页、还是塞进脚本里自动跑——形态不同,但底下是同一个引擎。
类比:同一个工人,有好几种到岗方式。 他可以来你办公室坐班(终端 / 编辑器)、远程在线办公(网页)、也可以你发个工单他自动接活儿(脚本调用)。人和本事是同一个,只是「在哪儿、怎么个到岗法」不一样。
Surface(交互入口)
一句话: 你访问 Claude Code 的任何地方——CLI、VS Code、JetBrains、桌面端、claude.ai;所有入口共用同一个引擎,你的 CLAUDE.md、设置、skill 在哪儿都一样使。
类比:同一品牌不同车型,共用一套车机系统。 轿车、SUV 外形不同,但车机界面、操作逻辑一模一样,上手零成本。换入口用 Claude Code 也是这感觉。(详见第 08 篇)
Non-interactive mode(非交互模式 / 旧称 headless)
一句话: 用 -p(或 --print)跑——执行单条提示、出结果就退出,不进对话会话;专门给 CI、脚本、流水线用。旧文档里叫 headless mode,是同一个东西。
类比:发一张工单,他干完交活就走,不跟你唠。 不是坐下来你来我往聊,而是「这件事,做完给结果」。它的 Python / TypeScript 等价物是 Agent SDK。(详见第 45 篇)
Agent SDK(代理 SDK)
一句话: 把 Claude Code 的能力搬进你自己程序的开发包(Python / TypeScript),让你在代码里像调函数一样驱动它。
类比:把整台咖啡机的机芯拆出来,装进你自己的产品里。 不再是用现成的咖啡机,而是拿到机芯自己造一台。非交互模式是命令行版,Agent SDK 是「写进代码」版。(详见第 45 篇)
Claude Code on the web(网页版)
一句话: 在浏览器里跑的 Claude Code,任务在云端沙箱里执行(跟「Remote Control」不同——后者代码还在你本机,只是 UI 远程)。
类比:租了台一次性云电脑,用完即焚。 活儿在云上那台临时机器里干,不占你本地环境。(详见第 11 篇)
Bare mode(精简模式)
一句话: 启动加 --bare,跳过 hook、skill、plugin、MCP server、auto memory、CLAUDE.md 的自动发现——只有你显式传的参数生效;给 CI 和脚本求「换台机器行为也一致」用。
类比:出差只带一个登机箱,家里那堆都不带。 把所有「本地个性化配置」清空,光带任务本身上路,到哪台机器跑出来都一个样。(详见第 34 篇)
Worktree isolation(工作树隔离)
一句话: 一种隔离方式,用 -w 或在 subagent 配置里写 isolation: worktree,让 Claude 在 .claude/worktrees/ 下一个单独的 git worktree、单独分支里干活,改动不会跟别的并行代理打架。
类比:同一套图纸,给每个施工队各开一个独立工地。 几队人同时干,各在各的场地,谁也不会把别人砌好的墙推倒。并行跑多个会话时全靠它隔开。(详见第 41 篇)
Remote Control(远程控制)/ Teleport(传送)
一句话: Remote Control 是从手机或浏览器接管你本机正在跑的会话(代码还在你机器上,只有界面远程);Teleport(/teleport)反过来,把云端会话拉进你本地终端接着干。
类比:给办公室那台电脑装个远程遥控器。 Remote Control 像你出门用手机遥控家里的电脑(活儿在家里跑);teleport 像把云上没干完的活儿「传送」回你面前这台机器接着干。(详见第 11 篇)
💡 一句话总结:这一族讲「从哪儿用、怎么跑」——surface 是入口(共用一个引擎)、非交互模式(旧称 headless)是发工单式跑法、Agent SDK 是写进代码、网页版在云沙箱跑、bare mode 是纯净启动、worktree 隔离让并行不打架、Remote Control / teleport 在本机与云端之间来回接管。
07 最容易搞混的几对,撞车时回来对一眼
术语多了,总有那么几对长得像、一用就纠结。把新手撞车最多的几对单独拎出来对照,你卡哪对回来扫一眼就分清。这张表也是对前面六族的一次横向收口。
| 容易混的一对 | 关键区别 | 一句话切开 |
|---|---|---|
| Skill vs Subagent | 内容进谁的上下文 | skill 加载进你主桌面用;subagent 用它自己的桌面,只把结论递回来(详见第 30 篇) |
| CLAUDE.md vs Skill | 什么时候加载 | CLAUDE.md 每会话自动加载;skill 用到才加载(详见第 30 篇) |
| Hook vs 权限规则 | 管的面 | hook 是「事件触发跑一段动作」;权限规则是「这个工具准不准」的黑白判断(详见第 30 篇) |
| Subagent vs Agent team | 你能不能直接跟它聊 | subagent 在单会话里跑、只向主对话汇报;agent team 是多个完整会话,你能直接跟任一个对话(详见第 29 篇) |
| Session vs Turn | 粒度 | 一次会话是一整段对话(独立上下文);一个回合是其中「你说一句→它答完」这一来一回(详见第 03 篇) |
Compaction vs /clear | 留不留旧内容 | 压缩是把旧对话「总结成精简版」留着;/clear 是直接清台面开新会话(详见第 19 篇) |
| Permission mode vs 权限规则 | 粗细 | 权限模式是整场的大基线(问不问你);权限规则是叠在上面的细则(这条命令准不准)(详见第 20 篇) |
| stdio vs http(transport) | server 跑在哪 | stdio 是本机后台拉起的进程;http 是连到某网址的远程服务(详见第 22 篇) |
| CLAUDE.md vs auto memory | 谁写的 | CLAUDE.md 你写的常驻规矩;auto memory 是 Claude 自己记的小抄(详见第 25 篇) |
这张表里的每一对,新手刚学时至少有四五对是真容易混的。最典型的是 skill 和 subagent——刚上手那会儿,很容易把一个「读整个目录找死代码」的活儿硬写成 skill,结果中间翻文件的过程把主对话灌得满满当当,跑两回才反应过来:只要结论的脏活,该派 subagent,不该塞 skill。
💡 一句话总结:撞车的几对,记区别的「那一个关键维度」就够了——skill/subagent 看上下文进谁的、CLAUDE.md/skill 看何时加载、mode/规则看粗细、stdio/http 看 server 跑在哪。
08 动手:让 Claude 自己当「活字典」,随时查权威定义
光有这张表还不够——术语会更新,这一篇是静态的,官方文档是活的。最稳的查法,是让 Claude 自己去查官方那份术语表。第 22 篇接过的那个「官方文档 server」正好派上用场:它免登录、免配置,接上就能问。这一节带你把它当成随身「活字典」用。
这个 server 是远程托管的 HTTP 服务,加它需要联网;国内访问
code.claude.com如果不通,先开「魔法上网」再试。
第一步:接上官方文档 server(在终端,不是在 claude 会话里)
claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcp
预期:打印一行类似 Added HTTP MCP server claude-code-docs ... 的确认。看到 Added = 配置写进去了。
第二步:确认连上了
claude mcp list
预期:列表里出现 claude-code-docs,旁边标着 ✓ Connected。看到绿勾 = 真连上;若是 ✗ Failed to connect,多半网络没通,开魔法上网再试。
第三步:进会话,点名让它查某个术语的官方定义
claude
进去后敲(点名 server,是为了让它走 MCP 查官方文档,而不是凭记忆答):
用 claude-code-docs server 查一下官方术语表里 compaction 和 context window 的定义,各用一句话告诉我
预期:Claude 第一次调这个 server 会停下来问你要不要批准(就是第 05 节权限那族里、工具首次调用要批准这一闸——归权限系统管,跟 checkpoint 是两回事)——批准它。然后它返回这两个术语的官方说明,而且输出里那个工具调用旁边会标着 claude-code-docs。看到这个标记 = 答案是真从官方文档查来的,不是模型记忆里的。
第四步:清理(可选)
claude mcp remove claude-code-docs
预期:打印移除确认,再跑 claude mcp list,它已不在列表里。
这套跑通,你就有了一个永不过时的术语查法:这一篇当速查卡,拿不准或怀疑过时了,就让 Claude 现查官方那份。核对每一条定义都靠这个——比凭记忆写一句然后心里打鼓踏实多了。
💡 一句话总结:这一篇是静态速查卡,官方文档 server 是活字典;接上它(
add→list看绿勾 → 会话里点名查 → 批准),任何术语都能现查最权威的定义,永不过时。
09 小结
这一篇不是让你背,是给你一张随身速查卡——全教程的术语按六族归好,撞上哪个翻回来一查就清。
把六族串起来回顾:
| 术语族 | 一句话定位 | 镇族术语 |
|---|---|---|
| 代理循环 | Claude「会自己动手」的运转机制 | agentic loop、tool、harness、turn、extended thinking、effort level、verification loop |
| 上下文 | 它的记性边界与说话方式 | context window、token、compaction、session、CLAUDE.md、auto memory、rules、output style |
| 扩展点 | 给它加装备 | skill、subagent、hook、command、plugin、marketplace |
| MCP | 接外部世界的 USB 标准 | MCP、server、transport、scope、tool search |
| 安全权限 | 动手前的把关分层 | permission mode、plan mode、auto mode、权限规则、sandbox、prompt injection、checkpoint |
| 入口与运行 | 你从哪儿用、它怎么跑 | surface、non-interactive(headless)、Agent SDK、网页版、bare mode、worktree 隔离、Remote Control |
你现在应该能: 看到这一路冒出来的任何一个术语,不再发懵——知道它属于哪一族、一句话是啥、配个什么类比好记;遇到 skill vs subagent、stdio vs http 这种容易撞车的对子,回第 07 节对一眼就分清;还学会了用官方文档 server 把 Claude 当「活字典」,任何术语都能现查最权威的定义。这张速查卡放在手边,前面五十篇里那些一闪而过没记牢的名词,都有了回头查的去处。
整个正式教程到这儿基本齐活了——从「这是什么」到装好、用熟、加装备、配置优化、再到这张术语收口,该认的字你都认全了。
下一篇 53「制作视频(Remotion)〔选读〕」——这是整套教程的彩蛋篇,跳出「写代码」的框,带你看 Claude Code 还能玩点啥花的:用 Remotion(一个「用 React 代码写视频」的框架)让 Claude 帮你把一段动画视频用代码生成出来。选读,不影响主线;但想看看「AI 编程」能延伸到多远的,这一篇值得瞄一眼。想想看:既然视频能用代码写,那让 Claude 来写这段代码,是不是又是一个「描述需求、它出活」的活儿?
53 · 制作视频(Remotion)〔选读〕
📌 关于本篇的定位:Claude Code 官方文档没有 Remotion 专页——这不是 Claude Code 的内置功能,而是「拿 Claude Code 去写另一个框架的代码」的一种用法。所以本篇的技术事实基于 Remotion 的通用知识 + 教程实践,不引官方 Claude Code 文档(因为它压根没讲这个)。归到「选读」,是因为它确实是个边角料:大多数人用不上,但用得上的人会觉得「卧槽这也行」。
兄弟们,先甩个数据给你找找感觉。
Remotion 这个开源项目,在 GitHub 上攒了五万多颗 star。 一个「用 React 写视频」的框架,能有这个量级的关注度,本身就说明一件事——「把视频当代码来写」不是小众极客的自娱自乐,是真有人靠它干活。
最出圈的一个用法是这样的:某些产品给每个用户生成「专属年度总结视频」——你的播放时长、你听得最多的歌、你的排名,几万个用户就是几万条内容不同但模板一致的视频。这种活儿你让剪辑师用 Pr、AE 一条条剪?剪到天荒地老。但如果视频是一段能传参数的代码,那就是一个循环的事——换个数据,渲染一条新的。
说到「能传参数的代码」,你是不是想起谁了?对,正是 Claude Code 的主场。 视频一旦变成 React 代码,那它就跟你前面五十二篇里折腾的任何代码没区别了——你描述需求,它写、它改、它调。这一篇就带你看明白这套组合到底怎么玩,以及最关键的:它适合你吗?
看完这一篇,你会拿到:
- 一句话讲明白 Remotion 是什么、它凭什么能「用代码做视频」
- 为什么 Remotion 和 Claude Code 是绝配——视频变代码,代码就是 Claude 的活儿
- 一套「从空目录到一个 mp4」的最小流程,每步给了预期输出,能照着跑
- 三个核心概念(帧、插值、弹性)的小白版解释,看懂 Claude 生成的代码在写啥
- 一张「谁该用 / 谁别碰」的对照表,帮你判断要不要在这上面花时间
01 先搞懂:Remotion 凭什么能「用代码做视频」
先给结论:Remotion 就是把「视频的每一帧」变成一张 React 渲染出来的画面,再把这些画面按顺序拼成视频。 你不再用鼠标在时间轴上拖素材,而是写代码描述「第几帧长什么样」。
这听着有点反直觉——视频不都是拍出来、剪出来的吗?怎么还能「写」出来?关键在于它做的是哪一类视频:不是真人出镜、实拍剪辑那种,而是文字动画、数据图表、Logo 片头、代码演示这类「画面完全由规则生成」的视频。这类东西本来就没有「拍摄」一说,全是「按规则画」——而「按规则画」,正是代码最擅长的。
类比:小时候玩的翻页动画书(flip book)。 你在便签本每一页角上画一个小人,第一页他抬左脚、第二页抬右脚、第三页跳起来……单看每一页都是静止的一张图,但你拇指飞快一翻,小人就跑起来了。视频的本质就是这么回事——一堆静止画面,放得够快,眼睛就看成了连续动作。Remotion 干的事,就是让你用代码画这本翻页书的每一页:你写一个函数,告诉它「第 0 页文字在屏幕外、第 30 页滑到中间」,它就把中间每一页该画成啥样算出来、画出来、连成视频。
落到真实场景,下面这几类视频用 Remotion 做就特别顺:
- 数据可视化视频:一个数字从 0 涨到一百万的弹跳动画、一张随时间生长的柱状图——数据驱动,代码一控一个准
- 批量个性化视频:上面说的「年度总结」那种,同一个模板灌不同数据,循环渲染几千条
- 技术演示 / 教程片头:代码块逐行高亮、终端打字效果、Logo 砸入画面——程序员做自己的演示视频,比学 AE 快多了
举个常见的场景:想给一个小工具做个 15 秒的发布预告。不会 After Effects,找剪辑外包又觉得为 15 秒不值当。这时候让 Claude Code 配 Remotion,从空目录到一条能看的 mp4,前后一个多小时——其中大半时间还是在反复调「这个字飞得太快了」「背景太丑了」。这事儿要搁以前,软件都还没装明白。
为了让你一眼看清 Remotion 在「做视频」这件事里的位置,我把它和你大概率听过的另外两类工具并排放一下:
| 工具类型 | 怎么做视频 | 强在哪 | 弱在哪 |
|---|---|---|---|
| 剪辑软件(剪映 / Pr / AE) | 鼠标拖素材、手 K 关键帧 | 真人实拍、自由创意、所见即所得 | 不能批量、改一处要手动、学起来慢 |
| 在线模板(各种「一键生成」站) | 套现成模板填内容 | 快、零门槛 | 模板套死、改不动细节、风格千篇一律 |
| Remotion | 写代码描述每一帧 | 精确可控、能批量、能进 git、能复用 | 不碰实拍、要点编程环境(但有 Claude 顶上) |
看这张表你就明白它的生态位了——它不跟剪映抢「剪生活视频」的活,也不跟在线模板抢「随手出一张」的活,它专攻那块「要精确、要批量、要可复用」的硬骨头。而它唯一的门槛「要会写代码」,恰好被 Claude Code 给抹平了。
💡 一句话总结:Remotion 把视频拆成一帧一帧的 React 画面,你用代码描述「第几帧长什么样」,它负责画出来拼成片子;它擅长的是文字、数据、Logo 这类「按规则生成」的视频,不跟剪辑软件抢实拍、不跟在线模板抢「随手出图」,专攻「精确 + 批量 + 可复用」那一块。
02 为什么 Remotion 和 Claude Code 是绝配
上一节最后那句话其实已经点透了——视频一旦变成代码,做视频就变成了写代码,而写代码是 Claude Code 的本行。 这就是这俩凑一块儿的全部理由。
我把这事儿展开说清楚。传统做动效视频,门槛卡在哪?卡在软件:你得会用 After Effects 或 Pr,得懂关键帧、缓动曲线、图层蒙版那一整套「软件操作」。这套东西学起来不快,不少程序员都卡在「想做个动画但懒得学 AE」这一步。
类比:你不会 After Effects,但雇了个懂 React 的动效师傅坐你旁边。 你不用碰那些复杂软件,只要跟师傅用大白话说需求——「我要一行字从左边飞进来,停一下,再变成绿色发光」——师傅听懂了,转身把对应的代码写出来。Remotion 提供了「视频能用代码写」这个可能性,Claude Code 就是那个帮你把需求翻译成代码的师傅。你负责审美和拍板,它负责动手敲。
这套配合的妙处,在于它完美踩中了 Claude Code 最擅长的几件事:
| 做视频的环节 | 传统方式(手动) | Claude Code + Remotion |
|---|---|---|
| 从零搭项目 | 自己配 React、装依赖、建目录 | 一句话让它把项目脚手架全搭好 |
| 写动画逻辑 | 在 AE 里手 K 关键帧 | 你描述效果,它写 interpolate/spring 代码 |
| 改一个细节 | 软件里翻图层找参数 | 「第 2 个场景字太小」→ 它定位代码改掉 |
| 批量出不同版本 | 一条条另存为重做 | 改个参数循环渲染,几千条不在话下 |
看「改一个细节」这行最能体会爽点。你在预览里看到「这个卡片入场太快了」,搁 AE 你得在一堆图层里翻出那个关键帧;而这儿你只要在终端打一句「FeaturesScene 里卡片的入场动画慢一点」,Claude 自己去对应的 .tsx 文件里把那个数值调小——预览还会热更新,你立刻看到效果。这种「自然语言改视频」的体验,实测下来是这套组合最上瘾的一点。
这里得插一句重要前提,免得你产生误会:这套组合的核心是 Claude Code 在写 React 代码,不是 Claude Code 自己「会做视频」。 所以前面教程里讲的那一整套,在这儿全都用得上——
- 提需求越具体,它做得越准(详见第 15 篇「怎么提问」),「6 秒、1920×1080、30fps、黑底金字」比「做个酷炫片头」强一百倍;
- 用
/init或一份 CLAUDE.md 把项目约定固定下来(详见第 12、18 篇),它后续改代码就更稳; - 甚至可以挂一个专门的 Skill 把「Remotion 该怎么写」的规范喂给它(详见第 26 篇),生成的代码质量会明显不一样。
换句话说:Remotion 这部分你不用从头学,你前五十二篇练的「怎么指挥 Claude Code 写代码」的功夫,在这儿直接复用。
💡 一句话总结:Remotion 把视频变成 React 代码,而写 React 代码正是 Claude Code 的本行;你负责用大白话提需求和审美拍板,它负责搭项目、写动画逻辑、按你的反馈改——前面学的指挥 Claude 写代码那套,原样搬过来就行。
03 三个核心概念:看懂 Claude 生成的代码在写啥
你完全可以不懂代码,光靠嘴指挥 Claude 也能做出视频。但只要花三分钟认识三个词,你看它生成的代码就不再是天书,改起来也更有底气。这三个词是 Remotion 的全部地基:帧、插值、弹性。
帧(frame):视频是按「第几帧」算的
回到翻页书的类比——视频的最小单位是「帧」,也就是翻页书的「一页」。Remotion 里有个核心函数 useCurrentFrame(),它告诉你「现在画的是第几帧」。你的整个动画,本质就是一句话:「在第 frame 帧,画面该是什么样」。
帧和时间的换算就一个公式,记住它你就能看懂所有时长设置:
总帧数 = 秒数 × 帧率(fps)。比如 6 秒、30fps 的视频,就是 6 × 30 = 180 帧。
所以你在代码里看到 durationInFrames={180} 配 fps={30},脑子里立刻反应过来:这是个 6 秒的片子。(fps 即 frames per second,每秒多少帧;30fps 流畅,60fps 更丝滑但文件更大。)
插值(interpolate):把「从 A 到 B」平滑算出来
interpolate() 是用得最多的函数,干的事一句话能说清:给两个时间点和两个值,它帮你算出中间每一帧的过渡值。
举个最直白的例子——你想让一行字在前 30 帧里从「完全透明」淡入到「完全不透明」:
import { interpolate, useCurrentFrame } from "remotion";
const frame = useCurrentFrame();
// 第 0 帧时 opacity=0,第 30 帧时 opacity=1,中间自动平滑过渡
const opacity = interpolate(frame, [0, 30], [0, 1]);
读这段代码:interpolate(frame, [0, 30], [0, 1]) 翻成人话就是「当 frame 从 0 走到 30,把值从 0 平滑拉到 1」。Claude 写淡入淡出、位移、缩放、旋转,底层全靠它。你看到 interpolate 就知道:这儿有个东西在「从某状态平滑变到另一状态」。
弹性(spring):让动画「Q 弹」而不是直愣愣
spring() 是让动画带物理弹性的函数。interpolate 出来的是匀速直线运动,看着「机械」;spring 模拟的是弹簧那种「冲过头再弹回来」的手感,自然得多。
有个说法很在理:用 spring() 做的弹性动画,比线性动画自然 10 倍。 拿前面那个发布预告来说,一开始 Logo 是「啪」一下硬切到中间的,丑得很;后来跟 Claude 说「让 Logo 用弹性效果弹进来」,它把 interpolate 换成了 spring,Logo 就有了那种「弹一下稳住」的高级感。所以你想让动画显得专业,提需求时直接说「用弹性缓动」——这是一条很实用的经验。
这三个概念你不用会写,认识就行。下面这张表帮你对号入座:看到哪个词,就知道 Claude 在干啥。
| 你看到的词 | 它在干啥 | 你想要时怎么跟 Claude 说 |
|---|---|---|
useCurrentFrame() | 取「当前第几帧」 | (一般不用你管,它自己用) |
durationInFrames / fps | 定视频多长、多流畅 | 「做个 6 秒、30fps 的视频」 |
interpolate(...) | 从 A 平滑过渡到 B | 「让它淡入 / 滑进来 / 放大」 |
spring(...) | 带弹性的过渡 | 「用弹性效果,弹一下那种」 |
最后把三个词串成一个完整画面,你就彻底有感觉了。下面这段是 Claude 可能生成的一个最小组件——一行 HELLO,淡入的同时带弹性放大。你不用会写,跟着右边注释读一遍:
import { interpolate, spring, useCurrentFrame, useVideoConfig } from "remotion";
export const Hello = () => {
const frame = useCurrentFrame(); // 现在画第几帧
const { fps } = useVideoConfig(); // 拿到帧率
// 前 30 帧从透明淡入到不透明
const opacity = interpolate(frame, [0, 30], [0, 1]);
// 用弹性算出缩放值,从小弹到正常大小
const scale = spring({ frame, fps, config: { damping: 12 } });
return (
<div style={{ opacity, transform: `scale(${scale})` }}>HELLO</div>
);
};
读懂它一点不难:useCurrentFrame() 取「第几帧」→ interpolate 把透明度从 0 拉到 1(淡入)→ spring 把缩放做成弹性(弹一下)→ 最后把这两个值套到那行字的样式上。整段就在回答一个问题:「第 frame 帧,这行 HELLO 该长啥样」。Claude 生成的代码再花哨,骨架也是这个套路——认出这几个词,你就能跟它讨论该改哪儿。
💡 一句话总结:三个词够你看懂代码——帧是视频的「页」(总帧数 = 秒 × fps)、
interpolate把「从 A 到 B」平滑算出来、spring让动画带弹性更自然;它们串起来就在回答「第几帧画面长啥样」,你不用会写,认得它们 + 知道用大白话怎么点单就够了。
04 最小流程全景:从空目录到一个 mp4
把整套流程在脑子里过一遍,你做视频就不会迷路。核心五步,每一步要么是你给 Claude 下指令,要么是跑一条命令看结果。
我先用一张流程图把全景画出来,再逐步拆。

这张图说的是:装好环境后,你跟 Claude 描述需求 → 它生成代码 → 你预览 → 不满意就用嘴让它改、满意就渲染成 mp4,中间「预览—改—再预览」会转好几圈,这是常态。
下面把每一步说清楚,关键的给命令和预期。
第一步:准备环境
Remotion 是基于 Node.js 的,所以你机器上得有 Node.js 18 或更高版本,外加装好的 Claude Code(装 Claude Code 详见第 02 篇)。验证 Node 版本:
node --version
预期:打印类似 v20.11.0 的版本号。只要前面那个数字 ≥ 18 就行。如果低于 18,Remotion Studio 启动会报错——这是新手最常踩的第一个坑(用 nvm 这类工具升到 20 即可)。
⚠️ 注意: Remotion 渲染视频时,底层会用到一个无头浏览器(headless Chromium,没有界面、在后台跑的浏览器,用来把每一帧「截图」下来)。首次渲染它可能要下载这个组件,国内网络如果卡在这一步,开「魔法上网」再试。
第二步:建个空目录,启动 Claude Code,把需求讲清楚
mkdir hello-video && cd hello-video
claude
进了 claude 交互界面,把你的需求一次性描述清楚。需求越具体,它一次到位的概率越高。一个最小示例提示词:
帮我用 Remotion 创建一个项目,做一个 6 秒的开场视频。
要求:1920x1080,30fps,纯黑背景;
画面中央显示 "HELLO" 几个白色大字,从透明淡入并轻微放大,
最后这几个字带一圈绿色(#67c23a)发光。
只要一个 Composition,不用拆多个场景。
注意我这个提示词里把时长、分辨率、帧率、颜色、动画方式全写死了——这正是第 15 篇反复强调的「指令要具体」。「6 秒、1920×1080、30fps、黑底白字、淡入放大、绿色发光」,比「做个酷炫片头」强太多。
你不用每次都从零想,记住一个「五要素」清单,照着填就是一条好提示词:
| 要素 | 该说清什么 | 例子 |
|---|---|---|
| 时长 | 几秒 | 「6 秒」 |
| 尺寸 + 帧率 | 投哪个平台、多流畅 | 「1920×1080,30fps」 |
| 背景 | 别只说「好看」,给具体的 | 「纯黑」「深灰到墨蓝的渐变」 |
| 主体内容 | 显示什么文字 / 数字 / 图形 | 「中央白色大字 HELLO」 |
| 动画方式 | 怎么进、怎么出、要不要弹 | 「淡入并轻微放大、用弹性效果」 |
尺寸这一项,直接说你要投的平台,比报数字更省事——抖音竖屏(1080×1920)、B 站横屏(1920×1080)、微信朋友圈方形(1:1),你说平台名,它换算尺寸。提需求基本就照这五行填,一次到位的概率明显比瞎描述高多了。
第三步:它搭项目 + 写代码
接下来 Claude Code 会自己干活:初始化 package.json、装 Remotion 依赖、建好 src/ 目录、写出那个 Composition 组件、把动画逻辑用 interpolate/spring 写好。整个脚手架它一手包办,你看着它一个个建文件就行。生成完,它通常会告诉你「装依赖、跑预览」的命令——照着做。
第四步:预览(这步最关键)
npm install
npx remotion studio
预期:终端打印类似 Remotion Studio running at http://localhost:3000,浏览器自动打开。你会看到一个带时间轴的预览界面——能播放、能拖动时间轴逐帧看效果。
这步是整个流程的核心。视频好不好,全在这儿看出来。 你拖着时间轴看,觉得「这个字飞太快了」「绿光太刺眼了」,记下来——下一步直接让 Claude 改。
第五步:不满意就让它改,满意了渲染导出
发现问题,别自己去翻代码,回到 Claude Code 终端用大白话说:
"HELLO" 淡入太快了,把淡入时间拉长到 1 秒;绿色发光弱一点。
它定位到对应代码改掉,Remotion Studio 会自动热更新,你回浏览器刷一眼就看到新效果。这个「说—改—看」的循环转几圈,调到满意为止。
满意后,渲染成 mp4:
npx remotion render HelloVideo out/hello.mp4
这里 HelloVideo 是你的 Composition ID(要和代码里注册的那个 id 一致,Claude 会告诉你叫啥),out/hello.mp4 是输出路径。预期:终端跑一个进度条,结束后打印类似 Rendered ... → out/hello.mp4。去 out/ 目录,你的 mp4 就躺在那儿了。
两个新手最容易卡的小点,这里一次说清:
Composition ID 不知道叫啥? 别瞎猜——直接问 Claude「这个视频的 Composition ID 是什么」,它告诉你;或者打开 remotion studio 预览界面,左边那一栏列出的就是所有 Composition 的名字,照着抄即可。ID 错了渲染会报「找不到这个 Composition」,这时候去那两个地方核对一下就好。
为什么不能跳过预览直接渲染? 因为渲染是「重活」,一条视频可能跑几分钟;而预览是实时的、能逐帧拖。正确姿势是:在预览里反复调到满意,最后才渲染一次出片。很多人一开始不懂这道理,每改一点就渲染一遍看效果,白白等了一堆进度条——记住「预览调、渲染出」,能帮你省下大把时间。
💡 一句话总结:五步走——装环境(Node 18+)→ 描述需求 → 它搭项目写代码 →
remotion studio预览 → 用嘴让它改 / 满意了remotion render出 mp4;其中「预览—改—再预览」会转好几圈,这是正常的,别指望一次到位,而且调试全在预览里做,渲染只在最后出片时跑一次。
05 动手:跑通一个最小示例并验证
光看流程不算数,这一节给你一套能照着敲、每步有预期的最小实战。全程不依赖你已有任何视频相关环境,只要有 Node.js 18+ 和 Claude Code。
⚠️ 提醒: 这个例子会让 Claude Code 真去联网装依赖、建文件、跑渲染,比你平时问它问题「重」一些。装依赖和首次渲染下组件可能要等几分钟,国内网络不稳就开魔法上网。
第一步:确认 Node 版本够(不够后面全白搭)
node --version
预期:打印 v18.x.x 或更高(如 v20.11.0)。第一个数字 ≥ 18 就过关。低了先升级再往下走。
第二步:建空目录,启动 Claude Code
mkdir hello-video && cd hello-video
claude
预期:进入 Claude Code 交互界面,光标在输入框等你说话。
第三步:把第 04 节那段最小需求提示词粘进去发给它
就用上面那段「6 秒、1920×1080、30fps、黑底白字 HELLO、淡入放大、绿色发光」的提示词。
预期:Claude Code 开始建文件、写代码——你会看到它创建 package.json、src/Root.tsx(或 src/index.ts)、那个动画组件等。它干活时可能会请求你批准「创建文件」「跑 npm install」这类操作(这正是第 20 篇讲的权限机制)——批准它继续。干完它会提示你下一步命令。
第四步:装依赖 + 起预览
npm install
npx remotion studio
预期:npm install 拉完依赖(第一次稍慢)。remotion studio 打印 Remotion Studio running at http://localhost:3000 并自动开浏览器,你能看到 HELLO 几个字在黑底上淡入、带绿光的预览,可以拖时间轴逐帧看。看到这个能播放的预览 = 你这条链路通了。
第五步:用一句话让它改,验证「自然语言改视频」
回到 Claude Code 终端,敲:
把 HELLO 的淡入时间拉长,慢一点进来。
预期:Claude 找到对应的 interpolate 那段代码,把过渡的帧区间改大(比如从 [0, 15] 改成 [0, 45])。Remotion Studio 自动热更新,你回浏览器看,HELLO 进场明显变慢了。看到这个变化 = 你已经掌握了这套玩法的精髓——做视频不用碰软件,张嘴就行。
第六步:渲染出 mp4
npx remotion render HelloVideo out/hello.mp4
(HelloVideo 换成 Claude 告诉你的真实 Composition ID。)预期:跑一个进度条,结束打印 Rendered ... → out/hello.mp4。打开 out/hello.mp4,一条真正的视频文件,能用任何播放器打开。
跑通这六步,你就把「确认环境 → 描述需求 → 生成代码 → 预览 → 用嘴改 → 渲染出片」这条完整链路亲手走了一遍。以后做更复杂的视频,无非是把需求描述得更细、改的轮次更多——核心流程就这些。
💡 一句话总结:动手六步——
node --version确认 ≥18 → 空目录起claude描述需求 → 它生成代码 →remotion studio预览 → 用一句话让它改看热更新 →remotion render出 mp4;亲手跑通一次,比看十遍流程图都管用。
06 谁该用、谁别碰:先想清楚再投入
这一节最实在,也是〔选读〕篇该有的态度——不是所有人都该碰这玩意儿,我直接告诉你它对谁是利器、对谁是浪费时间。
先说结论:Remotion + Claude Code 适合「程序化、参数化、要批量、数据驱动」的视频;不适合「一次性创意、真人实拍、重剪辑」的视频。 拿不准就看下面这张表对号入座。
| 场景 | 适不适合 | 为什么 |
|---|---|---|
| 给每个用户生成专属「年度总结」视频,要几千条 | ✅ 非常适合 | 同模板灌不同数据,循环渲染,正是代码的强项 |
| 数字增长、图表生长这类数据可视化视频 | ✅ 非常适合 | 数据驱动,代码精确控制,比手 K 关键帧准 |
| 程序员给自己产品做技术演示 / 片头 | ✅ 适合 | 代码高亮、终端打字、Logo 动画都好实现,省去学 AE |
| 想要每帧精确可控、可版本管理的动画 | ✅ 适合 | 视频是代码,能进 git、能 diff、能 code review |
| 婚礼 / 旅行 vlog,要剪真人实拍素材 | ❌ 别碰 | 这是剪辑活,用剪映 / Pr,Remotion 帮不上 |
| 一次性的、靠灵感的创意 MV | ❌ 别碰 | 没有「可复用模板」,写代码的成本远高于直接剪 |
| 你完全不想碰命令行、装环境都嫌烦 | ⚠️ 慎入 | 哪怕有 Claude 帮忙,装 Node、跑命令这关躲不掉 |
判断标准就一句话:这条视频是「一次性的艺术品」,还是「能换数据复用的模板」? 前者老老实实用剪辑软件,后者才轮到 Remotion 上场。前面那个发布预告之所以值得用它,是因为后面还会做第二个、第三个工具的预告——有了这套代码,下次换个文字和颜色就能再出一条,这才是它的价值所在。要是真就只做这一条、以后再不碰,那老实学十分钟剪映可能更快。
再说句可能不太中听的大实话:刚学会这套的人,很容易高估自己会用到它的频率。常见的情形是:兴冲冲搭好环境、做了个炫酷片头,然后……就没有然后了——因为平时根本没有「批量出视频」的需求。工具再酷,没有真实场景撑着,就是个一次性的玩具。 所以这里有个很务实的建议:别为了学而学。你先扪心自问一句「我手头有没有那种『同模板换数据』的视频要反复做」——有,这篇就是给你的,赶紧上手;没有,知道有这条路就够了,等真碰上了再回来翻这篇,照着五步走一遍就行。这也正是它被归进〔选读〕的原因。
还有个容易被忽略的隐性成本得提醒你:渲染要吃机器性能和时间。一条 60 秒、带特效的视频在普通笔记本上渲染两三分钟很正常——视频越长、特效越多,渲染越慢,风扇会呼呼转。好在有个省事招:渲染慢就让 Claude 加上 --concurrency 参数开多线程并行,速度能快几倍。
再说两条常见的坑,能帮你少走弯路:
第一,别一句话要它做特别复杂的视频。 要是一上来就贪心,让它做「五个场景、每个场景不同转场、还要配音乐节奏」的长视频,生成的代码很容易乱成一团,改起来比重做还累。稳妥的做法是——先让它做一个最简单的版本跑通,再一个场景一个场景地往上加。这跟第 16 篇讲的「复杂任务拆开做」是一个道理,在做视频上尤其明显。
第二,spring 动画偶尔「只显示第一帧」别慌。 有时某个带延迟的弹性动画死活不动,查下来是个已知小毛病——延迟没处理好时传给 spring 的帧数变成了负数。你不用懂原理,直接把现象告诉 Claude:「这个动画只显示第一帧,不动」,它基本一眼就知道怎么修(给帧数加个不让它变负的保护)。这也是这套组合的好处:坑你不用自己填,描述清楚交给它就行。
💡 一句话总结:判断标准就一句——「一次性艺术品」用剪辑软件、「能换数据复用的模板」才上 Remotion;数据可视化、批量个性化、技术演示是它的主场,真人实拍和一次性创意别硬凑;另外渲染吃性能和时间,长视频记得让 Claude 开
--concurrency并行。
07 小结
这一篇带你见识了 Claude Code 的一个边角玩法——让它用 Remotion 帮你「用代码做视频」。
把核心要点串起来回顾:
| 你想搞清的事 | 答案 | 一句话关键点 |
|---|---|---|
| Remotion 是什么 | 用 React 写视频的框架 | 视频 = 一帧帧的 React 画面,像翻页书 |
| 为啥配 Claude Code | 视频变代码,写代码是它本行 | 你提需求审美,它搭项目 / 写动画 / 改细节 |
| 要懂哪些概念 | 帧、interpolate、spring | 认识就行,不用会写;总帧数 = 秒 × fps |
| 怎么做 | 描述 → 生成 → 预览 → 改 → 渲染 | 「预览—改—再预览」转几圈是常态 |
| 适合谁 | 程序化 / 批量 / 数据驱动的视频 | 真人实拍、一次性创意别碰 |
你现在应该能: 一句话讲清 Remotion 凭什么能用代码做视频(每帧一张 React 画面,像翻页书)、说明白它和 Claude Code 为啥是绝配(视频变代码就是 Claude 的活儿)、看懂生成代码里帧 / interpolate / spring 在干啥、照着动手环节从空目录跑出一条真 mp4,并且最重要的——判断出这玩意儿到底值不值得你花时间。这就够了:选读篇的目的不是让你都得会,而是让你知道「还有这条路」,需要时知道去哪找。
到这儿,这一篇结束了。而它结束的同时,整套《Claude Code 小白教程》也走到了终点。 下面这段,是给一路读到这儿的你的收尾。
08 写在最后:五十三篇,咱们一起走完了
兄弟们,能读到这一篇的最后,我得先说一句:牛。
回头看这一路——
第一组咱们从「Claude Code 到底是个啥」聊起,把环境装好、把账号配通、把第一个例子跑起来,让你从「听说过」变成「手里有」。
第二组带你把它接进 VS Code、JetBrains、桌面端、网页端,又教你怎么在自己的项目里把它正经用起来——初始化、认识项目结构。
第三组是核心交互的硬功夫:怎么提问、怎么贴图、怎么写 CLAUDE.md、怎么管上下文、怎么配权限、怎么守住安全边界。这一组练扎实了,你就算真正「会用」Claude Code 了。
第四组给你递上了五件兵器——MCP、Subagent、Plugin、记忆、Skill,外加 Agent teams,还教你「啥时候抽哪一把」。
第五、六组深入系统配置与实战:settings、输出样式、Hook、CLI、检查点、Chrome、并行、Git、GitHub Actions、Agent SDK……把你从「会用」推向「用得精、用得自动化」。
第七组收尾:最佳实践、反模式、FAQ、术语表,加上你刚读完的这篇 Remotion 选读。
五十三篇,从一个命令行工具,讲到一整套能融进你工作流的代理能力。
说句心里话——这套教程从来不是让你「背命令」的。命令会变、版本会更新、新功能层出不穷(你看官方那个 changelog 多勤)。真正想留给你的,是那套「怎么和 AI 协作」的思路:把它当坐你旁边的搭档而不是查询机器、需求讲具体、该确认时确认、把反复用的东西固化下来、信任但留一道闸。这套思路,比任何一条具体命令都活得久。
最后,别把这五十三篇当终点,当起点。工具是死的,真正的功夫在你接下来用它去解决一个真问题的过程里长出来。去起一个你一直想做却没空做的小项目,让 Claude Code 陪你从零干到上线——那一刻你学到的,会比读完这五十三篇还多。
这套手艺,最好的练法永远是:关掉教程,打开终端,敲下
claude,然后开始干你自己的活。
咱们,后会有期。
16 小时 Claude Code