简历写“做了大模型应用”，不如展示一次失败样本怎样进入回归集

不少校招项目的结构都一样：接一个模型API，做一个聊天页面，再放几张“回答正确”的截图。面试官真正追问时，候选人却说不清换模型、改Prompt或更新知识库后，怎么证明系统没有退步。

Apple在WWDC26介绍Evaluations框架时强调，生成式AI打破了“同样输入必得同样输出”的传统单测契约，需要通过评测驱动开发持续改进。你不必复刻Apple平台，也能把这套思想做成一个应届生可完成的AI测试项目。

项目目标：不是做聊天机器人，而是做质量闭环 

选择退款客服Agent作为业务。规则只保留四条：无订单号先追问；订单不属于用户要拒绝；超过退款时间说明原因；工具超时最多重试一次。Agent本身可以很简单，项目价值在于怎样证明规则持续成立。

最小目录和模块 

cases保存20条正常、边界和失败请求；agent实现知识检索与退款工具；traces记录文档命中和工具调用；evaluators包含确定性断言与语义评分；reports比较基线版本和候选版本；CI运行评测并阻断红线失败。

每条用例不固定整段答案，而是定义必须出现的事实、禁止动作和预期工具。例如缺订单号时可以有不同问法，但不得直接执行退款。

def test_missing_order_id(run):
    assert run.trace.count('refund_order') == 0
    assert run.follow_up_fields == ['order_id']
    assert run.final_status == 'need_more_info'

做一次真实迭代，项目才像工程 

第一版只判断最终回答，结果Agent说“请提供订单号”但后台仍调用了退款工具。第二版加入Trace断言，发现了行为问题。第三版给工具加幂等键和权限校验，再把这条失败样本加入回归集。

保留三次报告：改了什么、哪条用例从通过变失败、如何定位、修复后有没有伤害其他场景。面试时，这条迭代链比一张漂亮架构图更有说服力。

报告至少展示四个维度 

业务规则通过率、危险工具误调用数、重复运行稳定性、平均延迟与成本。总体分数可以变化，但越权退款、重复执行等红线必须为零。换模型时使用同一数据集和工具模拟器，避免环境差异污染结论。

简历怎么写 

“设计退款Agent持续评测项目，维护20+业务与失败用例；基于Trace校验知识引用、工具选择、权限和幂等行为，通过CI比较Prompt/模型版本并阻断高风险回归。”

这句话的每一部分都应能现场演示。面试官若问语义评分不稳定怎么办，你可以回答：业务红线使用确定性断言，表达质量才交给模型裁判，并用人工抽样校准。

面试可能继续追问什么 

为什么不用答案相似度；如何防止评测集污染；线上新Badcase怎样进入回归；工具调用有多条合法路径时怎么写断言；模型成本下降但风险上升是否发布。准备这些问题，你展示的就不是“会调用API”，而是具备AI测试开发的完整思路。

校招项目不需要大而全。只要一个真实业务、一组能失败的用例、一条可回放Trace和一次有证据的版本改进，就足以和普通聊天Demo拉开差距。

数据集怎样避免只包含“你已经会修”的题 

把用例分为固定回归和隐藏挑战两部分。日常调Prompt只看固定回归；发布前再跑隐藏样本，防止不断针对已知答案调参。线上出现新Badcase时先归因，再选择是否加入固定集，避免同一种问题重复堆几十条。

每条样本记录来源、业务规则版本和最后更新时间。退款政策变化后，旧期望不能继续参与评分。面试时能讲清数据治理，会比单纯展示更多用例更加分。

给项目加一个人工校准环节 

随机抽取模型裁判判定的通过与失败各5条，由人工按同一Rubric复核。若分歧集中在“回答是否清楚”，可以改进语义评分；若分歧涉及退款资格，就应把规则改成确定性断言。

这一步能回答面试官常问的问题：你怎么知道评测器本身是对的？答案不是模型更强，而是业务红线程序化、主观维度有人类校准、分歧会持续回写。

项目最终展示顺序也很重要：先演示一个漏检，再打开Trace定位，随后展示新增断言和版本对比，最后让CI阻断回归。四分钟内讲清一次质量闭环，比十分钟介绍技术栈更容易让人记住。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。