LLM 题解验证实践：代码能跑样例不代表正确

LLM 题解验证实践代码能跑样例不代表正确一、模型生成题解最容易漏边界LLM 生成算法题解很快变量名也挺工整但它常犯一个问题样例能过隐藏用例翻车。尤其是边界值、重复元素、空数组、溢出、图不连通、多个最优解这类情况模型容易说得很自信代码却不稳。所以题解生成后必须验证。验证不是跑题目给的两个样例而是构造系统化用例、随机测试和对拍。算法题的正确性不靠语气坚定靠证据。二、验证链路样例、边界、随机、对拍flowchart LR A[模型生成题解] -- B[样例测试] B -- C[边界用例] C -- D[随机用例] D -- E[暴力解对拍] E -- F[复杂度检查]对拍是非常实用的方法。写一个慢但明显正确的暴力解再和模型生成的优化解跑随机数据。只要结果不一致就说明题解有问题。三、代码示例用暴力解对拍import random def brute(nums): best 0 for i in range(len(nums)): for j in range(i, len(nums)): best max(best, sum(nums[i:j1])) return best def fast(nums): cur best nums[0] for x in nums[1:]: cur max(x, cur x) best max(best, cur) return best for _ in range(1000): arr [random.randint(-10, 10) for _ in range(random.randint(1, 20))] assert brute(arr) fast(arr)这段代码验证的是最大子数组和。fast 看起来很经典但对拍能给我们信心。更复杂的题也一样只要数据规模小暴力解通常能写出来。四、工程边界验证也要检查复杂度代码正确还不够复杂度也要符合题目限制。模型可能生成 O(n²) 解法样例和小随机都能过但真实数据超时。验证系统要读取题目约束估算复杂度是否合理。比如 n 到 1e5就要警惕双重循环。取舍方面自动验证能挡住大量错误但不能证明所有题都绝对正确。图论、浮点、交互题、概率题验证更复杂。系统应该输出“通过了哪些验证”而不是直接宣称“绝对正确”。严谨一点不丢人。还要保存失败用例。模型生成的代码一旦错了失败用例就是最好的训练材料。把失败用例回填到提示词或评测集里下一轮生成会更稳。题解系统要像刷题的人一样会复盘。验证系统还要防止“暴力解也写错”。暴力解通常简单但并不天然正确。可以先用极小规模手工枚举结果校验暴力解再扩大随机测试范围。对拍里如果两边都错错误会被掩盖。严谨一点宁愿多写几个手工用例。对于浮点或多答案题验证策略也要调整。浮点比较要用误差范围多答案题要验证答案是否合法而不是和某个固定答案完全相等。题目类型不同验证标准也不同。最后LLM 题解要保留推理和代码的对应关系。模型说用滑动窗口代码却写了双重循环这种不一致要被标出来。题解不是只看代码能不能跑还要看解释是否能帮助学习。验证报告也要写得清楚。不要只说“测试通过”要列出样例数量、边界用例、随机轮数、是否对拍、最大数据规模和复杂度判断。这样读者知道这份题解被验证到什么程度。严谨不是绝对保证而是把证据摆出来。五、总结LLM 生成题解后必须经过样例、边界、随机和对拍验证。代码能跑样例不代表正确复杂度也要检查。算法题解的可信度来自可复现测试。