装好 Claude Code、跑通第一个命令之后,大多数人就停在了"把它当一个能写代码的聊天框"的层面。但 Claude Code 真正的威力,在于怎么"调教"它、怎么和它配合 —— 同样的工具,会用和不会用,产出的差距是巨大的。这篇是一份进阶使用指南:CLAUDE.md 项目记忆、高效协作的节奏、子代理、MCP、自定义命令、那些让它从"能用"变"好用"的实战习惯,以及团队里怎么用。看完你对 Claude Code 的认知,会从"一个聊天框"升级成"一个需要你会带的工程搭档"。
第一件事:写好你的 CLAUDE.md
如果只让你做一件事来提升 Claude Code 的效果,那就是 —— 在项目根目录写一个 CLAUDE.md。这是投入产出比最高的一件事,没有之一。
它是项目的"常驻记忆":Claude Code 每次开启会话,都会自动先读它。你项目里那些"没写在代码里、但团队人人默认"的约定 —— 技术栈选型、目录规范、命名习惯、错误处理方式、"我们这个项目坚决不做什么" —— 这些 Claude 是猜不到的,代码里也读不全,只能靠你明明白白写给它。
# CLAUDE.md —— 放在项目根目录,Claude Code 每次会话都会先读它 ## 项目背景 这是一个 Vue 3 + TypeScript 的后台管理系统,后端是 .NET 8 Web API。 ## 技术约定 - 组件用 <script setup> 语法,不要用 Options API - 状态管理用 Pinia,网络请求统一走 src/api/ - 样式用 UnoCSS,不要写裸 CSS ## 工作方式 - 改代码前先读相关文件,跨多文件的改动先说方案、等我确认 - 一次只推进一步,改完等我确认再继续 - 提交信息用中文,遵循 conventional commits ## 红线(绝对不要做) - 不要在组件里直接 fetch - 不要自作主张升级依赖、不要删我没让你删的文件 - 不要为了"健壮"加一堆永远走不到的兜底逻辑
有了这份文件,你就不用每次对话都重复交代一遍,而且它的产出会稳定地贴合你项目的风格。换个角度想:一个新人入职,你也得给他一份"项目说明 + 团队规范",让他知道这个项目的脾气 —— CLAUDE.md 就是写给 AI 的那份"入职文档"。
更重要的是,CLAUDE.md 是一份会"增值"的资产 —— 它不是写一次就完事的。每次 Claude 踩了一个坑、或者你纠正了它一个习惯,就往里加一条:它又一次在组件里直接发请求了,你就加一条"不要在组件里 fetch";它又自作主张升级了某个依赖,你就加一条红线。这样持续维护下去,这份文件会越来越懂你的项目,Claude 也会越用越顺手。把维护 CLAUDE.md 当成一件日常的、值得花时间的事。
第二件事:掌握"探索 → 方案 → 小步实施"的节奏
和 Claude Code 协作,最影响效率的,其实不是"它有多聪明",而是"你给任务的方式"。
最大的反模式,是一上来就甩一个大任务:"帮我重构 X 模块"、"把这个页面用新框架重写"。Claude 会基于它脑补出来的项目结构直接开写,因为它还没读你的代码,大概率会跑偏 —— 然后你返工,反而比一步步来更慢。
善用"先探索、后动手"的节奏:
✗ 低效:"帮我把用户模块重构一下"
—— Claude 基于脑补的结构直接开写,大概率跑偏,你再返工
✓ 高效:
第 1 步【探索】"先读 src/modules/user/ 下的文件,
说说现在的结构、依赖关系、你觉得的问题 —— 先别改"
第 2 步【方案】(确认理解无误后)"给我两个重构方案及各自取舍,我来选"
第 3 步【实施】"按方案 A 开始,一次只改一个文件,改完等我确认"
第 4 步【验证】"跑测试,把失败的修掉"
把大任务拆成"探索 → 方案 → 小步实施 → 验证",
是和 Claude Code 协作效率最高的节奏
高效的节奏,是把大任务拆开:先让它"读"和"说方案"(这一步要明确地不让它改代码),你确认它的理解和方案没问题,再让它小步实施、每一步都可验证。
这里面"读在写之前"这一条尤其重要。算一笔账:让 Claude 先花两分钟读一遍相关文件,成本是两分钟;它因为没读、基于错误假设写了一大段,你 review 出问题、解释、让它返工,成本是半小时起。这个账怎么算都是"先读"划算。一个实用技巧:让它读完后,别只问"懂了吗",要问"按你的理解,这个改动会动哪几个文件、大概怎么改" —— 它的回答会立刻暴露它有没有真理解。
三个层次的能力:对话、子代理、MCP
Claude Code 的能力其实分三个层次,很多人只用到了第一层:
三个层次的能力,按需使用: ┌─ 单次对话 ───────────────────────────────────┐ │ 直接提问 / 让它改代码。适合明确的小任务。 │ └──────────────────────────────────────────────┘ ┌─ 子代理(subagent)─────────────────────────┐ │ 让它派一个"分身"去做独立的子任务(大范围搜索、│ │ 并行调研),结果汇总回来,不占用主对话的上下文 │ └──────────────────────────────────────────────┘ ┌─ MCP(Model Context Protocol)───────────────┐ │ 给 Claude 接上外部工具/数据源:数据库、浏览器、│ │ 设计稿、内部 API…… 让它能直接操作真实环境 │ └──────────────────────────────────────────────┘
单次对话是最基础的,适合明确的小任务 —— 直接问它、让它改一段代码。不展开。重点说后面两个,它们才是"进阶"和"普通"的分水岭。
子代理:把脏活累活外包给"分身"
子代理(subagent)解决的是这样一类问题:你需要做一件"独立、量大、又会产生一大堆中间信息"的子任务。
典型场景:你想在整个代码库里大范围搜索某个用法到底在哪些地方被用到了;或者你想让它并行调研三四个不同的技术方案;或者你想让它把一个很大的目录通读一遍、归纳出结构。这些任务的特点是 —— 过程中会产生海量的中间信息(一堆搜索结果、一堆文件内容),但你最终只想要那个"结论"。
这时候可以让 Claude 派一个"分身"(子代理)去做。子代理在它自己独立的上下文里干这个活,把所有的搜索、阅读、试错都在它那边完成,最后只把提炼好的结论汇报回你的主对话。
好处是:那些大量的中间过程,不会挤占你主对话的上下文,你的主线任务始终保持清爽、聚焦。一句话概括:脏活累活外包给分身去干,主对话只接收最终结果。当你发现一个子任务"信息量很大、但你只要个结论"时,就该想到用子代理。
MCP:给 Claude 接上"真实世界"
MCP(Model Context Protocol)是 Claude Code 进阶的关键,也是最能改变"它能做什么"的一环。
没有 MCP 时,Claude Code 的能力边界基本是"读写你本地的文件、跑命令"。MCP 是一个标准协议,它的作用是给 Claude 接上外部的工具和数据源 —— 接上之后,Claude 就不再只是"对着本地文件干活",而是能直接和真实环境打交道。
能接什么?举几个有代表性的:
- 数据库:接上之后,Claude 能直接查你的数据库 —— 排查一个数据问题时,它能自己去
select看看真实数据长什么样,而不是靠你复制粘贴。 - 浏览器:接上之后,它能真的打开一个页面、点击、截图 —— 你让它改一个 UI,它能改完之后自己打开页面看效果、对比、再调,形成一个"改-验证"的闭环。
- 设计稿工具:接上之后,它能直接读取设计稿,然后照着实现 —— 不用你把设计稿一块块截图发给它。
- 各种内部系统 / API:你公司的工单系统、监控、知识库,只要有对应的 MCP 服务,都能接进来。
MCP 做的事情,本质上是把 Claude 从一个"代码编辑助手"扩展成了一个"能动手的工程助手"。它能查数据、能验证、能操作真实系统 —— 这让"交给它一个完整的、需要和外部打交道的任务"成为可能。配置 MCP 通常是在 Claude Code 的配置里声明你要接哪些 MCP 服务,具体的服务有现成的、也可以自己写。如果你只用 Claude Code 的对话功能、从没碰过 MCP,那你大概只发挥了它一半的能力。
自定义命令与技能:把你的常用流程"固化"下来
还有一个进阶用法常被忽略:把你反复要做的流程,固化成可复用的东西。
如果你发现自己总是对 Claude 说一段类似的话 —— 比如每次都让它"按某某规范走查这个文件、列出问题、给修改建议" —— 那你就可以把这段流程固化成一个自定义命令,以后一个简短的指令就能触发整套流程,不用每次重新交代。
更进一步,对于那些"有固定步骤、有特定知识、会反复用到"的复杂工作流,可以把它整理成一个"技能" —— 把流程、注意事项、用到的模板都写进去。下次遇到同类任务,Claude 就能按这套固化好的流程来做,而不是每次都从零开始、每次的质量还不稳定。
这个思路和 CLAUDE.md 是一脉相承的:凡是"反复出现的东西",都值得花一次时间把它固化下来 —— 项目的约定固化进 CLAUDE.md,常用的流程固化成命令或技能。固化一次,之后每次都省事,而且质量稳定。这是把 Claude Code 用出"复利"的关键。
那些让它"好用"的实战习惯
除了上面几块"机制",还有一些日常的协作习惯,直接决定你的体验。这些和单独用任何 AI 编程工具是相通的,但在 Claude Code 这种"能力更强、能交付更完整任务"的工具上,尤其重要:
- 任务切小,一次只推进一步。大改动它容易逻辑漂移,你也没法逐行 review。拆成小步,每步可验证、可回退。判断标准:如果这一步的改动你没法在一两分钟内 review 完并确认对错,那它就还是太大了。
- 让它解释,不要只让它给代码。问它"为什么这样写""有什么取舍""这段代码什么情况下会出问题" —— 它解释不清楚的地方,往往就是它自己也没想透的地方,你能借此提前拆雷。
- 把测试当缰绳。它写的代码"看着对"不等于"真的对",边界情况它经常想不全。有测试就让它边写边测,没测试也要自己跑关键路径。它说"应该没问题"的地方,就是需要你验证的地方。
- 不可逆操作自己来。删文件、改数据库、
git push、git reset --hard这种,它可以建议,但执行那一下自己把关 —— 它的视野里没有你那些"看不见的历史"。这种地方,"慢"就是"快"。 - 它写的代码,你必须能看懂。看不懂又懒得搞懂就合进去,等于给自己埋技术债。要么让它讲到你懂,要么换个你 hold 得住的方案 —— 代码最终是你在维护、你在背锅。
- 会卡死的循环要果断踩刹车。某个问题它改了几版越改越乱,别让它继续"猜测—试错"。回退到最初的版本,自己花十分钟把问题搞清楚,再重新带它一遍。识别"它已经不在解决问题、只在打补丁"这个信号,本身就是一种能力。
一个心智模型:它是搭档,不是黑盒
用好 Claude Code 的关键,是建立一个正确的心智模型:把它当成一个手速极快、知识面极广,但完全不了解你项目历史、也不会替你负责的资深搭档。
基于这个模型,前面所有的"用法"都变得自然、不用死记:它不了解你的项目 → 所以要写 CLAUDE.md、要让它先读再写;它不会替你负责 → 所以不可逆操作你把关、它写的代码你得看懂、得自己跑测试;它手速快、知识广 → 所以重复的、查资料式的、有明确模式的劳动,尽管交给它;它能力强但需要引导 → 所以用子代理、MCP、自定义流程去放大它,用"探索-方案-实施"的节奏去引导它。
反过来,有两种极端心态会让你用不好它。一种是把它当"全自动黑盒" —— 觉得描述完需求就该出能直接上线的代码,然后不 review 就合进去,迟早被坑。另一种是把它当"高级补全" —— 只敢让它补几行代码,不敢把完整任务交给它,这又严重浪费了它(尤其是 Claude Code 这种擅长跨文件、跨步骤任务的工具)的能力。真正的用法,在这两个极端的中间。
团队里用 Claude Code:协作方式要跟着变
前面讲的是个人怎么用。当一个团队都开始用 Claude Code,有些协作规则需要跟着调整,否则会出乱子。
CLAUDE.md 应该是团队共享、共同维护的。它沉淀的是团队的集体约定,不该是每个人各写一份、各用各的。把它纳入版本管理,像维护项目文档一样维护它 —— 谁发现 AI 又踩了某个团队特有的坑,就负责往里补一条。这样整个团队用 AI 的"基线"是一致的。同理,有价值的自定义命令、技能,也应该团队共享。
Code Review 要更严,而不是更松。有人觉得"AI 写的代码质量不错,review 可以放松了" —— 恰恰相反。AI 让每个人的代码产出量暴涨,reviewer 面对的待审代码反而更多了;而且 AI 代码"读起来通顺"的特点,会让 reviewer 更容易松懈、漏掉问题。团队要明确:AI 写的代码,和人写的代码,适用完全相同的质量标准,review 一视同仁、不打折。
"谁提交谁负责"这条铁律,不能因为 AI 而松动。绝不能出现"这段是 AI 写的,出问题不怪我"的心态。提交者就是责任人,无论代码是谁、是什么写的。这条立住了,大家才会认真把关。
警惕"AI 同质化"。如果团队所有人都用 AI、都不加思考地接受它的默认方案,代码会慢慢变得"千篇一律地平庸" —— 全是 AI 眼里的"标准做法",缺少针对项目的巧思和取舍。保持"人的判断"在环路里,是对冲这种同质化的关键。
常见误区与坑
误区一:不写 CLAUDE.md,每次对话从零交代。这是最浪费时间的用法。该固化的不固化,等于每天重复同样的劳动。
误区二:只用对话功能,从不碰子代理和 MCP。等于买了把瑞士军刀,只用了那个最小的刀片。子代理省上下文、MCP 接真实世界,这两个不用,Claude Code 的能力你只发挥了一部分。
误区三:甩大任务,不拆。"重构整个模块"丢过去,它逻辑漂移、你失去把关能力,最后比自己写还慢。
误区四:它说什么信什么。AI 的语气永远笃定,但笃定不等于正确 —— 它会很自信地用一个不存在的 API、给一个有 bug 的实现。对它说的话,尤其涉及具体 API、版本、配置的,要有"默认怀疑、动手验证"的习惯。
误区五:不读它的代码就提交。所有误区里代价最高的一个。看不懂的代码合进项目,就是利息很高的技术债。
FAQ
CLAUDE.md 应该写多长?不在长短,在"有效"。写那些"代码里读不出来、但很重要"的约定和红线就够了。代码里能直接看出来的(比如用的什么框架),不用重复写 —— 它自己会读代码。太长太杂反而稀释重点。它是"约定速查",不是"项目百科全书"。
子代理和"再开一个对话"有什么区别?核心区别是上下文。再开一个对话,它和你的主任务是割裂的,结果你还得手动搬运回来;子代理是你主对话"派出去"的,它干完活,结论自然回到主对话的流程里,而中间过程不污染你的主上下文。它是"受你主线调度的分身",不是"另一个独立的人"。
MCP 配置复杂吗?有没有必要折腾?常用的 MCP 服务大多有现成的,配置就是在 Claude Code 的设置里声明一下要接哪个。值不值得折腾,看你的场景 —— 如果你经常需要它"查数据库验证一下""打开页面看看效果",那 MCP 带来的体验提升是质变级的,绝对值得花一次时间配好。
用 Claude Code,自己的能力会退化吗?取决于你怎么用。如果你"不读它的代码、不让它解释、出问题就让它瞎改",那是在外包思考,会退化。但如果你坚持"让它解释、自己 review、自己做判断、把关每一步",它反而是个高效的学习工具 —— 你能快速接触到大量不同的写法和思路。退化的不是"用 AI 的人",是"用 AI 来代替思考的人"。
它和 Cursor、Copilot 比,该用哪个?它们取向不同。Claude Code(命令行)擅长"派活"式工作流 —— 交给它一个相对完整的任务,它自己探索、实施、验证。Cursor 擅长"结对"式 —— 你在写它在旁边补。Copilot 是最成熟的行内补全。喜欢"派活"就偏 Claude Code,而且本文讲的 CLAUDE.md、子代理、MCP 这套机制,正是为这种工作流设计的。
从新手到高手:用 Claude Code 的几个阶段
观察身边人用 Claude Code(以及一切 AI 编程工具),大致会经历几个阶段。对照一下,你能知道自己在哪、下一步该往哪走。
阶段一:当聊天框用。遇到不会的就问一句、让它写一小段。这个阶段它对你来说,和一个"能写代码的搜索引擎"差不多 —— 有用,但只用到了皮毛。大多数人停在这里。
阶段二:开始交付完整任务。你不再只让它"补几行",而是敢把"实现这个功能"这样一个相对完整的任务交给它。这个阶段你会开始踩坑 —— 它跑偏、它逻辑漂移、它写的代码你没看懂就合了 —— 然后你会痛,会开始反思"该怎么交任务"。
阶段三:学会"带"它。你开始写 CLAUDE.md、开始用"探索→方案→小步实施"的节奏、开始坚持让它解释、坚持自己 review、坚持把不可逆操作攥在自己手里。这个阶段,你和它的配合开始变得高效而稳定 —— 因为你不再"指望"它,而是在"驾驭"它。本文的大部分内容,就是帮你跨到这个阶段。
阶段四:把它接进体系。你开始用子代理外包脏活、用 MCP 把它接上真实环境、把反复的流程固化成命令和技能、在团队里共建 CLAUDE.md。这个阶段,Claude Code 不再是一个"你时不时去用一下的工具",而是嵌进了你整个工作流的一个能力底座。
这几个阶段,差的不是"工具的版本",也不是"模型的智商",而是使用者的认知和习惯。从阶段一跳到阶段三、阶段四,工具一行代码没变,变的全是你。这也再次印证了那句话 —— AI 编程拉开的差距,在"会不会带",不在"用不用"。你现在处在哪个阶段不重要,知道往哪走、并且愿意刻意练习,才重要。
写在最后
Claude Code 的进阶,核心就这么几件事:
- CLAUDE.md —— 把项目的隐性约定和红线写下来,给它一份常驻记忆,并持续维护它;
- 协作节奏 —— 探索 → 方案 → 小步实施 → 验证,别甩大任务,读在写之前;
- 子代理 + MCP —— 用分身外包"信息量大但只要结论"的脏活,用 MCP 把它接上数据库、浏览器等真实环境;
- 固化流程 —— 反复要做的事,固化成自定义命令或技能,赚"复利";
- 把关习惯 —— 测试当缰绳、危险操作自己来、代码必须看得懂、循环卡死要刹车;
- 团队层面 —— CLAUDE.md 共享共建、review 不打折、谁提交谁负责。
说到底,AI 编程拉开的差距,从来不在"用不用",而在"会不会带"。把判断权牢牢留在自己手上,把重复劳动尽管交给它,再用 CLAUDE.md、子代理、MCP 这些机制去放大它 —— 这就是 Claude Code 高级用法的全部精髓。工具已经足够强,决定它是助力还是负担的,永远是用它的人。
—— 别看了 · 2026