LLM代码评估：从人工判题到模型驱动的代码质量自动评分

一、当人工判题跟不上刷题量：代码评估的效率瓶颈

在线编程平台和算法训练系统中，代码评估（评判代码正确性和质量）是核心环节。传统的评估方式是：运行预设测试用例，比对输出是否匹配。这种方式只能判断"对不对"，无法评估"好不好"——代码的时间复杂度是否达标、空间使用是否合理、编码风格是否规范、边界条件是否处理完整。

更具体的场景：一个算法训练平台，用户提交了 1000 份代码，其中 600 份通过了所有测试用例。但这 600 份代码中，有的时间复杂度是 O(n²)，有的是 O(n log n)；有的变量命名清晰，有的全是 a、b、c。传统评估系统给它们相同的"通过"判定，无法区分代码质量的差异。

LLM 代码评估的目标是：在功能正确性之外，自动评估代码的复杂度、风格、鲁棒性和可读性，给出结构化的质量报告。这不是替代测试用例，而是在测试通过的基础上提供更深层的质量分析。

二、LLM代码评估架构：从静态分析到语义理解的多层评估

代码评估系统包含三个评估层次：功能测试、静态分析、语义评估。

graph TD
    A[用户提交代码] --> B[功能测试层]
    B --> C{测试通过?}
    C -->|否| D[返回测试失败详情]
    C -->|是| E[静态分析层]

    E --> F[复杂度分析]
    E --> G[风格检查]
    E --> H[边界条件检测]

    F --> I[语义评估层]
    G --> I
    H --> I

    I --> J[LLM评估代码质量]
    J --> K[可读性评分]
    J --> L[鲁棒性评分]
    J --> M[优化建议]

    K --> N[综合质量报告]
    L --> N
    M --> N

    subgraph 自动化评估
        B
        E
    end

    subgraph AI增强评估
        I
        J
    end

功能测试层通过运行测试用例判断正确性，这是最基础也是必需的。静态分析层通过 AST 解析和规则匹配检测复杂度、风格和常见问题。语义评估层使用 LLM 理解代码的意图和逻辑，评估可读性、鲁棒性和优化空间。

三、LLM代码评估系统实现

3.1 静态分析：复杂度推断

# complexity_analyzer.py 代码复杂度分析

import ast
from dataclasses import dataclass
from typing import List

@dataclass
class ComplexityReport:
    """复杂度报告"""
    time_complexity: str      # 推断的时间复杂度
    space_complexity: str     # 推断的空间复杂度
    loop_depth: int           # 循环嵌套深度
    recursive_calls: int      # 递归调用次数
    has_memoization: bool     # 是否使用记忆化
    warnings: List[str]       # 复杂度警告

def analyze_complexity(source_code: str) -> ComplexityReport:
    """分析代码的复杂度特征"""
    tree = ast.parse(source_code)

    loop_depth = _max_loop_depth(tree)
    recursive_calls = _count_recursive_calls(tree)
    has_memoization = _detect_memoization(tree)

    # 基于特征推断复杂度
    time_complexity = _infer_time_complexity(
        loop_depth, recursive_calls, has_memoization
    )
    space_complexity = _infer_space_complexity(
        recursive_calls, has_memoization
    )

    warnings = []
    if loop_depth >= 3:
        warnings.append(f"循环嵌套深度为{loop_depth}，可能存在优化空间")
    if recursive_calls > 0 and not has_memoization:
        warnings.append("递归未使用记忆化，可能存在重复计算")

    return ComplexityReport(
        time_complexity=time_complexity,
        space_complexity=space_complexity,
        loop_depth=loop_depth,
        recursive_calls=recursive_calls,
        has_memoization=has_memoization,
        warnings=warnings,
    )

def _max_loop_depth(tree: ast.AST) -> int:
    """计算最大循环嵌套深度"""
    class LoopVisitor(ast.NodeVisitor):
        def __init__(self):
            self.max_depth = 0
            self.current_depth = 0

        def visit_For(self, node):
            self.current_depth += 1
            self.max_depth = max(self.max_depth, self.current_depth)
            self.generic_visit(node)
            self.current_depth -= 1

        def visit_While(self, node):
            self.current_depth += 1
            self.max_depth = max(self.max_depth, self.current_depth)
            self.generic_visit(node)
            self.current_depth -= 1

    visitor = LoopVisitor()
    visitor.visit(tree)
    return visitor.max_depth

def _count_recursive_calls(tree: ast.AST) -> int:
    """统计递归调用次数"""
    class RecursionVisitor(ast.NodeVisitor):
        def __init__(self):
            self.function_names = set()
            self.recursive_calls = 0

        def visit_FunctionDef(self, node):
            self.function_names.add(node.name)
            self.generic_visit(node)

        def visit_Call(self, node):
            if isinstance(node.func, ast.Name):
                if node.func.id in self.function_names:
                    self.recursive_calls += 1
            self.generic_visit(node)

    visitor = RecursionVisitor()
    visitor.visit(tree)
    return visitor.recursive_calls

def _detect_memoization(tree: ast.AST) -> bool:
    """检测是否使用记忆化"""
    source = ast.dump(tree)
    memo_keywords = ['lru_cache', 'cache', 'memo', 'dp', 'fibo']
    return any(kw in source.lower() for kw in memo_keywords)

def _infer_time_complexity(loop_depth: int, recursive: int,
                           has_memo: bool) -> str:
    """推断时间复杂度"""
    if recursive > 0 and not has_memo:
        if recursive >= 2:
            return "O(2^n)"  # 多分支递归
        return "O(n)"  # 单分支递归
    if loop_depth == 0:
        return "O(1)"
    if loop_depth == 1:
        return "O(n)"
    if loop_depth == 2:
        return "O(n²)"
    return f"O(n^{loop_depth})"

3.2 LLM 语义评估

# semantic_evaluator.py LLM语义评估

from dataclasses import dataclass
from typing import List

@dataclass
class QualityScore:
    """代码质量评分"""
    readability: float      # 可读性 0-100
    robustness: float       # 鲁棒性 0-100
    efficiency: float       # 效率 0-100
    style: float            # 风格 0-100
    overall: float          # 综合分 0-100
    suggestions: List[str]  # 改进建议

async def evaluate_code_quality(
    source_code: str,
    problem_description: str,
    complexity_report: ComplexityReport,
    llm_client: LLMClient
) -> QualityScore:
    """使用LLM评估代码质量"""

    prompt = f"""评估以下代码的质量，从四个维度打分。

## 题目描述
{problem_description}

## 提交代码
```python
{source_code}

静态分析结果

• 推断时间复杂度：{complexity_report.time_complexity}
• 推断空间复杂度：{complexity_report.space_complexity}
• 循环嵌套深度：{complexity_report.loop_depth}
• 递归调用次数：{complexity_report.recursive_calls}

评分维度

1. 可读性(0-100)：变量命名、注释、代码结构清晰度
2. 鲁棒性(0-100)：边界条件处理、异常处理、空值检查
3. 效率(0-100)：时间/空间复杂度是否最优，有无冗余计算
4. 风格(0-100)：是否符合语言惯例，代码格式是否规范

输出格式

返回JSON：
{{
"readability": 分数,
"robustness": 分数,
"efficiency": 分数,
"style": 分数,
"overall": 综合分(加权平均),
"suggestions": ["改进建议1", "改进建议2"]
}}

只返回JSON："""

response = await llm_client.chat(
    messages=[{"role": "user", "content": prompt}],
    temperature=0.1,
)

try:
    result = json.loads(response.content)
    return QualityScore(
        readability=result["readability"],
        robustness=result["robustness"],
        efficiency=result["efficiency"],
        style=result["style"],
        overall=result["overall"],
        suggestions=result["suggestions"],
    )
except (json.JSONDecodeError, KeyError):
    # LLM输出异常时返回默认分数
    return QualityScore(
        readability=50, robustness=50, efficiency=50,
        style=50, overall=50,
        suggestions=["评估服务异常，请稍后重试"],
    )

### 3.3 综合评估报告生成

```python
# evaluation_report.py 综合评估报告

@dataclass
class EvaluationReport:
    """综合评估报告"""
    passed: bool                    # 是否通过测试
    test_results: List[TestResult]  # 测试用例结果
    complexity: ComplexityReport    # 复杂度分析
    quality: QualityScore           # 质量评分
    rank: str                       # 代码等级

def generate_report(
    test_results: List[TestResult],
    complexity: ComplexityReport,
    quality: QualityScore
) -> EvaluationReport:
    """生成综合评估报告"""
    passed = all(t.passed for t in test_results)

    # 根据综合分确定等级
    rank = _determine_rank(quality.overall)

    return EvaluationReport(
        passed=passed,
        test_results=test_results,
        complexity=complexity,
        quality=quality,
        rank=rank,
    )

def _determine_rank(score: float) -> str:
    """根据分数确定代码等级"""
    if score >= 90:
        return "S"  # 优秀：最优解+规范代码
    if score >= 75:
        return "A"  # 良好：正确解+较好风格
    if score >= 60:
        return "B"  # 合格：正确解+风格一般
    if score >= 40:
        return "C"  # 需改进：正确但质量差
    return "D"      # 不合格：需重写

四、LLM代码评估的准确性与成本边界

LLM 评估的准确性受限于模型对代码语义的理解深度。对于简单的代码（单函数、逻辑清晰），评估准确率较高；对于复杂的代码（多函数交互、隐式状态依赖），LLM 可能遗漏关键问题。LLM 评估不应作为唯一评判依据，而应与静态分析和测试用例互补。

评估延迟是工程上的挑战。一次 LLM 评估需要 2-5 秒，如果平台有大量并发提交，LLM API 的吞吐可能成为瓶颈。优化策略包括：使用小模型（如 CodeLlama-7B）做评估、对相似代码做评估结果缓存、以及将 LLM 评估设为异步操作（先返回测试结果，评估报告延迟展示）。

评分标准的一致性是另一个问题。不同时间调用 LLM 可能给出不同的评分，尤其是边界分数（如 59 分和 60 分）的判定不稳定。解决方案是：评分粒度不要太细（10 分一档而非 1 分一档），以及多次评估取中位数。

五、总结

LLM 代码评估在传统测试用例和静态分析的基础上，增加了语义层面的质量评估能力。三层评估架构——功能测试判断正确性、静态分析推断复杂度、LLM 评估可读性和鲁棒性——形成互补的质量画像。工程实现中需要控制 LLM 评估的延迟和成本，接受评分的有限精度，将 LLM 评估定位为"辅助参考"而非"绝对标准"。代码评估的终极目标不是给代码打分，而是帮助开发者理解代码的改进方向。

补充落地建议：围绕“LLM代码评估：从人工判题到模型驱动的代码质量自动评分”继续推进时，应把验收标准写成可执行清单。性能类方案要给出基准数据，架构类方案要给出故障隔离方式，AI 类方案要给出质量评估和人工兜底策略。每一次迭代都应回答三个问题：收益是否可量化，失败是否可回滚，维护成本是否被团队接受。

如果短期资源有限，可以先保留最关键的观测指标，包括处理耗时、失败率、资源占用和人工介入次数。等这些指标稳定后，再扩展自动化能力。这样的节奏更慢，但风险更低，也更符合生产级技术文章强调的工程可验证性。