Claude 3.5 Sonnet 在代码重构时能直接给出全量文件，比 Copilot

在写代码的时候，我习惯在多个 AI 之间跳着试，因为不同模型的“脾气”决定了它们在处理特定任务时的效率。最近我用 Claude 3.5 Sonnet、Gemini 和 Copilot 跑一个入职引导（Onboarding）的审计项目，结论是：如果你需要对代码有强控制感，且讨厌碎片化的补全，Claude 的 Web 端聊天体验其实比很多 IDE 插件更高效。

为什么我更倾向于用 Claude 3.5 Sonnet 做重构

很多开发者习惯在 VS Code 里用 Copilot 或 Cursor 这种插件，但我在这次项目里发现，直接在 Claude 桌面端聊天反而更顺畅。最核心的一点是：当涉及多个文件需要同步修改时，Copilot 往往给出的是片段，你得一个个去 Copy-Paste，且容易漏掉上下文。

而 Claude 3.5 Sonnet 在处理这类任务时，如果我明确要求「请直接重新生成包含这些修改的完整项目文件」，它能一次性把几个文件的全量代码全部吐出来。这种「全量覆盖」的逻辑在快速迭代小模块时极快，省去了我在编辑器里反复定位行号的时间。

不过，用 Claude 必须养成「质疑」的习惯。我在处理一个脱敏（Redaction）功能时，它给我推了所谓的 NSA 安全编码最佳实践，建议用两套不同的供应商引擎分别执行脱敏和验证。这在预算无限的军工项目里可能可行，但在普通企业项目里简直是浪费。当我追问来源时，它承认这只是它的「推荐」而非一个可引用的标准。

实际操作中的几个关键细节

这次我完全没用 Claude Code 也没有装 VS Code 插件，就是纯用桌面端 Chat。这样做的目的是为了隔离上下文，防止 AI 把之前的对话干扰到当前的逻辑。

• 关于上下文隔离： 我通过开启多个独立 Chat 窗口来处理不同的功能点，这样能确保每次提问都是在一个「干净」的环境下，避免它产生记忆偏差。
• 关于额度： 使用 Sonnet 3.5 免费版，在两周的开发周期里，我只触发了两次消息限制。这可能因为我经常在 Gemini 和 Copilot 之间切换，没有把所有压力都给 Claude。
• 验证技巧： 面对不确定的技术方案，我强制要求它 cite your sources（列出来源）。如果它给不出具体的文档链接或标准号，那么这个建议大概率是基于概率分布的「感觉」，而不是事实。

对比 Gemini 和 Copilot 的体感差异

虽然这次任务主要靠 Claude 撑起，但 Gemini 和 Copilot 在某些场景下有不同的侧重：

• Copilot： 适合写那种毫无脑力的样板代码（Boilerplate），但在处理跨文件的逻辑重构时，碎片化的输出方式让我觉得很心累。
• Gemini： 处理超长文档的理解能力确实强，但在代码的严谨度上，偶尔会出现一些莫名其妙的语法错误，不如 Sonnet 那么稳。

给开发者的避坑建议

如果你在用 AI 写代码，千万不要把它当成「标准答案生成器」，而要把它当成一个「可以通过质疑来优化方案的同事」。

一个典型的坑是：AI 给你推荐了一个库，你直接安装运行，结果报错 Module not found。这时候不要直接问「为什么报错」，建议用以下命令让它自检：

# 假设 AI 给了一个错误的安装命令，不要直接运行
# 应该要求它检查当前环境的版本
node -v 
npm -v

把你的环境版本发给它，强制它在当前版本环境下重新验证方案。

最后，关于成本，如果你像我一样在免费额度之间跳跃，建议准备 3 套账号。在 Claude 触顶时切换到 Gemini，这样可以保证开发流程不中断，且不需要支付每月 20 刀的订阅费。