1. 装完 Claude Code 之后第一件事不是写代码很多人把 Claude Code 装好终端里敲出那个熟悉的提示符然后就愣住了——接下来干嘛我见过太多人卡在这一步装是装完了但不知道怎么让它真正干活。这篇文章就是解决这个问题的从零开始在终端里把第一个任务从“想法”跑到“git 提交”全程不离开命令行。先说清楚 Claude Code 是什么。它是 Anthropic 推出的命令行 AI 编程助手直接跑在你的终端里能读写文件、执行命令、理解整个项目上下文。和那些网页版的对话工具不一样它就在你的工作目录里能直接操作你的代码。适合谁看如果你已经装好了 Claude Code或者正准备装但不确定怎么把它用起来那这篇就是写给你的。不需要你是终端老手但至少得知道cd和ls是干嘛的。我自己的习惯是装完任何工具先跑一个最小闭环。什么叫最小闭环就是从“提出需求”到“产出结果”再到“留下记录”这一整条链路走通一遍。对 Claude Code 来说这个闭环就是让它改一个文件然后提交到 git。听起来简单但里面有不少细节值得说。为什么强调“终端里跑通”因为 Claude Code 的核心价值就在于它活在终端里。你可以用 VS Code 插件可以用各种 GUI 封装但终端才是它最自然的环境。终端里没有花哨的按钮一切靠命令和对话效率反而最高。而且终端里的操作是可脚本化、可复现的这对开发者来说太重要了。下面我会按实际操作的顺序把整个过程拆开讲。从环境确认开始到计划模式的使用到实际执行任务最后到 git 提交。每一步都会说清楚为什么这么做以及我踩过哪些坑。2. 动手之前的准备工作环境、目录、git 一个都不能少2.1 确认 Claude Code 真的装好了装完 Claude Code 之后第一件事是确认它能在终端里正常调用。打开你的终端——macOS 用 Terminal 或 iTerm2Linux 用你习惯的终端模拟器Windows 用 WSL 或者 PowerShell 都行——然后输入claude --version如果能看到版本号输出说明安装没问题。如果提示 command not found那说明 PATH 没配好或者安装步骤漏了。这时候别急着往下走先把这个问题解决掉。我见过有人装完之后在 VS Code 的集成终端里跑不起来但在系统终端里正常。这种情况通常是 VS Code 的环境变量没继承系统配置。解决办法要么重启 VS Code要么在 VS Code 设置里把终端的环境变量继承打开。实测下来重启大法能解决八成这类问题。还有一个常见情况你在项目目录里跑claude它启动后找不到项目文件。这通常是因为启动目录不对。Claude Code 默认以当前工作目录为项目根目录所以一定要先cd到你的项目文件夹再启动。2.2 准备一个干净的实验项目别拿你正在开发的重要项目练手。新建一个空目录初始化 git放一两个简单文件进去就行。这样做的好处是万一 Claude Code 做了什么出乎意料的改动你不会有任何损失。mkdir claude-code-demo cd claude-code-demo git init echo # Demo Project README.md git add README.md git commit -m init: 初始化项目这几行命令做了几件事创建目录、进入目录、初始化 git 仓库、创建一个 README 文件、把它加入暂存区、提交。为什么要先提交一次因为这样你就有了一个干净的基线。后面 Claude Code 做的任何改动你都能用git diff清楚地看到。注意如果你还没配置 git 的用户名和邮箱提交会失败。提前跑一下git config --global user.name 你的名字和git config --global user.email 你的邮箱。2.3 git 状态要干净这是铁律在让 Claude Code 动手之前务必确认git status显示 working tree clean。什么意思就是没有任何未提交的改动。为什么这么强调因为如果工作区里已经有未提交的修改Claude Code 再一改你就分不清哪些是它改的、哪些是你之前改的。排查问题的时候会非常痛苦。我自己的流程是每次启动 Claude Code 之前先跑一遍git status。如果有未提交的改动要么先提交要么先 stash 起来。这个习惯看起来多余但能省掉很多麻烦。另外提一句.gitignore文件要提前配好。比如node_modules/、__pycache__/、.env这些不该进版本库的东西提前排除掉。不然 Claude Code 可能会去读这些文件浪费上下文窗口还可能把敏感信息带进对话里。3. 计划模式先想清楚再动手别上来就干3.1 什么是计划模式为什么它重要Claude Code 有一个很关键的功能叫计划模式Plan Mode。简单说就是让它先分析任务、给出方案而不是直接动手改代码。这个模式的价值在于你可以在它真正执行之前审查它的思路对不对。我刚开始用的时候觉得计划模式多此一举——直接让它干不就完了后来踩了几次坑才明白AI 编程助手最大的风险不是它不会做而是它理解错了你的意图然后一顿操作猛如虎改了一堆不该改的文件。计划模式就是给你一个“刹车”让你在它动手之前确认方向。怎么进入计划模式在 Claude Code 的对话里你可以直接说“先给我一个计划”或者“plan first”。它就会进入分析状态列出它打算怎么做但不会实际修改文件。你看完计划觉得没问题再说“执行”或者“go ahead”它才会动手。3.2 怎么给 Claude Code 描述任务描述任务的方式直接决定了输出质量。我总结了一个简单的原则说清楚“改什么”和“改成什么样”但不要说“怎么改”。举个例子。假设我想给项目加一个简单的 Python 脚本读取一个文本文件并统计词频。差的描述是“帮我写个代码。”好的描述是“在项目根目录创建一个word_count.py读取input.txt输出每个单词出现的次数按次数从高到低排序。”为什么不说“怎么改”因为那是 Claude Code 的强项。你告诉它目标它自己会选择用字典、用 Counter、还是用其他方式。你如果指定了实现细节反而可能限制了它的发挥或者让它写出不符合项目风格的代码。还有一个技巧如果项目里已经有类似的代码告诉它参考哪个文件。比如“参考utils.py里的风格”。这样它生成的代码会更一致。3.3 审查计划时重点看什么Claude Code 给出计划后你要重点看三件事第一它打算改哪些文件。如果它说要改一个你根本没提过的文件那就要警惕了。可能是它理解错了也可能是它发现了你没意识到的问题。不管是哪种都值得问一句“为什么要改这个文件”。第二它打算用什么方式实现。比如你说“加一个统计功能”它说“我会引入 pandas 库”。如果你的项目是个轻量脚本不想引入重依赖那就要及时叫停。第三它有没有遗漏你要求的关键点。比如你说了“按次数排序”计划里没提排序那就要补充说明。我自己的习惯是计划出来后先通读一遍然后用一两句话确认或修正。比如“计划没问题但不要引入新依赖”或者“第三点改成用标准库实现”。这样比让它直接干要稳妥得多。4. 从对话到执行让 Claude Code 真正动手4.1 执行过程中的实时观察确认计划后让 Claude Code 开始执行。这时候你会看到它在终端里输出各种信息它在读文件、在写文件、在运行命令。别走开盯着看。这不是不信任它而是你需要了解它做了什么。我一般会关注几个点它读了哪些文件如果它读了一个跟任务无关的文件可能是上下文理解有偏差。它运行了什么命令如果它跑了rm或者git reset这类危险命令要立刻叫停。它写了什么内容终端里通常会显示文件变更的摘要扫一眼有没有明显问题。Claude Code 执行的时候你可以随时打断它。按Esc或者CtrlC就能中止。如果发现它跑偏了别犹豫直接停。停下来之后你可以补充说明让它重新来。4.2 执行完之后先别急着提交任务跑完Claude Code 说“完成了”这时候千万别直接git commit。先做两件事第一用git diff看所有改动。这是最可靠的检查方式。终端里会显示每个文件的具体变更加了什么、删了什么一目了然。重点看有没有意外的改动比如格式被批量调整了、注释被删了、或者某个文件被重写了。第二实际跑一下。如果改的是代码运行一下看能不能正常工作。如果改的是配置验证一下配置是否生效。Claude Code 不是万能的它可能写出语法正确但逻辑有问题的代码。实测一下是最稳妥的。我踩过的一个坑有一次让 Claude Code 改一个函数它确实改了但顺手把函数上面的一段注释也删了。那段注释记录了重要的业务逻辑删掉之后我过了两周才发现。从那以后我每次都会仔细看 diff特别是删除的部分。4.3 如果结果不对怎么调整如果发现结果不对有几种处理方式。最简单的是直接告诉它哪里不对让它改。比如“第三行的变量名拼错了”或者“这个函数应该返回列表而不是字典”。Claude Code 会根据你的反馈调整。如果改动比较大方向就错了那就git checkout .把所有改动撤销重新来。这就是为什么之前强调要保持工作区干净——撤销起来毫无负担。还有一种情况它改对了但风格你不喜欢。比如它用了列表推导式但你的项目风格是显式循环。这种时候可以直接说“改成用 for 循环实现”。Claude Code 会尊重你的偏好。提示如果你发现 Claude Code 反复在同一个问题上出错可能是你的描述有歧义。换个说法或者给它一个具体的例子通常能解决。5. git 提交给这次协作画上句号5.1 提交之前的分寸感改动确认没问题了接下来就是提交。但提交之前有一个分寸感的问题哪些文件该提交哪些不该。Claude Code 可能会创建一些临时文件、日志文件、或者缓存文件。这些不应该进版本库。用git status看一下如果发现有不该提交的文件把它们加到.gitignore里或者直接删掉。另外如果 Claude Code 改了多个文件但这些改动逻辑上是独立的可以考虑分多次提交。比如它既修了一个 bug又加了一个新功能那分成两个 commit 更清晰。怎么分用git add指定文件而不是git add .。5.2 写一条像样的提交信息提交信息别随便写。我见过太多fix、update、change这种毫无信息量的提交信息。好的提交信息应该让人一眼看出这次改了什么、为什么改。格式上我习惯用这样的结构类型: 简短描述 详细说明可选类型可以是feat新功能、fix修复、refactor重构、docs文档、chore杂项。简短描述控制在 50 个字符以内详细说明解释背景和原因。比如这次的任务是加词频统计脚本提交信息可以写feat: 添加词频统计脚本 读取 input.txt输出单词出现次数按降序排列。 使用标准库 collections.Counter 实现无额外依赖。这样以后回头看提交记录一目了然。5.3 提交之后的验证提交完成后跑一下git log --oneline -5看看最近的提交记录。确认你的提交在最上面信息正确。然后git status确认工作区干净。如果发现提交信息写错了别慌。还没 push 的话用git commit --amend修改。已经 push 了的话看情况决定要不要 force push——如果是个人分支问题不大如果是共享分支谨慎操作。我自己的习惯是提交之后立刻 push 到远程。这样即使本地出问题代码也不会丢。而且 push 之后CI/CD 如果配了的话会自动跑测试相当于多了一层验证。6. 常见问题与排查技巧实录6.1 Claude Code 启动报错怎么办最常见的启动报错是权限问题。在 Linux 和 macOS 上如果安装时用了sudo可能会导致文件权限不对。解决办法是重新安装不要用sudo或者手动修正权限。另一个常见问题是网络连接。Claude Code 需要访问 API如果你的网络环境有特殊配置可能会连接失败。这时候检查一下终端的代理设置或者确认 API key 是否有效。还有一种情况终端类型不兼容。某些终端模拟器可能不支持 Claude Code 使用的某些转义序列导致显示混乱。换个终端试试比如从 Tabby 换到系统自带终端通常能解决。6.2 它改的文件不是我想要的这是最常见的问题之一。原因通常是项目根目录不对或者.gitignore没配好导致 Claude Code 看到了不该看的文件。排查步骤先确认启动 Claude Code 时所在的目录是不是项目根目录。然后检查.gitignore确保临时文件、依赖目录都被排除了。如果还不行在对话里明确告诉它“只改 xxx 文件”。6.3 执行命令时卡住了Claude Code 执行某些命令时可能会卡住比如它运行了一个需要交互输入的命令或者一个长时间运行的服务。这时候按Esc中断然后告诉它“不要运行需要交互的命令”或者“用非交互模式运行”。我遇到过一次它试图运行npm init这个命令会交互式地问一堆问题结果就卡住了。后来我告诉它“用npm init -y”问题解决。6.4 git 提交时发现大文件如果git add的时候提示文件太大说明你不小心把大文件加进去了。用git reset HEAD 大文件把它从暂存区移除然后加到.gitignore里。如果已经提交了那就麻烦了。需要用git filter-branch或者 BFG 工具来清理历史。所以最好的办法是提前预防.gitignore里把*.log、*.zip、dist/、build/这些常见的大文件目录都加上。6.5 常见问题速查表问题现象可能原因解决办法启动时报 command not foundPATH 未配置检查安装路径添加到 PATH找不到项目文件启动目录不对cd 到项目根目录再启动改了不该改的文件.gitignore 未配置补充 .gitignore明确指定文件执行命令卡住命令需要交互输入中断后改用非交互模式提交时提示文件过大大文件被加入暂存区移除并加入 .gitignore提交信息写错手误未 push 用 --amend已 push 谨慎处理7. 我自己的使用节奏和一些碎碎念用 Claude Code 这段时间我慢慢形成了一套自己的节奏。每次开始一个新任务之前先确保 git 工作区干净然后启动 Claude Code用计划模式让它先分析。计划确认后执行执行完看 diff、跑测试最后提交。整个过程下来一个中等复杂度的任务大概十几分钟就能搞定。有几个小技巧是我踩坑之后总结的。第一对话尽量用英文关键词比如“refactor”、“fix”、“add”Claude Code 对英文技术术语的理解更准确。第二如果任务比较复杂拆成多个小任务一个一个来比一次性描述一大段要靠谱。第三善用git stash如果临时要切分支处理别的事stash 一下比提交半成品要干净。还有一点别完全依赖它。Claude Code 很强但它不是万能的。关键逻辑、核心算法、安全相关的代码自己还是要过一遍。把它当成一个效率工具而不是替代品。最后分享一个我常用的命令组合用来快速查看 Claude Code 改了什么git diff --stat git diff--stat先看概览哪些文件改了、改了多少行。然后再看具体内容。这个组合比直接git diff要清晰得多特别是改动文件多的时候。这个流程跑熟之后你会发现终端里的 AI 协作其实很顺手。没有花哨的界面但每一步都清清楚楚每一次改动都有记录。这大概就是命令行工具的魅力吧。