有个计算机相关专业的毕业生问过我一个问题：手上还有四个月【推断】的准备时间，想做一份能写进简历、能在面试里讲三分钟【推断】、面试官能当场打开跑起来的测试方向作品集，该选什么题。
我给的回答，和几年前不一样了。几年前我会说：做一个自己的测试框架吧，把请求封装、断言、报告、并发执行串成一条链，看上去很完整。现在我不会这么说了。
原因很直接：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.txt
python tools/make_sample.py
python -m gatecheck run --report reports/latest.md
@echo "打开 reports/latest.md 看结果"
写这段的时候踩过一个坑：一开始把 demo 做成「跑全部用例」，结果第一次执行要等很久，对方直接关掉了页面。后来改成先跑一个小样例集，几十秒【推断】出结果，想跑全量的另开一条命令。演示路径必须短，完整路径可以长。
六、面试三分钟怎么讲
三分钟的讲法，建议按这个顺序排练，别按你的开发顺序讲。
第一句讲场景：谁在什么时候遇到了什么。第二句讲判断：为什么这个问题值得做，而不是别的问题。第三句讲做法：一句话说清核心机制，不铺细节。第四句讲结果：可复现的证据在哪，请你打开哪个文件。
剩下的时间留给对方追问。你会发现追问基本集中在两处：这个痛点是不是真的，你这套东西换个项目还能不能用。前者靠你选题时留下的证据（issue 链接、日志片段、维护者的回复），后者靠你把「场景相关的部分」和「可迁移的部分」在代码里分开，哪怕只是分成两个目录。
如果排练时你发现第一句要讲二十秒【推断】才说得清场景，那说明选题太大，回去砍。
七、小而完整，胜过全面
最后回到开头那个问题：四个月【推断】，做什么。
我的建议是，做一个小到能在九十秒【推断】里演示完、但完整到能被陌生人一键复跑的东西。宁可只有一个场景，也要把 README、一条命令、CI、运行记录、演示、测试这六样配齐。
因为作品集不是用来证明你学了多少，是用来证明你能不能把一件事收口。收口能力，恰恰是产品化和工具化替代不掉的那部分。
当 AI 测试开始被做成产品，毕业生能拿出手的，就不再是「我也做了一个」，而是「我找到了一个还没人解决的具体问题，并且让你能亲手验一遍」。
你手上那份作品集，现在是「能运行」还是「能被别人一键复现」，卡在哪一步？
