DeepSeek扩招非AI研究岗：测试人的Skills该往哪练？

刷到“DeepSeek扩招，全部非AI研究方向”，一个在职测试人的脑内小剧场，大概能连演三集。

第一集：终于轮到有工程经验的人了？

第二集：点开岗位——服务端开发、Agent弹性计算……等一下，测试呢？

第三集：招聘页面关了，回归报告还没写完。

最扎心的地方就在这里。

AI公司的招聘消息，你一条没少看；新工具，你也收藏了不少。但真要问一句“这次机会，我凭什么接得住”，答案又卡住了。

尤其是已经工作几年的人：白天跟需求，晚上跑回归。想换工作，又怕自己离开熟悉的业务，就只剩下“熟练使用各种测试工具”。

DeepSeek这次扩招，恰好值得拿来回答一个问题：过去几年的测试经验，怎么才能在AI项目里继续算数？

先把新闻里的信息说准确。

据界面新闻9月8日报道，DeepSeek本轮招聘约150人，主要面向有2至10年经验的工程师，集中在服务端开发、Agent弹性计算两个岗位序列。

“全部非AI研究方向”，指这轮专项招聘的岗位结构。DeepSeek招聘官网仍列有深度学习研发等岗位，不能据此理解为停止招聘研究人员。

还有一点和测试人直接相关：这两个序列是开发岗位，也不能直接翻译成“DeepSeek大规模招聘测试工程师”。

但把招聘页关掉之前，有些东西值得多看一眼。

招聘单上的工程问题，为什么让测试人觉得眼熟？

报道列出的方向里，有Agent框架组件、研发效率基建、API、线上服务。

你可能没训练过大模型。

但接口一多，哪个环节容易超时；任务一重试，会不会执行两遍；版本一升级，会不会把老功能带崩——这些问题，你未必陌生。

换个场景，你就更熟悉了。

想象一次AI功能上线评审：

产品演示得很顺：“用户说一句话，系统就能自动查订单、判断规则、处理售后。”

研发补充：“工具已经接上了。”

大家开始讨论什么时候上线。

然后，测试问了四句话：

“用户中途改主意呢？”

“接口超时，但后台其实执行成功了呢？”

“换个账号，能不能操作别人的订单？”

“明天换模型，今天测过的还算数吗？”

会议突然安静了。

这只是一个假设场景，但里面的分歧很真实：演示已经证明“有机会做成”，上线却需要回答“什么情况下会做错，做错后怎么发现和处理”。

一个功能接上真实用户之后，你以前追过的那些异常分支，就重新有了分量。

这是我从这轮工程招聘中读出的信号：AI系统越深入实际业务，围绕交付、稳定性和质量的工程工作，就越值得关注。

这不等于某个岗位必然涨薪，更不意味着工作年限可以直接兑换机会。

你需要做的，是把经验落到新系统里。

在职测试人最容易吃亏的，是AI学了一圈，项目还是讲不出来。

你可能已经让AI写过用例，补过脚本，也装过几个Skills。

可面试官继续往下问：

“AI生成的用例，漏了关键规则怎么办？”

“它写的断言，和业务需求不一致怎么办？”

“你说提效了，原来要多久，现在要多久？返工算进去了吗？”

这时候，截图里的长篇输出帮不上多少忙。

对在职工程师来说，时间尤其经不起这种消耗：新名词越记越多，简历里的项目却一直停在上一家公司。

你更需要一件能讲清楚的事：

我发现了什么风险，用什么方法复现，如何证明修复有效，又怎样防止它下次再出现。

下面就拿一个问题，把这件事讲透。

退款Agent说“成功了”，测试能直接通过吗？

以下是用于说明测试方法的原创业务示例，不是DeepSeek内部项目。

假设你们做了一个售后Agent：用户提出退款申请后，它可以查询订单、校验资格，再调用退款工具。

看起来已经形成闭环。

现在加一个异常条件：

退款服务已经受理成功，响应却在返回途中丢失了。Agent只看见超时，于是决定再试一次。

这时，“自动重试”到底是在恢复服务，还是在制造第二笔退款？

如果你以前测过支付、订单或者消息重试，应该已经想到：幂等。

同一笔业务重复请求，不能重复产生退款效果。

可到了Agent系统，测试还要往前追一层：重试时，它是否仍然使用同一个退款申请标识？会不会自己换一个标识，绕开了原有的去重机制？

所以，这个场景至少要看三类证据：

• **执行过程：**调用了哪些工具、传了什么参数、为什么重试。
• **业务结果：**退款记录、订单状态和账务结果是否一致。
• **用户回复：**系统到底已完成、仍在处理中，还是需要人工核查。

一条看起来很专业的“退款成功”，不能替代这些检查。

还有一个容易写错的断言：

“退款接口只能调用一次。”

这未必合理。系统可能允许携带同一幂等标识安全重试。

真正要守住的是业务结果：符合条件时完成退款，同一申请只生效一次；不符合条件时，没有发生退款。

从“检查接口有没有返回”走到这里，测试经验就已经开始进入AI系统的实际工作了。

Skills、Agent和自动化测试，可以在这里接起来。

Agent负责结合上下文推进任务、调用工具。

Skills可以把团队的任务说明、操作步骤、脚本和参考资料组织起来，供Agent按需使用。

例如，把售后测试中的业务规则、常见异常和检查脚本整理成一个Skill，帮助Agent准备测试数据、执行检查、输出报告。

但“退款前确认资格”“超时后先查状态”，即使写进了Skill，也仍然只是给Agent的操作指引。

退款资格、权限和幂等，需要业务服务真正执行；测试负责验证这些约束能否守住。

这也回答了标题的问题：测试人的Skills，应该围绕可验证的业务任务来练。

拿这个退款Agent来说，你完全可以把过去的测试积累接上来：

当然，原来的技术底子仍然需要：Python、接口、数据库、日志、基本工程能力，一个都不是靠改简历关键词就能补齐的。

区别在于，你现在有了明确的练习对象。

今晚如果只有一小时，就从一个异常用例开始。

不用先给自己列几十个工具。

找一个熟悉的业务，例如售后、审批或者工单，搭一个本地模拟环境。只做一条正常路径，再加一条容易出错的异常路径。

仍以退款为例：

正常路径，合法申请最终完成退款。

异常路径，模拟“后台成功、响应超时”，检查重试后是否只产生一笔退款。

先把成功标准写出来，再执行，再保存证据。

接下来几次练习，再逐步加入越权订单、规则缺失、用户改口，以及模型或Skill版本变化。

同一场景要重复运行，每次重置测试数据，保存模型标识、提示词和Skill版本、工具调用记录及最终状态。这样才能比较结果，避免前一次执行留下的数据影响后一次判断。

如果你让另一个模型给答案打分，也要抽样人工核对。关键业务结果能用程序判断，就优先写成明确的检查规则。

做到这里，你手上会多出一份比“安装了十个Skills”更具体的东西：一组场景、一套检查方法、一份失败记录，以及修复前后的对比。

它们也能进入你的面试表达。

完成实践后，你可以这样介绍：

我做了一个售后Agent测试练习，重点验证退款工具超时后的恢复行为。我对照工具调用记录和业务数据检查重复退款，并把异常场景加入回归，比较不同版本的执行结果。

这是学习项目，就明确说是学习项目。做出了什么、还缺什么，讲清楚，比编一个无法追问的企业项目更有说服力。

你会发现，后续需要补的知识也开始具体了：幂等键怎么设计，异步状态怎么等，失败结果怎么分类，回归怎么接进流水线。

每补一项，都能回到项目里用上。

下次再刷到AI公司的招聘，你可以少停留一会儿在“它是不是在招测试”，多看一眼：

它要解决的工程问题里，有哪一个，我已经能拿出证据讲清楚？

这份底气，可以从你最熟悉的一个老Bug开始积累。

你们团队接入AI后，最让你头疼的是哪一种：用例看着很多却漏规则、脚本跑过却没测对，还是Agent执行结果不好复现？欢迎在评论区聊聊具体场景。