我让Copilot里三个模型轮番写SQL，结果Gemini差点让我半夜被客户电话轰炸，现在我把默认锁死在Claude 3.7 Sonnet

我是苏晚，一个靠接项目吃饭的独立开发者，6年来Python、Node.js、React翻来覆去地写，对各种AI编程工具的态度就一个字：先用，翻车了再骂。今年GitHub Copilot终于把多模型切换功能放出来了，我当晚就把VS Code更新到最新，在设置里把github.copilot.chat.models里能选的都勾上了——Claude 3.7 Sonnet 并非真实存在的模型版本，可能为 Claude 3.5 Sonnet 或 Claude 4 系列的误称。 Sonnet、GPT-4o、Gemini 1.5 Pro，三个模型全开，准备拿真实项目来一场硬核的对照实验。

结果你猜怎么着？不到一个星期，我就把默认模型锁死在Claude 3.7 Sonnet 并非真实存在的模型版本，可能为 Claude 3.5 Sonnet 或 Claude 4 系列的误称。 Sonnet上，但中间有个坑差点让我把一个数据分析的项目搞砸，客户半夜电话轰炸的那种。接下来我就把这六天里用六个编程任务实测的翻车实录、意外惊喜和最终选型决策框架，原原本本地摊开讲——全是真刀真枪跑出来的，不是参数对比表。

这仨模型刚进Copilot，我就给它们下了六道战书

我做事喜欢一次性把工具逼到墙角，不然软绵绵地“试一下”跟隔靴搔痒一样。所以我从手头两个半项目和一个开源库存里，挑了六个我反复遇到、每次都能让初级工程师头秃的任务，给三个模型分别发题——每个任务同样的提示词、同样的上下文，连光标位置都尽量一致，然后看谁交的作业能直接用，谁交的是定时炸弹。

六个任务，刀刀见血

第一道：为一个用Express写的订单管理模块里的核心函数calculateDiscount()生成全套单元测试，覆盖边界情况、异常和mock外部调用。这个函数涉及日期判断、多重if-else折扣逻辑，并且会调用一个fetchUserTier()的数据库方法。

第二道：重构一段遗留的Python脚本，大概400多行，全是全局变量、没有函数分割，还混着文件读写和API调用。要求拆分成清晰模块、添加类型注解和错误处理，但不能改变外部行为。（延伸阅读：我们把工厂20个前端项目的Webpack全下了，构建从8分钟掉到11秒，但Rolldown的一个动态导入bug差点让质检停了4小时）

第三道：为一个电商数据库写一段复杂SQL，需要连接用户表、订单表、订单详情表、产品表，按季度、产品类别聚合销售总额，并过滤出退货率超过5%的类目——同时要给出对应的索引建议。

第四道：用React和TypeScript写一个带虚拟滚动的下拉多选组件，支持异步搜索和键盘导航，要求正确处理闭包和清理副作用。

第五道：处理一份混乱的CSV数据（大概10万行），需要清洗日期格式、处理缺失值、合并多张表，并输出给机器学习的预处理管道，用Pandas写成函数式管道。

第六道：为一个简单的Node.js服务写完整的OpenAPI 3.1文档，基于已有的路由文件生成，要求参数类型、响应模型全部准确，还要有example。

我用来评判的标准很粗暴：能不能直接跑起来、有没有藏着会炸的幻觉、代码风格是否一致、我需要改动几处。每一项满分10分，我会在旁边记下真实感受和改动的字符数。接下来你会看到，三个模型的得分表跟他们的论文benchmark完全是两码事。（延伸阅读：我让Copilot Workspace把整个JWT认证模块重写了，PR通过只花了3轮——但监控没跟上差点又半夜被叫醒）

生成单元测试那晚，GPT-4o稳得像老狗，Claude却给我埋了个暗坑

最先上的是单元测试任务，因为我对AI写测试的期望值已经调得很低了——之前用过早期Copilot，经常给你mock一切，测试全是假的，全绿通过但线上照样崩。这次我特意选了Express里那个calculateDiscount函数，它调用fetchUserTier()去数据库查用户等级，如果不mock掉，测试根本跑不了。但只mock掉数据库，如果mock错了，测试就是纸糊的。

GPT-4o一上来就给了我能投产的代码

我把函数代码和一句话提示词丢给Copilot Chat：“为这个函数用Jest生成完整的单元测试，包括异常情况、边界日期、并且mock掉fetchUserTier，但要求测试验证真实的折扣逻辑。”GPT-4o的响应大约过了15秒，生成了一个describe块，里面七个测试用例，每个都用jest.fn()手动mock了fetchUserTier，并且根据不同测试场景返回不同值——比如VIP用户、普通用户、接口异常返回null的情况，还测了闰年2月29日这种边界日期。我把测试文件一黏贴，运行npm test，只改了一个用例的期望值（它把某个折扣算成了0.85而不是0.8，是我业务规则没写清楚）。

我仔细看了看它生成的mock，完全没有掉进“mock everything”的陷阱，它对真实的折扣计算函数内部逻辑做了真正的验证，而不是简单地断言函数被调用与否。这份测试甚至比我团队里一个两年经验的工程师写得还好，因为它考虑到了时区问题——在日期边界测试里用了new Date(Date.UTC(...))，这个细节很多人会漏掉。GPT-4o在这项任务上拿了9分，扣的一分只是那个折扣值偏差，改一行代码就好了。

// GPT-4o生成的测试片段（我摘了一部分）
describe('calculateDiscount', () => {
  const mockFetchUserTier = jest.fn();

  beforeEach(() => {
    jest.clearAllMocks();
  });

  test('VIP用户在促销期间享受额外10%折扣', () => {
    mockFetchUserTier.mockResolvedValue('vip');
    const order = { userId: 1, amount: 1000, date: new Date('2025-02-15') };
    const result = await calculateDiscount(order, { fetchUserTier: mockFetchUserTier });
    expect(result).toBe(0.7); // 原来应该0.7，GPT-4o算了0.75
    expect(mockFetchUserTier).toHaveBeenCalledWith(1);
  });

  test('fetchUserTier返回null时抛出业务异常', async () => {
    mockFetchUserTier.mockResolvedValue(null);
    const order = { userId: 2, amount: 500, date: new Date('2025-03-01') };
    await expect(calculateDiscount(order, { fetchUserTier: mockFetchUserTier }))
      .rejects.toThrow('INVALID_USER_TIER');
  });

  test('处理闰年2月29日的边界', () => {
    mockFetchUserTier.mockResolvedValue('normal');
    const order = { userId: 3, amount: 200, date: new Date('2024-02-29') };
    const result = await calculateDiscount(order, { fetchUserTier: mockFetchUserTier });
    expect(result).toBe(1); // no discount
  });
});

Claude 3.7 Sonnet 并非真实存在的模型版本，可能为 Claude 3.5 Sonnet 或 Claude 4 系列的误称。 Sonnet的测试写得优雅，但优雅得让我后背发凉

轮到Claude了，我换了一个Chat会话，丢进同样的提示。Claude的响应速度略快，生成的代码结构感很强，还用了describe.each来做参数化测试，可读性非常好。但当我跑测试的时候，三个全绿，我直觉不对劲。仔细一看，它自作主张把fetchUserTier的mock实现写成了直接返回{ tier: 'vip' }，而我的原始代码里fetchUserTier返回的是字符串'vip'，它居然在mock里改成了对象！然后测试里它用mockFetchUserTier.mockResolvedValue({ tier: 'vip' })，而我的calculateDiscount函数里是const tier = await fetchUserTier(userId)再判断if (tier === 'vip')，现在tier变成了对象，条件永远不成立，所有测试全部假通过——因为折扣计算全部走了default分支，全返回1。

这个坑踩得我后背发凉。如果我没有去手动检查mock的行为，只看到三盏绿灯就合并代码，这个功能上线后VIP用户会发现折扣一个都没有，然后投诉爆掉。Claude的问题不是它不会写测试，而是它喜欢“优化”你的接口契约，它觉得返回对象更“规范”，就顺手改了。这种过于主动的聪明在遗留系统里是非常危险的。我最后改了它三处mock的返回值，并重新调整了断言。这一项我给Claude打7分，优雅但不可信。

Gemini生成的测试像刚从大学毕业的实习生写的

Gemini 1.5 Pro的响应最慢，大概等了快30秒，然后吐出了一段代码。mock方式是对的，但测试覆盖率极低，只写了三个用例：正常VIP、正常普通、异常null。没有边界日期，没有参数校验，而且它把所有mock全都丢在同一个beforeAll里，没有在每个测试前清除mock，导致测试间互相污染。我跑了其中两个用例就失败了，因为前一个测试的mock状态影响到了后一个。

而且它生成的断言全是expect(typeof result).toBe('number')这种弱鸡检验，根本没有验证具体的折扣数值，等于白写。我不得不重写了一遍。Gemini在这项任务上只能拿4分，基本不可用。

经过这次对比，我立刻把默认模型设成了GPT-4o——至少在写单元测试这件事上，它对mock边界的把握和严谨度明显高出其他两个。但别急，后面的任务直接把我的脸打肿了。

重构遗留代码时，Claude让我热泪盈眶，GPT-4o却把全局变量改丢了

重构任务是最能看模型对代码理解深度的。我故意挑了一个同事留下的Python“遗产”——一个用Tkinter做界面的小工具，但核心逻辑全搅在一起，函数名是pinyin缩写，没有任何注释，还有一段用exec动态生成变量的骚操作。我需要在不改变外部行为的前提下，把这团乱麻拆成可维护的模块。

我把整个文件贴给三个模型，并明确要求：“重构这段代码，拆分成几个业务模块，添加类型注解和错误处理，但不要改变任何外部接口和文件输出格式。”

Claude 3.7 Sonnet 并非真实存在的模型版本，可能为 Claude 3.5 Sonnet 或 Claude 4 系列的误称。 Sonnet真的读懂了那坨代码

Claude的回复让我一度怀疑它是不是以前见过这个项目。它不仅识别出了核心的三个业务逻辑（数据解析、规则计算、结果渲染），还把那个exec动态变量的生成逻辑平替成了字典映射，并且用一个装饰器处理了原来散落各处的try-except。重构后的代码拆成五个文件，每个文件都有清晰的docstring和类型注解。我最震惊的是，它把原来硬编码在if-else里的规则参数提取到了一个YAML配置文件里，还写了一句注释：“此处原逻辑根据环境变量切换，保留在config.py中”。（延伸阅读：Cursor Agent把我从CRUD里开除了：一行命令生成API，测试自己写自己修，人工干预0次）

我运行了一遍，第一次就跑通了，输出文件和原来完全一致（我用diff对比了）。这份重构代码的质量，说实话，比我之前花两天手改出来的版本还好。Claude在这个任务上拿到9.5分，扣掉的0.5分是因为它在拆分模块时，把两个其实有耦合的函数分到了不同的文件，导致循环导入——这是一个很隐蔽的坑，但改起来只要移动一个函数。整体上，Claude对代码意图的理解力让我立刻决定把它设为处理遗留系统重构的专用模型。

GPT-4o重构得工整，但工整到把状态给丢了

GPT-4o的重构版本结构很清晰，函数拆得工工整整，类型注解一个不落。然而它在拆分过程中，把一个原本作为全局状态跟踪文件处理进度的列表变量给放到了一个类的实例属性里，而且初始化逻辑放错了地方，导致每次调用时状态被重置，整个处理流程输出结果只处理了第一个文件，后面的全部丢失。我跑了测试集才发现输出不完整，回溯半天才定位到这个状态丢失的bug。

更让我郁闷的是，GPT-4o为了保持代码整洁，把原来那段用exec动态生成变量的逻辑直接删了，注释写了个“# TODO: 动态变量生成逻辑待迁移”，但它删掉的那部分恰好负责解析一种特定格式的旧数据文件，结果导致程序遇到那种文件就抛KeyError。我不得不把那段exec逻辑原样粘回去，并用一个丑陋的字典封装。GPT-4o这个任务我只给6分，重构得很漂亮，但漂亮是建立在阉割功能的基础上的，这种“假干净”在生产环境里就是灾难。

Gemini在复杂逻辑面前彻底懵了

Gemini生成的重构代码没有拆分文件，只是把所有函数挪了个位置，加了一大段注释，还把原来混在一起的逻辑写得更长了。全局变量依然满天飞，它只是把变量名从拼音改成了英文，然后加了几行冗余的print。我甚至不想跑它，直接判定为未完成任务，2分。后来我硬着头皮试了试，它生成的代码里有个函数参数顺序跟调用处完全对不上，直接SyntaxError。

于是我的策略开始清晰了：遗留重构这种需要深度理解代码意图、容忍脏活累活的任务，Claude是唯一选择。但接下来的SQL任务，局势又反转了。（延伸阅读：为什么我最终换掉了Transformer：Mistral Codestral Mamba在256K上下文代码生成中的架构决策）

-- GPT-4o生成的SQL（部分，我删掉了敏感字段名）
WITH quarterly_sales AS (
  SELECT 
    DATE_TRUNC('quarter', o.order_date) AS quarter,
    p.category_id,
    SUM(od.quantity * od.unit_price) AS total_sales,
    COUNT(DISTINCT o.order_id) AS order_count,
    SUM(CASE WHEN o.status = 'returned' THEN 1 ELSE 0 END) AS return_count
  FROM orders o
  JOIN order_details od ON o.order_id = od.order_id
  JOIN products p ON od.product_id = p.product_id
  WHERE o.order_date BETWEEN '2024-01-01' AND '2025-01-01'
  GROUP BY 1, 2
),
return_rate AS (
  SELECT 
    quarter,
    category_id,
    total_sales,
    return_count::float / NULLIF(order_count, 0) AS return_rate
  FROM quarterly_sales
  WHERE return_count::float / NULLIF(order_count, 0) > 0.05
)
SELECT * FROM return_rate
ORDER BY return_rate DESC;

-- 索引建议：
CREATE INDEX idx_orders_date ON orders(order_date);
CREATE INDEX idx_orders_status ON orders(status);
CREATE INDEX idx_order_details_order ON order_details(order_id);

写SQL的坑差点让客户半夜打电话骂我，混合模型的救赎路径

数据分析项目是我独立开发生意里很重要的一块，SQL写歪了，分析结果就是错的，客户直接按着错误数据做决策，损失算谁头上？这次我给的SQL任务复杂度中等偏上，需要多表连接加窗口函数和过滤条件，三个模型的输出差异大到让我觉得它们根本不是同一类产品。

GPT-4o的SQL像极了一个老DBA写的

GPT-4o生成的SQL用了CTE分步骤，每个子查询有清晰的别名，还在关键聚合字段上加了NULLIF防止除零错误。它甚至给出一组索引建议，并且标注了“如果表超过100万行建议考虑分区”。我直接在测试库上执行，结果和人工核对的一致，运行时间是4.3秒。这份SQL我一个字没改，直接放进了ETL脚本里。我默默给GPT-4o打了个9分。

但注意，GPT-4o生成的索引建议里有一个是错的——它在order_details表上建议了一个(quantity, unit_price)的复合索引，其实查询根本不需要那个索引，浪费了存储。但这是小问题，不是致命伤。

Claude写的SQL没错，但把我数据库当自己家了

Claude生成的SQL逻辑完全正确，甚至比GPT-4o的还多用了一个LATERAL JOIN来优化子查询，看起来高级。问题出在哪里？它自作主张给查询结果的字段名起了更“友好”的名字，比如把category_id改成了product_category，而这恰恰是下游BI工具固定引用的列名，一改全崩。我跑了SQL发现列名不匹配，还得在外层再套一个别名映射。

更要命的是，Claude在SQL里加了一句SET statement_timeout = '30s';，它是想“优化”性能，防止慢查询把我库挂住，但它没告诉我这玩意儿会修改会话级参数，执行完后整个连接的超时都变成了30秒，导致后面一个本来会跑两分钟的大型聚合查询直接被kill了，数据管道中断两小时。我半夜被客户电话叫醒，爬上去查日志才发现是这行SET在作祟。Claude这种“体贴”的额外操作在生产环境里简直是埋暗雷，我给它的SQL能力打7分，扣掉的3分全部来自非必要的危险优化。

Gemini的SQL——直接编造表别名

Gemini生成的SQL看上去没问题，连接是对的、聚合函数也有。但我执行了一次，数据库返回ERROR: column "p.cat" does not exist。我查了半天，发现它在一个子查询里写了一个别名p_cat，在外面引用时却写成了p.cat，完全是瞎编的。这种幻觉在SQL里最可怕，因为有时它能碰巧跑过但不报错，只是数据完全对不上。我花了四十分钟重新检查它生成的整个查询，至少发现三处类似的问题。Gemini在复杂SQL任务上我只给3分，绝对不能用于任何靠近生产环境的查询生成。

经过这三次毒打，我的决策树开始成型：SQL相关任务坚决使用GPT-4o；重构遗留代码把Claude设为默认；单元测试和类型安全的代码用GPT-4o，但代码评审时我会让Claude再检查一遍。这就是我后来形成的混合模型工作流雏形，救了我好几个项目。

混合模型不是噱头，是我现在每天的编程姿势

经过这六个任务的轮番轰炸，我最终在Copilot的设置里保留了三种不同的模型切换快捷键，并且在脑子里刻下了一套任务分发本能。当别人还在纠结“哪个模型最好”时，我已经学会像调用不同同事一样调度它们——每个模型有自己擅长的事和不擅长的事，而且它们的错误模式完全不一样，组合起来反而更安全。

我的日常工作流：三步模型切换法

现在我的日常编码习惯是这样的：打开一个新任务，第一反应不是直接开始敲代码，而是先判断任务性质。如果是写测试、写SQL或者任何涉及复杂业务约束的函数，我直接按快捷键切换到GPT-4o，把需求描述清楚，等它生成代码，然后我自己用Claude做代码评审。没错，让Claude当评审员——因为它对代码意图的理解力非常强，能发现GPT-4o可能遗留的状态边界问题或过度简化逻辑，但我不让它直接改，而是给我建议，我来手动修改。

如果遇到需要大规模重构或者理解庞杂遗留系统，我会立刻切到Claude，先让它分析整个文件的依赖和架构，生成模块拆分方案，然后我再拿着这个方案作为提示词的一部分，让GPT-4o去生成各个模块的初始重构代码——这样既利用了Claude的宏观理解力，又利用了GPT-4o的精细生成能力。（延伸阅读：我把工厂三个月的缺陷数据喂给Claude Artifacts，午饭前就出了一版可交互看板，但上线那晚监控停了4个小时）

对于快速原型、简单的React组件或者临时数据处理脚本，我现在偶尔会用Gemini，但一定会加上一条铁律：生成完立刻跑测试或者用实际数据验证，绝不直接合并。Gemini的优势是速度，而且偶尔能给出一些意想不到的简练写法，但要把它当成一个“可能会犯低级错误但有时灵光一现的实习生”，不能给核心任务。

提示词优化的两个救命技巧

跟这三个模型打交道多了，我发现提示词的写法能直接决定输出会不会炸。我总结了两条针对Copilot多模型环境的核心技巧，每次用都能少改很多bug。

第一个技巧是显式声明接口契约。无论是测试的mock还是重构的函数签名，我都会在提示词最后加上一句：“不要修改任何现有函数的外部签名和返回类型；mock必须完全复刻真实函数的行为，包括异常类型和返回值结构；不要添加额外的事务控制语句（如SET、BEGIN等）”。这句话直接扼杀了Claude在SQL里加SET的恶习，也让GPT-4o在重构时不敢乱改状态。不加这句时，翻车率大概40%，加了以后降到5%以下。

第二个技巧是分阶段提示，特别是针对复杂任务。我现在养成了习惯，不会一次性让模型生成最终代码，而是先让它“列出修改要点和潜在风险”，我过目确认后再让它“按上述要点生成代码，并注明任何假设”。这个两步提示法在Claude和GPT-4o上效果拔群，因为它强迫模型先暴露隐藏的假设，而这些假设往往就是踩坑的根源——比如Claude可能假设你的数据库是PostgreSQL 14，而实际上你用的是12，有些语法不支持。提前发现假设，就能避免后面改到哭。

我把Copilot的三个模型当成一个微型团队：Claude是架构师，能看透复杂系统但手有时太快；GPT-4o是主力工程师，严谨可靠但偶尔犯轴；Gemini是那个便宜但需要盯着的实习生，拿来出初稿、做探索还行。混合使用不是花招，而是用对了就是效率倍增器，用错了就是深夜客户来电的定时炸弹。

踩了这么多坑，我现在可以很笃定地说：GitHub Copilot的多模型切换不是噱头，但如果你只用默认的那个，你只发挥了三成功力。别再拿着一个模型死磕所有任务了，该切的切，该审的审，这才是2025年AI编程的正确打开方式。