企业招人，不再看“会不会写代码”了

有个准备跳槽的朋友，最近把自己2023年投简历时保存的秋招JD和今年春招的JD并排放在一起看，然后把截图发给我，只说了一句话："这还是同一个岗位吗？"

2023年那份JD上写着："熟悉自动化测试框架，有Python编程经验。"简简单单两行字，是那几年测试岗位招聘的标准模板。而今年的JD，同样是测试开发方向，字节跳动的岗位要求里多了一条硬性条件——"对AI Agent有深入理解和实践经验"；阿里通义实验室的测试开发岗位则要求"熟练掌握机器学习算法原理"；另一家大厂的质量工程师岗位JD里，直接写着要"熟悉大模型应用工程化全流程（Prompt Engineering / RAG / Agent框架 / 向量数据库 / 对话状态管理等）"，还特别注明"具备质量保障场景AI落地案例者优先"。

两年时间，同一个岗位名称，招聘要求几乎换了一套语言体系。这不是个别公司的个例，而是一场正在发生的、行业性的招聘逻辑重构。

一、能力模型是怎么变的

要看懂这场转变，得先看懂它背后到底在考察什么。2023年那份JD考察的，本质上是"执行能力"——你会不会用某个工具、熟不熟悉某个框架、能不能按照既定流程把测试用例跑起来。这套能力模型的假设前提是：业务需求已经拆解好了，你只需要把它准确地实现出来。

而今天的JD考察的，是"落地能力"——你能不能把一个模糊的业务问题，转化成AI能理解、能执行的具体任务，再把AI给出的结果，判断出是否真正解决了业务问题。前面提到的那份质量工程师JD里，有一句话把这个转变说得很直白："从功能测试向价值交付的质量转型"。这句话背后的逻辑是，企业不再满足于"测试用例跑完了、没报bug"这种执行层面的完成度，而是要求测试这个职能，直接对最终的业务价值负责。

这种转变落到具体的能力项上，大致可以拆成三层。第一层，是"会用"AI工具的基础操作能力，这是入场券，几乎所有新JD都会提到，门槛已经不高。第二层，是"会设计"——知道怎么把一个业务场景拆解成AI能处理的任务，比如把"这个新功能有哪些潜在风险"这样模糊的问题，转化成AI能生成对抗性测试场景的具体指令。第三层，也是真正拉开薪资差距的一层，是"会判断"——面对AI给出的输出，能不能一眼看出哪里可能有问题，能不能对AI的判断做二次校验。前面提到的那份质量工程师JD里就明确写到，要"通过构建自动化基准评测集、LLM-as-a-judge等手段，量化模型推理效果，解决AI应用带来的不确定性质量挑战"——说白了，就是要有能力去评判AI本身靠不靠谱，这已经不是执行者的活，是更接近架构师的活。

二、简历和面试话术该怎么改

一个具体的转型建议是，先别急着把简历上的技术栈全部换成"大模型"、"Agent"这些新词，那样反而显得空洞。更有效的做法，是把过去的项目经验，用新的能力框架重新包装一遍。

比如，过去简历上写"负责某模块的自动化测试用例编写和维护"，这句话对应的是第一层的执行能力，在今天的筛选逻辑里几乎不加分。可以试着往第二层、第三层靠：如果你确实用AI工具生成过测试场景，就具体写清楚"设计了什么样的业务约束条件、AI生成了多少场景、你人工筛掉了多少、为什么筛掉"，这个描述展示的是"会设计"和"会判断"的能力，而不只是"会用工具"。

面试环节同样如此。与其笼统地说"我熟悉AI辅助测试"，不如准备一个具体的案例，讲清楚一次真实的判断过程——比如AI生成的某个测试结论，你是怎么发现它其实有问题的，判断依据是什么。这类具体的判断案例，往往比罗列工具名称更能打动面试官，因为它证明的是招聘方现在最想要的那种能力：不是会不会用AI，而是能不能对AI的产出负责。

结尾

那位朋友后来把简历按这个思路重新改了一遍，没有堆砌任何新概念词，只是把过去几个项目里"自己做判断"的细节写得更具体了。他后来告诉我，面试官第一反应不是问他会不会用某个AI工具，而是顺着他写的判断案例，接连追问了好几个细节。

这场招聘逻辑的转变，说到底不是要求每个人都变成算法专家，而是在重新划定一条更本质的能力分界线：过去比拼的是"你会不会做"，现在比拼的是"你能不能对结果负责"。这条线一旦想清楚，简历该怎么改、面试该讲什么案例，答案自然就清晰了。