LLM 题解去幻觉证明链比漂亮解释更重要一、题解幻觉通常很有迷惑性LLM 写算法题解时最危险的不是语气不自信而是解释非常顺却在关键逻辑上错了。它可能把贪心条件说得像定理却没有交换论证也可能给出动态规划状态却漏掉初始化边界。题解去幻觉的核心是把自然语言解释拆成可验证的证明链。一个合格题解应该说明状态定义、转移依据、边界条件、正确性理由和复杂度。缺任何一环都不能只靠“看起来合理”放过。二、证明链要结构化flowchart TD A[题意解析] -- B[核心不变量] B -- C[算法步骤] C -- D[正确性证明] D -- E[复杂度分析] E -- F[边界用例]不同算法需要不同证明重点。贪心题要证明局部选择不会破坏全局最优。动态规划题要证明状态覆盖全部情况且没有重复。图论题要证明遍历顺序或松弛规则的正确性。证明链不能只有结论。结构化之后系统可以逐项检查。没有不变量就提示证明不足没有边界用例就提示验证不完整复杂度和代码结构不匹配就提示重新分析。三、代码和解释要互相校验def extract_features(code: str) - dict: return { uses_sort: sort( in code or .sort() in code, uses_heap: heapq in code, nested_loop: for in code and code.count(for) 2, }代码特征可以反向校验解释。解释说没有排序但代码里调用了 sort复杂度至少要考虑排序成本。解释说使用堆代码里却没有优先队列结构也要标记可疑。这类检查不需要完美理解代码只要抓常见矛盾就很有价值。题解幻觉往往不是深奥错误而是解释和实现之间对不上。claim_check: claim: 时间复杂度为 O(n) evidence: 代码包含排序 status: suspicious四、反例搜索要参与验证如果题解声称使用贪心系统可以针对贪心条件生成反例。比如区间选择、字符串匹配、数组划分都能构造小规模穷举对比暴力解和生成解。小输入反例往往最能暴露逻辑漏洞。反例搜索不只用于代码也能用于解释。解释里的不变量如果无法覆盖某些状态就要求模型补充证明或承认适用范围。题解不是背模板必须能经得起追问。还可以引入“声明抽取”。先让模型把题解里的关键结论抽成列表再逐条验证。比如“窗口左端只会右移”“每条边最多松弛一次”“排序后相邻元素即可比较”。这些声明如果无法被代码或数学理由支撑就标记为待复核。去幻觉不是让模型少说话而是让每句话都有来源。版本管理也很重要。换模型、换提示词或换题解模板后历史题解要重新抽样验证。某个版本可能更会写长解释却更容易漏边界另一个版本可能代码更稳但证明更薄。没有版本对比就很难判断优化是否真实。最后去幻觉结果要反馈给生成阶段。常见错误如复杂度低估、贪心证明缺失、边界不完整可以反向写进生成提示和审查清单。验证系统不能只做裁判也要帮助生成器少犯同类错误。对高风险题型可以强制二次生成证明。第一轮生成代码第二轮只根据代码和题目生成证明再比较两轮解释是否一致。如果两轮对核心性质说法不同就说明题解需要人工或规则复核。五、总结LLM 题解去幻觉要把解释拆成证明链并用代码特征、复杂度校验和反例搜索交叉验证。漂亮解释不是正确性证明。算法文章真正可靠的地方在于每个结论都能被代码、用例或逻辑推导支撑。
