AI 测试开始被做成产品了：毕业生的第一个作品集，该往哪个方向选

关注 「软件测试就业联盟」公众号陪你走好校招求职的每一步有个计算机相关专业的毕业生问过我一个问题手上还有四个月【推断】的准备时间想做一份能写进简历、能在面试里讲三分钟【推断】、面试官能当场打开跑起来的测试方向作品集该选什么题。我给的回答和几年前不一样了。几年前我会说做一个自己的测试框架吧把请求封装、断言、报告、并发执行串成一条链看上去很完整。现在我不会这么说了。原因很直接AI 测试这件事正在被厂商做成产品、被开源社区做成工具。据界面新闻 2026-09-07 报道 2026 年服贸会期间发布的 XAgent提出「面向 AI Agent 时代重构软件测试质量命题」几乎同一时间阿里也开源了面向 Agent Skill 的评测工具 skill-up。这两条我都不展开讲细节公开报道的正文我并没有完整读到任何指标、覆盖范围、客户数量我都不会替它们编。我只把它当成一个方向性的信号来用这类能力已经有人在产品级和工具级上认真做了。信号落到毕业生身上结论有点扎心再去「造一个没人用的 AI 测试框架」差异化已经很薄了。面试官见过太多长得差不多的轮子。真正能被验证的是另一种东西。一、被产品化之后作品集的评价标准变了以前作品集的隐含评分标准是「广度」你用了多少技术、写了多少行代码、覆盖了多少模块。因为那时候能力本身是稀缺的你能自己搭起来就说明你会。现在这条标准失效了一部分。当一类能力已经被做成产品、做成开源工具「我也做了一个」传递的信息量就变小了。面试官脑子里会自动冒出一个问题你为什么不直接用现成的于是评价标准往另一个方向挪从「你会不会做」挪到「你判断得准不准」。判断准不准靠什么体现靠你有没有找到一个真实存在的问题并且给出了一个别人能一键复现的解法。请注意这里的关键词是可复现不是可运行。可运行是你自己电脑上能跑可复现是面试官在他自己电脑上、用你 README 里的一条命令能跑出同样的结果。这两者之间的差距正是绝大多数作品集被问穿的地方。二、三类方向摆在同一张表上看我把毕业生常见的三类作品集方向放在一起对照。先说结论再看表投入产出比最高的是第三类但它对「选题」这一步的要求也最高。对照维度造轮子型自研测试框架平台复现论文型复现某个评测方法解决真实痛点型具体场景的具体问题面试官可信度中低容易被追问「和现成的差别在哪」中学术味重工程可信度偏弱高痛点真实、解法可查、结果可对投入周期长四个月【推断】常常只做出半成品中容易卡在环境和数据复现上短到中四周【推断】就能出一个能跑的版本差异化程度低长得都差不多中但差异来自论文而不是你高场景是你自己挖出来的可验证性低强依赖作者本地环境低到中数据集与随机性难对齐高一条命令加一次真实运行记录面试可讲性弱只能讲功能列表弱到中容易被追问原理细节强三句话能讲清问题与结果表里最值得盯的一行是「差异化程度」。造轮子型的差异化低不是因为轮子做得差而是因为轮子的形状已经被市场定义过了你很难在别人的定义里做出不同。解决真实痛点型反过来场景是你自己找到的别人没法说你抄。三、为什么第三类在当前环境下性价比最高第三类的典型形态都很小给一个开源项目补一条能稳定跑的门禁给一类偶发失败写一个归因脚本把日志、时间、上下游依赖对齐到一张表里给一份数据集做一个质量校验工具把重复、缺失、异常值先扫出来再交给人看。它们小但都有一个共同结构一个真实场景 一个可观测的问题 一个能被别人复跑的解法。这三样凑齐作品集就从「展示我会什么」变成「展示我判断什么值得做」。而在 AI 测试被产品化的当下判断力的价值恰恰在上升。产品化解决的是通用能力通用能力越强剩下的问题就越靠近具体业务的具体细节那部分没人能替你做也正是毕业生能插进去的地方。反过来说选第一类你会和一个已经存在的成熟产品正面比选第二类你会和一篇论文的原作者比。这两种比法四个月【推断】的准备时间都不够用。四、可验证性四件套让面试官当场能验完选好方向只是一半另一半是让它可验证。我把它拆成四件套按面试官真实会动的顺序来排。第一件README 开头三行说清解决什么问题。不是项目简介不是技术栈清单就是三行这个场景里原来发生了什么、别人现在怎么办、你让它变成什么样。面试官平均只会给你 README 的前几行耐心。第二件一条命令能跑起来。make demo 或者一行脚本把装依赖、准备样例数据、执行、出结果全串起来。中间不要出现「请先手工配置某某」。第三件有 CI 徽章和一次真实的运行记录。徽章说明它不是只在你机器上绿过一次运行记录说明你真的跑过、真的看过输出。记录里最好留着一次失败和一次修复那比全绿更可信。第四件一段九十秒【推断】的演示。不用配音精致屏幕录制加几句话讲清楚「输入是什么、跑完看到什么」就够。很多面试官不会当场跑代码但会点开视频。四件套之外还有一条底线代码里要能看到测试而不是只有功能。你交的是测试方向的作品集如果仓库里全是业务脚本、一个测试文件都没有方向感立刻就散了。给自己的工具写几条测试甚至故意留一条能复现问题的用例都是加分项。五、把「可复现」写在明面上README 的开头我会这么写这是什么问题某个开源项目的检查只在合并后跑偶发失败要人工翻日志才能定位。现在怎么办维护者手工重跑失败原因散落在评论区里。变成什么样一条命令跑出门禁检查把偶发失败归因到一张表里。快速开始make demo # 装依赖 造样例数据 跑一次 出报告一次真实运行记录runs/2026-09-11.log # 里面留着一次失败和一次修复这段模板里没有一个技术名词在炫技全是「问题—现状—变化」。它的好处是面试官读完这三行就知道该问你什么而这些问题你全都提前准备过。配套的入口只留一条越短越好demo:pip install -r requirements.txtpython tools/make_sample.pypython -m gatecheck run --report reports/latest.mdecho “打开 reports/latest.md 看结果”写这段的时候踩过一个坑一开始把 demo 做成「跑全部用例」结果第一次执行要等很久对方直接关掉了页面。后来改成先跑一个小样例集几十秒【推断】出结果想跑全量的另开一条命令。演示路径必须短完整路径可以长。六、面试三分钟怎么讲三分钟的讲法建议按这个顺序排练别按你的开发顺序讲。第一句讲场景谁在什么时候遇到了什么。第二句讲判断为什么这个问题值得做而不是别的问题。第三句讲做法一句话说清核心机制不铺细节。第四句讲结果可复现的证据在哪请你打开哪个文件。剩下的时间留给对方追问。你会发现追问基本集中在两处这个痛点是不是真的你这套东西换个项目还能不能用。前者靠你选题时留下的证据issue 链接、日志片段、维护者的回复后者靠你把「场景相关的部分」和「可迁移的部分」在代码里分开哪怕只是分成两个目录。如果排练时你发现第一句要讲二十秒【推断】才说得清场景那说明选题太大回去砍。七、小而完整胜过全面最后回到开头那个问题四个月【推断】做什么。我的建议是做一个小到能在九十秒【推断】里演示完、但完整到能被陌生人一键复跑的东西。宁可只有一个场景也要把 README、一条命令、CI、运行记录、演示、测试这六样配齐。因为作品集不是用来证明你学了多少是用来证明你能不能把一件事收口。收口能力恰恰是产品化和工具化替代不掉的那部分。当 AI 测试开始被做成产品毕业生能拿出手的就不再是「我也做了一个」而是「我找到了一个还没人解决的具体问题并且让你能亲手验一遍」。你手上那份作品集现在是「能运行」还是「能被别人一键复现」卡在哪一步