被所谓的“颠覆性”模型坑了两次后，我决定给所有新模型设门槛

现在每周都能刷到好几个号称能“改变工作流”的新模型，截图精美，点赞破万。但事实是，很多模型在跑分上无敌，实操起来却极其不稳定。最可怕的不是那种直接报错的模型，而是那种“一本正经胡说八道”的模型。我之前因为跟风换了个模型，它没报错，但偷偷把代码注释里的变量命名规范给改了，导致我的 API 文档被搞乱了一周才被读者发现。

为了不再被这种所谓的“突破”给坑，我给自己定了一套筛选机制。任何新模型想进入我的生产环境，必须得像职场新人一样通过三道关卡，只要任何一环掉链子，直接淘汰。

第一关：压力面试（一小时，绝不留情）

在让它接触任何真实任务前，我会用一套打磨了几个月的测试题把它考一遍。

• 格式强校验： 要求它输出严格的 JSON 结构或没有任何废话的 Shell 一行命令。因为我的自动化流水线只要多出一句“Here is the code”，整个脚本就直接崩溃。
• 陷阱题： 我会故意给一个缺失关键信息或根本不存在的库，看它是否敢于承认不知道。如果它给我编一个看起来很完美的答案，直接出局，因为这种幻觉在实战中是灾难性的。
• 范围蔓延测试： 我让它只修改一个函数，看它会不会趁机帮我“优化”周围的代码或乱改命名。这种不请自来的“好心”通常是 Bug 的来源。
• 真实体感延迟： 官方宣传的 Token/s 没意义，我只在自己的硬件和 Prompt 长度下实测。如果响应慢到让我分心，那它就没资格留在我的工具栏里。
• 已知答案的实操题： 拿一个我已经解决过的真实任务考它，用标准答案对标，而不是凭感觉觉得它“写得不错”。

第二关：观察期（影子运行）

能通过面试的模型会被放入为期一周的观察期。具体操作是：我所有的 Prompt 会同时发给目前在用的主力模型和这个新模型。但我只看主力模型的答案，新模型的回复被记录在日志里。等我忙完一天，我会随机抽查几个回复，对比两者的差异。如果新模型在逻辑上出现了低级错误，哪怕它通过了第一关，也会被立马踢掉。

第三关：有限职责

最后一步是给它分配一些“即使错了也能被机械化检测”的小任务。比如写一段可以通过单元测试的简单函数，或者转换一个格式。只有在这种低风险环境下表现稳定，我才会考虑把它升级到核心工作流中。

这套流程虽然慢，但极大地降低了我的试错成本。大多数被吹上天的模型在第一关就死掉了，这让我意识到，比起追新，建立一套自己的验证标准才更重要。