第 1 周 · D7约 4 小时

体检套件本身：饱和、坏任务与判分缺陷

最后一天把矛头转向评估系统自己。一个逼近满分的套件已经不再提供信息，一条判分写错的任务会让一个好模型看起来差五十个百分点。这一天给套件做体检、建立读轨迹的纪律，并把七天的产物收成一个能放进简历的项目。

今日目标 0/3

能识别套件饱和并说出饱和之后该做什么，而不是继续汇报那个漂亮的分数
能从一批失败里区分出模型的问题与判分的问题，并说出判分缺陷的典型形态
能说清自动化评估之外的五种质量手段各自补上了哪一类漏洞

登录后可以勾选并保存进度。

今日目标

能识别套件饱和并说出饱和之后该做什么，而不是继续汇报那个漂亮的分数
能从一批失败里区分出模型的问题与判分的问题，并说出判分缺陷的典型形态
能说清自动化评估之外的五种质量手段各自补上了哪一类漏洞

小白版讲解

六天以来我们一直默认的那件事

前六天你建了一套完整的评估系统：能跑出两个概率、有二十四条双向基准集、裁判经过一致性校准、能抓出绕路和死循环、每次运行都有链路和成本、退化时流水线会变红。

这六天里，有一个假设从来没有被质疑过：套件是对的。分数掉了，就是 Agent 的问题。

今天要做的就是质疑它。

因为评估系统是代码，代码会有 bug。而评估系统的 bug 有一个特别恶劣的性质：它不会让你的程序崩溃，它会让你得到一个错误的结论，然后你带着这个结论去改一个没有毛病的地方。

一个五十三个百分点的教训

先看一个真实案例，它是这门课能给出的最有说服力的论据。

某个模型在一个公开基准上初评，得了 42 分。看起来是能力不行。

排查之后发现，问题出在判分：那个基准比较数值答案时用了严格相等。模型答「96.12」，标准答案是「96.124991…」，两个字符串不相等，判错。类似的还有任务描述有歧义、随机任务不可复现。

把判分修好之后，同一个模型、同一套题，得了 95 分。

五十三个百分点的差距，全部来自评估本身的缺陷，与模型能力毫无关系。

如果没有人去排查，这个结论会一路传下去：这个模型不行，我们换一个。团队会花几周时间做一件完全没有必要的事。

今天的实验里有这个案例的最小复现。同一个 Agent、同一笔退款、金额一模一样，挂两个评分器：

TextText

-- 判分缺陷的代价（同一个 Agent，同一件事，两个评分器）--
  严格相等比较：0%　整数域比较：100%
  退款金额一模一样。差距全部来自判分那三行代码。

把 4990 分换算成 49.9 元，中间经过一次会产生误差的运算，就会得到 49.89999999999999。而它不等于 49.9。

套件饱和：分数还在，信息没了

第二类问题更隐蔽，因为它的表现是分数很好看。

一个套件刚建起来的时候，通过率可能只有三成，每次改进都能看到明显的涨幅。跑了半年之后，它稳定在 98%。

这时候它还有价值，但价值变了：它只剩回归价值，不再提供改进信号。

分数从 98% 涨到 98.5%，你没法判断这是真的进步还是噪声。而一次真正的能力飞跃，在这个套件上可能只体现为一个百分点。

有一个反过来的例子值得记住：某团队用一次性的单轮评估测一个新模型，结论是「提升不明显」。后来他们改做多步的、带真实工具的评估，才看到这个模型在长任务上的真实收益。不是模型没有进步，是他们的尺子量不到那个维度。

坏任务的三种形态

第三类问题是任务本身写坏了。D2 讲过参考解验证，今天补齐识别方法。

形态	表现	怎么发现
描述有歧义	通过率在中间徘徊，读轨迹发现 Agent 做的是另一件合理的事	两个人独立判，判不一致
判据无法验证	判据写的是「回答得专业」这种没法自动判的东西	写参考解时发现自己也判不了
随机性不可复现	同样输入每次正确答案都不一样，评分器拿着固定答案在比	固定种子跑两遍，结果不一致

加上 D2 那条判据：通过率长期为零的任务，先怀疑题目。 一条真正可解的难任务，跑很多次通常会蒙对至少一次；全零更像一堵墙而不是一个斜坡。

今天的体检器把这些做成了自动检查。但要说清楚它的边界：它只能发现它知道怎么找的那几类。报告里没有问题，不等于套件健康。

一个恒真的检测器比没有检测器更糟

写今天这个体检器的时候，我自己踩了一个坑，值得原样讲出来。

「基线代表性」那一项要回答的问题是：你那个基线数字，是不是恰好记在了运气特别好的那一次上？如果是，之后每次正常运行都会显得像退化，D6 那道门禁会长期误报。

第一版的判据写的是「基线大于等于分布最高值就报警」。跑出来的报告写着：

TextText

✗ unrepresentative-baseline [套件级]
    基线 60.0% 落在 12 次同配置运行的最高端（区间 60.0%–60.0%，中位 60.0%）

区间是 60.0% 到 60.0%——那批任务根本不抖，十二次运行分数完全一样。这时候基线必然同时是最高和最低，「落在最高端」这个判据恒成立。于是检测器对每一个完全稳定的套件都会报警，而且报警文本还写得有理有据。

这一项同时补上了 D6 没有回答的那个前置问题：D6 教了怎么记基线、怎么定阈值，但没说基线本身该记在哪一次上。答案是：记在有代表性的一次上，并且要能验证它确实有代表性。

Agent 会钻空子，而空子是你留的

还有一类现象，第一次遇到会让人很生气：Agent 找到了一条你没想到的捷径，把任务「做完了」，但完全不是你想要的做法。

比如它发现直接改测试文件就能让测试通过，或者从 git 历史里找到了答案。

生气之前先想一件事：这些空子是评估设计者留的。 如果判据是「测试通过」，那么改测试确实满足了判据。Agent 只是在优化你写下的目标函数，它没有作弊，是目标函数写得不准。

这件事的正确用法是：把每一次钻空子当成一次免费的评估审计。它精确地指出了你的判据和你的真实意图之间的差距在哪。

读轨迹是纪律，不是建议

今天最后一条，也是整门课最需要被记住的一条：

除非有人真的读过几条轨迹，否则不要相信任何评估分数。

理由前面已经铺完了：判分可能写错、任务可能有歧义、Agent 可能钻了空子、检测器可能恒真。这四类问题没有一类能被分数本身暴露出来，它们全都需要有人打开一条具体的运行记录去看。

问题是「要多读轨迹」这句话写进文档就等于没写。所以今天把它做成了函数：体检报告末尾会直接给出一份清单，列出本轮该读哪几条、为什么读。

清单的抽样规则刻意不是纯随机：失败样本必须进，因为信息密度最高；通过样本也要抽几条——只看失败会形成「它什么都做不对」的错觉，而且判据太松这种问题只有在通过样本里才看得见。

瑞士奶酪：没有一层能单独兜住

最后把视野拉开。自动化评估只是质量体系的一层，它有它看不见的地方。

手段	补上了哪一类漏洞	代价
自动化评估	已知问题的回归，每次提交都能跑	只覆盖你想得到的场景
生产监控	真实用户行为，合成用例想不到的情况	事后才知道，信噪比低
对照实验	真实结果，能排除混淆因素	慢，只能测已上线的改动
用户反馈	你完全没预料到的问题	稀疏，偏向严重问题
人工读轨迹	自动检查抓不到的细微质量	费时，覆盖不均匀
系统性人工研究	主观任务的黄金标准，用来校准模型裁判	最贵最慢

每一层都有洞，但洞的位置不一样。叠在一起，一层漏掉的会被另一层接住。

不要指望任何一层单独兜住质量，包括你这七天建的这一套。

源码导读

今天回到 Anthropic 那篇文章的后半部分——前六天一直在用它的前半部分。后半段讲的是评估的长期维护：读轨迹的纪律、评估饱和、怎么组织一支持续维护评估的团队，以及那个六层质量手段的对照表。它提出的「eval-driven development」值得留意：在 Agent 具备某项能力之前就先把评估写出来，用评估来定义你打算做什么。这和测试驱动开发是同一个思路。

Harbor 是另一份材料，一个容器化的 Agent 评估框架。读它主要看两件事：一是它怎么把「每个试次一个干净环境」做到容器级别（我们这七天是在进程内用对象拷贝做的，够教学但不够生产）；二是它怎么把不同的 Agent 接进同一套任务接口。

看许可要落到仓库里的 LICENSE 文件，不要只看代码托管平台页面上那个标签——那个字段是自动识别的，识别不出来就报「未指定」，而它识别不出来的恰恰是那些做了特殊安排的项目。选自建还是选现成，取决于你的团队要不要自托管、会不会二次分发、以及这个项目停止维护时你能不能接手。

动手实验

🧪 D7：套件体检与作品集收尾

代码位置：labs/agent-evals-7days/day-07-suite-health

今天的 lab 把七天的模块全部汇合到一个项目里，然后新增体检与报告两块。

四个练习对应四类问题：饱和、长期零分、判分缺陷、基线代表性。第四个是重点，它是最容易写出恒真实现的地方，README 里单独讲了。

体检器的核心结构是这样的，注意每一类问题都带着「该怎么办」而不只是「有问题」：

suite-health.js

export function detectUnrepresentativeBaseline(baselineRate, noiseRates) {
  if (noiseRates.length < 5) return []
  const sorted = [...noiseRates].sort((a, b) => a - b)
  const lo = sorted[0]
  const hi = sorted[sorted.length - 1]
 
  // 关键的一行：分布没有展开时直接沉默。
  // 所有运行同分时，基线必然同时是最高和最低，
  // 「落在最高端」这个判据恒成立，检测器会对每个稳定套件报警。
  if (hi - lo < 1e-9) return []
 
  if (baselineRate >= hi) {
    return [{ kind: 'unrepresentative-baseline', severity: 'error',
      detail: '基线记在幸运的一次上，之后每次正常运行都会像退化，门禁会长期误报' }]
  }
  return []
}

suite_health.py

def detect_unrepresentative_baseline(baseline_rate, noise_rates):
    if len(noise_rates) < 5:
        return []
    sorted_rates = sorted(noise_rates)
    lo, hi = sorted_rates[0], sorted_rates[-1]
 
    # 关键的一行：分布没有展开时直接沉默。
    # 所有运行同分时，基线必然同时是最高和最低，
    # 「落在最高端」这个判据恒成立，检测器会对每个稳定套件报警。
    if hi - lo < 1e-9:
        return []
 
    if baseline_rate >= hi:
        return [{
            "kind": "unrepresentative-baseline",
            "severity": "error",
            "detail": "基线记在幸运的一次上，之后每次正常运行都会像退化，门禁会长期误报",
        }]
    return []

手动验收清单里有一条是练习 4 的手动版变异检验：把会抖的那条任务注释掉再跑，基线检测应当保持沉默；恢复它，报警回来。两个方向都验过，才算这个检测器是有效的。

面试题

今天的四道题是全课的收口：套件饱和之后怎么办、怎么区分模型退化与判分写错、为什么读轨迹是纪律、以及评估框架的选型判据。

第四题会追问到许可。这是个容易露怯的地方——很多人答得出框架名字，答不出「这个项目的许可允许我们自托管并二次分发吗」。而这恰恰是真实选型里绕不过去的一关。

检查清单与明日预告

七天结束时，你应该能做到：

说出套件饱和的判据，以及饱和之后该做什么（不是删掉那条任务）
说出判分缺陷的三种典型形态，并解释为什么钱要用整数比较
从一批失败里区分模型问题与判分问题，并说出排查顺序
解释为什么一个恒真的检测器比没有检测器更糟
说清六层质量手段各自补上哪一类漏洞
让 MOCK=1 pnpm selftest 九项全绿
亲手做一次手动变异检验：注释掉会抖的任务，看检测器沉默；恢复，看它回来

七天到此结束。你手里现在有一个完整的 evalkit：它跑得出两个概率指标，带一份双向的基准集，裁判经过一致性校准，能抓出绕路和死循环，每次运行都有链路和成本，退化时会让流水线变红，并且能给自己做体检。

把它接到你自己的 Agent 上，是这门课真正的作业。四个冻结文件里只有靶子是课程专用的，换成你的 Agent 只需要实现一个接口：给一个任务和一个世界，返回一条轨迹。

最后留一句话。这门课教的所有方法，最终都服务于一个很朴素的目的：让你能够诚实地回答「它到底行不行」这个问题——包括在答案是「不行」的时候。一个报喜不报忧的评估系统，比没有评估系统更危险。

面试题库

你们的评估套件通过率已经百分之九十八了，接下来你会做什么？Your evaluation suite is passing at 98 percent. What do you do next?
国内高频海外高频进阶#evaluation#saturation#suite-health
分析过程 · 先想清楚再作答
这题考的是「能不能识别饱和」。回答「很好，说明系统质量高」的，等于承认自己从没想过评估也有生命周期。
先说清楚 98% 意味着什么：这个套件的**改进信号已经耗尽**。分数从 98 涨到 98.5，你分不清是真进步还是噪声；而一次真正的能力飞跃，在这个套件上可能只体现为一个百分点。它现在只剩回归价值。
然后给动作，而且第一个动作不是删题：**把饱和的任务移进回归集**，它们继续守着「不要退步」这条线。删掉等于放弃了对这项能力的回归保护，这是最常见的错误处置。
第二个动作是出更难的新题，而新题从哪来要说得出来：从最近的线上故障、从用户抱怨、从当前 Agent 明显做不好但业务真的需要的场景。新的能力集应该**从低通过率起步**，那才是有爬坡空间的尺子。
第三个动作是检查尺子本身量的维度对不对。有个真实的反例：某团队用一次性的单轮评估测新模型，结论是提升不明显；改成多步、带真实工具的评估之后，才看到它在长任务上的真实收益。**不是模型没进步，是尺子量不到那个维度。**
可预期的追问是「那你怎么知道 98% 是真的，不是判据太松」。答案是抽样读通过样本的轨迹——只看失败样本永远发现不了判据太松这类问题。
How to reason about it · think before answering
This tests whether you recognize saturation. Answering 'great, the system is high quality' admits you have never thought of an evaluation suite as having a lifecycle.
State what 98 percent means: this suite has exhausted its improvement signal. Moving from 98 to 98.5 is indistinguishable from noise, and a genuine capability jump might show up as a single point. All that remains is regression value.
Then give actions, and the first one is not deleting tasks: move the saturated ones into the regression set, where they keep guarding against backsliding. Deleting them forfeits regression protection for that capability, which is the most common mishandling.
Second, write harder tasks, and say where they come from: recent production incidents, user complaints, scenarios the current agent clearly handles badly but the business genuinely needs. A new capability set should start at a low pass rate, because that is what leaves room to climb.
Third, check that the ruler measures the right dimension at all. A real counterexample: a team evaluated a new model with one-shot single-turn evals, concluded the gains were unremarkable, and only saw the real benefit after building a multi-step evaluation with real tools. The model had improved; the ruler could not see that dimension.
Expected follow-up: how do you know the 98 percent is real rather than a loose criterion? Sample the transcripts of passing trials - looking only at failures can never surface a criterion that is too lenient.
答题要点
98% 说明改进信号已耗尽，只剩回归价值，小幅变化无法与噪声区分。
第一个动作是把饱和任务移入回归集，**不是删掉**——删掉会放弃回归保护。
出更难的新题，来源是线上故障、用户抱怨、业务需要但当前做不好的场景。
新能力集应从低通过率起步，才有爬坡空间。
检查尺子量的维度对不对：单轮评估可能量不到多步能力的进步。
Key points
98 percent means the improvement signal is exhausted; small deltas are indistinguishable from noise.
First action is moving saturated tasks into the regression set, not deleting them.
Write harder tasks sourced from incidents, complaints, and business-critical weak spots.
A new capability set should start at a low pass rate to leave room to climb.
Verify the ruler measures the right dimension - single-turn evals miss multi-step gains.
一个模型在你的套件上突然掉了很多分，你怎么区分是模型退化还是判分写错了？A model suddenly drops a lot of points on your suite. How do you tell a real regression from a broken grader?
国内高频海外高频深入#evaluation#debugging#grading-defect
分析过程 · 先想清楚再作答
这题考排查顺序。直接说「回滚模型」的丢一半分——你还没证明问题在模型那边。
第一步是看**掉分的形状**。真实的模型退化通常是弥散的：各类任务普遍降一点。判分缺陷往往是**集中的**：某一类任务集体归零，而其他类纹丝不动。形状本身就是很强的线索。
第二步读失败理由。判分缺陷有很典型的指纹：两个数字只差一点点却判不相等（严格相等比较，尤其是浮点换算之后）、大小写或空格差异、以及「期望 X 实际 X」这种看起来一模一样却判失败的情形。有个公开案例，某模型因为「96.12」不等于「96.124991…」初评 42 分，判分修好后同一套题得 95 分——**五十三个百分点全部来自评估缺陷**。
第三步用参考解验证：把一条人工做对的答案喂给评分器。参考解都过不了，那 100% 是评估的问题，与模型无关。这是最干净的判据。
第四步检查环境是否变了：依赖升级、上游 API 改了返回格式、测试数据被人动过。这些会伪装成模型退化，而且在团队里最容易互相甩锅。
最后才是读轨迹确认模型确实做错了。整个顺序是**从评估侧走向模型侧**，因为评估侧的问题更容易排查、也更常见。可预期的追问是「怎么让这个排查变快」——答案是基线快照里记全环境指纹（模型版本、提示词版本、任务集版本、随机种子），少记一样就多一个没法排除的变量。
How to reason about it · think before answering
This tests your debugging order. Saying 'roll back the model' loses half the credit - you have not yet shown the problem is on the model side.
First look at the shape of the drop. A genuine model regression is usually diffuse: everything sags a little. A grading defect is typically concentrated: one class of tasks goes to zero while the rest is untouched. The shape alone is a strong signal.
Second, read the failure reasons. Grading defects have a recognizable fingerprint: two numbers differing in the last digits yet judged unequal (strict equality, especially after a float conversion), case or whitespace mismatches, and the 'expected X, got X' pattern that reads identical yet fails. In one public case a model scored 42 because '96.12' did not equal '96.124991...', and the same model on the same suite scored 95 once grading was fixed - fifty-three points entirely from the evaluation.
Third, validate with a reference solution: feed a hand-verified correct answer to the grader. If the reference solution fails, the fault is one hundred percent in the evaluation. This is the cleanest test.
Fourth, check whether the environment moved: dependency upgrades, an upstream API changing its response shape, test data someone edited. These masquerade as model regressions and cause the most finger-pointing.
Only then read transcripts to confirm the model really did worse. The order runs from the evaluation side toward the model side, because evaluation-side faults are both easier to check and more common. Expected follow-up: how do you make this faster? Record a complete environment fingerprint in the baseline - model version, prompt version, task-set version, random seed. Every missing field is one more variable you cannot rule out.
答题要点
先看掉分形状：真实退化弥散，判分缺陷集中在某一类任务。
读失败理由找判分指纹：严格相等、浮点换算、大小写与空格差异。
用参考解验证：人工做对的答案过不了评分器，就一定是评估的问题。
检查环境变更：依赖升级、上游返回格式变化、测试数据被改。
排查顺序从评估侧到模型侧；基线快照记全环境指纹才能快速排除变量。
Key points
Check the shape: real regressions are diffuse, grading defects are concentrated.
Read failure reasons for grading fingerprints: strict equality, float conversion, case and whitespace.
Validate with a reference solution - if a known-correct answer fails, the fault is in the evaluation.
Check environment changes: dependencies, upstream response shapes, edited fixtures.
Debug evaluation-side first; a complete environment fingerprint makes variables ruleable-out.
为什么说没读过轨迹就不该相信评估分数？你会怎么把读轨迹变成团队习惯？Why should you not trust an evaluation score before someone has read transcripts? And how do you make transcript reading a team habit?
国内高频海外高频进阶#evaluation#transcripts#process
分析过程 · 先想清楚再作答
这题前半问原因，后半问落地。只答前半段拿不到高分——「应该多读轨迹」这句话本身毫无信息量，所有人都同意，然后没有人做。
原因要具体列出分数看不见的东西：判分可能写错（分数照样是个数）、任务描述可能有歧义（Agent 做了另一件合理的事）、Agent 可能钻了判据的空子（改测试让测试通过）、检测器本身可能恒真（永远报警或永远沉默）。**这四类没有一类会体现在分数上**，它们只在具体的运行记录里看得见。
特别要提钻空子这一类，因为它的归因容易搞反：Agent 找到捷径不是它作弊，是**你的判据和你的真实意图之间有差距**。每一次钻空子都是一次免费的评估审计，精确指出了差距在哪。
落地部分的关键是**把它从建议变成产物**。做法：让评估报告自动输出一份「本轮该读的轨迹」清单，附上每条为什么被选中。人对着清单打勾，比对着一句倡议要可执行得多。
抽样规则要说清楚，而且不能是纯随机：失败样本必须进（信息密度最高），**通过样本也要抽几条**——只看失败会形成「它什么都做不对」的错觉，而且判据太松这类问题**只有在通过样本里才看得见**。
可预期的追问是「读多少条才够」。诚实的答案是没有普适数字，但可以给操作性判据：读到你开始重复看到同一类失败原因，这一轮的边际收益就下来了。另外每次改判据、换模型、加新任务之后必须重读，因为那正是新问题最可能出现的时候。
How to reason about it · think before answering
The first half asks why, the second asks how. Answering only the first scores poorly - 'we should read more transcripts' carries no information, everyone agrees with it, and nobody does it.
Be concrete about what a score cannot show: the grader may be wrong (the score is still a number), the task may be ambiguous (the agent solved a different reasonable problem), the agent may have exploited the criterion (editing tests so tests pass), the detector itself may be vacuous (always firing or never firing). None of these four surface in the score; all of them are visible in a specific run.
Call out the exploitation case, because the attribution is easy to get backwards. An agent finding a shortcut is not cheating - it is evidence of a gap between your criterion and your actual intent. Every exploit is a free audit that points at exactly where the gap is.
For adoption, the key move is turning the practice into an artifact. Have the report emit a reading list for this round, with a reason attached to each entry. People tick off a list; they do not act on an exhortation.
Spell out the sampling rule, and it must not be purely random: failures always go in because they carry the most information, and a few passing trials go in too - looking only at failures breeds the illusion that nothing works, and a criterion that is too lenient is visible only among passes.
Expected follow-up: how many is enough? Honestly there is no universal number, but there is an operational test: once you start seeing the same failure cause repeat, the marginal value of this round has dropped. Also mandate a re-read after any change to graders, model, or task set, because that is exactly when new problems appear.
答题要点
分数看不见四类问题：判分写错、任务有歧义、Agent 钻空子、检测器恒真。
Agent 钻空子说明判据与真实意图有差距，是免费的评估审计，不是作弊。
落地要把它变成产物：评估报告自动输出「本轮该读的轨迹」清单并附选中理由。
抽样不能纯随机：失败样本必进，通过样本也要抽——判据太松只在通过样本里可见。
改判据、换模型、加新任务之后必须重读，那是新问题最可能出现的时候。
Key points
Scores hide four failure classes: broken grading, ambiguous tasks, criterion exploitation, vacuous detectors.
An exploit reveals a gap between criterion and intent - it is a free audit, not cheating.
Make it an artifact: have the report emit a reading list with a reason per entry.
Sampling is not random: always include failures, and include some passes, since a lenient criterion is only visible there.
Mandate a re-read after any grader, model, or task-set change.
自建评估框架还是用现成的？说出你的判断依据，以及选型时会看许可的哪些方面。Build your own evaluation framework or adopt an existing one? Give your decision criteria, and say what you check in the license.
国内高频海外高频深入#evaluation#tooling#licensing
分析过程 · 先想清楚再作答
这题有两个考点，很多人只答得出第一个。前半是工程判断，后半是法务意识——后者恰恰是真实选型里绕不过去的一关，也是最容易露怯的地方。
工程判断部分先给判据而不是结论：任务与判据的特殊程度（业务判据越独特，现成框架的适配成本越高）、要不要自托管、团队有没有人维护、以及最关键的一条——**你要的是框架还是平台**。评估的难点从来不在跑测试用例的那段代码，而在**高质量的任务和评分器**，那部分无论如何都得自己写。所以框架选型的权重其实没有多数人以为的那么高。
合理的折中是：跑批与报告用现成的，任务与评分器自己写。先快速选一个框架，把精力压在测试用例质量上。
许可部分要说清楚看什么：① **能不能自托管**；② **能不能作为服务提供给第三方**——这一条会卡住相当一部分「源码可见」的项目；③ 有没有**分目录的差异化许可**（核心开源、企业版目录另有条款是常见结构）；④ 传染性条款会不会影响你的闭源部分。
特别要强调一个操作细节：**看许可要落到仓库里的 LICENSE 文件，不要只看代码托管平台页面上那个标签**。那个字段是自动识别的，识别不出来就报「未指定」，而它识别不出来的恰恰是那些做了特殊安排的项目。实测过三个例子：一个被广泛称作 MIT 开源的可观测平台，LICENSE 原文写明有三个企业版目录另有许可；一个被普遍称作开源的评估平台用的是 Elastic License 2.0，明文禁止作为托管服务提供给第三方，并不是 OSI 认可的开源；还有一个常被误认为出自某家模型厂商的框架，其实来自另一个机构。
可预期的追问是「这个项目停止维护了怎么办」。答案是把它当作选型判据之一：许可允许你 fork 并自行维护吗？有多少组织在依赖它？核心逻辑你的团队读得懂吗？一个你接不了手的依赖，就是一个将来会卡住你的依赖。
How to reason about it · think before answering
Two things are being tested and most people only answer the first. The front half is engineering judgment; the back half is licensing awareness, which is unavoidable in real procurement and where candidates most often come up short.
For the engineering half, give criteria rather than a verdict: how unusual your tasks and criteria are (the more bespoke the business rule, the costlier the adaptation), whether you need self-hosting, whether anyone will maintain it, and the decisive one - are you buying a framework or a platform? The hard part of evaluation was never the code that loops over test cases; it is high-quality tasks and graders, and you are writing those yourself regardless. Framework choice matters less than most people assume.
The sensible compromise: adopt something for running batches and rendering reports, write tasks and graders yourself. Pick a framework quickly and spend the saved effort on test-case quality.
For licensing, say what you check: whether you may self-host; whether you may offer it to third parties as a service, which disqualifies a good number of source-available projects; whether different directories carry different terms (an open core with a separately licensed enterprise directory is a common structure); and whether any copyleft term reaches your proprietary code.
Stress one operational detail: read the LICENSE file in the repository, not the badge on the hosting platform. That field is auto-detected and reports 'not specified' whenever detection fails - and detection fails precisely on the projects with unusual arrangements. Three verified examples: an observability platform widely described as MIT has LICENSE text carving out three enterprise directories; an evaluation platform widely called open source ships under Elastic License 2.0, which explicitly forbids offering it as a hosted service and is not OSI-approved; and a framework commonly attributed to a model vendor actually comes from a different organization.
Expected follow-up: what if the project stops being maintained? Make that a selection criterion too - does the license let you fork and maintain it, how many organizations depend on it, can your team read the core logic? A dependency you cannot take over is a dependency that will eventually block you.
答题要点
判据：判据的特殊程度、是否要自托管、有没有人维护、要的是框架还是平台。
评估的难点在任务与评分器，那部分必须自己写，所以框架选型权重没那么高。
许可看四件事：能否自托管、能否作为服务提供给第三方、是否分目录差异化、有无传染性。
**必须读仓库里的 LICENSE 文件**，平台上那个自动识别的标签在特殊安排的项目上经常不准。
把「停止维护怎么办」纳入选型：许可是否允许 fork、依赖它的组织多不多、团队能否接手。
Key points
Criteria: how bespoke your rules are, self-hosting needs, maintenance ownership, framework versus platform.
The hard part is tasks and graders, which you write either way, so framework choice carries less weight.
License checks: self-hosting, offering as a service, per-directory terms, copyleft reach.
Read the repository's LICENSE file - the auto-detected badge is often wrong on projects with unusual terms.
Treat abandonment as a criterion: can you fork it, who else depends on it, can your team take it over?