AI 刷题评测集：别用三道样例证明系统有效

AI 刷题评测集：别用三道样例证明系统有效

一、样例通过不等于训练有效

AI 辅助刷题系统最容易犯的错误，是拿题目自带样例当评测集。样例通常只覆盖最基础路径，很多边界条件不会出现。系统如果只会生成能过样例的代码，看起来很聪明，实际训练价值很有限。

评测集要验证三件事：题解是否正确，解释是否自洽，学习路径是否真的暴露薄弱点。只看最终代码能不能运行，会漏掉复杂度错误、边界遗漏和证明链断裂。刷题系统不是答案打印机，它应该帮助用户建立可迁移的解题能力。

二、评测集要分层

flowchart TD
  A[题目集合] --> B[基础样例]
  A --> C[边界用例]
  A --> D[随机生成用例]
  A --> E[反例库]
  E --> F[题解验证]
  F --> G[学习反馈]

基础样例用于检查输入输出格式。边界用例用于覆盖空数组、重复元素、极值、单节点图和不可达状态。随机用例用于发现隐藏错误。反例库则记录历史错误解法的失败场景。

不同题型要有不同评测策略。双指针题要关注单调性是否成立，动态规划题要关注初始状态和转移顺序，图论题要关注环、重边、孤立点和不可达节点。评测集如果不懂题型，最后只能变成一堆随机输入。

三、题解验证要能复现

def run_case(solution, case):
    try:
        actual = solution(case["input"])
    except Exception as exc:
        return {"status": "runtime_error", "error": str(exc)}
    if actual != case["expected"]:
        return {
            "status": "wrong_answer",
            "actual": actual,
            "expected": case["expected"],
        }
    return {"status": "accepted"}

验证流程要保存题目版本、代码版本、测试用例版本和运行结果。否则今天通过、明天失败，很难判断是题目变了、代码变了，还是测试集变了。可复现是算法训练系统的底线。

复杂度也要进入评测。可以通过静态分析、运行曲线和大输入压力测试综合判断。比如声称 O(n) 的解法，在输入扩大十倍时耗时接近百倍，就要提示复杂度描述可疑。复杂度不是装饰，它决定算法能不能从样例走向规模数据。

eval_result:
  correctness: accepted
  complexity_claim: O(n)
  stress_growth: linear_like
  counterexample: null

四、反馈要指向可改进动作

评测失败后，系统不应该只说“答案错误”。更有价值的反馈是指出失败用例类型：重复元素、边界为空、环处理错误、状态初始化错误，还是溢出风险。用户需要知道下一步该修哪里。

AI 生成解释也要被检查。代码正确但解释错误，会误导学习。比如代码用了单调队列，却解释成普通队列；或者明明有排序，却声称整体 O(n)。这类问题应进入语义评测，不然系统会把错误知识讲得很流畅。

评测集还要控制题目泄露。训练样本、提示样本和最终评测样本要分开。如果系统在提示词里见过标准答案，再拿同题评测，就只能证明记忆能力。更稳的做法是保留一批隐藏题和变形题，只在版本发布前运行。

五、总结

AI 刷题评测集要覆盖基础样例、边界用例、随机用例和历史反例，并同时验证代码、解释和复杂度。

刷题系统是否有效，不能靠几道样例证明。它要能稳定发现错误，并把错误转成下一步可执行的学习反馈。