为什么我建议在 Debug 时尝试用“弱模型”给代码排雷

很多开发者在升级到 Claude 3.5 Sonnet 或 GPT-4o 之后，会陷入一种“代码运行很流畅”的错觉。这种错觉其实非常危险，因为强模型在处理代码时具有极强的“脑补”能力。当你交给它一段带有潜在瑕疵的代码时，它往往能凭借强大的上下文推理能力，不动声色地绕过那个逻辑漏洞，把整段逻辑“合理地”续完。

结果就是，你在本地测试时一切正常，甚至觉得模型帮你把问题解决了，但代码一旦上线，在真实的生产环境下遇到边界条件，依然会毫无征兆地崩溃。

我最近在实践中发现，强模型在 Debug 时其实是在和你“协商”一个合理的解释，而弱模型则是在和你“对抗”。

举个具体的例子，假设你写了一个解析配置文件的函数 def parse_config(raw: str) -> dict: return json.loads(raw)。如果传入的 raw 恰好是一个空字符串，强模型在辅助你编写后续逻辑时，可能会默认你已经处理了空值情况，或者在生成测试用例时潜意识地避开了空字符串，导致你认为这个函数是健壮的。

但如果你把这段代码丢给一个参数量较小的开源模型，它没有那种“体面”的脑补能力，它会老老实实地执行调用。这时它会直接触发 json.JSONDecodeError: Expecting value: line 1 column 1 (char 0)。这个刺眼的报错恰恰是真正的宝藏，它强行地把代码中自相矛盾的地方像照妖镜一样照了出来。

在这种逻辑下，我调整了自己的开发工作流，将 Debug 分成了两个阶段：

第一阶段是“压力测试”，我不再直接使用最强的模型，而是调用 Clio 或者一些 7B 级别的轻量化开源模型。我的目标不是让它帮我写出正确答案，而是让它尽可能多地在代码中“摔跤”。我会让弱模型跑一遍所有逻辑路径，收集它在运行过程中抛出的所有 Edge Case 和报错信息。

第二阶段才是“精准修复”。我会把第一阶段收集到的所有失败点和具体的报错日志，完整地喂给 Claude Code。因为此时修复的依据不再是强模型的“猜测”，而是真实发生过的失败记录。这样改出来的代码，鲁棒性（Robustness）会提升一个档次，因为它修复的是导致 Bug 产生的前置条件，而不仅仅是掩盖一个报错。

这种方法论其实也可以迁移到 Prompt 评测上。在做提示词对比实验时，用弱模型作为 Judge（裁判）有时比用人类判断更客观。人类在评审时很容易产生心理滤镜，比如觉得某个 Prompt 写得很有技巧，从而在打分时潜意识地宽容；但弱模型没有这种立场，它只在乎输出结果是否符合预设的硬性指标。

模型的能力就像手电筒的亮度，太亮了反而会掩盖掉细微的裂缝。在追求极致性能之前，留一盏“昏黄”的弱模型之灯，反而能让你看清代码底层的真实缺陷。