用 Claude Code 改第一处代码

准备：先开一个分支

git switch -c try-claude-code

这一步不是为了流程好看，而是为了让「不满意」有退路：整条分支可以直接删掉。

同时确认项目本身能跑：依赖装好、测试能执行。它读得懂代码，但跑不起来的环境 会让它只能猜。

第一步：安装并按官网方式启动

安装方式以官方文档当前给出的为准 （原生安装、包管理器或桌面端，不同平台不一样）。装好后在项目根目录启动。

第一次启动会要求登录或配置凭据，按提示走完即可。

第二步：先让它只读

第一句话不要让它改代码，先让它解释：

读一下这个项目，告诉我：入口在哪、测试怎么跑、这个模块负责什么。先不要改任何文件。

这一步有三个作用：

1. 你能看出它有没有读懂；
2. 它建立了对项目的上下文；
3. 你能确认权限提示长什么样。

第三步：给一个「可验证」的小改动

好的第一个任务：

给 src/utils/format.ts 里的 formatBytes 补三个单元测试，覆盖 0、1023、1024。 不要改实现。写完跑一遍测试，把结果贴出来。

为什么选这种任务：

• 范围小，diff 一眼能看完；
• 有客观标准（测试通过与否）；
• 不需要产品判断。

不要一上来就让它重构核心逻辑，你还没有判断它水平的基础。

第四步：看 diff，不看总结

它会给一段「我做了什么」的总结。不要只看总结，看实际差异：

git diff

重点看三件事：

• 有没有改到任务范围之外的文件；
• 有没有顺手「优化」你别的东西；
• 新增的测试是不是真的在测行为，而不是在测实现。

第五步：跑测试，再决定

npm test    # 或你项目里对应的命令

测试过了也不代表可以直接合并：还要看它有没有为了让测试通过而改实现。 如果测试和实现一起改了，要求它只保留测试改动。

第六步：留下或丢弃

• 满意：正常提交，写清改了什么；
• 不满意：继续对话让它改，或者 git restore . 回到起点。

一次不满意就整段重来，比在错误的方向上反复微调便宜。

该让它先问再做的事

• 删除文件、重写大段代码；
• 执行部署、推送、改数据库；
• 读取或写入密钥、生产配置。

这些操作应该在权限设置里要求确认，而不是靠它自觉。

常见错误

• 在主干上直接试：出问题回滚成本高。
• 只读总结不看 diff：它说的和做的可能不一致。
• 环境跑不起来就让它改：它无法验证，只能猜。
• 一次给太大的任务：diff 超出你能 review 的范围，就等于没 review。

自测

1. 你的项目能在本地一条命令跑完测试吗？
2. 第一次任务的 diff，你能在五分钟内看完吗？
3. 哪些命令你要求它必须确认后才执行？

下一步

• 它是什么：Claude Code 是什么
• 接外部工具：接一个 MCP Server
• 上线前检查：上线前过一遍这张清单