1. 装完 Claude Code 之后第一件事不是急着敲代码很多人装完 Claude Code 的第一反应是赶紧找个项目试试结果一上来就卡在权限确认、目录不对、模型没选对这些问题上。我自己第一次跑的时候也是这样装是装好了但真正让它把一个任务从理解需求跑到git 提交中间踩了不少坑。这篇就把我从零到第一次成功提交的完整过程拆开讲包括安装后的初始化配置、计划模式怎么用、终端里怎么跟它配合、最后怎么让它帮你完成一次规范的 git 提交。先说清楚 Claude Code 是什么定位。它不是那种你在网页里聊天、复制粘贴代码的工具而是直接跑在你终端里的命令行助手。它能读你本地的文件、执行命令、改代码、跑测试甚至帮你写 commit message 然后提交。核心价值在于它在你真实的开发环境里干活而不是在一个隔离的沙箱里给你建议。这就意味着两件事第一它对目录结构、git 状态、依赖环境是有感知的第二它的操作会真实影响你的工作区所以权限管理和操作确认机制必须搞清楚。适合谁来参考这篇内容如果你已经装好了 Claude Code或者正准备装想尽快跑通一个完整流程那这篇就是给你写的。不需要你是 git 高手但至少要能看懂基本的终端命令。我会把每一步为什么这么做讲清楚而不是只丢一串命令让你抄。整个流程我拆成几个阶段安装后的环境确认、项目目录的准备、计划模式的启用、任务的拆解与执行、最后到 git 提交的收尾。每个阶段都有它存在的理由跳过任何一步后面都可能出问题。2. 安装完成后的环境自检别让低级问题浪费你半小时2.1 确认 Claude Code 真的在 PATH 里装完之后第一个要确认的是命令能不能直接调用。打开终端敲claude --version如果返回版本号说明安装基本没问题。如果提示 command not found大概率是 npm 全局 bin 目录没进 PATH。这种情况在 macOS 和 Linux 上都挺常见尤其是用 nvm 管理 node 版本的时候全局包会装在 nvm 对应的目录下而不是系统默认路径。排查方法很简单npm config get prefix拿到这个路径后确认它的 bin 子目录在 PATH 里。如果不在在 shell 配置文件里加一行以 zsh 为例export PATH$(npm config get prefix)/bin:$PATH然后source ~/.zshrc重新加载。这一步看着基础但我见过太多人卡在这里以为是安装失败反复重装其实只是路径问题。2.2 检查 node 版本是否达标Claude Code 对 node 版本有要求版本太低会直接报错或者行为异常。跑一下node -v如果低于官方要求的最低版本建议用 nvm 切一个较新的 LTS 版本。这里有个经验不要用太激进的版本LTS 通常最稳。切换之后记得重新确认claude --version还能正常返回因为全局包是绑定 node 版本的切版本后可能需要重新安装。2.3 首次启动的登录与模型选择第一次运行claude会引导你完成认证。这一步按提示走就行关键是认证完成后要确认当前使用的模型。不同模型在代码理解和长上下文处理上差异明显跑复杂任务时选错模型会直接影响体验。启动后可以用斜杠命令查看当前状态确认工作目录、模型、权限模式这些信息。我习惯在正式干活前先看一眼避免在错误的目录里让它读文件。注意如果你在多个项目之间切换每次启动前确认一下当前工作目录。Claude Code 默认以启动时的目录为工作根目录不对会导致它读不到你的项目文件。2.4 权限模式的选择逻辑Claude Code 在執行敏感操作比如写文件、跑命令、git 提交时会请求确认。这个机制是保护你的工作区不被误改。但如果你每个操作都要手动点确认效率会很低。常见的做法是前期用默认的逐步确认模式熟悉它的行为逻辑等你摸清它的操作习惯后再针对特定类型的操作放开权限。不要一上来就全放开尤其是涉及删除、覆盖、git push 这类不可逆操作时确认机制是你最后的安全网。3. 把项目目录准备好比什么都重要3.1 一个干净的 git 仓库是前提Claude Code 帮你做提交前提是这个目录本身是个 git 仓库。如果还没初始化git init然后确认 git 的用户名和邮箱配置好了否则提交会失败或者作者信息不对git config user.name git config user.email这两个值会写进你的 commit 记录里。如果是公司项目用错账号提交会很尴尬。我建议在项目级别单独配置而不是依赖全局配置这样不同项目可以用不同身份。3.2 先手动做一次初始提交这一步很多人会跳过但我觉得很有必要。在让 Claude Code 介入之前先手动把当前状态提交一次形成一个干净的基线。这样做的好处是后面 Claude Code 改了什么你通过git diff能看得一清二楚出问题也能一键回退到这个基线。git add . git commit -m chore: initial baseline before claude code session有了这个基线你就有了后悔药。这是我踩过坑之后养成的习惯——曾经有一次让它批量改文件改完发现方向不对幸好有基线直接 reset 回去了。3.3 确认 .gitignore 到位在让它干活之前检查一下.gitignore有没有配好。node_modules、构建产物、本地配置文件、密钥文件这些都不应该进版本库。如果.gitignore缺失Claude Code 在帮你git add .的时候可能把这些垃圾文件一起提交进去清理起来很麻烦。一个典型的 Node 项目.gitignore至少要有node_modules/ dist/ .env *.log3.4 目录结构的可读性Claude Code 读文件是靠路径和内容匹配的。如果你的目录结构混乱文件命名随意它定位相关文件的效率会下降。花几分钟把目录理顺对后续任务执行帮助很大。这不是玄学是它检索上下文时的实际影响。4. 计划模式让它在动手之前先把思路讲清楚4.1 为什么一定要用计划模式这是我觉得 Claude Code 最值得强调的功能之一。所谓计划模式就是让它先不写代码、不改文件而是先输出一份我打算怎么做的方案。你可以把它理解成开工前的需求评审。为什么这个模式重要因为 AI 改代码最大的风险不是改错一行而是方向性误解。它可能理解错了你的需求然后一口气改了十几个文件等你发现不对已经很难回退了。计划模式把理解和执行拆成两步你可以在它动手之前就纠正方向。4.2 怎么触发计划模式在对话里明确告诉它先给方案比如先不要改任何文件给我一个实现计划列出你打算修改哪些文件、每个文件改什么、为什么这么改。或者用内置的模式切换命令进入 plan mode。进入之后它的输出会聚焦在方案上不会直接动你的代码。4.3 一份好的计划应该包含什么我判断一份计划靠不靠谱主要看这几点它有没有正确理解任务目标而不是答非所问它列出的待改文件是否合理有没有漏掉关键文件或者多改了无关文件每个改动点的理由是否说得通有没有提到潜在的风险和边界情况如果计划里出现我会优化相关代码这种模糊表述就要警惕了这说明它没想清楚具体改什么。这时候你应该追问让它细化。4.4 在计划阶段就要纠偏计划阶段是成本最低的纠偏时机。你可以直接说第三个文件不用改你理解错了我的需求是 xxx这个方案会影响 xxx换个思路。它调整方案几乎不花时间但如果你等它改完代码再纠正返工成本就高了。我一般的做法是计划出来后先通读一遍把不认可的点标出来一次性反馈给它让它出第二版计划。通常两轮之内方案就能收敛。5. 从任务执行到验证终端里的实际配合方式5.1 任务拆解要颗粒度适中一个任务如果太大比如帮我把这个项目重构一遍Claude Code 很容易跑偏或者中途迷失。更好的做法是拆成可验证的小任务比如把 utils 目录下的日期处理函数统一成 dayjs给 user 模块补上参数校验。每个小任务都有明确的完成标准你能快速判断它做对了没有。做完一个确认一个再进入下一个。这种节奏比一次性丢个大任务要稳得多。5.2 让它自己跑测试和验证Claude Code 能执行终端命令所以你可以让它改完代码后自己跑测试改完之后跑一下 npm test把失败的用例贴出来。它会执行命令、读取输出、根据报错继续修。这个闭环能力是它区别于纯聊天工具的关键。但要注意测试命令本身要能在你的环境里跑通如果测试环境本身是坏的它会陷入无效循环。5.3 用 git diff 做人工复核它每完成一个改动我都会习惯性看一眼 diffgit diff重点看几件事有没有改到不该改的文件、有没有引入调试用的 console.log、有没有把配置文件的密钥写死。AI 生成的代码整体质量通常不错但偶尔会有这类顺手的小动作人工过一眼能挡掉大部分。5.4 遇到它卡住时怎么处理有时候它会反复尝试同一个错误方案陷入死循环。这时候不要干等直接打断把错误信息和你自己的判断告诉它你刚才的方案不对报错是 xxx我怀疑是 xxx 导致的换个方向试试。给它提供新的信息或者约束比让它自己瞎撞效率高得多。我遇到过它在依赖版本问题上绕圈最后是我手动指定了版本号才解决。5.5 上下文管理的经验对话太长之后它的表现会下降因为上下文里塞了太多历史信息。这时候可以开新会话把当前状态和待办事项简要描述一下重新开始。或者用内置的压缩命令把历史对话精简。我的经验是一个会话专注一件事做完就收不要在一个会话里塞太多不相关的任务。6. 收尾让它帮你完成一次规范的 git 提交6.1 提交前先确认改动范围在提交之前先看整体状态git status确认哪些文件被改了、哪些是新加的、有没有意外文件混进来。这一步是提交前的最后一道关。如果发现不该提交的文件及时处理掉比如加进.gitignore或者手动排除。6.2 让 Claude Code 生成 commit message这是它很擅长的一件事。你可以直接说根据当前的改动帮我写一个符合 conventional commits 规范的提交信息。它会读取 diff总结改动内容生成类似feat: add date formatting utility这样的信息。conventional commits 的好处是提交历史清晰方便后续生成 changelog 和做版本管理。如果你对生成的 message 不满意可以让它调整比如太笼统了具体说明改了哪个模块。6.3 提交操作的执行方式有两种方式让它执行提交或者你自己手动提交。如果让它执行它会跑git add和git commit。这时候权限确认机制会介入你确认一下命令内容没问题再放行。如果自己手动提交就把它生成的 message 复制过来用。我个人的习惯是message 让它生成但提交命令我自己敲。这样我对到底提交了什么有完全的掌控尤其是git add的范围我会手动指定而不是用git add .避免误加文件。6.4 提交之后验证提交完成后确认一下git log --oneline -5看看最新的提交记录是否符合预期作者信息对不对message 是否清晰。如果发现提交信息写错了可以用git commit --amend修改最近一次提交的信息。但注意如果这个提交已经推送到远程amend 会导致历史不一致需要谨慎处理。6.5 关于提交粒度的心得一个实用的建议让每个提交对应一个逻辑完整的改动。不要把加功能和修格式混在一个提交里。Claude Code 帮你干活时你可以按任务分批提交每完成一个小任务就提交一次。这样提交历史读起来像一条清晰的故事线出问题也容易定位是哪个改动引入的。7. 几个我踩过的坑和对应的处理方式7.1 自动更新失败与权限问题有段时间启动时总报自动更新失败提示没有 npm 目录的写权限。原因是全局 npm 目录的权限配置有问题。解决办法有两个方向一是修正 npm 全局目录的权限二是干脆用包管理器或者官方推荐的安装方式重装避开权限冲突。我最后是重新配置了 npm prefix 到一个当前用户有写权限的目录问题就消失了。7.2 找不到工作目录相关的功能有时候会提示找不到某个工作目录相关的选项这通常是因为启动 Claude Code 的目录不对或者项目根目录没有正确识别。解决办法是确保在项目根目录启动并且这个目录里有明确的标识文件比如 package.json、.git 等让它能正确判断项目边界。7.3 终端复用带来的困惑如果你用 tmux 或者 tabby 这类终端工具多窗口多会话切换时容易搞混 Claude Code 跑在哪个会话里。我的建议是给它单独开一个窗口或者 pane固定在一个项目目录下不要和别的任务混在一起。这样上下文清晰也不容易误操作。7.4 模型选择的实际影响不同模型在处理长文件和复杂逻辑时表现差异明显。跑简单任务时用轻量模型响应快跑涉及多文件重构的复杂任务时换更强的模型。这个切换成本很低但效果差别很大值得根据任务类型灵活调整。7.5 别让它碰你不懂的东西这条是我最想强调的。如果它要执行一条你看不懂的命令或者要改一个你不了解的文件先停下来搞清楚再说。AI 助手再强也是辅助最终对代码负责的是你。看不懂的操作不放行这是底线。8. 把这套流程固化成习惯之后跑通第一次完整流程之后后面就顺了。我现在的基本节奏是进项目目录、确认 git 状态干净、启动 Claude Code、用计划模式过一遍方案、分小任务执行、每个任务做完看 diff、最后让它生成 commit message 我自己提交。整套下来一个中等规模的任务从理解到提交效率比纯手动高不少而且提交历史反而更规范了因为 conventional commits 的格式被强制执行了。有一点体会比较深工具本身的能力是一方面但真正决定体验的是你怎么用它。计划模式用不用、任务拆得细不细、diff 看不看、权限放不放这些选择叠加起来结果差别很大。把它当成一个需要你引导的协作伙伴而不是一个许愿池效果会好很多。如果你刚开始用建议就按这个流程走一遍哪怕是个很小的任务。跑通一次之后你自然就知道哪些环节需要根据自己的习惯调整了。