评估 人工智能 题解：别只看主观感受

“读起来像对的”不是题解质量指标。评估应把可自动检查的事实与需要人工判断的解释分开：代码是否运行、复杂度声明是否有依据、题面约束是否覆盖，以及讲解是否会误导读者。

分层测试

• 单元测试：解析器、结构化输出和错误分类；
• 集成测试：模型客户端、工具调用、超时和降级；
• 端到端测试：从题目输入到最终展示，覆盖权限和缓存。

测试集需要包含边界题、反例题和模型容易混淆的题型，并与训练或提示样例隔离。对于无法自动判定的“解释是否清楚”，采用带标准的人工抽样，而不是把偏好当成准确结论。

type Report struct {
    Parsed bool
    RanTests bool
    HasUnsupportedClaim bool
}

func Accept(r Report) bool { return r.Parsed && r.RanTests && !r.HasUnsupportedClaim }

报告中应保留样本范围、失败类别和版本信息。指标变化要能追溯到数据、提示词或代码变更，否则数字不能指导发布决策。

把失败样本变成下一轮输入

我更愿意把评测结果看成一次排错记录，而不是给模型打总分。每次失败先归到题面解析、算法选择、代码生成、复杂度说明或展示渲染中的一类；同一类连续出现时，再回头检查提示词、检索材料和工具约束。这样处理的好处是，修复目标足够具体，不会因为一两个漂亮分数就贸然换模型。

上线前还要保留一组不参与调参的回归题。改动后先比较这组题的通过情况和失败类型，再决定是否扩大样本。对于需要人工复核的解释，评审人应只看题目、答案与事先写好的检查项，避免先看到模型名称而放宽标准。实习时做题解工具，最怕的不是答错一道题，而是系统把不确定的话说得很笃定。

继续把问题说具体

围绕评估 人工智能 题解：别只看主观感受，最需要避免的是把一个结果当成全部证据。题解、评测或代码审查都有自己的输入分布：容易的样本、边界样本和错误输入给出的信号并不相同。分层测试、把失败样本变成下一轮输入已经说明了主要做法，补充部分应该把“什么算通过”说得更细，而不是把一次高分或一次构建成功写成质量结论。

实际判断可以从反例开始。对题解就看是否漏掉条件和复杂度，对缓存和算法就看失效、负权或状态转移是否被覆盖，对合并改动则看冲突解决后语义有没有悄悄改变。每次只引入一个能解释的问题，比堆一长串抽象术语更适合读者复现和讨论。

测试名称和断言最好描述行为，而不是描述实现。比如写清“重复请求不会生成两份记录”或“负权输入被明确拒绝”，比断言某个内部变量更耐改。发现失败时，把输入、预期和实际结果放在一起；尚未确认的原因就标注为待查，不要用推测替代结论。

这样积累下来的样例既能防回归，也能反过来约束功能范围。需求变了就新增样例或调整判定规则，旧样例仍保留其背景，文章的判断链条才不会随着一次改版断掉。

容易漏掉的细节

评价题解时，可以把“看起来有道理”和“确实解决问题”分开。前者主要来自叙述是否顺畅，后者需要回到样例、边界条件和复杂度。若答案只解释了常规情况，却没有交代极端输入的处理，评分时就不该用一段漂亮文字把这个空缺抵消。

失败样本的记录也要保留原貌：题目条件、模型答案、人工指出的问题和最终处理结论应放在一起。只留下“已修正”没有意义，因为下一次相似题目出现时，系统仍然不知道上次错在理解、推导还是表达。