1. 为什么我选择在终端里跑 Claude Code第一次听说 Claude Code 的时候我其实是有点抗拒的。原因很简单——我已经习惯了在编辑器里点按钮、看图形界面突然让我回到黑漆漆的终端里敲命令总觉得是在开倒车。但真正用下来一周之后我的看法完全变了。终端这个东西一旦你跨过那道心理门槛它带来的效率提升是图形界面很难比的没有鼠标来回切换没有窗口焦点丢失所有操作都是键盘流一条命令下去代码改完、测试跑完、提交也顺手做完了。Claude Code 本质上是一个跑在命令行里的智能编程助手。你给它一个任务描述它会自己去读你的项目文件、理解代码结构、制定修改计划、动手改代码最后还能帮你把改动提交到 git。整个过程你只需要在终端里跟它对话就行。它解决的核心问题是把想改什么和改完提交之间的所有琐碎操作压缩成一句话。适合谁来用我觉得三类人最合适一是天天跟终端打交道的后端和运维同学二是想提升编码效率但又不想被 IDE 插件绑死的前端三是刚学编程、想通过观察 AI 怎么改代码来学习的新手。这篇文章我不打算写成官方文档的翻译而是按照我自己从零装好、跑通第一个任务、一直到成功提交的完整路径来写。中间踩过的坑、想明白的道理、以及那些文档里不会告诉你的细节我都会摊开讲。你跟着走一遍基本就能在自己的机器上复现同样的流程。2. 装之前先把环境理清楚2.1 终端工具的选择与取舍很多人一上来就问用哪个终端其实这个问题没有标准答案但有几个实际因素值得考虑。如果你在 macOS 上系统自带的 Terminal 就够用但我更推荐 iTerm2 或者 Tabby原因是它们支持分屏和更好的字体渲染长时间盯着看眼睛舒服很多。Windows 用户的选择稍微复杂一点传统的 cmd 和 PowerShell 能用但体验一般Windows Terminal 是目前比较舒服的选择支持多标签和自定义配色。如果你想要跨平台一致的体验Tabby 是个不错的选项它在 Windows、macOS、Linux 上都有配置可以同步。Linux 用户基本不用纠结系统自带的终端模拟器加上 tmux 就非常能打了。这里提一句终端复用工具 tmux它的价值在于你可以把一个终端窗口切成多个面板一边跑 Claude Code一边看日志一边留着 shell 随时敲命令。更关键的是即使你关掉窗口或者网络断了tmux 里的会话还在后台跑着重新连上就能恢复。对于需要长时间跑任务的人来说这个特性几乎是刚需。提示不管你选哪个终端先把字体换成等宽字体并且开启连字ligature支持。代码里的箭头、不等号这些符号显示会正常很多阅读体验提升明显。2.2 Node.js 环境的准备Claude Code 是通过 npm 分发的所以你得先有 Node.js。我建议直接装 LTS 版本不要追最新的奇数版本稳定优先。装完之后在终端里敲node -v和npm -v确认一下版本号能正常输出。如果提示命令找不到说明环境变量没配好这是新手最容易卡住的地方。Windows 上装 Node.js 有个坑如果你用的是 nvm-windows 来管理版本有时候会出现全局包安装路径和系统 PATH 不一致的情况导致装完了 Claude Code 却找不到命令。遇到这种情况先npm config get prefix看看全局路径在哪再确认这个路径在系统环境变量里。macOS 和 Linux 上用 nvm 的话相对省心但记得每次新开终端要nvm use一下对应版本或者把默认版本设好。2.3 git 的安装与基础配置git 是这套流程里绕不开的一环因为 Claude Code 最后要帮你提交代码。安装本身很简单Windows 去官网下载安装包一路下一步macOS 用 Homebrew 一行命令搞定Linux 用包管理器装就行。装完之后第一件事是配置用户名和邮箱这两项会写进你的每一次提交记录里git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有个细节很多人忽略如果你同时用 GitHub 和 Gitee可能会想给不同仓库配不同的身份。那就不要用--global而是在具体仓库目录里单独配置。另外提交注释的规范也值得提前想好我个人的习惯是遵循约定式提交Conventional Commits比如feat:开头表示新功能fix:表示修 bugdocs:表示文档改动。这样后面看提交记录的时候一目了然Claude Code 生成的提交信息也更容易保持一致。注意如果你之前配过 git 但换了电脑或者改了邮箱记得用git config --list检查一下当前生效的配置避免提交记录里出现错误的身份信息。3. 安装 Claude Code 并跑通第一个任务3.1 安装命令与常见报错处理安装命令本身很短npm install -g anthropic-ai/claude-code但这一行命令背后可能出的问题不少。我整理了几个自己遇到过或者帮别人排查过的典型情况报错信息原因解决办法EACCES: permission denied全局目录没有写权限不要用 sudo改用 nvm 管理 Node或者修改 npm 全局路径auto-update failed: no write permission to npm prefix自动更新时没有写权限同上根源都是全局目录权限问题command not found: claude全局 bin 目录不在 PATH 里检查npm config get prefix把对应 bin 目录加进 PATH安装卡住不动网络原因导致包下载慢换用国内镜像源或者配置代理注意合规使用我自己的做法是用 nvm 管理 Node 版本这样全局包都装在用户目录下完全避开权限问题。如果你已经用系统包管理器装了 Node又不想重装那就手动改 npm 的全局路径npm config set prefix ~/.npm-global然后把~/.npm-global/bin加到 PATH 里。这一步做完之后重新安装就不会再有权限报错了。3.2 首次启动与登录流程装好之后在终端里直接敲claude就能启动。第一次运行会引导你完成登录通常是打开浏览器授权。这里有个小细节如果你在远程服务器上跑没有图形界面它会给你一个链接让你在本地浏览器打开然后把授权码粘贴回去。整个过程不算复杂但要注意授权码有时效性别磨蹭太久。登录成功之后你会看到一个交互式的提示符这时候就可以开始对话了。我建议第一次先别急着让它改代码而是先问它几个关于当前项目的问题比如这个项目的入口文件在哪、用了哪些主要依赖。这样做有两个好处一是验证它确实能读到你的文件二是让你感受一下它的回答风格和准确度。3.3 计划模式先想清楚再动手Claude Code 有一个我觉得非常关键的模式叫计划模式。开启之后它不会直接改代码而是先给你一份修改计划列出它打算动哪些文件、每个文件改什么、为什么这么改。你确认没问题了它才动手。这个模式的价值在于AI 改代码最怕的就是它理解偏了你的意图然后一通乱改你还得一个个回滚。有了计划模式你可以在它动手之前就发现方向性问题成本低很多。我的习惯是任何涉及超过两个文件或者逻辑比较复杂的任务都先走计划模式过一遍。简单的一行修改就没必要了直接让它改更快。提示计划模式里如果它列的计划你觉得不对直接告诉它哪里不对、应该怎么改它会重新出计划。这个来回沟通的过程其实也是你梳理自己需求的过程。4. 从任务描述到代码提交的完整实操4.1 用一个真实小任务走完全流程我拿一个自己项目里的小需求来演示给一个工具函数加上参数校验如果传入的不是数字就抛出明确的错误。这个任务足够小但涉及读代码、改代码、跑测试、提交四个环节正好把完整流程走一遍。第一步我在项目根目录启动 Claude Code然后输入任务描述。我的描述是这样的在 utils/calculate.js 里有一个 divide 函数现在传入非数字参数会返回 NaN我希望改成传入非数字时抛出 TypeError错误信息里要包含实际传入的值。改完之后跑一下现有的测试。第二步它开始读文件。我能看到它在读取 calculate.js 和对应的测试文件。这个过程是自动的不需要我干预。读完之后它给出了一个修改计划在函数开头加类型检查用 typeof 判断如果不是 number 就 throw new TypeError错误信息用模板字符串拼上实际值。计划里还提到会检查测试文件里有没有覆盖这个场景如果没有就补一个测试用例。第三步我确认计划没问题让它执行。它修改了 calculate.js然后在测试文件里加了一个测试用例。接着它自动运行了测试命令看到测试通过之后告诉我改动完成了。第四步我让它提交。它先运行git status和git diff确认改动范围然后生成了一条提交信息大意是fix: divide 函数增加参数类型校验。我看了下没问题它就执行了git add和git commit。整个过程从我开始描述任务到提交完成大概三分钟。如果手动做读代码、改代码、写测试、跑测试、写提交信息怎么也得十分钟以上。4.2 关键环节的细节拆解上面这个流程看起来顺滑但有几个环节值得展开说。关于任务描述我的经验是越具体越好但不要具体到告诉它每一行怎么写。比如我说在函数开头加类型检查这是给它方向但我不会说用 if (typeof x ! number) throw...那是替它写代码。好的描述应该像你给同事派活说清楚要什么效果、在哪个文件、有什么约束具体实现让它自己决定。关于测试Claude Code 会尝试识别你项目里用的测试框架。如果它识别错了比如你用的是 Jest 但它跑了 Mocha 的命令你直接纠正它就行。我建议在项目根目录放一个说明文件写清楚测试命令是什么这样它每次都能找对。关于提交这里有个细节Claude Code 生成的提交信息质量其实挺高的但偶尔会太长或者太笼统。我的做法是看一眼如果觉得不合适就直接告诉它提交信息改成 xxx它会用git commit --amend重新提交。这个命令在修改最近一次提交时非常有用但注意如果已经推送到远程了amend 之后需要强制推送多人协作的仓库要谨慎。4.3 提交记录的整理与回退有时候一个任务改完你发现改动太大想拆成几个提交。Claude Code 本身不直接支持拆分提交但你可以让它帮你做。比如你说把这次改动拆成两个提交一个只包含函数修改一个只包含测试它会用git add -p或者分步 add 的方式来实现。回退也是类似。如果改完发现方向错了你可以说撤销刚才的改动它会用git checkout或者git restore把文件恢复到修改前的状态。但这里有个前提你的改动还没有提交。如果已经提交了就得用git reset了这个操作风险高一些建议先确认清楚再执行。注意任何时候让 AI 操作 git都建议先确保工作区是干净的或者至少你知道当前有哪些未提交的改动。否则一旦回退可能把你手动改的东西也一起弄丢了。5. 踩过的坑和排查经验5.1 权限与路径类问题前面提过 npm 全局权限的问题这里再补充一个场景有些公司的电脑有安全策略不允许往系统目录写文件也不允许修改 PATH。这种情况下nvm 方案也可能受限。我的建议是如果实在搞不定全局安装可以考虑在项目本地安装然后用npx claude来启动。虽然每次都要走 npx 稍微慢一点但至少能跑起来。另一个常见问题是 git 的 SSH 认证失败。如果你用 SSH 方式克隆仓库但密钥没配好Claude Code 在提交后推送时会报错。解决办法是检查ssh -T gitgithub.com能不能通不通就重新生成密钥并添加到账户里。如果公司网络对 SSH 有限制那就改用 HTTPS 方式配合凭据缓存或者访问令牌。5.2 模型响应异常的处理偶尔会遇到 Claude Code 卡住不响应或者回复到一半断了。这种情况通常是网络波动导致的。我的处理方式是先按 CtrlC 中断当前操作然后重新发起。如果频繁出现检查一下网络稳定性。另外如果任务特别大比如让它一次性改十几个文件响应时间会明显变长这时候耐心等一等或者把任务拆小一点。还有一种情况是它理解错了你的意图改出来的东西完全不是你想要的。这时候不要急着让它继续改先让它把改动撤销然后重新描述任务。在错误的改动上继续叠加修改只会越来越乱。5.3 常见问题速查表现象可能原因排查方向启动时报命令找不到PATH 没配好检查 npm 全局 bin 目录是否在 PATH登录后无法读取文件工作目录不对确认在项目根目录启动而不是用户主目录提交时提示身份未配置git user.name/email 缺失运行 git config 检查并补上测试命令跑错项目测试框架识别错误在项目说明文件里写清楚测试命令改动范围超出预期任务描述太模糊用计划模式先确认再执行自动更新失败全局目录无写权限改用 nvm 或修改 npm prefix5.4 几个提升效率的小技巧第一个技巧是善用git commit --amend。当你刚提交完发现漏了一个文件或者提交信息有错别字不用重新提交一次直接 amend 就行。Claude Code 对这个命令的支持很好你直接说把刚才的提交信息改成 xxx它就会用 amend。第二个技巧是给项目写一个 CLAUDE.md 文件。这个文件放在项目根目录里面写清楚项目的技术栈、目录结构、测试命令、代码规范等信息。Claude Code 启动时会自动读取这个文件这样你就不用每次重复解释项目背景了。我自己的 CLAUDE.md 里会写用什么包管理器、测试怎么跑、提交信息用什么格式、有哪些目录不要动。写一次后面省很多事。第三个技巧是分屏操作。用 tmux 或者终端自带的分屏功能一边跑 Claude Code一边留一个 shell。这样当它需要你确认某个操作或者你想手动检查某个文件时不用来回切换窗口。我通常是左边跑 Claude Code右边跑一个 watch 模式的测试改完代码测试结果实时刷新一目了然。6. 我对这套工作流的真实体会用 Claude Code 这段时间最大的感受是它改变了我对写代码这件事的节奏感。以前我改一个功能思路是线性的打开文件、找到位置、改、保存、跑测试、提交。现在更像是对话式的我描述意图它执行我看结果给反馈。这个过程中我更多是在做决策和审查而不是在敲键盘。但这不意味着可以完全放手。我踩过的最大的坑就是有一次任务描述写得太模糊它理解偏了一口气改了七八个文件等我发现的时候已经提交了。回退花了不少时间。从那以后我就养成了习惯稍微复杂点的任务一定先走计划模式看清楚它要动哪些文件再放行。另外一点体会是git 的基本功还是得扎实。Claude Code 能帮你执行 git 命令但当你需要回退、拆分提交、解决冲突的时候如果你自己不懂 git 的原理就很难判断它做得对不对。所以我的建议是把这次上手当成一个契机顺便把 git 的常用命令和概念过一遍后面会省心很多。最后分享一个我最近发现的小用法当你接手一个陌生项目不知道从哪看起的时候可以让 Claude Code 帮你梳理。比如问它这个项目的请求处理流程是怎样的从入口到返回经过哪些文件它会读代码然后给你一条清晰的路径。这比你自己一个个文件翻快多了而且它还会告诉你每个文件大概负责什么。这个用法我现在每次看新项目都会用算是意外收获。