
LLM 题解自动生成从问题描述到代码验证的闭环实践一、题解的质量参差官方题解看不懂社区题解不靠谱LeetCode 题解的最大问题不是没有题解而是题解质量参差不齐。官方题解偏理论缺少直觉解释高赞题解偏技巧缺少通用性低赞题解可能有 bug。对于初学者找到一篇既正确又易懂的题解比做题本身还难。LLM 生成题解的核心价值是按需定制——根据用户当前的理解水平生成对应深度的解释。初学者需要从直觉出发的逐步推导进阶者需要复杂度论证和变式分析。但 LLM 生成的题解存在准确性风险——代码可能有 bug复杂度分析可能有误。必须建立生成 验证的闭环才能保证题解质量。二、题解生成与验证闭环graph TB subgraph 生成阶段 A[题目描述] -- B[LLM生成题解br/思路代码复杂度] B -- C[结构化解析br/提取代码块] end subgraph 验证阶段 C -- D[编译检查br/语法正确性] D -- E[测试用例执行br/功能正确性] E -- F[复杂度验证br/时间/空间分析] F -- G{验证通过?} G --|否| H[错误反馈重新生成] H -- B G --|是| I[输出最终题解] end闭环的关键是验证反馈驱动重新生成。LLM 生成的代码如果测试不通过将错误信息反馈给 LLM 重新生成最多重试 3 次。这种生成-验证-修复的循环可以将题解准确率从 60% 提升到 95% 以上。三、题解生成系统实现3.1 结构化题解生成from dataclasses import dataclass from typing import List, Optional dataclass class Solution: 结构化题解 problem_id: str approach: str # 解题思路 intuition: str # 直觉解释 algorithm: str # 算法步骤 code: str # 代码实现 language: str # 编程语言 time_complexity: str # 时间复杂度 space_complexity: str # 空间复杂度 edge_cases: List[str] # 边界条件 variations: List[str] # 变式题目 class SolutionGenerator: LLM 题解生成器 def __init__(self, llm_client, max_retries: int 3): self.llm llm_client self.max_retries max_retries def generate( self, problem_description: str, difficulty: str medium, language: str python, user_level: str intermediate ) - Solution: 生成题解带验证闭环 prompt self._build_prompt( problem_description, difficulty, language, user_level ) for attempt in range(self.max_retries): response self.llm.chat(prompt) solution self._parse_response(response, language) # 验证代码 is_valid, errors self._validate(solution) if is_valid: return solution # 验证失败反馈错误信息重新生成 prompt f{prompt}\n\n上次生成的代码有以下问题请修复\n{errors} raise RuntimeError(f题解生成失败重试 {self.max_retries} 次后仍不通过) def _build_prompt( self, description: str, difficulty: str, language: str, level: str ) - str: level_instruction { beginner: 从最基础的概念出发逐步推导避免跳步, intermediate: 给出直觉解释和关键推导步骤省略显而易见的细节, advanced: 聚焦复杂度优化和变式分析简洁直接, } return f为以下算法题生成完整题解。 题目 {description} 难度{difficulty} 语言{language} 读者水平{level_instruction.get(level, level_instruction[intermediate])} 输出以下JSON格式 {{ approach: 解题思路概述2-3句话, intuition: 直觉解释为什么这样想, algorithm: 算法步骤编号列表, code: 完整可运行的代码包含注释, time_complexity: O(?)附推导, space_complexity: O(?)附推导, edge_cases: [边界条件1, 边界条件2], variations: [变式题目1, 变式题目2] }} def _parse_response(self, response: str, language: str) - Solution: 解析 LLM 输出为结构化题解 import json data json.loads(response) return Solution( problem_id, approachdata[approach], intuitiondata[intuition], algorithmdata[algorithm], codedata[code], languagelanguage, time_complexitydata[time_complexity], space_complexitydata[space_complexity], edge_casesdata.get(edge_cases, []), variationsdata.get(variations, []), ) def _validate(self, solution: Solution) - tuple[bool, str]: 验证题解代码的正确性 # 1. 编译检查 compile_ok, compile_err self._compile_check(solution) if not compile_ok: return False, f编译错误: {compile_err} # 2. 测试用例执行 test_ok, test_err self._run_tests(solution) if not test_ok: return False, f测试失败: {test_err} return True, 3.2 代码验证器import subprocess import tempfile import os class CodeValidator: 代码验证器编译检查 测试用例执行 def compile_check(self, solution: Solution) - tuple[bool, str]: 编译检查 ext_map {python: .py, java: .java, cpp: .cpp} ext ext_map.get(solution.language, .txt) with tempfile.NamedTemporaryFile( modew, suffixext, deleteFalse ) as f: f.write(solution.code) temp_path f.name try: if solution.language python: result subprocess.run( [python3, -c, fimport py_compile; py_compile.compile({temp_path})], capture_outputTrue, textTrue, timeout10 ) elif solution.language java: result subprocess.run( [javac, temp_path], capture_outputTrue, textTrue, timeout30 ) if result.returncode ! 0: return False, result.stderr return True, except subprocess.TimeoutExpired: return False, 编译超时 finally: os.unlink(temp_path) def run_tests( self, solution: Solution, test_cases: list[dict] ) - tuple[bool, str]: 执行测试用例 errors [] for tc in test_cases: input_data tc[input] expected tc[expected_output] # 执行代码并获取输出 actual self._execute(solution, input_data) if actual ! expected: errors.append( f输入: {input_data}, 期望: {expected}, 实际: {actual} ) if errors: return False, \n.join(errors) return True, 四、题解生成的 Trade-offs 分析LLM 幻觉风险LLM 可能生成看起来正确但实际有 bug的代码尤其是边界条件处理。验证闭环可以捕获大部分 bug但无法保证 100% 正确。建议对生成的题解标注AI 生成仅供参考并鼓励用户自行验证。生成成本每次生成约消耗 2000-4000 tokens加上验证失败后的重试单次题解生成成本约 0.05-0.2 美元。批量生成时可以通过缓存相似题目的题解来降低成本。题解深度与可读性LLM 倾向于生成标准答案式的题解缺少直觉解释和思维过程。通过 Prompt 中明确要求先讲直觉再讲方法可以改善可读性但深度仍不如高质量人工题解。语言覆盖Python 题解的生成质量最高训练数据最多C 和 Java 次之Go 和 Rust 较差。对于冷门语言建议先生成 Python 题解再翻译为目标语言。五、总结LLM 题解生成的核心是生成 验证闭环。LLM 负责生成结构化题解自动化验证器负责检查代码正确性验证失败则反馈错误信息重新生成。这种循环机制将题解准确率从 60% 提升到 95% 以上但仍需标注AI 生成并鼓励用户自行验证。落地建议先实现 Python 题解的生成和验证管线验证闭环跑通然后扩展到 C 和 Java最后根据用户反馈优化 Prompt提升题解的直觉解释和思维过程描述。全程监控生成成功率和用户满意度。