先说结论：Claude Code 是一款跑在终端里的 AI 编程搭档。它不是在浏览器里聊天的 AI，也不只是 IDE 的补全插件，而是一个能直接读你项目文件、执行命令、替你改代码的命令行工具。你只需要在项目目录下启动它，用自然语言描述需求，它就会像一名坐在你旁边、能随时翻代码库的同事一样帮你推进。

这套入门实战写到这里已经是第四篇，前面把工具和概念铺垫得差不多，这期偏重落地。我的目标读者很明确：已经会用终端、日常写 Python、Node.js、Shell 脚本的开发者，或者正在接手不太熟悉的项目、想提升效率的人。基础用法不难，难的是知道什么场景值得用它，以及怎么避免它把事情搞砸。这篇就围绕这两件事展开。

1. 先搞懂 Claude Code 到底解决什么问题

1.1 它和聊天网页的差别

很多人第一个问题是：我在网页版聊天窗口里把代码粘进去不也能用吗？能，但效率完全不同。网页版最大的问题是它对你的项目一无所知。你每次都得手动挑出相关文件，粘贴进去，然后等着。一旦项目文件超过三五个，这种用法的上下文成本开始起飞，你经常会觉得自己在做 Copy Paste 搬运工，而不是写代码。

Claude Code 不一样。你启动它的时候，它会以当前目录作为工作区，自动感知项目里的文件结构、git 状态、语言类型。我常用的第一个指令就是“先不要改代码，读一下项目结构，告诉我这是个做什么的项目”。这个动作在网页版里几乎没法完成，但在这里只需要一句话。

这个差异背后是设计取向的问题。网页版聊天更接近“知识问答”，你用代码当素材，让它回答问题。Claude Code 更接近“工程协作”，它把你的项目当成工作环境，可以搜文件、读内容、改动文件，再返回 diff 给你审查。理解了这一点，你才不会用错工具——不是所有写代码的问题都应该搬进终端，但只要涉及真实项目文件，Claude Code 的价值就一下子凸显出来了。

1.2 为什么是命令行，而不是 IDE 插件

还有一个常见问题：为什么不做成 IDE 插件？IDE 插件当然有它的优势，光标悬浮、逐行补全、内嵌代码示例都很方便，但它能接触的范围非常有限。哪怕模型再聪明，插件拿到的基本上只是你当前打开的这一两个文件。要模型帮你梳理整个模块的调用关系，IDE 插件反而束手束脚。

命令行形态带来几个天然好处。第一，它用一个终端窗口就能管理整个项目，不依赖特定的编辑器，你用 VS Code、Neovim 还是纯终端，它都能接入。第二，它天然适合和 git、shell、测试工具串在一起。我可以让它先跑一遍测试，再根据失败信息修代码，最后再跑一次确认通过，整个过程不需要切换窗口。第三，多个会话可以放在多个终端标签页里并行，互不干扰，这一点做多任务时非常好用。

当然命令行也有门槛。它不提供图形化按钮，新手需要记住少量命令和参数。但我的体会是：只要你会cd到项目目录、会看git diff，其他都可以边用边学，门槛比想象中低。

1.3 它的核心能力速览

如果要给 Claude Code 的核心能力做减法，我会留下三件事：读取、修改、执行。读取是理解项目，包括文件树、代码内容、注释和依赖关系；修改是在理解之后直接在文件里编辑，而不是只给一段建议文本；执行是调用你项目里的命令，比如跑测试、装依赖、做静态检查。

这三个能力组合起来之后，你会感觉到一种很直接的代理感。我经常让 Claude Code “帮我看看这个函数为什么运行得慢”“把报错信息贴出来分析一下”，再让它“在调用处加个日志”。它能把“定位 → 修改 → 验证”连成一条线，而网页版和 IDE 插件往往只做到其中一步。

不过也要提醒一句：它能够执行命令，并不代表你应该把整个开发流程都交给它。我会在第五部分专门讲权限和边界问题，这里只需要记住，Claude Code 更像一个高产的实习生，能力强，但需要你验收。

2. 安装与启动：从零开始跑起来

2.1 环境要求与安装命令

在动手安装之前，先检查你本机有没有 Node.js，因为 Claude Code 是构建在 Node 运行时上的。我的建议是 Node.js 18 以上，版本太低会遇到兼容性报错。检查方法很简单：终端里输入node -v，如果返回的数字低于 18，就先升级再继续。

安装方式官方推荐一行脚本，我在全新环境里试过，基本没有额外依赖：

curl -fsSL https://claude.ai/install.sh | bash

执行完会自动下载并安装，之后你可以在任何目录输入claude --version来确认是否成功。如果你更习惯 npm 管理工具，也可以在官方文档里找对应的全局安装方式，效果是一样的。只要你本机的网络环境正常，安装过程通常不会卡住。等命令跑完之后，你就能在终端里直接唤起它了。

2.2 登录认证与项目初始化

安装完成之后，在项目目录里输入claude，第一次启动会让你完成一个登录流程。这个流程本质上是在确认你有权限调用 Claude 的服务，并且会在本机保存凭证，后续再启动就不用重复登录了。

登录之后，建议你第一件事不是急着写代码，先跑一遍基础对话。我的习惯是输入这样一句话：“当前目录下的项目是做什么的？请列出主要文件和用途。”这是最安全的启动方式，因为 Claude Code 只是扫描并读取文件，不会改动任何东西。如果它回答得比较准确，说明项目已经被正确识别了；如果它说“没有读到文件”，那你就要检查是不是在错误的目录下启动了它。

这里有一个容易犯的低级错误：在~用户目录或者C:\根目录直接启动，Claude Code 会把整个目录当成项目，读到一堆无关文件，导致上下文被污染。我会专门为每个项目开一个终端，并且确保当前目录就是项目根目录。

2.3 认识会话界面和帮助系统

Claude Code 启动之后是一个交互式命令行，你会在底部看到输入提示符。你可以像聊微信一样直接发消息，也可以输入/help查看所有内置命令。这里我整理几个最常用的：

刚开始用的时候，我建议大家把/help放进脑子。这个工具的命令并不多，但每个命令背后都对应一个真实场景。比如/clear不是可有可无——聊到后面上下文变得混乱时，清一下再重新提问，效果经常比在混乱中硬撑要好得多。这些命令是基础中的基础，会了它们，你才算是真正掌握了交互方式。

3. 基础用法：五个高频操作，直接抄作业

3.1 让 AI 先“读懂”项目再动手

Claude Code 最迷人的一点，是它可以先理解项目，再动手。但前提是你得让它“主动读”，而不是默认它什么都懂。我的标准开场白是：

先不要修改任何文件。请阅读项目根目录下的 README 和主要源码目录，概括一下这个项目实现了什么、技术栈是什么、哪个模块是入口。

这个指令有几个关键词：“先不要修改任何文件”是安全约束，“阅读”是给它授权，“概括”是限定输出。如果你不加这些限制，它有时候会默认你想改代码，反而多出一些不必要的操作。这个小习惯我在所有 AI 编程工具里一直沿用，它很像你和外包程序员交接时说的一句“你先看，看明白再聊”。

读懂项目之后，你可以在后续对话里随时追加问题，比如“routes 这个目录为什么这么分层”“utils 里有哪些函数是公用的”。这些追问不用把整个文件粘给它，因为它自己已经读过了。

3.2 用自然语言直接改文件

读完项目之后，最常见的操作就是改代码。比如我会说：

请在 src/utils.js 里新增一个函数 formatBytes，接收字节数，返回可读性更好的大小文本。

Claude Code 会直接改文件，然后给出一个 diff 让你确认。这里很多人第一次用会懵：它改完了，我还没同意，怎么就算改了呢？实际上它会根据你的提示词判断是否需要确认，如果改动范围不大，默认会直接执行，但会展示 diff。你可以用/status或查看终端输出确认改动，也可以打开编辑器看文件。

我个人强烈建议，每次改动都要看 diff。你可以直接接受，但必须肉眼扫一遍。这不是不信任，而是对自己代码库负责。我踩过几次坑之后，已经养成了条件反射：只要它说“已修改”，我一定会在编辑器里打开文件或运行git diff再复查。

3.3 让它替你执行命令和测试

这是从“聊天工具”升级成“开发助手”的关键一步。在 Claude Code 里，你可以要求它执行 shell 命令。例如：

运行一下 pytest，如果失败就把失败信息贴出来，并定位到对应的测试文件。

它会执行命令，然后把结果反馈到对话里。如果命令需要管理员权限、或者涉及危险操作，它会弹出一个权限确认，等你批准后才继续。这个设计我很喜欢——相当于给实习生开的权限只到“可以读和改代码”，执行关键命令之前还要敲门。

但也要注意，执行命令不等于命令一定安全。你最好事先知道大概会发生什么。比如让它“安装所有依赖”可以，让它“把所有文件中的 TODO 替换为空”就要格外小心，因为替换操作可能比你想象的覆盖范围更大。之后的常见问题部分会专门讲怎么收紧权限。

3.4 用 @路径 精确锁定上下文

当项目文件多、对话内容杂的时候，与其让 Claude Code 自己猜，不如直接告诉它该看哪个文件。它支持用@路径的方式引用文件，比如：

参考 @src/apis/user.js 的实现风格，新增一个 @src/apis/order.js 文件，包含获取订单列表的接口函数。

这样它会只聚焦你指定的文件，输出对应风格的代码。这个功能在网页版 AI 工具里很难实现，因为你需要手动复制粘贴代码，而这里只需要一个引用。@ 引用对新人来说可能有点陌生，但学会之后，你会省掉很多上下文浪费。

我还会用这个能力做代码审查。直接把一个重要文件 @ 进去，问它“这个文件里有没有明显的 bug 或隐患”。它给的回答不一定全对，但往往能抓到我忽略的边界情况，相当于免费过了一遍 review。

3.5 处理跨文件的批量修改

第三个高频场景是跨文件修改。例如这个需求：

整个项目里有很多硬编码的接口地址，把这些地址统一改成从 config/env.js 里读取，并给出所有需要修改的文件列表。

这种活放在以前，我得用 grep 搜一遍，再一个个文件改，稍不留神就会漏。Claude Code 做这件事的优势在于，它能同时搜索和修改多个文件，并且把改动点集中反馈给你。你只需要盯着 diff，确认没有误伤就行。

不过也正是这种场景，最容易翻车。我记得有次让它把“全部 API 域名都改成新地址”，它把注释里的旧域名、测试用例里的 mock 地址也一起改了。从那以后，所有批量修改的提示词里，我都会加一句“只修改正式代码文件，不要动测试和注释里的内容”。边界越清晰，它越少自由发挥。

4. 使用场景拆解：我从实际项目里提炼的四个典型用法

4.1 临时脚本与自动化杂活

坦白说，Claude Code 最让我上瘾的场景，不是写复杂业务，而是处理那些“自己写要十分钟，不写也会忘”的杂活。比如批量重命名一堆文件、把 CSV 转成 JSON、写一个定时清理日志的小脚本。这类需求技术含量不高，但很耗时间。

我会直接在项目目录里说：

写一个 Python 脚本，把所有 .txt 文件改成 .md 后缀，并批量替换文件内的第2行标题格式。

它生成脚本后，我会让它先在临时目录里试跑，确认没问题再应用到真实文件。Claude Code 在这里的角色像是一个快速编码工，帮我完成从“想法”到“可用脚本”的最后一步。省下来的时间，我可以用来做其他更值得思考的设计问题。

这类用法对初学者最友好，因为脚本是新增的、不涉及改老代码，失败了推倒重来也没有负担。我建议第一次上手的人，都从这种独立的小脚本开始，而不是直接拿生产代码测试。

4.2 接手老项目：先让 AI 画地图

接手的旧项目往往是“没有文档，代码又多又乱”。之前我拿到这种项目，第一反应是打开目录一层层看，看到哪算哪。现在我会先把 Claude Code 拉进来，让它做一份“地图”：

请分析这个项目的模块结构、数据流向和主要入口，最终给我一份 README 风格的说明。不要改任何文件。

它会阅读入口文件、路由、package.json、数据库 schema 等，然后输出一份结构化说明。哪怕是第一次接触的代码库，我也能快速知道哪个模块是核心、哪个文件是历史遗留。这个能力在带新人、交接项目时特别有价值。

但你也别完全依赖这份地图。它的理解是基于静态阅读，可能会忽略运行时才出现的状态变化。所以我会把它的输出当作“地图初稿”，再通过跑一下 demo、看两段关键日志来修正。毕竟 AI 给的是大概率猜测，不是事实。

4.3 技术验证：用最小 Demo 说服自己

有时我需要快速验证一个库或一个方案是否可行，但又不想为了验证搭一个完整项目。以前我会手写最小 Demo，现在直接让 Claude Code 来：

用 Node.js 快速验证一下某个开源库能否解析这种格式的日志文件，写一个 minimal demo，跑通后输出结果。

它会搭一个临时目录、安装依赖、写 demo 代码、运行，然后把结果反馈回来。如果方案可行，我再把这段代码扩展成正式模块；如果不可行，我的成本只是几句对话的时间和一点算力开销。

这个场景的核心价值是“低成本试错”。程序员往往因为懒得验证，把一个大概率不行的方案做了两个星期才发现问题。现在有了 Claude Code，验证成本被压得很低。我甚至会在选择第三方库之前，先让它做一个 API 可用性冒烟测试。

4.4 团队协作：什么时候该放手，什么时候该收紧

Claude Code 本质上是个人效率工具，团队里用需要定好规矩。我的建议是：个人分支、临时脚本、技术验证这些低风险环节，可以大方使用；但凡是会给主干造成影响的改动，它只能做“建议者”，不能做“执行者”。

举例来说，我可以让它在自己的特性分支里直接修改代码，然后我自己git diff后合并。但如果要重命名一个被全项目引用的公共函数，我会让它先列出所有调用点，我自己来判断怎么改。Claude Code 的空间感不够，它不熟悉你团队的编码规范、命名习惯和隐藏的业务约束，这些都要由人来兜底。

团队里还可以共享一些提示词模板，比如“按本项目编码规范 review 这个文件”。这种模板能减少大家重复表达上下文的时间。但模板只是起点，最终审核还是得人来完成。别让 AI 写了代码就等于这个功能做完了，这是团队协作里最需要盯住的一条线。

5. 踩过的坑和实用建议：这些没人告诉你的细节

5.1 上下文窗口是要管理的，不是无限的

所有大模型工具都会碰上下文窗口，Claude Code 也一样。你聊得越久、读过的文件越多、输出越长，后面的回复可能就越偏。它不像人一样能意识到“我忘记前文了”，它只是在窗口允许范围内尽力推理。

我的管理方法很朴素：每完成一个明确的小任务，就/clear一次。如果任务比较大，我会用/compact把长对话压缩成摘要再继续。别舍不得上下文，很多时候“问得越多越糊涂”，清掉重新来反而更清醒。

还有一个技巧：如果某个项目文件特别大，不要让它整个文件反复读。用@引用再加上“只看关键函数”的指令，能有效节省上下文空间。我通常会先用grep定位行号，再让它精确读那一段。这些做法都算“上下文卫生”，在新手阶段很容易被忽略。

5.2 权限边界一定要收住

Claude Code 默认的权限策略相对保守，但部分开发者为图省事会开启跳过所有确认的模式。我的建议非常明确：不要在生产环境、不要在有敏感数据的仓库里开启这种模式。它一旦获得完整权限，理论上可以执行任何命令，包括删除文件、覆盖配置、强制 push。

如果只是为了调试，可以临时用一下，但也要先确认当前会话只对着临时目录，不会碰重要数据。我个人的底线是：让执行命令必须人工确认，文件修改也必须在 diff 里可见。代码无所谓，但凭据、密钥、生产数据库这些绝对不是 AI 应该自动碰的东西。

另外提醒一点，它可能会读取环境变量里的敏感信息，也可能把不该被读到的文件内容纳入上下文。为了安全，我会在项目根目录配置忽略文件，明确哪些目录不允许它扫描。用静态检查思路保护敏感信息，比事后后悔要安心得多。

5.3 问法不同，结果天差地别

同样一个任务，“帮我修一下这个 bug”和“帮我看看 @src/parser.js 里 parseHeader 函数在解析空行时报错，原因可能是什么，先不要改代码”是完全不同的两个问题。前者需要模型猜，后者给了路径、函数、现象和约束，回答质量和针对性不是一个数量级。

我给新手一个公式：上下文 + 目标 + 边界。上下文是相关文件、函数、报错信息；目标是改什么、跑什么、输出什么；边界是“不要动测试”“不要改公共接口”“先只出方案”。把这三件事说清楚，Claude Code 的产出质量会明显提升。

写提示词还有一个心态问题：不要连续追问同一个失败好几遍。如果第一次回答不理想，停下来补充信息，而不是重复抱怨。这就像带实习生，你把背景交代得越细，对方犯错的概率就越低。

5.4 常用参数配置与低开销调试

Claude Code 在启动时可以带一些参数，我实际使用最多的几个是：

• --continue：接着上一次会话继续聊，适合跨天处理同一个任务。
• --model：指定模型版本，不同的模型在速度和效果上有差异。
• --output-format：改变输出格式，脚本处理场景下比较好用。

我一般默认用--continue，因为开发任务很少一次对话能完成。不建议每次都启动新会话，否则每次都需要重新交代项目背景。但如果上下文已经很长，我会优先/clear，而不是继续叠上下文。

调试阶段我还会刻意选一个模型参数，主要是为了降低算力消耗。不涉及复杂业务需求时，先拿低参数的模型跑一版，看方向对不对，再换效果更好的模型做收尾。这一步很像写代码时先用 notebook 做实验、再进正式工程，能有效控制试错成本。

5.5 多会话并行的小技巧

最后分享一个我每天都在用的习惯：同一个项目开多个终端，每个终端负责一个独立任务。一个会话专门“梳理架构”，一个会话专门“改支付模块”，另一个专门“处理日志解析”。各会话之间互不干扰，等于同时带了三个 AI 外包，并且每个外包的上下文都不会串味。

如果你发现某个会话越聊越乱，别硬撑，直接/clear再开。比在乱成一团麻的话术里找线索要快得多。这本质上是一种“上下文隔离”的思路，跟代码里模块解耦是一个道理。用好了，Claude Code 的并行效率会明显高于单会话模式。

我在实际项目里用了几个月，最大的体感不是它能写多少代码，而是它改变了我和代码库的互动方式。以前我想到一个问题，得先去文件里找答案，再回来写代码；现在我可以先问它，再根据它的回答去验证，相当于把一个“会翻资料的同事”塞进了终端。当然，它也会犯错，也会乱改，所以我始终把它当一块加速板，而不是方向盘。如果你也刚开始接触，建议从临时脚本和代码 review 这两个低风险场景练手，先建立手感，再慢慢把更多环节放给它。熟悉之后你会发现，Claude Code 不只是一个工具，更像是一种新的开发习惯。