30_sources/video-transcripts/127_Nick_Heiner_刷榜瘟疫与基准阅读/。本场是大会 talk（AI Engineer 分会场当天最后一场），无闪电问答环节。收尾即上面第 13 条的行动倡议："benchmark 并不难。我们需要掀开引擎盖往里看，需要真正把它搞懂，然后去加入 Discord——因为工程师的意见是有价值的。"→ 详细
Ali Khial — Director of AI & ML, G2i。演讲中未留个人邮箱或社媒，只发出一个入口邀请：加入他们的 Discord 参与 benchmark 任务的共建（"工程师的意见是有价值的"）。→ 详细
这一期跟你的关系比标题看起来近得多。你可能觉得"我又不造 benchmark"——但你造了。你的 PRD 工厂里有三驾马车的碰撞和真人评审，那就是一套自建基准：一份规格进去、agent 给出解法、你的评审判据去验证打分、通过的才算数。Ali 这场讲的每一个翻车点，都是在你那套规则上能对号入座的。
① 弱评分器会同时放过错的、误杀对的——这是本期对你最直接的一条
怎么做的：DeepSWE 团队去测 SWE-bench Pro 这个评分器本身，测出两个方向同时在错：8.5% 的错误实现被判通过，超过 24% 的正确实现被判失败。他扒开具体案例后发现病因只有一个——评分标准里出现了规格书里根本没写的要求。一个测试要求"必须存在某个变量"，可这个变量在规格里压根没提，而且凭什么指望模型恰好用这个名字命名它；另一个测试去检查没有导出的内部函数，也就是去考实现细节而不是对外承诺的行为。Ali 的话很硬：如果这是我们自己项目里的 PR，写着这种测试，我们是不会合的。
你可以怎么做：把你碰撞环节和真人评审用的判据逐条摊开，只问一个问题——这条规则考的东西，在需求规格里写过吗？ 凡是"我期待它长成某种样子"但规格没约定的（字段该叫什么名、章节该按什么顺序排、某个模块该拆成几块），都是在给 agent 下套，都在制造误杀。近四分之一的误杀率不是小事：如果你的评审也在这个量级，那你每四次被打回的产出里就有一份其实是好的，而你还在照着"打回率"判断 agent 能力，越判越偏。本周就能做的最小动作：翻出最近 10 份被打回的产出，人工重判一遍，只回答"这份如果我当时直接用了，会出事吗"，数出误杀了几份。
② 好题的验收标准是"能不能翻译成一个授权决定"
怎么做的：他的第三条原则叫 production grade，配了一句最好用的判据——"一个能把 LLM 难住的任务，只能证明 LLM 还没到那个水平，这是一回事；而让一个工程师看着这个任务说出'如果 LLM 能修好这个，那我就信得过它去修那个'——这是完全另一回事。而今天，我们并没有后面这种任务。"反例是 SWE-Marathon 那道"用 Rust 写一个 C 编译器"：题面写得很规范、抽象度也刚好，但测的东西现实里没人真需要。
你可以怎么做：这条正对着你"agent 产出要可验证"这个悬念。你的 PRD 工厂现在拿什么证明自己有效？如果答案是"跑通了多少张工单、评审通过率多少"，那就是 Rust 写 C 编译器那一类——难，但不产生授权。换一个标准：挑三个真实在推的需求，让工厂跑一遍，然后问自己"看完这三份产出，我敢不敢把下一个同类需求直接交给它、我只做终审"。 敢，工厂就有了闭环证据；不敢，就把"为什么不敢"写下来——那个理由才是工厂下一步该修的东西，比任何通过率指标都准。
③ 精确度要按风险分层投放，不是全域一样严
怎么做的：他的第二条原则 holistic graders，直接类比工程测试的老实践：涉及安全问题或核心业务逻辑就全套上（单元测试 + 集成测试 + 端到端测试），但代码库其余部分不追求 100% 覆盖率，"因为那不划算"。评分器要覆盖面大而不死板，精确只投在真正需要的地方。
你可以怎么做：你的评审大概率是"所有产出走同一套检查"。按这条原则改成分层：涉及资金、库存、对外承诺、跨线接口的部分，检查拉满；纯描述性的章节、内部措辞、格式规范，只做行为级的粗检。 好处是双份的——严的地方更严，松的地方不再制造那 24% 的误杀，而且你自己维护规则的精力也省下来（这对你"精力是元约束"的处境是实打实的收益）。
④ 只给名次不给信息的评审，帮不了人做决定
怎么做的：他的第五条原则是"给信息，而不是只给排行榜"——"排行榜告诉你谁赢了，却不告诉你为什么赢。"他想把"横轴"重新摆回首页：跑测过程里其实能提取出大量数据，但从来没被摆到台面上，人们必须自己去刨、自己做实验才能拿到那些数据点。
你可以怎么做：检查你的碰撞和真人评审最后吐出的是什么。如果是"通过 / 不通过"加一个分数，那它和排行榜一个毛病——收到的人知道自己被判了，但不知道下一步该改什么。 改成每个角色必须输出"哪一条不满足 + 规格里对应的原文 + 一个可执行的修改动作"。这条同时解决你另一个痛点：跨线对齐之所以难，往往不是因为大家标准不同，而是因为谁也看不见对方是按什么依据判的。
契约写得越死，你测到的越不是能力
怎么做的：泄题式 prompt 那个例子，第一张截图直接把测试文件的路径指了出来——"意味着 LLM 手里已经拿到了全部食材"；第二张更狠，把实现的完整接口定义原封不动给出来，"等于把 LLM 的任何创造空间都锁死，逼着它只能按这一种方式实现"。他的第一条原则就是解药：spec 应该表达期望的行为、目标、硬性约束，不是实现细节。
你可以怎么做：你把"设计稿即工程强制契约"当作这条链路的地基，方向没错，但这个例子提醒你契约有个边界。该锁死的是对外行为——间距、状态、交互结果、可访问性底线；不该锁死的是实现路径——组件怎么拆、用什么状态管理、文件怎么组织。 一旦契约越界写到实现层，你就再也看不出这条 7-Agent 链路到底有多强，因为它每次都只是在照抄你给的答案；而你想把"该做什么"前移到 agent，前提恰恰是给它留出做判断的空间。下次写契约时给自己一个检查：这一条如果换个实现方式也满足，我会不会判它失败？会，那这条就写太细了。
这一期是现成的"大佬说 X 我试了"验证体选题
怎么做的：Ali 这场的分量不在观点，在于他真的去扒了：统计出 SWE-bench Pro 平均每题 481 个词、捞出具体任务一行行看测试在考什么、引用 DeepSWE 测出的 8.5% 与 24% 两个数字。整场最有说服力的一句还是一手观察——"过去半年里，我没有遇到过任何一个工程师是照着排行榜去选模型的"。
你可以怎么做：你的 C/D 类选题正缺供血，而这条能直接变成一篇验证体：《AI 大会上有人说基准的评分器会误杀 24% 的好产出，我拿自己的 PRD 质检器测了一遍》。做法就是上面那个动作——10 份被打回的产出人工重判，数出误杀几份，把数字和最典型的两条"考了规格里没写的东西"的规则原样贴出来。它天然过你的弹药库闸门：删掉你的实测和数字，这篇就不成立了。而且"可抄物"是现成的——一张"评分规则自查表"，读者拿走就能对自己的 AI 工作流用。如果误杀率是 0，那更好，标题变成《我以为我的质检器在误杀，测完发现问题在别处》，一样成立，这才叫真验证。
"把横轴摆回首页"就是你 Phase 1 该长的样子
怎么做的：他反对只给排行榜的理由是——名次是结论，结论不能帮人做判断，能帮人做判断的是那些被折叠掉的维度数据。
你可以怎么做：这正好支持你把 StockHelp 的 Phase 1 定在"只看数据、不做信号"。看板要显示的不是"这只被低估了 X%"这个综合结论，而是让结论成立的那几根轴分别在哪——市盈率现在多少、在五年分位的什么位置、基本面比率的趋势、公允价是用哪个目标市盈率乘出来的。 一个合成分数最容易让你在心里把尽调偷偷跳过；分维度铺开则会逼你每次都重新想一遍"我信的是哪一条"。等 Phase 2 做信号时，也应该让每个信号带上它的依据，而不是只弹一个红绿灯。
该反着用：Ali 要造的是一套给全行业用的公开基准，所以他强调只做全新任务、留私有保留集、人写人评——成本极高，因为他必须防止别人的模型见过题。你不是。你一个人扛正职加多条副业，精力是最稀缺的东西，你需要的不是一套普适可比的基准，而是一份够用的贴身私测集：十来个你自己项目里真实发生过的需求，人工标好"这份产出我接受 / 不接受"，就够用很多年。他最怕的"污染"（题目模型见过）在你这里反而是优点——你的评审集就该全是你写过的真需求，因为你要测的从来不是通用能力，是"在我的场景里能不能替我干活"。
和你现在做法冲突：你搭碰撞判据和评审规则的直觉是"规则加得越多越安心"——每加一条都感觉更严谨了。这一期说的是反话：每加一条评分规则，你都同时在增加误杀率，而你大概从来没量过被拦下来的东西里有多少其实是好的。这里有真实张力，我不替你下结论——在你的场景里，放过一份坏 PRD 的代价可能确实高于误杀一份好的，那么偏严就是对的。要做的是把这个取舍显性化：写下来"我愿意为了少放过 1 份坏的，接受误杀几份好的"，而不是默认"严一点总没错"。
对你的镜子：你花了大力气建 agent、建流程、建评审，但你从来没有评估过"评估者"。碰撞协议和真人评审的判据是整套工厂里唯一没被检查过的一环——它决定什么能出厂，却没有任何人给它打过分。8.5% 和 24% 这两个数字之所以刺眼，正是因为它们是有人真的动手去测评分器才测出来的。你的判断力优先于努力这条原则，在这里的具体含义就是：先花半天测你的评审判据，胜过再花两周给工厂加功能。
可迁移思维模型【耐用】：评分标准里不能出现规格书里没有的要求。 这一条对 PRD 评审成立，对给 agent 派活成立，对招人面试成立，对你自媒体的自审标准也成立——每次你判一份东西不合格，先问"我用的这条标准，事先说过吗"。没说过就否掉，那是你的问题不是它的问题。这条模型十年后依然管用。
【会过期】：SWE-bench Pro 和 SWE-Marathon 具体那些毛病、8.5% 和 24% 这两个数字。基准迭代很快，明年这些题可能都修了。所以别把结论记成"SWE-bench Pro 不行"，要记成"评分器本身也需要被评分"。
判断更新：你原来大概默认"有闸门 > 没闸门"。改成 "被测过的闸门 > 没有闸门 > 没被测过的闸门"——一个从没被验证过的闸门不只是不管用，它比没有更糟：它给你虚假的安全感，同时在悄悄杀掉你最好的产出，而你还以为那是 agent 不行。
这周一个赌注：翻出最近 10 份被碰撞或真人评审打回的 PRD 产出，自己人工过一遍，只回答"这份如果我当时直接用了，会出事吗"，数出误杀几份。如果 10 份里有 2 份以上其实是好的，你的评审和 SWE-bench Pro 是同一个病——那就去查这几条规则是不是要求了规格里没写的东西，删掉或改写它们。半天的事，而且顺手就是 onehuman_company 的一篇验证体稿子。