构建LLM生成代码检测系统：CS教育中学术诚信的技术防御架构

问题背景：CS 教育面临的 AI 代码生成挑战

近期 UC Berkeley 计算机科学课程的不及格率上升现象引发广泛关注，这与学生过度依赖 AI 代码生成工具密切相关。当学生使用 ChatGPT、GitHub Copilot 等大语言模型完成编程作业时，传统的代码相似度检测工具（如 MOSS、JPlag）面临失效风险 ——LLM 生成的代码在表面语法上具有高度多样性，但在语义层面可能高度相似。

研究表明，现有通用 LLM 文本检测器在代码检测场景下表现不佳。以 GPTZero 为例，在 114 份人工编写的提交中产生了 52 份假阳性误判，误判率高达 45.6%。当学生使用 QuillBot 等释义工具对 AI 生成代码进行改写后，检测器的平均准确率从 77.42% 骤降至 49.17%，几乎等同于随机猜测。这一现状迫使教育机构和课程设计者必须构建专门针对代码生成的多层级技术防御体系。

技术检测方案：四层检测栈设计

第一层：语义指纹检测（Semantic Fingerprinting for Code, SFC）

传统基于 token 匹配的 plagiarism 检测器容易被代码重命名、变量替换等简单混淆手段绕过。语义指纹技术通过构建程序的依赖图（Program Dependence Graph, PDG）和执行语义表示，捕捉代码的功能本质而非表面语法。

可落地参数：

• 构建包含数据依赖和控制依赖的 PDG 表示
• 使用图神经网络（GNN）编码语义结构，嵌入维度建议 512-1024
• 相似度阈值设定：余弦相似度 > 0.85 触发人工复核
• 支持语言：优先覆盖 Python、Java、C++ 等主流教学语言

第二层：编码风格特征分析（LPcodedec）

LLM 生成的代码往往具有可识别的风格特征，包括命名规范一致性、注释模式、缩进偏好、API 选择倾向等。LPcodedec 方法通过提取这些风格特征，训练二分类模型区分人类编写与 AI 生成代码。

核心特征维度：

• 词法特征：变量命名长度分布、驼峰 / 下划线命名比例
• 语法特征：控制结构使用频率、异常处理模式
• 语义特征：标准库 vs 第三方库使用比例、设计模式偏好
• 时序特征：代码编辑历史中的增量模式（如连续保存间的修改幅度）

模型配置建议：

• 基线模型：XGBoost 或 LightGBM，在千级样本上即可达到可接受性能
• 深度模型：基于 CodeBERT 或 GraphCodeBERT 的微调，需万级标注样本
• 置信度阈值：模型输出概率 > 0.7 时标记为高风险

第三层：水印与隐写检测

部分 LLM 服务提供商（如 OpenAI）在生成内容中嵌入不可见水印。技术实现上，这通常通过在 token 采样过程中微调概率分布，在统计层面植入可检测的签名模式。

检测策略：

• 监控特定 token 组合的出现频率异常
• 检测文本熵分布是否符合 AI 生成特征
• 注意：水印可被后处理（如释义、翻译）部分或完全移除

第四层：抗混淆的容忍性 Token 匹配

针对学生可能采用的代码混淆手段（如变量重命名、代码重排、插入死代码），需要引入结构感知的容忍性匹配算法。

算法选型：

• 基于抽象语法树（AST）的相似度计算，忽略标识符名称
• 使用最长公共子序列（LCS）的变体，允许节点级别的替换
• 引入编译器优化技术：将代码编译至中间表示（IR）后比对

工程实现：检测系统架构

系统组件设计

┌─────────────────────────────────────────────────────────────┐
│                    代码提交接口层                            │
│         (支持Git仓库、LMS集成、文件上传)                      │
└──────────────────────┬──────────────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────────────┐
│                    预处理管道                                │
│  • 语法解析 (Tree-sitter)                                   │
│  • 标准化 (去除注释、格式化)                                 │
│  • 多语言支持检测                                           │
└──────────────────────┬──────────────────────────────────────┘
                       │
        ┌──────────────┼──────────────┐
        │              │              │
┌───────▼──────┐ ┌────▼─────┐ ┌──────▼──────┐
│  语义指纹    │ │ 风格分析 │ │ 相似度匹配  │
│   检测器     │ │  模型    │ │  (MOSS+)   │
└───────┬──────┘ └────┬─────┘ └──────┬──────┘
        │             │             │
        └─────────────┼─────────────┘
                      │
┌─────────────────────▼──────────────────────────────────────┐
│                  风险评分融合引擎                            │
│  • 加权投票机制 (语义0.4 + 风格0.3 + 相似度0.3)              │
│  • 阈值决策：高风险(>0.8) / 中风险(0.5-0.8) / 低风险(<0.5)   │
└─────────────────────┬──────────────────────────────────────┘
                      │
┌─────────────────────▼──────────────────────────────────────┐
│                  结果输出与人工复核                          │
│  • 可视化报告 (高亮可疑代码段)                               │
│  • 教师复核工作流                                           │
│  • 学生申诉与解释机制                                       │
└─────────────────────────────────────────────────────────────┘

关键性能指标与阈值

API 集成与自动化

检测系统应提供 RESTful API 接口，便于与现有学习管理系统（LMS）集成：

# 示例：检测API调用
POST /api/v1/detect
{
  "submission_id": "cs61a-proj3-001",
  "code_files": [...],
  "student_id": "...",
  "assignment_context": "data-structures-binary-tree"
}

Response:
{
  "risk_score": 0.82,
  "risk_level": "high",
  "indicators": [
    {"type": "semantic_similarity", "score": 0.91, "matched_repo": "..."},
    {"type": "style_anomaly", "score": 0.78, "features": [...]}
  ],
  "recommended_action": "manual_review"
}

教育防御策略：技术之外的多层防护

技术检测仅是学术诚信体系的一环。有效的防御需要结合教育干预和作业设计优化：

作业设计层面

1. 过程化评估：要求提交代码演进历史（git commits），分析开发过程中的增量模式。人类编码通常呈现探索 - 重构 - 优化的迭代特征，而 AI 生成代码往往一次性完成。

2. 设计文档强制：要求学生提交架构设计说明、关键算法选择理由、测试用例设计思路。LLM 难以生成与代码完全一致的详细设计文档。

3. 口述答辩机制：对高风险提交要求学生现场解释代码逻辑，回答关于边界条件处理、复杂度权衡等技术细节问题。

4. 个性化题目：使用参数化题目生成器，为每位学生生成略有差异的输入约束，降低直接复制 AI 生成答案的可行性。

政策与流程层面

• 透明度原则：明确告知学生检测系统的存在和检测维度，强调学术诚信教育而非 "抓作弊" 的对抗心态
• 分级响应：低风险自动通过，中风险触发额外文档要求，高风险启动人工复核
• 申诉机制：建立学生对检测结果的申诉渠道，避免自动化决策的误判伤害

局限性与应对

当前 LLM 代码检测技术存在以下固有局限：

1. 释义对抗的脆弱性 当学生使用 AI 工具对生成代码进行改写（如变量重命名、逻辑重排、添加冗余代码）后，检测准确率显著下降。应对策略是结合语义分析而非仅依赖表面特征。

2. 多语言支持不足 非英语编程环境（如中文注释、多语言混合代码）的检测准确率可能降至 17.5% 以下。建议在系统设计中明确标注语言支持范围，对不支持语言降低自动化决策权重。

3. 假阳性的公平性问题 优秀学生可能因编码风格规范、使用现代语言特性而被误判。必须保留人工复核环节，禁止仅凭检测结果进行处罚。

4. 模型迭代导致的过时 LLM 持续演进，检测模型需要定期重训练。建议建立持续学习机制，使用新收集的标注数据每季度更新模型。

实施路线图

对于计划部署 LLM 代码检测系统的教育机构，建议分阶段实施：

第一阶段（1-2 月）：部署基于 MOSS / 相似度匹配的基础检测，建立人工复核流程，收集标注数据

第二阶段（3-4 月）：集成风格分析模型，针对本校学生历史代码训练定制化检测器

第三阶段（5-6 月）：引入语义指纹检测，构建融合决策引擎，完成 LMS 集成

持续优化：建立反馈闭环，根据教师复核结果持续优化模型阈值和权重

技术检测是手段而非目的。在部署检测系统的同时，应同步加强学术诚信教育，引导学生理解独立编程思维的价值 —— 这不仅关乎成绩，更是职业工程师的核心素养。

参考来源

• Hacker News 讨论：UC Berkeley CS 课程 AI 使用与不及格率关联讨论
• arXiv:2307.07411 - Detecting LLM-Generated Text in Computing Education: A Comparative Study for ChatGPT Cases
• arXiv:2502.17749 - Detection of LLM-Paraphrased Code and Identification of the Responsible LLM Using Coding Style Features

ai-systems