这篇继续围绕 Claude Code 展开，主题是「Claude Code 做重构安全吗？我的做法是先框住边界」。前面几篇已经讲过安装、settings.json、-p 模式和 CLAUDE.md，这次往真实使用流程里再拆细一点。
重构不是「全部重写」
小白对重构常有一个误解：重构 = 把代码大改一遍。所以让 Claude Code 重构时，常说「帮我把这个模块整理一下」，然后模型真的整理了一遍，结果 200 行代码变成了完全陌生的 300 行。
真正的重构是保持外部行为不变，改善内部结构。这意味着：能小改不大改，能改一处不改两处。
第一原则：先框边界
在让 Claude Code 重构之前，我会先告诉它三件事：
- 改什么：明确到具体的函数或类
- 不改什么：哪些接口签名、哪些行为不能动
- 怎么验证：靠哪些测试或哪段调用来证明没改坏
这三件事不交代，重构很容易变成「重写」。
第二原则：小步走
一次重构最好只做一件事，比如：
- 只把一个长函数拆成几个小函数
- 只把重复代码抽成公共方法
- 只改变量命名，不改逻辑
小步走的好处是 git diff 看得清楚。一次 diff 只有 30 行，你能审；一次 diff 一千行，你就只能信。对 AI 生成的代码，「能审」比「能跑」更重要。
第三原则：测试当护栏
如果项目里有现成的单元测试，重构前先跑一遍，确认全绿。重构后再跑一遍，确认还是全绿。
这是判断「行为是否改变」的最廉价方式。没有测试的项目要不要重构？可以，但你要补一两个最关键的回归测试，让它们保护你最在意的功能。
你可以让 Claude Code 帮忙补：
在重构前，先帮我给这个函数补一个最小的单元测试，覆盖它当前的核心行为。
第四原则：分阶段审查
复杂重构建议拆成多个 commit：
- 第一步：提取函数（行为不变）
- 第二步：重命名（行为不变）
- 第三步：替换实现（行为可能变，要重点审）
每一步独立 commit、独立审查。中途发现问题，回滚也只会丢一小段。
第五原则：不要顺手「优化性能」
Claude Code 在重构时常常会突然说「我顺便优化了一下性能」。听起来很贴心，实际上很危险，因为：
- 性能优化常常牺牲可读性
- 没基准测试的性能优化容易是错觉
- 它把性能改动混进重构 diff 里，你很难分辨
所以重构任务里，我会明确告诉它：
只重构结构，不做性能优化，不引入新依赖。
一些实际场景
以下是 Claude Code 比较擅长的重构类型（基于一般经验，不做绝对承诺）：
- 拆分过长函数
- 抽取重复逻辑
- 重命名变量、统一风格
- 把回调改成 async/await
相对要小心的：
- 跨文件、跨模块的大范围重构
- 数据库 schema 迁移类重构
- 涉及并发、锁、事务的重构
这些不是不能做，而是要分得更细、审得更慢。
小结
Claude Code 重构不是不安全，而是要你先把边界画好。改什么、不改什么、怎么验证——这三句话讲清楚了，AI 才能在护栏内做事。
延伸阅读
如果你还没看前面的基础篇，可以先看《Claude Code 从零搭建》《settings.json 权限配置》《CLAUDE.md 项目规则》这几篇，再回来看本文会更顺。
小结
Claude Code 真正好用的地方，不是让它一次性替你完成所有事，而是把流程拆清楚：哪些让 AI 做，哪些必须人来确认，哪些结果要留下验证记录。这个习惯养成之后，它就更像一个靠谱的编程搭档。
