Claude Code 是 2025 年 2 月跟着 Claude 3.7 一起放出来的，我拖了快一年才认真试。理由很实在：前一年用 DeepSeek 用得顺手，工作流没觉得缺东西，就没动力再多学一个工具。

上个月终于装上了，试了一晚，第一晚就踩了几个坑。

这个名字容易被误读。它不是给 Claude 做一个代码编辑器，也不是那种按 Tab 补全的插件——它更像一个能自己动手的同事：你描述需求，它去读仓库、找文件、改代码、跑命令、看报错，然后接着改。

装之前要知道的三件事

第一，它要 Node 环境，通过 npm 装（包名是 @anthropic-ai/claude-code），装完在项目目录里直接敲 claude 启动。

第二，它要花钱，而且是按 token 走的。不是包月套餐里随手用用的那种量级，长上下文的时候消耗更明显。

第三，也是最需要心理准备的一点：它会动你的文件。不是给你一段代码让你复制，是真去改文件、真去执行命令。

第一晚我让它做了什么

我拿了一个自己写的小项目试，Python 加一堆散脚本，没有类型检查，只有零散的几个测试。

第一件事是让它熟悉项目。它会自己用搜索命令在仓库里翻，找入口文件、看目录结构，读几个关键文件，然后把理解讲一遍。这一步比我预想的准，它没有上来就瞎改。

第二件事是让它在现有代码里加一个小功能。这个环节它表现得很好：改了三个文件，顺手把调用点也更新了，还自己跑了一遍测试。以前用补全类工具，改完三个文件之后调用点是我自己的活。

第三件事是让它修一个失败测试。它先跑测试看报错，改了代码又跑一遍，发现没修好，换了个思路再改。这个循环——读报错、改、再跑——是它最像”在干活”的地方。

也出过一次让我很无语的情况。我让它把处理单个文件的脚本改成支持批量，它顺手引入了 pandas——可那个项目里只装了标准库，跑起来直接 ModuleNotFoundError。它不是不知道要看依赖，而是默认”这个库这么常见，应该有”。后来我在 CLAUDE.md 里把”不许新增第三方依赖”写成明文，这类事就少多了。

顺便说一句它找文件的方式：不是靠我告诉它路径，而是自己用搜索和列目录的命令一层层翻。项目根目录放一个 CLAUDE.md 写清楚约定（用什么测试框架、代码风格、哪些目录别动），它会读，而且基本照做。这一点比提示词有用得多。

它是怎么拿到权限的

第一次让它执行命令时，它会先问同不同意；同意之后，同类命令在这次会话里就不再多问。写文件同理。

这个设计是对的——一个能随手跑删除命令的工具，不确认才可怕。但它带来一种新的注意力消耗：确认弹窗来得很快，多的时候人会下意识一路回车。我后来给自己定了条规矩：删除、覆盖、回滚这三类命令，不看清楚不点同意，其余放行。这条规矩救过我一次——那次它想从仓库根目录执行一个清理脚本，而那个路径下还有我另外两个项目。

让我不太舒服的地方

一个是改得太多。让它加一行判断，它可能会顺手重构周边逻辑、改命名、加日志。对它的思路来说这是”顺手”，对我来说这是额外要 review 的 diff。

一个是猜。遇到它不确定的库 API，它不一定会停下来问，而是照着”看起来合理”的样子写。跑起来报错还好，最麻烦的是不报错但行为不对的那种。

还有一个是它太快就开始动手。有些任务我想要的其实是”先说说你打算怎么改”，但它更喜欢直接给结果。后来我养成了习惯：开头就说清楚”先给方案，别改文件”。

一晚上下来留下的习惯

  • 先提交。开动之前 git commit，让所有改动可以一键回退。这不是多余步骤，是底线。
  • 任务切小。”把这个模块重构一下”这种指令，出来的 diff 我基本没法看；”把这三个函数里的重复逻辑提取成一个函数，别动调用方”这种就顺得多。
  • 要它先说计划。一句话的事，能省下大量来回。
  • 看 diff 再看结果。它说”改好了”，不代表改的是我想要的。跑测试通过也不代表逻辑对。
  • 项目里最好有测试。有测试的项目里它像个靠谱的同事，没测试的项目里它是个手很快但没人监督的实习生。

关于成本

一晚上试下来，token 消耗比我预估的高。让它读整个仓库、反复跑测试、出错重试，全是钱。我后来把用它的场景收窄到两类：一类是”改动的范围我完全清楚，只是懒得敲”，一类是”这是我完全不熟的技术栈，需要它带我认路”。

有人在网上把这种写法叫 vibe coding——不去细看代码，凭感觉让它一路写下去。我现在的态度是：小项目、自己用的工具，可以这么玩，反正坏了就重写；但涉及别人要用的东西，diff 还是得一行一行看。判断标准不是”它写得对不对”，而是”出了问题我能不能定位”。

什么任务适合交给它

试了一晚，大概摸出个边界。

适合的：跨多个文件的机械改动，比如改函数签名、统一命名、把重复逻辑提出来；在我不熟的技术栈里”带我认路”式的探索；补测试；把一段能跑的脚本收拾成能读的样子。

不适合的：需求本身还没想清楚的时候。我不敢让它替我决定架构——它会给出一个”看起来合理”的方案，而且话说得很有把握，等我发现方向不对，diff 已经铺开一大片。也不适合拿它去碰没有版本管理、没有测试、还正在线上跑的东西。

有一点值得单独说：它把”写代码”这件事的时间分布改了。以前我大部分时间在打字和查文档，现在大部分时间在描述需求、看 diff、判断它有没有跑偏。手没以前忙，脑子比以前累。

有一点我还没想清楚

它的能力强弱，好像并不主要取决于模型，而取决于项目本身的状态——有没有测试、依赖清不清晰、约定有没有写成文档。同一晚，同一个它，在我的老项目里表现平平，在一个结构干净的小项目里就像换了个工具。

如果是这样，那”用它提效”这件事的第一步可能不是学提示词，而是先把项目收拾干净。这个结论我暂时只信一半，样本太少。