很多人第一次听说 Claude Code,印象大概是"Anthropic 出的一个 AI 编程助手,能在终端里帮你写代码"。这个描述没错,但也容易把人引到一条窄路上——以为学会几条命令就算会用了。实际上,Claude Code 用得好不好,从来不取决于你记住了多少参数,而取决于你怎么跟它协作。同样一个工具,有人用它三分钟修好一个缠了半天的 bug,有人折腾一下午反而越改越乱,差别往往就在使用方式上。 这篇文章想做的事情,是把"从装上它到真正用顺它"的过程讲清楚。不是功能清单,也不是命令手册,而是一条成长路径:新手阶段该关心什么,进阶阶段会遇到什么瓶颈,到了精通阶段你的思考方式又会发生什么变化。中间还会涉及第三方模型接入、网关配置这类实际问题——因为很多人真正开始深度使用,就是从解决这些问题开始的。
一、新手阶段:装好它,完成第一件小事
新手最该做的事情,不是研究 Claude Code 有多少功能,而是尽快在一个真实项目里跑通一个完整的小闭环。
Claude Code 的入口不止一个。它可以运行在终端、VS Code、Cursor、JetBrains、桌面应用和浏览器里,这些入口共享同一套底层能力。不过最典型的起步方式仍然是终端。macOS、Linux 和 WSL 下,官方推荐的安装命令是:
Windows 有对应的 PowerShell 和 CMD 脚本,也可以通过 Homebrew 或 WinGet 安装——具体以官方文档为准,因为安装方式会随版本更新。装好之后,进入你的项目目录,运行 claude,首次启动会要求登录。 到这一步其实只完成了"通路"。真正的入门标志,是你让它在一个具体仓库里帮你做了一件事,而且这件事的结果你能判断对不对。比如让它解释某个文件的逻辑,或者给一个函数补一条边界检查,或者修一个你已经定位到但懒得动手的报错。
不过,比起具体做什么任务,新手阶段更重要的是学会怎么提任务。很多人第一次用 Claude Code 觉得"不好用",回头一看,问题出在指令本身:说了"帮我优化一下",但没说优化哪里、不能动什么、怎么算优化成功。Claude Code 不是搜索引擎,它接到指令之后会真的去读文件、改代码、跑命令,如果你给的上下文太模糊,它只能边猜边做,猜对了是运气,猜错了才是常态。
一个好的任务描述,通常至少包含三层信息。第一层是目标:你到底要它做什么。第二层是边界:哪些文件、哪些接口、哪些行为不能动。第三层是验收:做完之后你打算怎么确认结果——跑哪条命令、看哪个输出、检查哪段 diff。这三层信息不需要写得多正式,但要写得具体。"在 src/auth/login.ts 里给 login() 函数增加一条对空密码的校验,不要改函数签名,改完我会跑 npm test",这样的描述就比"帮我加强一下登录安全"清楚得多。
除了指令模糊,新手还有几个常见的坑。一是不给文件路径,让 Claude Code 自己猜该改哪里;二是一次塞进太多目标,既要重构又要加功能还要补测试;三是改完之后不看 diff 就接受。这三个习惯只要在早期纠正过来,后面的使用体验会好很多。
新手阶段的目标说到底就一句话:让自己知道 Claude Code 在什么任务上最顺手,并且养成"具体指令 + 人工验证"的基本节奏。
二、进阶阶段:从"偶尔能用"到"每天离不开"
能跑通几个小任务之后,很多人会进入一个微妙的阶段:觉得 Claude Code 确实有用,但又说不清它到底帮自己省了多少时间。有时候一个任务它处理得很漂亮,有时候又会改出新问题,来来回回反而比自己手写更慢。
这种不稳定感,通常不是模型能力的问题,而是使用方式还没有沉淀成习惯。进阶阶段要解决的核心问题,就是把 Claude Code 从一个"偶尔试试"的东西,变成开发流程里可靠的一环。
第一步是建立一个固定的工作节奏。不需要多复杂,一个足够好的顺序是:先在对话里把任务说清楚,等它改完之后用 git diff 看一遍变更,然后跑测试或 lint 确认没有引入新问题,最后再决定要不要提交。这个顺序的关键不在于步骤本身——任何稍有经验的开发者都会觉得这是常识——而在于你是否真的每次都这样做。很多人用 Claude Code 时会不自觉地放松审查,因为"它看起来写得挺对的"。但 AI 生成的代码和人写的代码一样需要 review,甚至更需要,因为它有时会自信地引入一个你不熟悉的写法,表面能跑,但跟项目里已有的惯例不一致。
固定节奏有了之后,下一个提升点是长期上下文。你会发现,每次新开会话都要重复解释一遍项目背景、代码风格、测试命令,很烦也很浪费 token。Anthropic 给出的方案是 CLAUDE.md:在仓库根目录放一个 Markdown 文件,把编码规范、架构约定、常用命令、不能动的模块等长期有效的规则写进去。Claude Code 每次启动会先读这个文件,相当于给它一份持久化的项目记忆。
这个文件不需要一次写完美。建议的做法是边用边补:第一次你发现自己在反复纠正同一个问题(比如它总是用 var 而你项目里只用 const),就把这条规则写进 CLAUDE.md。积累几周之后,这个文件会变成一份非常实用的项目约定文档,不光对 Claude Code 有效,对新加入的人类同事也有参考价值。
在 CLAUDE.md 之外,官方还提供了几层递进的机制。Auto memory 会自动沉淀会话中学到的事实,比如你项目的构建命令、某个模块的调试技巧。Skills 适合把重复流程封装成可共享的命令,比如团队内部的 /review-pr 或 /deploy-staging。Hooks 则更底层一些,它让你在 Claude Code 的特定动作前后自动执行脚本——编辑文件之后自动跑 formatter,提交之前自动跑 lint,类似 git hooks 的思路但作用范围是 Claude Code 的行为。
进阶阶段还有一个标志性变化:你开始把 Claude Code 当作命令行工具来组合使用,而不只是打开一个交互式对话。官方文档里展示了不少管道用法——把最近的日志输出喂给它做异常判断、让它审查 git diff 列出的文件、在 CI 里自动翻译或生成变更摘要。这些场景的重点不在语法,而在思路:Claude Code 遵循 Unix 哲学,可以跟 shell 里的其它工具串起来用。一旦你开始这样用,它就不再是一个你需要"专门去打开"的窗口,而是像 grep 或 jq 一样融进日常操作里。
如果要给进阶阶段一个总结,那就是:你开始把 Claude Code 当成工程工具来对待,而不是一个需要哄着用的聊天产品。你有了固定的协作节奏,有了持久化的项目上下文,也开始把它接入更大的工作流。到这一步,效率提升已经不是"偶尔惊喜",而是每天可预期的事。
三、精通阶段的前置课题:模型选择与第三方接入
在往精通阶段走之前,很多人会先遇到一个实际问题:模型到底怎么选,以及如何接入官方路径之外的模型。
默认情况下,使用 Claude Code 最简单的方式是直接通过 Anthropic 官方订阅或 Console 账号登录。模型路由、计费、版本管理都由平台处理,你不需要操心。但现实中,不是所有团队都走这条路。有的公司要求所有 API 流量过企业网关;有的团队希望在不同任务上使用不同厂商的模型;有的开发者在意成本,想试试更便宜的选项;还有人出于隐私考虑,希望模型跑在本地。
理解这些接法之前,需要先抓住一个核心事实:Claude Code 在协议层面只认 Anthropic API 格式。所以,接入第三方模型的思路,本质上就是在 Claude Code 和真正的模型之间加一个翻译层,让上游的响应"长得像"Anthropic API 返回的样子。
这个翻译层的实现方式有好几种,但控制它的手段最终都落在三个环境变量上:
ANTHROPIC_BASE_URL 决定请求发到哪里,ANTHROPIC_API_KEY 用来鉴权(这里填的是网关 key,不一定是 Anthropic 官方 key),ANTHROPIC_MODEL 指定要调用的模型名。具体的翻译层怎么搭,常见的有这几条路线。
LiteLLM 是目前社区里用得最多的方案。它本身是一个代理服务,能在 100 多个模型供应商的 API 格式之间做自动翻译。你在本地或服务器上启动 LiteLLM,在它的配置里填上各家模型的 key,然后把 Claude Code 的 ANTHROPIC_BASE_URL 指向 LiteLLM 的 Anthropic 兼容端口就行。之后切换模型就变成了换一个名字的事,比如 claude --model gpt-4o 或 claude --model gemini-2.5-pro。对于经常需要在不同模型之间比较效果的人来说,这是最省事的选择。
如果你更在意隐私或者想在离线环境下使用,可以走 Ollama。本地拉一个模型,确保 Ollama 服务在跑,然后把环境变量指过去:
需要注意的是,本地小模型在复杂推理、跨文件理解这类任务上的表现,和云端大模型有明显差距。Ollama 路线更适合对隐私要求高、或者用来做轻量级辅助的场景,不适合当作主力。
无论走哪条线,都建议先在当前终端会话里用环境变量临时验证,确认能通之后,再把配置写进 ~/.claude/settings.json 做持久化:
这样做的好处是开新终端不用再手动 export。另外,如果你希望在 Claude Code 的模型选择器里看到自己的自定义条目(比如内部网关映射的模型),部分版本支持通过 ANTHROPIC_CUSTOM_MODEL_OPTION 和 ANTHROPIC_CUSTOM_MODEL_OPTION_NAME 来注册。
还有一类需求是国内开发者常遇到的:想用 DeepSeek、Kimi、MiniMax 等国内模型。通常的做法是通过 302.AI、OpenRouter 或自建网关做中转,把多个供应商统一到一个 ANTHROPIC_BASE_URL 后面。成本方面各家差异很大,需要看实时定价。 有一点要反复强调:环境变量的名称、settings.json 的字段、网关兼容路径的写法,都可能随 Claude Code 版本和网关实现而变化。不要死记文章里的示例,每次配置前先对照 claude --help和你所用网关的说明。排错时,401/403 通常是 key 或白名单问题,404 通常是 Base URL 路径缺了兼容前缀或 http/https 写反,模型名无效则几乎都是网关侧注册的 model id 和你本地写的对不上。
模型接入这件事,新手容易把它当成"高级玩法",其实它只是基础设施配置。真正区分水平的不是你能接多少模型,而是接好之后你拿它做什么。
四、精通阶段:从使用工具到设计系统
当你已经有了稳定的工作流、持久化的项目上下文、按需可选的模型配置,Claude Code 对你来说就不再是一个需要学习的新事物,而是日常工具箱里的一部分。这时候,你的关注点会自然地从"怎么用好这个工具"转向"怎么围绕它设计一套协作系统"。
这种转变首先体现在任务分类上。新手是什么都问它,进阶用户知道什么任务适合交给它,而精通用户开始主动规划分工:这类任务适合在交互式会话里做,那类任务应该写成 skill 让团队复用,还有一类任务最好做成 CI 流水线里的自动步骤。你不再把每次对话当成孤立事件,而是在构建一个可重复运行的体系。
MCP(Model Context Protocol)在这个阶段会变得有意义。它解决的问题是:当 Claude Code 需要访问外部系统——读设计文档、查工单状态、从数据库拉数据——你不想每次都手动复制粘贴,也不想把敏感信息暴露在聊天记录里。MCP 提供了一个标准化的接入方式,让模型按配置、有权限地访问这些外部资源。对于日常只改代码的开发者来说,MCP 可能用不上;但如果你的工作涉及多个系统之间的串联,它会是一个关键拼图。
Sub-agents 是另一个精通阶段的工具。当任务足够复杂,比如"在三个模块里同时重构某种模式,并分别补上测试",让一个会话从头做到尾既慢又容易丢上下文。Sub-agents 允许主会话拆分子任务、并行推进,最后合并结果。这跟你在代码里做并发处理是一个道理:不是所有场景都需要,但一旦需要,没有它会非常痛苦。
精通用户还会开始关心一类之前不太在意的问题:治理。哪些操作 Claude Code 可以自动执行,哪些必须等人确认?密钥是通过网关统一管理还是散落在各人的 settings.json 里?团队成员是不是在同一套 CLAUDE.md 和模型映射上工作?新人加入时能不能在十分钟内把环境配好?这些问题听起来不如"写代码"那么有技术含量,但它们决定了 Claude Code 在团队里是昙花一现的尝鲜,还是长期可持续的生产力。
说得再直接一些:精通不是"更会提问",而是"更会建制度"。你从一个使用者变成了设计者,从一个跟 AI 对话的人变成了定义 AI 如何参与项目的人。
五、怎么判断自己到了哪个阶段
这不需要考试,看看自己的日常状态就知道。
如果你现在的感受是"装上了,试过几次,有时好用有时不好用,还不太确定该怎么跟它配合",那你在新手阶段。这很正常,也不需要着急。这个阶段最值得做的一件事,是挑一个你很熟悉的项目,让 Claude Code 帮你完成三到五个你已经知道答案的小任务。你不是在测试它的能力上限,而是在校准自己对它的预期,同时培养"具体指令 + 人工验证"的基本功。
如果你已经养成了改完看 diff、跑测试的习惯,写了 CLAUDE.md,也开始把一些固定任务交给它处理,那你已经在进阶阶段。这时候最有价值的动作,不是去学更多新功能,而是把你现在已经跑通的做法稳定下来——写进文档、做成 skill、或者加到 CI 里。成功经验如果不固化,下次换个项目又要从头摸索。
如果你已经在考虑模型路由策略、团队级的 CLAUDE.md 模板、hooks 自动化、MCP 接外部系统、甚至在根据不同任务类型决定"这件事要不要让 Claude Code 参与",那你已经接近精通了。你关心的不再是"它能不能做",而是"这件事用什么方式做最合理"。
六、从新手到精通,真正跨过去的那一步
如果回头看整条路径,会发现一个规律:每个阶段的跃迁,都不是因为学会了某个新命令或新功能,而是因为思考方式变了。
新手阶段,你在问"Claude Code 能做什么"。进阶阶段,你在问"我的哪些工作应该交给它"。精通阶段,你在问"围绕它我该怎样组织整个协作方式"。这三个问题看起来是递进的,但其实中间的跳跃并不自动发生。很多人会一直停在第一个问题上,不断试新功能、换新模型、追新版本,却始终没有把任何一种用法沉淀成自己的工作习惯。
如果只能给一个最实用的建议:先在真实项目里积累几个稳定的小闭环,然后用 CLAUDE.md、测试流程和 review 习惯把它们固定下来,最后再去碰模型网关、MCP、自动化这些基础设施层面的东西。顺序对了,每一步都在加固前一步的成果。顺序反了,就很容易变成"什么都试过,什么都没用顺"。
工具在不断迭代,模型在不断变强,但使用者的成长路径其实是稳定的:先做对一件事,再把做法稳定下来,最后围绕它搭建系统。这条路走通了,不管 Claude Code 将来怎么更新,你都不会掉队。
参考与延伸阅读
按下面的顺序读官方文档,可以跟本文的成长路径对应起来: