一个意外的发现
之前用 Claude 主要是写新代码，补全速度快，生成质量也还行。但最近一个项目让我对它的印象变了——它更适合当重构搭档，而不是单纯的代码生成器。
起因是我在 kulaai（titiai.cn） 上对比几个模型的代码能力，顺手把一个拖了两个月没重构的老模块丢给了 Claude 4.8。结果它给的建议，比我自己规划的重构方案还合理。
干脆认真测了一轮，把真实体验记下来。
第一个场景：200 行 Python 数据处理脚本
典型的"能跑但难维护"风格——函数嵌套四层、变量名随意、重复逻辑一堆。
让它重构，提了两个要求：保持原有逻辑不变，提升可读性。
它做了这几件事：
把嵌套函数拆成独立函数，每个只做一件事。变量名全部按业务含义重命名，不是简单的 a、b、c，而是 raw_log_entries、filtered_records 这种一眼能看懂的名字。重复的日期解析逻辑提取成了公共函数。
最让我意外的是，它在改动处加了注释，标注"此处仅调整结构，逻辑未变"和"此处新增了边界检查"。这种自觉性，其他模型目前做得不够。
第二个场景：800 行 TypeScript API 模块
这个复杂度上来了，涉及认证、权限校验、数据库查询、错误处理四块逻辑纠缠在一起。
| 重构建议 | 是否实用 | 备注 |
|---|---|---|
| 认证逻辑抽成独立中间件 | ✅ 实用 | 我早就想改，一直没动 |
| 错误处理分层（可预期/意外） | ✅ 实用 | 线上出过类似问题 |
| 数据库查询封装成 Repository 模式 | ⚠️ 看情况 | 小项目没必要 |
| 引入依赖注入 | ❌ 过度 | 800 行搞 DI 属于杀鸡用牛刀 |
有用的建议大概占六成，剩下的偏架构师视角，对当前项目规模来说太重了。但那六成是真的有用，特别是错误处理分层的建议，我后来直接用到了生产环境。
第三个场景：跨文件重构
把三个相关文件一起丢给它，让它分析依赖关系并建议重构顺序。
它画了一个简单的依赖图，标注了哪些改动会波及下游，建议从叶子节点开始改，避免中间状态破坏现有功能。
这个分析质量很高，基本等于一个熟悉项目的同事在帮你梳理重构路径。但有个前提——你得自己判断哪些文件是相关的，它不会主动帮你发现跨模块的隐性依赖。
它擅长什么，不擅长什么
| 维度 | 表现 |
|---|---|
| 代码风格统一 | ⭐⭐⭐⭐⭐ 改完风格一致 |
| 逻辑等价重构 | ⭐⭐⭐⭐⭐ 不会偷偷改语义 |
| 边界情况标注 | ⭐⭐⭐⭐ 主动提醒 |
| 架构建议 | ⭐⭐⭐ 偏理想化 |
| 性能优化 | ⭐⭐ 定量分析不可信 |
| 大规模项目理解 | ⭐⭐⭐ 依赖人工拆分模块 |
一句话总结：代码层面的重构很强，架构层面的建议要打折听。
三个使用技巧
先描述问题再给代码。 别直接丢代码让它"看看有什么问题"，先说"这个模块响应慢，怀疑是数据库查询的问题"，聚焦之后建议质量明显提升。
接受它的代码风格建议，质疑它的架构建议。 命名、拆分、格式化这类改动基本都靠谱。但让它引入设计模式、分层架构之类的建议，要结合项目实际情况判断。
重构后一定要跑测试。 它改的代码语法层面几乎不出错，但逻辑等价性不能完全信任，特别是涉及并发和异步的代码。
最后说两句
Claude 4.8 不是一个能替代你思考的工具，但它是一个很好的"橡皮鸭"——你把问题说给它听，它能给你一个比你自己想的更清晰的方案。
特别是重构这种吃经验的活儿，有它在旁边提建议，效率确实比一个人埋头改高不少。前提是你要有判断力，知道哪些建议该听，哪些该忽略。
工具就是工具，用得好是搭档，用不好是负担。
