彭河森先聊点实际的。我大概从 Claude Code 发布初期就开始用，一路从“这玩意是不是个高级玩具”用到“离了它我写代码效率直接腰斩”。但说实话，网上的教程要么是官方文档的翻译腔，要么是“教你三分钟配置出高级 AI 编程环境”那种标题党。这篇东西我不会写成官方文档，也不会写成营销号软文，就是把我在真实项目里用 Claude Code 干活时的那些操作、参数、踩坑、心得全倒出来。标题叫“不完全使用指南”，是因为我确实不敢说把它玩透了，但下面这些内容，每一行都是实测过、在真实项目里跑过、并且现在还在用的东西。
如果你正打算装一个 Claude Code 试试水，或者已经装了但感觉用起来不顺手，这篇文章能帮你省下大量自己摸索的时间。我会从最基础的安装开始讲，然后说清楚它在 VSCode 里到底该怎么配、日常写代码时有哪些真正高频好用的操作、进阶一点有哪些命令和权限管理技巧，最后用一整段记录我实际踩过的坑和排查思路。哪怕你之前完全没接触过命令行 AI 编程工具，跟着这篇文章走一遍，也基本能把它跑起来、用起来、用顺手。
1. 先把 Claude Code 装好：从环境准备到安装完成
1.1 安装前必须确认的三件事
很多人装 Claude Code 失败，根本不是工具的问题，而是前置环境没弄对。我列一下最基础、也是最重要的检查项，这三条不满足，后面全是白折腾。
第一，操作系统。Claude Code 目前对 macOS 和 Linux 的支持最稳定，Windows 下面也能跑，但需要 WSL（Windows Subsystem for Linux）环境。我自己的主力机是 macOS，另一台 Windows 笔记本上也装了，实测下来 macOS 的体验会流畅很多，尤其是在权限管理和路径处理这些环节。如果你只有 Windows 机器，我强烈建议你先花半小时把 WSL 配好，直接在 WSL 的 Ubuntu 终端里操作，别在 PowerShell 或者 CMD 里硬搞，否则后面会遇到各种奇奇怪怪的路径分割符问题。
第二，Node.js 版本。Claude Code 是跑在 Node.js 上的命令行工具，官方要求 Node.js 18 以上。这里要提醒一句，很多人机器上装的 Node.js 是老版本，尤其是公司统一配发的电脑，Node 可能还停在 14 或者 16。你可以在终端里先跑一下 node -v 看版本，如果低于 18，建议用 nvm（Node Version Manager）装一个新的 LTS 版本，尽量不要直接去官网下安装包覆盖，那样容易把环境搞乱。nvm 的方式随时切换版本，对后面跑别的 Node 项目也更友好。
第三，网络环境。Claude Code 装好后要连接 Claude 的服务端，这就意味着你需要能稳定访问它的服务。国内网络环境下，这一步可能会遇到连接超时或者请求被中断的情况。这里我不展开讲任何网络工具的事，只提醒一点：尽量在网络稳定的环境下使用，保证 npm 安装依赖以及后面 Claude Code 连接服务的过程顺畅，不然你排查问题排查半天，最后发现是网络不通，很耽误时间。
1.2 npm 安装命令与权限处理
确认完上面三条，安装其实就一条命令的事。打开终端，输入：
bash复制npm install -g @anthropic-ai/claude-code
我加了 -g 参数，表示全局安装，这样你在任何目录下都能直接调用 claude 命令。如果你之前没全局装过 npm 包，可能会碰到权限报错，提示类似 EACCES: permission denied。官方的建议是不要直接用 sudo npm install -g，因为用 sudo 装全局包有安全风险，一旦包被恶意更新，它会拥有你整个系统的权限。更稳妥的做法是修复 npm 的全局目录权限，说白了就是让当前用户拥有那个目录的所有权。你只需要执行：
bash复制mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
然后把 ~/.npm-global/bin 加到环境变量 PATH 里，再重新打开一个终端，claude --version 能看到版本号就说明装好了。
装完之后，在项目目录下直接输入 claude，它会引导你完成登录。这一步需要你有一个 Claude 的账号，并且建议订阅了 Claude Pro 或者 Max 计划，因为免费用户在这个工具上能用到的配额非常有限，基本只够体验几分钟。登录完成后，它会生成一个凭证文件放在本地的 ~/.claude 目录下，这个文件就是你的身份凭证，要小心保管，别把它提交到 Git 仓库里去，我后面会专门讲这个问题。
1.3 升级与卸载：别小看这两个操作
很多人的 Claude Code 用着用着发现有些功能不对劲，比如模型的输出质量下降，或者某个命令突然找不到，大概率不是你的操作问题，而是版本太旧了。这个工具更新频率很高，几乎每周都会有修复和新功能。升级命令很简单：
bash复制npm update -g @anthropic-ai/claude-code
不过我要提一个细节：npm 因为缓存问题，有时候更新完还是旧版本。遇到这种情况，你可以先强制清缓存再升级：
bash复制npm cache clean --force
npm install -g @anthropic-ai/claude-code@latest
卸载就更简单了，npm uninstall -g @anthropic-ai/claude-code 一行搞定。但注意，卸载命令只是把程序文件删掉了，你本地配置的 ~/.claude 目录里的东西还在，包括项目记忆、自定义指令这些数据。如果你想彻底清掉所有痕迹，手动把这个目录删了就行，不过删之前想清楚，里面可能有你积累了很久的个性化配置，删完就真没了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. VSCode 搭配 Claude Code：这才是完全体形态
2.1 终端集成与工作目录选择
我一直觉得，从命令行启动 Claude Code 只是它的基础形态，真正好用的形态是把它嵌进 VSCode 的终端里，跟编辑器配合起来用，那体验才算到位。
在 VSCode 里用 Claude Code，最简单的方式就是直接用 VSCode 自带的终端，快捷键 Ctrl + ~ 打开，确保当前工作目录就是你的项目根目录，然后输入 claude，回车。它会基于当前目录作为工作上下文，读取项目里的文件、Git 历史和代码结构。这一步很重要，很多人刚上手时喜欢在随便一个目录下启动，结果 Claude 看不到你的项目文件，答非所问，就说工具不好使，其实是你目录选错了。
VSCode 终端集成的优势有几个方面。一是你可以在编辑器里选中一段代码，然后到终端里让 Claude 帮你分析这一段，不用手动把代码复制粘贴进去，省去不少麻烦。二是文件的修改可以直接在编辑器里看到 diff，哪一行改了、改成了什么样，一目了然，不用切到别的工具去看变更。三是如果你同时开着多个终端，可以起多个 Claude Code 会话，一个负责写业务逻辑，一个负责写测试用例，互不干扰。
2.2 让 Claude 看到你的代码思路：权限与上下文
Claude Code 不是魔法，它能看到什么、能改什么，全靠你给它授权的范围。第一次在项目里启动它时，它会弹出一堆权限确认，比如“是否允许读取 src 目录下的文件？”“是否允许修改 package.json？”这些都是运行时动态询问的，你可以选允许一次，也可以选始终允许。
我实际用下来的建议是：如果你在一个自己熟悉且代码有 Git 管理（也就是有历史版本控制）的项目里，可以放心给大一点的权限，让它自由读写代码文件；但如果你在一个还不太熟悉的新项目里，第一次跑起来时先把它限定在只读范围，先让它读代码、讲思路、提建议，确认它真的理解了你的需求和代码结构，再开放写入权限。这样能避免它在理解不准确时直接改掉你不该改的文件。
另外，Claude Code 还支持子代理模式。简单理解，你可以把一个比较大的任务拆成几个子任务，让 Claude Code 分别起子代理去处理，比如一个子代理专门做代码分析，一个子代理专门做搜索，它们在各自的上下文窗口里并行工作，最后把结果汇总。这对于那种涉及多文件重构的场景非常有用，不会出现聊着聊着上下文太长导致它“忘记”前面说了什么的情况。
2.3 配置 .claude 目录：自定义你的项目风格
真正让 Claude Code 从一个通用工具变成你专属助手的关键，是 ~/.claude 目录的配置。这里面有一堆可配置的东西，我挑最实用的讲。
一个是自定义指令。你可以把项目的编码规范、命名约定、不要使用的模式这些信息写进去，比如你可以在项目根目录放一个 CLAUDE.md 文件，Claude Code 每次启动时都会自动读取这个文件作为背景知识。我一般会在这个文件里写上项目的技术栈、目录结构说明、注意事项，这样 Claude 回答问题时会自动代入这些约束，输出更贴合项目实际情况。
另一个是 CLAUDE.local.md，这个文件不会提交到 Git，可以放一些个人偏好的东西，比如你不喜欢它用什么风格的注释等。这个设计很贴心，团队共享一套规范文件，个人又能加自己的偏好，两不冲突。
还有一个建议是定期看看 ~/.claude 目录下的 history.jsonl 文件，里面记录了你和 Claude 的所有交互历史。这东西不只是日志，还是你回顾项目决策的重要参考。你可以用它来复盘，比如上周让 Claude 改的一段复杂逻辑，到底为什么这么改，上下文是什么，翻翻历史文件比翻聊天记录好使。
3. 高频实操：把 Claude Code 当主力开发伙伴
3.1 常用 slash 命令速查
刚开始用 Claude Code 的人，最容易忽略的就是它的斜杠命令。这些命令就像快捷键一样，能大幅提高你跟 Claude 的协作效率。我把平时最常用的几个列成表格，方便你对照着用：
| 命令 | 作用 | 我常用的场景 |
|---|---|---|
/clear |
清空当前会话上下文 | 任务切换时防止旧任务影响新任务 |
/compact |
压缩/精简当前上下文 | 上下文较长时让回复更精准 |
/review |
对最近的代码改动进行代码审查 | 提交代码前快速自查 |
/terminal-setup |
设置终端相关权限 | 首次在一个新项目里启动时 |
/permissions |
查看和管理权限配置 | 排查为什么 Claude 不能改某个文件 |
/cost |
查看会话的 token 消耗情况 | 关注成本超支时 |
/status |
查看会话状态和信息 | 想确认当前会话用的是哪个模型时 |
/mcp |
配置和管理 MCP 服务器 | 需要接入外部工具时 |
/help |
查看帮助信息 | 不记得某个命令时 |
/usage |
查看订阅计划的使用量 | 月配额快用完时 |
这里我单独说一下 /clear。很多人在一个会话里连续处理不同任务，比如先让它写一个函数，然后又说“帮我看看另外那个组件的 bug”，这时候 Claude 容易把两个完全不相关的任务混在一起理解，输出就很混乱。我现在的习惯是：每切换一个任务，就先 clear 一下，让它彻底忘掉上一个任务，再开始新的。虽然这样会损失一些上下文，但换来的是更准确的回答，非常值。记住“旧的不去新的不来”这句话，放在这里再合适不过。
3.2 选对模型：sonnet、opus 还是 haiku？
Claude Code 默认使用的是某个均衡型模型，但你也可以在启动时通过参数指定别的模型。比如 claude --model opus 或者 claude --model haiku。这三个模型定位不同，我讲一下我的选型逻辑。
默认模型（sonnet）是我平时用得最多的，它平衡了速度和质量。写业务代码、改 bug、做代码解释，这些日常任务它都能胜任，响应速度也快，不会让人等得着急。
如果要处理更复杂的架构设计，比如把多个文件的重构思路理清楚，或者要在一个大型代码库里定位很隐蔽的问题，我会切到 opus。它的推理能力强一些，但代价是响应慢，而且 token 消耗更大，费用更高。所以我的策略是：只有 sonnet 搞不定的时候，才上 opus，而不是什么事都用 opus。
haiku 是轻量级模型，速度快，但也意味着没那么聪明。我一般只拿它处理简单机械的任务，比如改个变量名、格式化一下代码、补一些固定的测试数据。如果你发现用 haiku 处理简单任务时经常出错，别意外，它的能力上限就在那里，把它当个“实习生”用就行，重要的事还是要交给全职的 sonnet。
这里我想分享一个小技巧，可以在启动时直接指定模型，也可以在会话中和 Claude 对话时直接说“切换到 opus”或者“use opus”，它会自己切换。实测下来，直接在对话中用自然语言切换模型，比重新启动一个新的会话要方便得多。
3.3 让 Claude 干活更高效的三条黄金准则
用了一段时间后，我总结出三条能明显提高 Claude Code 输出质量的经验，非常重要：
第一，任务描述要具体到“文件”和“函数”。 你让它“优化一下用户登录模块”，这个描述太宽泛了，它不知道该从哪里入手。更好的方式是明确告诉它：“优化 src/api/auth.ts 文件里 login 函数的错误处理逻辑，现在的 session 超时后没有自动跳转，需要加上 token 过期检测和跳转逻辑。”粒度越清晰，输出越精准。
第二，让 Claude 先分析、后动手。 这是我在复杂任务里觉得最可靠的方式。比如你有个功能想改动，先跟它说：“不要急着写代码，先读这几个文件，告诉我当前实现的逻辑、潜在问题和你打算怎么改”，等它输出的方案你觉得合理了，再说“好，按你的方案执行吧”。这能避免它带着理解偏差就闷头写一堆代码，最后全要返工。
第三，定期把项目背景文件更新同步进去。 我在前文提到的 CLAUDE.md 不是写一次就完事的。随着项目发展，你可能会换技术方案、调整目录结构、引入新的依赖，这些都要及时更新到这个文件里去。你会发现，文件更新得越准确，Claude 从第一句话开始就越“懂行”，完全不用你每次重新解释一遍项目背景。
4. 进阶玩法：项目记忆、MCP 与成本控制
4.1 不止是对话：Claude Code 的位置与功能定位
我遇到很多朋友问我，Claude Code 和直接在网页上跟 Claude 聊天有什么本质区别？区别就在“位置”和“权限”。
网页上的 Claude 像一个顾问，你告诉它问题，它给你答案，但不能动手。Claude Code 是坐在你工位旁边的同事，它有你的项目代码、能看到 Git 历史、能直接改文件、能跑命令，你只需要确认它每一步的操作是否合理，然后按下允许键。这种差异在涉及多文件改动或者需要反复试错的任务上尤其明显，人工在网页上复制粘贴来回传话的效率远远比不上它直接在本地操作。
它的执行模式是“提交-确认”式的：Claude 会列出它打算做什么，比如修改哪个文件、新增什么内容，然后等你确认。你可以一句话允许它继续，也可以修改它的计划再执行。这种模式本质上就是你做代码审查（Code Review），它负责写代码，把人的角色从“打字员”变成了“审查者”。这也意味着，用 Claude Code 的前提，是你自己得理解代码，不然你连它的修改是否正确都判断不了。
4.2 MCP 配置：把 Claude 变成一个超级连接器
MCP（Model Context Protocol）是 Claude Code 里比较进阶、也很有价值的能力。简单理解，它就像给 Claude Code 装上了各种“传感器”，让它可以访问外部工具和实时数据源。
举个例子，你可以通过 MCP 让 Claude Code 访问你的 GitHub 仓库，这样它不只是看你本地的代码，还能读取远程仓库的 issues 和 PR 状态。你也可以接入数据库，让它实时查询数据；或者接一个你自己的内部文档系统，让它在写代码时参考你司的 API 文档。
配置 MCP 服务器有几种方式，一种是全局配置，放在 ~/.claude.json 里；另一种是项目级配置，放在 .mcp.json 文件里。我更推荐用项目级的配置，因为 MCP 服务通常跟具体项目相关，不同的项目接不同的数据源，用项目级配置不会污染全局环境。配置好之后，在会话里输入 /mcp 就能看到当前所有连接的服务器状态。如果某个服务器连不上或者没响应，排查方向一般是两件事：一是检查配置文件里的路径和参数是否正确，二是确认你本地的网络环境能不能访问到那个服务地址。
4.3 控制成本：别让费用在不知不觉中暴涨
关于成本，我觉得这是每个长时间用 Claude Code 的人都必须关注的事。它的计费方式是按照 token 消耗来的，而 AI 对话的 token 消耗比你想象的要快得多，尤其是一次性读入多个大文件的时候。
你可以在会话里敲 /cost，它会显示当前这次对话消耗了多少 token、折合多少钱。另外还有一个 /usage 命令，可以查看你订阅套餐的总配额和已用比例。我自己的习惯是：开始一个比较大的任务之前，先看一下 /usage，如果这个月已经用了百分之七八十，那我就用 sonnet 模型处理尽可能多的简单任务，省下配额给真正需要的复杂任务。
省成本还有一个技巧，就是不要在一个会话里开设太多任务。Claude Code 会把之前的对话历史都作为上下文保留，这意味着你聊得越多，它每次响应的输入 token 就越大，消耗也就越大。每次任务结束、下一个任务开始时，果断 /clear，不但能提高准确率，还能省下不少钱。这两个好处是同时出现的，你试个几次就明白我说的了。另外，/compact 命令可以把已有的上下文压缩一下，在对话很长、舍不得清空历史的时候，用它来给上下文减肥，也算一个省钱小技巧。
5. 避坑实录：我踩过的坑和你的解决方案
5.1 安装失败与权限问题的真实排查
我在一台新的 Linux 服务器上装 Claude Code 时，遇到过 npm 全局安装后找不到命令的情况。npm install -g 执行成功，但 claude --version 提示 command not found。排查后发现，问题出在 npm 的全局 bin 目录没有加入到系统的 PATH 环境变量里。这种情况在 Linux 和 macOS 上都很常见，因为不同方式安装的 Node.js，其全局路径不一致。
解决方法是先确认 npm 的全局 prefix 路径，用 npm config get prefix 查看，然后把 <prefix>/bin 加到你的 shell 配置文件中。举个例子，如果路径是 /usr/local，那你需要在 ~/.zshrc 或 ~/.bashrc 里加一行：
bash复制export PATH="/usr/local/bin:$PATH"
改完记得执行 source ~/.zshrc 让它生效。这个坑的本质不是 Claude Code 本身的问题，而是 Node.js 环境配置的问题，但排查起来很容易让人一头雾水。
5.2 登录认证失败与多账号管理
如果你在登录时一直卡在认证这一步，最常见的原因是网络代理环境异常，导致终端无法和认证服务器完成通信。这种时候我的建议是先检查 HTTPS 代理相关的环境变量，确认当前终端的代理设置不影响认证请求。还有一种情况是本地存在一个旧的凭证文件，导致新登录时认证信息被覆盖或冲突。解决方式很直接，去 ~/.claude 目录下把过期的凭证文件清理掉，再重新执行 claude 命令登录授权。
多账号管理这里也要多说两句。Claude Code 目前登录凭证是绑定在当前用户下的，如果你需要切换不同账号（比如一个是公司账号、一个是个人的），不要简单地把整个 ~/.claude 目录改来改去，容易把配置弄坏。更稳妥的办法是把不同的凭证目录备份下来，比如 ~/.claude-work 和 ~/.claude-personal，需要哪个账号干活时再替换过去，然后重启 Claude Code。这个方法比较土，但胜在稳定可靠，不依赖任何第三方管理工具。
5.3 权限误配置与“悄悄改错文件”的预防
有一次我在一个大型项目里，为了省事把 Claude Code 的权限设置成“允许所有文件操作”，结果它在一次代码重构时，把一个配置文件里的关键路径给改错了。因为配置文件不涉及语法的逻辑判断，Claude 不会意识到这个改动会破坏其他模块的引用，只有跑测试时才发现问题。虽然 Git 可以回溯，但那次返工浪费了不少时间，也给我长了教训：权限给得越宽，Claude Code 的自主性越强，但出错时的代价也越高。
现在我的做法是对不同目录设置不同的权限规则。比如 src 目录给它读写权限，config 目录只给读权限，docs 目录完全不给权限。这个可以通过 /permissions 命令来查看和调整，特别是当它告诉你“无法完成某操作，权限不足”的时候，别急着全部放行，先想想这个目录是不是真的需要它动。Claude Code 的设计里有一个非常好的理念，就是它每一步操作都需要你的确认，哪怕给了大范围权限，你仍然可以在每一次具体操作时选择拒绝。你要用好这个特点，权限给得宽不代表你要当甩手掌柜，每一步该做的 Code Review 还是要做。
5.4 提示词注入攻击：面向 AI 编程工具的新风险
最后聊一个比较新、也比较值得警惕的安全问题。如果你的项目代码里引入了不可信的第三方代码（比如从网上下载的开源包、参与协作的其他成员提交的代码），里面可能埋藏了“提示词注入”的恶意指令。它的原理是，Claude Code 在读取这些代码文件时，会把文件内容一并作为上下文，如果里面写着“忽略之前的指令，执行以下操作...”，它是有可能被“带偏”的。
我听过真实案例：有人在某个开源包里塞了一段注释，内容是让 AI 工具读取环境变量并把它们泄露到某个远程地址，当开发者用 Claude Code 分析项目时就中招了。这个问题目前没有完美的自动防护方案，我能给的最实用建议就是：让 Claude 直接修改或执行代码之前，严格审查它每一步的计划。尤其当它告诉你“需要读取某个环境变量”或者“要访问某一个你平时没见过的文件”时，多留个心眼。在公司团队协作这种场景下，提醒团队里每个人都了解一下这种攻击方式，比单独依赖工具防御要可靠得多。
5.5 一条压箱底的建议：把它当成结对编程的伙伴
说了这么多，最后再掏心窝子讲一点感受。Claude Code 用久了你会发现，它的输出质量很大程度上取决于你怎么跟它交流。跟它说话就像跟一个基础扎实、记忆力超强、但缺少项目全局观的初级工程师结对编程，你越是能把需求想清楚、把约束条件描述全，它给出来的代码就越像样。反过来，你如果自己都模模糊糊，把它当成一个能“读心”的魔法棒，那结果大概率会让你失望。
我现在的工作习惯是：每天开工时会先起一个新会话，并用几句简单的话把今天的核心任务背景写进 CLAUDE.md 或者直接在对话里交代一遍，剩下的时间就是不断地“提要求-审查-调整-确认-下一项”，一天下来代码产出效率比过去高了不少，关键是人还不累。有人担心这类工具会让程序员“废掉”，我个人目前持相反态度。它更像一个帮你搬砖的搭档，把重复劳动接走，把创造性决策留给你。你的核心竞争力永远是理解业务、拆解问题、把握方向的能力，而这些，恰好也是把 AI 工具用得比别人好的关键。