ARTICLE · 1285172
AI评测拿了高分,产品能交付吗
AI评测拿了高分,产品能交付吗
为了给自己的简历挑一套合适的版式，我做过一套简历模板评测 Skill：设定五个维度，让 AI 看图、打分，再筛选值得借鉴的模板。 其中有张模板，我觉得很普通，只值 2 到 3 分。但后来保留下来的同图对照记录里，旧规则给了它 4.90 分，新规则给了 3.00 分，满分都是 5 分。 模板没变，变的是评分规则。 这件事让我重新留意起分数的来路。今天读美团技术团队的 AI Coding 实践文章时，我又想到了它：一套评测给出了漂亮的结果，我们究竟获得了什么依据，足够拿去支持多大范围的交付？ 分数有用，但要连着它的条件一起读 那套 Skill 评的是模板版式，不是候选人的能力。五个维度分别是清晰易读、专业可信、内容替换与容量适配、视觉精致、可复用重建性。权重依次是 30%、30%、10%、25%、5%。 看起来已经很细了。阅读体验、视觉完成度和以后能不能换成自己的内容，都有对应的位置。 问题出在分档上。 旧规则下，AI 看到了深色正文与白底的对比、稳定的栏目和日期格式、统一的蓝灰配色。这些观察大体成立，它却把基础规整、没有明显错误，理解成了优秀。 我当时留下的判断是：“我觉得图一适合3分或者2分。因为它很普通。” 随后，规则明确改成了 3 分表示普通合格，4 分要能指出超出合格档的具体优势，5 分才是可以作为示范的成熟处理。简单、黑白、常见的版式仍然可以优秀，但得把优秀体现在哪里说清楚。 在 2026 年 10 月 16 日那次同图对照里，两个独立评分上下文分别读取新旧规则、查看同一张模板，不先给它们人工标签和历史分。旧规则的五维分项是 5、5、4、5、5，加权得到 4.90；新规则的分项都是 3，加权得到 3.00。 
这次高分和我的判断对不上，首先暴露的是评分标准的问题。拿到再多小数位，也不能省掉对“普通”和“优秀”的区分。 后面又遇到另一种偏差：有些扣分理由混入了占位日期、示例时间线和 Lorem 文案的问题。但我借用的是版式，示例文字会全部替换，这些问题应该与真正的重叠、裁切、容量不足分开。 至此，我才更清楚地看到，评测不仅需要把维度列出来，还得对准自己想做的决定。我要选优秀版式，评分就不能只检查有没有明显错误，也不能把将被替换的示例文案当作版式缺陷。 这些问题有不同的来处：评分标准可能偏了，熟悉的题可能被反复适配，运行环境也可能变了。把这些分清之后，才能讨论对外承诺做到哪里，以及交付后怎样核对实际结果。后面的几章，就沿着这条线往下拆。 一直围着同一套题优化，进步也会变得难判断 回看那份运行记录，当时固定评测集只有一张模板图，而且这张图参与了新版规则的制定。所以，3.00 分首先说明的是这一个开发案例得到了校准，距离证明它能稳定评价其他模板，还差新的证据。 如果我每次都拿它看结果，再据此改规则，就可能越来越擅长把这张图评对，却不知道换一张真正优秀、但风格朴素的模板，会不会又把它错挡在外面。 Dwork 等人关于自适应数据分析的研究，讨论了反复依据同一留出集调整模型，可能对留出集本身过拟合的问题。它也提醒我：根据同一批结果调 Prompt 或规则时，得留意评测适配偏差。 熟悉的案例仍然有用。那张普通模板值得留下，下一次修改不能又把它当成优秀参考；它承担的就是回归检查的任务。 判断对新模板的表现，则需要另一部分未参与日常调优的样本。优秀、普通和边界案例都要有，不能只补一批和旧图长得很像的负例。 这也让“扩充评测集”变得更具体：缺少的是哪种任务，哪种资料条件，或者哪种失败方式，要先说清楚。新加一百张相似图片，和补上一个从没验证过的任务，提供的信息并不相同。 生成式 AI 的输出还有波动。同一道题值得在相同条件下重复运行，观察它是偶尔答对，还是多数时候都能稳定完成。一次打分、一次通过，仍不足以回答后一件事。 换一份更难的试卷，仍然会有漏掉的问题 对简历模板来说，看图得分还没有覆盖完整的使用过程。 那次对照记录明确写着，部分维度只是据图预估。换上自己的中文内容会不会溢出，源文件是否方便修改，导出的 PDF 有没有断行或裁切，都还需要实际试排和导出后检查。图上规整与成品可用，中间还有一段工作。 美团的分布式存储实践，把这个差别放到了更复杂的工程环境里。 原文有个例子：某个告警问题没有被测试发现，因为测试设置和生产不同；另一处保护逻辑在单测里被手动提供了时间戳，真实运行路径却没有设置它。 测试正常执行了，但关键条件已经被替换，结果就没有触及生产中的缺陷。 
原文还提到，测试报告把失败数写死为零，失败用例没有进入汇总。这里连“测试通过”这个结论的产生过程，都需要另外检查。 前一种情况是环境与覆盖范围的问题，后一种是测量工具的问题。它们都不能归结成模型过拟合。把问题分清楚，才知道应该补新题、修测试，还是去查真实运行路径。 对多轮 Agent，还要检查任务过程。用户中途改了要求，旧计划有没有停；工具超时后重试，会不会重复执行；之前留下的状态，会不会影响下一次任务。单条回答的质量分数，覆盖不了这些行为。 普通软件同样存在这些工程问题。生成式 AI 又带来了开放输入和输出波动，使团队更需要把模型表现与整个任务的实际结果分开观察。 交付之前，先把承诺说具体 简历模板的例子也让我看到了交付范围的差别。给出一份值得研究的版式参考，与交付一份已经换好个人内容、完成 PDF 检查、可以直接投递的简历，承诺不同。 前者需要说明选中的依据和仍待确认的地方。后者还得完成内容替换、版面检查与导出验证。不能因为看图得分高，就把后续工作自动算作已经完成。 把同样的区别放到一个邮件助手里，会更直观。 它只生成草稿时，用户还有机会核对金额、收件人和附件；如果允许它直接发送，相同的文字错误就可能立刻影响真实业务。文案评分接近，也不代表两种产品可以共用一套交付条件。 
自动发送多出来的权限、对象检查和执行结果验证，要另外落实。人工审核本身也有成本：用户每天面对大量草稿，很可能逐渐习惯点确认。把人放进流程，还得让他看得见关键差异、有时间判断。 这对个人和小团队是一个实际取舍。暂时只交付有证据支持的那段任务，把不稳定的执行环节留给人，意味着自动化程度低一些，却能让产品承诺更接近现有能力。 我会更愿意用具体条件判断是否交付：关键任务在约定条件下达标，已知的严重问题已处理，超出支持范围时有清楚的停止方式。 信息不足，就留下缺口；执行结果无法确认，就不要报告成功。涉及外部操作时，必要的权限控制还要由程序落实，不能只寄望于一句 Prompt。 NIST 的生成式 AI 风险管理框架，也建议结合部署条件验证表现，记录泛化限制。所有产品共用一个上线分数，无法替团队完成这些判断。 这些标准最好在看最终成绩之前约定。否则，先拿到一个结果，再找理由解释为什么可以通过，很容易又回到那套 Skill 高估普通模板时遇到的问题。 上线之后，还要继续获得证据 明确使用范围，也不意味着上线前已经知道一切。 Google SRE 介绍的金丝雀发布，会先把新版本放到有限的流量和时间范围，与原版本比较，再决定是否扩大。它建立在必要的上线前验证之上，补充测试环境难以提供的真实运行信息。 对 AI 产品，先限定任务和权限，再小范围观察，也能让后续扩大有依据。限制人数与限制能力是不同手段：邮件助手即使只有少量用户，错误发送也已经产生影响；先采用草稿模式，可以更直接地限制这类风险。 进入实际使用以后，系统没有报错，仍可能交出了错误结果。 Anthropic 的评测文章用订票作过说明：Agent 声称订好了机票，最终需要核对的是环境里有没有真实的预订记录。监控因此也要看任务结果，不能停在请求成功、响应正常。 
对简历 Skill，后续值得核对的是选出的模板是否真有借鉴价值，能不能承载真实内容，以及用户需要多大修改才能使用。关于上线后的这些表现，现有的单例运行记录还没有提供答案。 用户反馈可以补充线索，但没有投诉也可能是没发现错误，或者已经放弃使用。结果抽查与反馈需要一起看。发现问题后，有人判断影响、决定暂停哪项能力，再把确认过的失败留下，才有机会少犯同样的错误。 换模型或更新规则时，保留当时的配置与必要记录，方便追溯变化。 关闭新版本能阻止部分后续错误，却无法让已经发出的邮件消失。监控与补救能减少损失，事前该做的验证仍然得做。 再看那张成绩单 现在回头看，我仍然认为评测很重要。它帮助我们发现问题，也让不同版本之间的比较有了依据。 只是下次看到一个很高的分数，我会继续核对它测了什么、对应哪种使用条件，以及产品获准做哪些事。对于暂时拿不准的部分，可以缩小承诺，先把一段任务交付好。 我还没有找到适用于所有 AI 产品的交付标准。至少在自己接下来的项目里，我会在评测成绩之外，多检查一件具体的事：当任务无法完成、结果又无法确认时，产品能不能停下来，把已有进展和剩余问题交给人。
