Ubuntu 22.04安装Claude Code并在VSCode中集成完整指南

Ubuntu 22.04 安装 Claude Code 并在 VSCode 中跑通的完整记录

最近项目里频繁要写自动化脚本和代码生成工具，朋友推荐我试试 Claude Code。在 Ubuntu 22.04 下装机、配 VSCode 的过程还是踩了不少坑的——尤其是版本匹配、Node.js 环境、扩展加载路径这几个地方，网上很多教程写得含糊，我这次把完整过程和我实际遇到的问题整理成文，希望能帮到正好卡在同样位置的人。

先说结论：Claude Code 是 Anthropic 提供的命令行 AI 编程工具，可以在终端里直接以对话方式让 AI 写代码、改代码、跑命令。它本质上是一个 Node.js 编写的 CLI 程序，官方的推荐安装方式就是通过 npm 全局安装，然后在终端输入claude启动。在 VSCode 里使用，不是装一个独立插件，而是把命令行工具和 VSCode 的终端能力结合起来，再加上官方提供的扩展（Claude Code for VSCode），能实现选中代码、右键发送给 Claude 这类交互。

这篇内容适合三类人：刚在 Ubuntu 22.04 上搭好开发环境、想用 CLI 工具写代码的新手；已经在用 Claude Web 网页版但嫌切窗口麻烦、想深度集成进编辑器的开发者；还有那些折腾了 VSCode 扩展装不上、或者安装完发现命令找不到的“卡住选手”。我会把从环境准备到最终跑通的每个环节都写清楚，途中重点解释“为什么要这么配”，避免大家稀里糊涂地照着敲完也不知道在干嘛。

1. 环境准备与前置条件解析

1.1 为什么先检查 Node.js 版本而不是直接装

Claude Code 是 npm 分发包，这意味着你的机器上必须先有 Node.js 和 npm。很多安装失败案例其实都出在 Node.js 版本太旧上。Claude Code 对 Node.js 的最低要求是 18.x 版本，但实话说，我用 18.19 跑起来没问题，建议直接用 20 LTS 版本，稳定性更好，新版 CLI 也频繁针对 Node 20 做适配。

我来解释一下为什么这个版本问题这么关键：Claude Code 本身是用 TypeScript 写的，编译后运行在 Node.js 运行时上。新版 CLI 使用了一些较新的 JavaScript API，比如fetch全局对象、AbortController这类特性，Node 18 以下要么缺失、要么行为不一致。你要是用 Ubuntu 自带的 apt 源直接装，装的通常是 Node 12 或者 14，那几乎是必挂，而且报错信息可能又长又含糊，很容易让人误判成“网络问题”“权限问题”，白折腾半天。

检查命令如下：

node -v npm -v

如果node提示 command not found，或者版本小于 18，就按下面步骤装 NodeSource 源里的 20 LTS。我比较推荐这种方式而不是用 nvm（Node Version Manager），原因后面会讲。

1.2 Node.js 安装方案的选择与实操

Ubuntu 22.04 的官方 apt 源里虽然有 nodejs 包，但版本比较落后。我一开始图省事直接sudo apt install nodejs，结果装出来是 v12.22.1，然后 claude 安装完一运行就报语法错误，回头排查了半天才发现是 Node 版本问题。这个坑你们一定要避。

推荐做法是用 NodeSource 官方提供的 apt 源：

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs

执行完再验证一下：

node -v # 应该输出 v20.x.x npm -v

为什么我不推荐当时用 nvm？因为 nvm 是用户级的版本管理器，装完之后你在 sudo 身份下、或者某些特殊的 shell 环境里，可能找不到 nvm 提供的 Node 命令。Claude Code 的 VSCode 扩展有时是以系统级方式调用 node 的，用户级 nvm 路径会出现“扩展里能加载、但真正执行 claude 命令时提示找不到”这种诡异情况。如果你已经在用 nvm，也问题不大，后面我会在常见问题里讲怎么解决。

1.3 Ubuntu 22.04 系统的其他依赖检查

Node.js 装好之后，还需要确保系统里有git，因为 Claude Code 在读取仓库上下文的时候经常要调用 git 命令来获取文件变更状态、分支信息。另外建议装好build-essential，在某些情况下 CLI 需要编译原生模块时省得临时抱佛脚再装。

sudo apt update sudo apt install -y git build-essential

这一步看着基础，但是千万别跳过。我遇到过一台精简安装的 Ubuntu 22.04 服务器版，里面的 git 竟然是没有的，Claude Code 启动之后一直说“unable to load git repository context”，后来一查就是缺 git。文章后面我会把这个现象写进常见问题表里。

1.4 VSCode 的安装与版本确认

VSCode 在 Ubuntu 上有两种安装路线：一种是 Ubuntu 软件中心里直接搜索安装，另一种是去官网下载 .deb 包。我的建议是直接用官网的 .deb 包，因为软件中心里的版本可能滞后，而 Claude Code 扩展对 VSCode 版本有一定要求（新版功能通常依赖较新的 IDE API）。

# 官网下载 .deb 包后，在下载目录执行： sudo dpkg -i code_*.deb

安装完执行：

code --version

确保你能看到一串版本号输出。如果提示找不到命令，多半是没把 VSCode 的 bin 目录加进 PATH，可以执行which code排查。还有个小细节：VSCode 安装后需要启动图形界面首次初始化，如果你是在没有桌面环境的 Ubuntu Server 上用 SSH 远程操作，那场景完全不同，本文先按桌面版来写，远程服务器的配置我放到最后额外补充。

2. 安装 Claude Code 的完整流程

2.1 npm 全局安装命令与镜像源说明

在 Node.js 环境就绪后，安装 Claude Code 本身其实只需要一行命令：

sudo npm install -g @anthropic-ai/claude-code

这里要注意的是全局安装需要权限，所以我用了 sudo。但如果你之前是用 nvm 装的 Node，那npm的全局目录就在你用户目录下，不需要 sudo；如果这种情况下你加了 sudo 反而会报错，因为 sudo 环境下的 PATH 里没有 nvm 的 Node 路径。这个细节非常坑，我分两种场景说清楚：

• 用 NodeSource apt 源装的 Node：全局目录在/usr/lib/node_modules或/usr/local/lib/node_modules，需要sudo。
• 用 nvm 装的 Node：全局目录在你的~/.nvm/versions/node/v20.x.x/lib/node_modules，不需要sudo。

装完后，验证是否成功：

claude --version

如果你执行后看到的是命令找不到，说明 npm 的全局 bin 目录没在 PATH 中。NodeSource 的安装方式下，bin 通常在/usr/bin或/usr/local/bin，正常情况下没问题；nvm 的方式需要在~/.bashrc里写上一行export PATH="$HOME/.nvm/versions/node/v20.x.x/bin:$PATH"，这个我会在常见问题里详细展开。

2.2 第一次启动与账号授权流程

安装成功之后，直接在终端输入claude启动。首次运行会进入一个授权引导流程，提示你登录 Anthropic 账号并完成订阅验证。这里有几种登录方式，我说一下它们的区别：

第一是直接用 Claude 账号登录，也就是你在网页版 Cluade 用的那套账号体系。CLI 会输出一个一次性登录链接，打开之后在浏览器确认授权即可。授权完成后 CLI 会保存一份本地凭证，之后启动就不再需要重复登录。

第二是如果你的账号或组织开通了 API key 方式，也可以选择用 API Key 作为认证凭据。具体做法是首次启动时按提示选择 API 模式，然后粘贴你的 API Key。这里要提醒一下：API 模式下 Claude Code 按 token 用量计费，和你订阅网页版的配额逻辑不一样，别混为一谈。

授权完成之后，你可以试试最简单的对话：

claude > 写一段 Python 代码，读取当前目录下所有 csv 文件的文件名和行数

如果它能正常返回代码，说明安装成功。此时先别急着关，我在实践过程中发现：第一次启动时 claude 会自动做一次环境检查和配置初始化，包括创建~/.claude目录、写入配置文件、下载一些内置的 agent 脚本，这些过程可能需要一两分钟时间。如果中断了，后续会出一些奇怪的错误，后面排查部分我会提到。

2.3 版本管理与升级路径

Claude Code 的迭代速度相对较快，基本每周都有小版本更新。升级很简单：

sudo npm update -g @anthropic-ai/claude-code

但有个问题值得注意：我在使用中遇到过，自动更新提示明明显示“A newer version of Claude Code is available”，执行claude update之后却发现版本没有变化。这大概率是因为权限问题——你不是用 sudo 装的，所以更新的时候没有写权限就静默失败了。这种情况手动执行一次：

claude update sudo npm install -g @anthropic-ai/claude-code@latest

其中claude update是 CLI 内置的自更新命令，它更新的是当前用户版本的安装目录；而后面那条 npm 命令是强制从源里拉到最新再覆盖。两条命令各执行一次，基本能解决九成以上的“明明有新版却更新不了”问题。

再说一点我个人的使用心得：如果你计划长期使用且不想频繁升级踩到新 bug，可以锁定一个稳定版本。Claude Code 的配置目录里有一个settings.json，可以通过设置来禁用自动更新提示：

{ "autoUpdates": false }

配置文件位置在~/.claude/settings.json，没有的话手动创建一个就行。不过要注意：关闭自动更新后，你需要自己留意版本，因为新版本通常会修复一些影响较大的 bug。

3. 在 VSCode 中集成 Claude Code

3.1 安装官方 VSCode 扩展的两种方式

现在重点来了：怎么在 VSCode 里跑通。首先要明确一点，Claude Code 的 VSCode 集成分为两部分：一是官方扩展Claude Code for VSCode，二是在 VSCode 终端里运行claude命令。官方扩展提供的是图形化的聊天面板和右键菜单；而终端方式则是 CLI 的完整能力。

安装扩展，我推荐直接在 VSCode 扩展市场搜索 “Claude Code”，注意认准发布者是Anthropic的官方扩展，避免装到第三方同名插件。搜索结果里可能有一堆名字相近的第三方工具，这些不是官方产物，质量和安全性都不保证。

如果你更喜欢命令行操作扩展，也可以：

code --install-extension anthropic.claude-code

这个命令在终端执行，效果等同于在 VSCode 的扩展面板里点安装。装完之后，左侧边栏会多出一个 Claude 的图标，点击就能打开官方聊天面板。

3.2 扩展与 CLI 工具的联动原理

这里我想花点篇幅讲清楚“扩展是怎么找到 claude 这个命令的”，因为权限和路径问题是最多人栽倒的地方。

VSCode 扩展在工作时会尝试启动一个 claude 进程。它查找命令的方式，是在系统 PATH 的环境变量里搜索claude可执行文件。因此，如果你在终端里能正常使用claude命令，但 VSCode 扩展报错“unable to find claude”，本质上就是 VSCode 进程里的 PATH 和终端里的 PATH 不一致。

这个情况在高频场景下非常常见：VSCode 通常是在图形桌面环境启动的，而你在终端里是通过~/.bashrc或~/.profile设置的 PATH；这两者不是一回事。尤其是用 nvm 安装 Node 的场景，扩展经常找不到 nvm 路径下的 claude。

调试方式非常简单：在 VSCode 里按Ctrl + `` 打开终端，先执行一次which claude。如果这个终端里能看到/usr/bin/claude或~/.nvm/.../bin/claude`，那扩展一般也能找到；如果这里都找不到，那你需要先解决 PATH 问题。

还有一个隐藏的坑：VSCode 扩展有时会使用“集成终端”，而集成终端默认使用的是你的默认 shell 配置。如果你的默认 shell 是 zsh，路径配置写在~/.zshrc里，那 VSCode 的集成终端里其实也有效。但如果你是 gnome 桌面直接用图标启动的 VSCode，那桌面进程不会加载 shell 的配置文件，PATH 里就缺了用户配置的路径。解决方法是编辑/etc/environment或创建~/.config/environment.d/*.conf把需要的路径加进去。这个属于比较进阶的操作，我放在常见问题里详细说。

3.3 常用配置项与建议值

配置好扩展后，你可以在 VSCode 的设置面板中搜索 “Claude Code”，看到几个常用配置项。根据我实际使用的经验，列几个值得调的：

• claude-code.autoLogin：设置为 true 时，扩展启动会自动复用 CLI 已保存的登录会话，省得每次打开 VSCode 都需要重新登录。实测下来这个开关默认是开启的，如果你的场景里有多账号切换需求，可以关掉。
• claude-code.terminalCommand：默认值是claude，如果你用了别名或者其他方式安装了不同版本的 claude，可以在这里改成具体的命令路径，比如/usr/local/bin/claude或~/.local/bin/claude。
• claude-code.vscodeDir：如果你的 VSCode 是 portable 模式安装的，工作区目录不在默认位置，需要手动指定。

这些配置项的取值，在设置面板里都可以通过下拉选择或手写路径。我个人的建议是不太懂就别乱动，默认值对绝大多数用户是合适的；真正需要调整的通常是奇特的安装场景。

3.4 在 VSCode 中使用 Claude Code 的实际工作流

配置完成后，我的日常工作流是这样的，供你参考：

第一，先在 VSCode 里打开你的项目根目录。Claude Code 判断项目上下文的方式，主要是通过当前打开的文件夹。在扩展面板里，它会自动感知你当前打开了哪个项目。

第二，选中一个函数、一段代码或者一个报错信息，右键选择 “Explain with Claude Code” 或者 “Ask Claude Code”。这样选中的内容会作为上下文自动附带到对话里。这个功能的实际价值非常大，比如你遇到一个诡异的报错，直接把报错信息送入 Claude，省得来回复制粘贴和解释。

第三，如果你要执行写代码类的比较复杂的任务，我建议直接用 VSCode 的集成终端跑claude。为什么？因为 CLI 模式拥有完整能力——可以直接读取文件、修改文件、执行命令、运行测试，这些操作在图形聊天面板里是受限的。CLI 模式下，Claude 会主动问你是否允许执行某些命令，确认后它就能实际改动你项目里的文件。

这中间有一个很重要的使用习惯：让 Claude Code 改文件之前，先用版本控制系统（比如 git）做好提交。Claude Code 在修改文件时虽然也会显示 diff，但如果你有 git 的缓冲，随时可以回退，安全感会高很多。我个人的习惯是：一个任务开始前先git add . && git commit -m "before claude task"，任务结束后再 review diff，确认无误后再提交一次。这样做的好处是，即使 Claude 做出了错误改动，你也可以精准对比前后差异，而不是靠记忆或目测手工判断。

3.5 远程开发场景下的特殊说明

如果你的 VSCode 连接的是远程服务器（比如用 SSH 插件连到远端 Ubuntu 22.04），安装逻辑略有差异。这个场景下，Claude Code 的 CLI 安装在远端机器上，而 VSCode 扩展实际上是在本地 Windows/Mac 上运行的。不过好在官方扩展支持远程开发模式。

需要做两件事：第一，SSH 到远端服务器，按本文第二部分的流程把 CLI 装好并完成一次登录验证；第二，在本地 VSCode 里安装扩展，连接远程后扩展会自动检测远端的 claude 命令。这里的关键是确保远端 PATH 正确。我在实践代理中经常遇到的场景是：SSH 登录后的交互式 shell 能正常使用claude，但 VSCode 的 Remote-SSH 通道加载环境时用的是非交互式 shell，~/.bashrc可能会被跳过。解决方案是把必要的 export 写入~/.profile文件（注意不是~/.bashrc），或者直接在/etc/environment里加上全局 PATH。

4. 实际测试跑通：从安装到第一个项目

4.1 搭建一个最小的测试项目

为了验证整套流程是否跑通，我建议你先建一个最小的测试项目，别一上来就拿真实项目练手。原因是 Claude Code 在大型项目里会读取大量上下文，首次使用时各种配置对不上，容易混淆是环境问题还是配置问题。

在终端执行：

mkdir ~/test-claude cd ~/test-claude git init

然后打开 VSCode，加载这个目录。在集成终端里执行：

claude

此时如果一切正常，你会进入一个交互式对话界面，提示符是>或者类似Model: ...的会话起始信息。输入一个简单的问题试试：

这个项目目前是空的，帮我创建一个 Python 脚本，读取当前目录下的所有文件并输出它们的文件名

正常情况下，Claude 会先分析目录（看到只有 .git 目录），然后生成一个 Python 脚本，并询问你是否要创建这个文件。这里我建议你选择“允许写入”，让它实际创建文件看看效果。执行完，回到 VSCode 文件资源管理器，应该能看到新生成的.py文件。

4.2 验证扩展面板的连接状态

接着，把 VSCode 左侧的 Claude 面板打开。如果扩展加载正常，你会看到一个会话列表，可能还有一个 “New conversation” 按钮。如果你之前已经在终端里完成了登录授权，这里应该不需要再次登录；如果界面提示你要登录，可以点一下登录按钮，会走一遍和 CLI 相同的授权流程。

这里有一个我实际遇到过的细节：扩展面板刚加载的时候，有时会显示 “Claude Code is starting” 或者一个转圈的状态，持续十几秒甚至更久。这通常是扩展在后台拉取模型列表或者做初始化检查。这时候别反复点击面板，稍等一会就好。如果超过两分钟还在转，大概率是网络连接问题或者登录会话过期了，重新登录一次试试。

4.3 一次真实的代码生成与审查实践

为了让你直观感受 Claude Code 的能力边界，我说一下我实际用它写脚本的经历。有一个周末我需要批量重命名一组图片，按照文件名中的日期信息，把 YYYYMMDD_HHMMSS.jpg 这种格式转换成带有可读日期名称的格式。这个需求虽然不复杂，但涉及正则提取、日期解析、文件系统操作、排除非常规格式等细节，很容易在各种边缘情况上翻车。

我把需求描述给 Claude Code，它在几分钟内给出了完整脚本，并且主动询问了几个我事先没想到的问题：文件名格式是否统一、遇到重复名字要如何处理、是否需要保留原始文件的备份。这些都是设计良好的脚本时需要考虑的点，说明它在实际生成代码时的表现还是相当不错的。

但我也要提醒一句：它的输出并不总是完美无缺。同一个任务我跑了两次，第二次它给出了完全不同的实现方案——用路径库而不是正则、用字典处理冲突而不是简单的判断。这说明它的输出随机性较大，所以人工审查永远是必要的。我的做法是：拿到代码后，先别急着运行，理一遍逻辑，看看它在边界情况上的处理是否符合你的预期，然后在小范围数据上测试通过后再全量执行。

5. 常见问题排查

这部分我把自己和身边朋友实际遇到过的问题整理成一个速查表，按出现频率排序。每个问题都给出了判断方法和解决步骤，照着排查基本能解决九成以上的安装集成问题。

下面挑几个典型的展开讲讲。

5.1 关于“command not found”的深层解释

先说你刚安装完，输入claude --version却提示找不到命令。先用这条命令查到 npm 的全局 prefix：

npm config get prefix

NodeSource 安装方式下，输出通常是/usr，那么对应的 bin 目录就是/usr/bin，这通常已经在本系统的 PATH 里了，一般不会出现找不到命令的问题。如果你看到的输出是/usr/local，那也是标准路径，没有问题。真正容易出现问题的场景是 nvm 安装的 Node：npm prefix 是你的~/.nvm/versions/node/v20.x.x，bin 在~/.nvm/versions/node/v20.x.x/bin，这串路径不会默认出现在非登录 shell 的 PATH 里。

我建议直接在~/.bashrc末尾加一行：

export PATH="$HOME/.nvm/versions/node/v20.x.x/bin:$PATH"

加完之后source ~/.bashrc让配置生效。然后你再执行which claude，应该能看到完整路径。

5.2 VSCode 扩展能加载但无法创建会话的问题

这个问题的变种很多，常见表现是：扩展图标出现了，面板也能打开，但只要一发消息就报错，或者长时间没有响应。

我排查这个问题的经验顺序是：

先看 VSCode 集成终端里是否能正常启动 claude。如果终端里能启动，但扩展面板不行，大概率是扩展进程的登录凭证无法访问。VSCode 扩展进程使用的是当前用户的登录状态，但如果你的 VSCode 是从 sudo 方式启动的，它可能读取的是 root 用户目录下的~/.claude，而你在终端里用普通用户的身份登录的，两边凭证不互通，就会导致“一个能用、一个不能用”的灵异现象。

解决方案很粗暴：不要用 sudo 启动 VSCode。正常从应用程序菜单双击图标打开，或者在终端不带 sudo 执行code。如果之前不小心用 sudo 打开过 VSCode，最好把~/.claude目录权限确认一下，避免文件属主混乱。

5.3 关于自定义 API 端点的说明

很多人问 Claude Code 能不能对接其他兼容 API 的服务，比如本地部署的模型服务或其他厂商提供的兼容接口。这是一个合法且常见的工程需求——在配置层面，Claude Code 支持通过环境变量指定 API 基础地址。

具体来说，可以在启动 claude 之前设置：

export ANTHROPIC_BASE_URL="http://你的服务地址" claude

这样 CLI 在请求时会访问你指定的接口地址，而不是官方默认的接口。这个能力在做内网部署、本地模型调用、或者团队内部网关转发的场景下非常实用。

但我在实际测试中发现，不同版本的 Claude Code 对自定义 API 端点的兼容程度不一样。较新的版本会要求在请求头里带特定的模型标识，如果你的 API 服务不支持对应的模型名，会返回错误。解决方法是查看服务方文档，找到它支持的模型标识，然后通过 OpenAI 兼容模式去适配。这一段我不过度展开，因为不同服务的配置细节差异较大，你只需要知道有这个环境变量开关就行。

5.4 日志目录与获取调试信息的技巧

如果上面的排查都没解决你的问题，我建议直接看日志。Claude Code 会把日志写到~/.claude/logs目录，VSCode 扩展的日志则可以通过命令面板（Ctrl+Shift+P）输入 “Output: Show Output Channels”，然后从下拉列表里选择 Claude Code 相关的通道查看。

日志文件里会记录每一次请求、返回、错误堆栈，排查问题的时候信息量非常大。有一次我遇到扩展一直提示“request failed”，看日志才发现是本地时钟偏差问题导致请求签名校验失败，这在时间偏移大的机器上偶尔会出现，调一下 NTP 时间同步就解决了。这种问题不看日志几乎想不到。

6. 多环境共存与团队协作经验

6.1 如何在同一台机器上切换不同版本

如果你一边用线上环境的稳定版 Claude Code，一边又想试试最新功能，在同一个全局目录装来装去很痛苦。我试过两种比较干净的方式：

第一种是使用 npm 的别名安装。比如：

npm install -g @anthropic-ai/claude-code@beta

注意这里如果你原本的非 beta 版本也在全局目录，覆盖安装会把两个版本搞混。更稳妥的办法是使用 npx：

npx @anthropic-ai/claude-code@latest

这样不会动你全局的安装版本，每次临时用最新版跑一次。缺点是启动参数要带整串前缀，日常用起来不太顺手。

第二种方式是把不同版本放进不同的目录，然后用 alias 切换。我在~/.claude-versions/stable和~/.claude-versions/canary两个目录里分别执行npm install（注意加--prefix参数），然后在~/.bashrc里定义两个别名：

alias claude-stable="~/.claude-versions/stable/bin/claude" alias claude-canary="~/.claude-versions/canary/bin/claude"

这样切换版本就是敲一下命令的事。如果你觉得当前版本足够稳定，其实没必要折腾这种玩法，但如果你喜欢尝鲜，这个方案值得一试。

6.2 团队共享配置的最佳实践

目前我在一个小团队里推动使用 Claude Code，最初遇到的一些协调性问题如下：

一是模型参数不一致。每个人各自在对话里设温度、上下文窗口，导致同一个任务在小明机器上表现很好，在小红机器上却效果很差。解决方式是把共享配置写入项目的.claude/settings.json，比如：

{ "model": "claude-sonnet-4-5", "permissions": { "allow": ["Bash", "Read", "Edit"] } }

这个文件放在项目目录下，配合同事克隆仓库后就能自动加载，起到项目级默认配置的作用。个人级的偏好写在~/.claude/settings.json里，二者是叠加关系，项目级优先。

二是凭证管理。千万别把~/.claude目录整体提交到 git 仓库里，里面包含登录凭证和你本地的对话历史。建议在.gitignore里加上：

.claude/ .claude.json

团队的共享配置只放上面那种 settings.json，并且里面不能有密钥类的字段。

6.3 对话历史的保存与恢复

Claude Code 默认会把每个会话的历史写到本地，位置在~/.claude/projects下，按项目路径编码的目录名区分。我经常用到的一个技巧是：某次会话的输出非常有参考价值，我会用claude --resume命令来恢复最近的会话，或者用claude --resume <会话ID>恢复指定的会话。

在 VSCode 的扩展面板里，左侧的会话列表也能找到以前的历史对话，点进去就能继续聊。这个功能在长时间调试场景下很实用——有时候调试到一半，我去开会吃饭，回来之后重新打开 VSCode，直接恢复上次的会话接着聊，上下文完全接续，不用从头再描述一遍问题。

7. 一些锦上添花的用法补充

7.1 用 Claude Code 处理 git 冲突和代码审查

除了写代码，我用得比较多的是代码审查和冲突解决。之前一次合并分支时出现了十几个冲突文件，看着头大。我用 claude 启动了对话，把其中一个冲突文件的内容送进去，让它分析两边版本的差异并给出合并建议。

它的表现是：先分别解释两个分支的意图，然后给出推荐保留哪一边，或者给出一个融合两者的方案，并把对应的代码写出来。我逐个文件处理过去，效率比手工解决高很多。当然冲突解决这个场景风险较高，涉及业务逻辑的取舍不能全交给 AI 判断，但用来做初步分析和建议，它节省的时间是实打实的。

另外，我也习惯在提交代码之前让 claude 做一个快速的 code review。比如执行：

请审查当前 git 变更，重点关注潜在的 bug、资源泄漏和安全问题

它会读取 git diff，给出若干条改进建议。这些建议的质量浮动比较大，有时候很准确，有时候是过度设计，但作为初步过滤是很有效的。通过审查发现过真实存在的问题，比如未处理的异常路径、不一致的错误返回值等。总体来看，花费半分钟让它扫一遍，比自己肉眼审查要全面得多。

7.2 结合 Shell 脚本做批量任务

Claude Code 最有价值的场景之一是“你描述个想法，它给你写脚本”。我做过一个比较典型的事情：我有一个目录里有几千个文本文件，需要把所有符合条件的行抽取出来，按照模板组织成新的 CSV。我描述完需求，它直接给出了一段 awk + python 混排的 Shell 脚本，考虑到了输入文件名中的特殊字符、编码问题，还附带了一个 dry-run 模式。

实际使用中有意思的地方在于它的交互式确认机制——它在执行 Shell 命令之前会打印命令并请求你的确认。你可以在确认提示符里输入一些修饰词来调整它，比如“用更保守的参数”、“不要删除文件”、“只输出统计信息”等等，它是能理解这些指令并修改命令再执行的。这个交互模式我很喜欢，你始终对系统行为有最终控制权。

7.3 注意事项：在敏感操作前的自我保护

最后说一个我认为非常重要的实用建议：在让 Claude Code 执行任何可能影响项目状态的操作前，先做好版本保存。我见过有同行在让 claude 做批量文件重命名时，没有提前 commit，执行完后发现命名规则不对，又只能手动改回来，非常狼狈。

如果你用了 git，一条命令解决：

git add -A && git commit -m "snapshot before claude task"

让 claude 执行完之后，用git diff看它到底改了什么，符合预期再保留。另外，不要轻易给它 root 密码或者让它执行需要 sudo 的全局性操作。CLI 工具的权限控制本质上是跟着你启动它的用户来的，你用普通用户启动，它也只能碰你普通用户有权限碰的东西。对于涉及系统级目录、服务配置的敏感操作，建议手动执行而不交给 AI。

我在实际使用中的体会是，Claude Code 这个工具确实能显著提升开发和脚本编写效率，但它更像一个能力很强但也有脾气的工作伙伴——你需要说清楚需求、管理好版本、审查它的输出，而不是把它当成可以完全接管项目的黑盒子。配置好之后，我日常至少有一半的写代码和查资料工作会在 VSCode 里直接通过它完成，工作流的调动也舒畅了不少。如果你也正卡在 Ubuntu 22.04 上某个安装步骤，或者发现了它在你项目里的其他妙用，按照本文的排查流程走一遍，大多问题都能解决。