你以为在做测试，其实在被 Skills 替代

前几个月，有个做了五年自动化测试的工程师在私信里问我：

“我现在写的自动化脚本，AI 三分钟就能生成一份差不多的。我的价值到底在哪里？”

我没有立刻回复他。

不是因为我不知道答案，而是因为他的问题背后藏着一个更扎心的真相——很多测试工程师正在做的事情，表面上是“测试”，实质上是在执行一套高度可预测、高度可模式化的操作流程。而这，恰恰是 AI Skills 最擅长的领地。

这篇文章不是来恐吓你的。但我想帮你看清楚，到底哪些工作正在被替代，哪些不会，以及你现在应该做什么。

一、Skills 是什么，为什么它比你想象的更危险

1.1 不是“更聪明的脚本”，而是“会思考的同事”

很多人第一次听到 Skills 这个词，会下意识地把它归类为“自动化工具”——就像 Selenium、Cypress 那类东西。这个理解是错的，而且这个误解会让你低估它的威胁。

Skills 本质上是封装了领域知识 + 执行逻辑 + 输出规范的 AI 能力单元。它不是在按规则执行，它是在理解意图后做决策。

打个比方：

• 传统自动化脚本像一台数控机床——你告诉它走哪条路，它严格执行，出了路线它就停下来报错。
• Skills 更像一个上岗第一周的新员工——你把需求文档扔给他，他会自己理解、自己拆解、自己输出一份测试方案，虽然不完美，但已经能用。

而这个“新员工”，不睡觉，不请假，不会因为赶 deadline 而漏掉边界用例。

1.2 Skills 的能力边界在哪里

坦白说，现阶段的 Skills 并非无所不能。它的能力边界大致如下：

它擅长的：

• 从结构化输入（接口文档、PRD、数据库 Schema）生成覆盖全面的测试用例
• 系统性地推导边界值、等价类、异常路径
• 识别代码变更范围，推荐回归测试集
• 根据历史 Bug 模式推断高风险区域
• 跨模块、跨系统地追踪测试覆盖盲区

它目前还做不好的：

• 理解高度隐性的业务规则（没有写进文档的“潜规则”）
• 判断某个 Bug 的业务影响优先级
• 在复杂的分布式系统中做全链路的因果推断
• 感知“用户体验”层面的问题（某个交互让人觉得别扭，但功能上没错）

注意：这个“做不好”的列表，正在以每季度为单位快速收缩。

二、被替代的，不是“测试”，是“测试里的体力活”

2.1 一个诚实的自我诊断

我想请你做一个思想实验。回顾你上周的工作，把每一项任务写下来，然后问自己一个问题：

这件事，如果给一个“读过所有相关文档、了解所有历史 Bug”的 AI，它能做到 80 分吗？

你可能会发现，大部分日常工作的答案是“能”。

不是因为你不优秀，而是因为测试工程这个领域，长期以来有相当大比例的工作处于一种奇怪的状态：它需要人来做，但它本质上并不需要“人的判断力”来做。

这部分工作，我把它叫做测试工程的体力层。

2.2 测试工程的三个层次

为了说清楚哪些在被替代、哪些不会，我想引入一个分层框架：

生产层：机械性的输出工作。写用例、跑回归、生成测试报告。Skills 已经可以在这一层做到 70-85 分，而且还在提升。

执行层：需要一定判断力的协作工作。这一层是当前的过渡地带——Skills 能辅助，但还需要人来把关和补充上下文。

策略层：需要深度业务理解和全局视角的决策工作。这是目前 AI 最难触及的地方，也是测试工程师真正的护城河所在。

2.3 一个残酷的现实

问题在于：很多测试工程师（包括工作了好几年的）绝大多数时间都停留在生产层，偶尔进入执行层，极少触及策略层。

这不是他们的错。这是行业长期以来对测试工程师定位的结果——“写好用例、跑好回归、提好 Bug”就够了。

但这个定位，在 Skills 出现之后，正在快速失效。

三、3个真实场景，看清被替代的路径

场景1：接口测试用例的“一键生成”

背景：某电商平台，商品搜索接口，参数包括关键词、分类 ID、价格区间、排序方式、分页参数，共 12 个字段。

传统做法：测试工程师逐字段分析，手写等价类、边界值、组合场景，最终产出约 80 条用例，耗时 4 小时。

Skills 做法：

把接口的 OpenAPI 文档（或者直接把接口定义代码）投喂给配置好的 Skill，5 分钟内输出：

用例编号 | 场景描述                          | 关键入参                     | 预期结果          | 优先级
TC-001  | 正常搜索：关键词有效，返回结果列表    | keyword="手机",page=1       | 200, list非空     | P0
TC-002  | 关键词为空字符串                     | keyword=""                  | 400, 错误提示     | P1
TC-003  | 价格区间上限小于下限                  | price_min=200,price_max=100 | 400, 参数错误     | P1
TC-004  | 分页超出总页数                        | page=99999                  | 200, list为空     | P2
TC-005  | 关键词含 SQL 注入特殊字符             | keyword="' OR 1=1--"        | 200, 安全过滤生效 | P0
...（共 94 条）

测试工程师的工作变成：审查 AI 有没有理解错业务规则（比如“价格区间为空时是否等同于不过滤”这类隐性规则），然后补充 2-3 条 AI 没有覆盖的场景。

结论：用例生成这件事，基本已经被替代。测试工程师在这个环节的价值，从“生产者”变成了“质检员”。

场景2：版本发布前的回归范围判断

背景：某 SaaS 产品，本次发版涉及 3 个模块的代码改动，共 47 个文件变更。测试资源有限，需要在 2 小时内完成回归。

传统做法：测试工程师看变更列表，凭经验判断影响范围，挑选用例手动执行。容易出现：改了 A 模块，没想到 B 模块有依赖，B 出问题了。

Skills 做法：

结合代码变更分析（Git diff）+ 模块依赖图 + 历史 Bug 数据，Skills 输出：

本次变更高风险影响区域：
1. 订单结算模块（直接变更）
   → 推荐回归用例：TC-201 到 TC-230（30条）
2. 优惠券核销模块（与订单结算有强依赖）
   → 推荐回归用例：TC-441, TC-445, TC-448（3条高频历史Bug场景）
3. 用户账单查询（数据层共享，变更可能影响展示）
   → 推荐回归用例：TC-512（1条，低优先级，可酌情跳过）
预计执行时间：约 1.5 小时
历史缺陷逃逸风险：低

测试工程师需要做的：确认这个判断是否遗漏了某个他们了解但 AI 不了解的业务耦合点。

结论：回归范围判断这个“有含金量”的工作，也开始被 Skills 辅助甚至主导。

场景3：一个 Skills 还做不了的案例

背景：某金融 App，新上线了一个“智能理财建议”功能，根据用户资产情况推荐产品组合。

测试工程师发现的问题：某用户资产为 0，系统推荐了一款“最低投资门槛 1000 元”的产品，且没有任何提示。功能上没有报错，数据上没有异常，但这是一个严重的产品体验问题，甚至可能涉及合规风险。

Skills 的局限：这类问题需要测试工程师理解“什么是合理的用户预期”、“金融产品推荐的合规边界在哪里”——这不是从文档里能读出来的，需要业务感知和行业经验。

AI 可以帮你生成“资产为 0 时调用推荐接口”的用例，但它不知道返回结果是否合理，除非你明确告诉它判断标准。

结论：这正是策略层的价值所在——知道“什么是对的”，而不仅仅是“执行是否正确”。

四、你现在应该做什么

4.1 不要等，现在就开始用 Skills

这是最重要的一条建议，而且很多人做反了。

有人觉得：“等 AI 更成熟了我再研究。” 这个逻辑是错的。因为现在用 Skills 的人，正在建立的是驾驭 Skills 的能力——知道如何配置它、如何审查它的输出、如何把自己的业务知识注入进去。这个能力，三个月后会成为核心竞争力。

入门三步：

1. 选一个你最熟悉的模块，尝试让 AI 生成测试用例草稿，然后做一次严格的人工审查，记录它遗漏了什么、错在哪里。
2. 把那些“遗漏”和“错误”整理成规则，写进你的 Skill 配置——这就是在把你的经验变成可复用的资产。
3. 重复这个过程，直到这个模块的 Skill 成熟到可以让你放心做质检而不是从头写。

4.2 把时间从生产层迁移到策略层

如果你现在每天花 6 小时写用例、跑回归，目标是在接下来三个月内，让 Skills 承担其中 4 小时的工作，而你把那 4 小时用在：

• 理解业务：深入理解你负责模块的业务逻辑，尤其是文档里没写清楚的隐性规则
• 建立测试策略：为团队制定测试覆盖率标准、风险分级方法、回归策略
• 积累领域知识：把历史 Bug 系统性地整理，找出模式，形成“高风险区域地图”

这些事，Skills 不会做，但 Skills 的输出质量高度依赖于做过这些事的人来配置和把关。

4.3 成为团队里的“Skills 架构师”

这是一个正在出现的新角色，虽然目前还没有正式的职位名称。

它的核心职责是：设计、维护、优化团队使用的 Skill 体系。

具体来说：

• 为不同业务模块设计专属 Skill，注入业务规则和历史经验
• 建立 Skill 的版本管理机制，像维护代码一样维护 Skill
• 定期评审 Skill 的输出质量，迭代优化
• 把新人的上手成本从“学 3 个月业务”降低到“学 1 周 Skill 怎么用”

这个角色，需要的恰恰是传统测试工程师最擅长的东西——对业务的深度理解、对质量的高标准、对异常场景的敏感度。只不过，它的工作方式从“亲自做”变成了“让 AI 做、自己把关和优化”。

五、一个值得认真对待的长期趋势

5.1 Skills 的进化速度超出大多数人的预期

我想用一个数据来说明这件事的紧迫性。

两年前，AI 写出来的测试用例基本只能用作“参考”——逻辑混乱、遗漏严重、格式随意。今天，一个配置得当的 Skill，在结构化输入的情况下，可以做到 80 分以上的覆盖率，而且输出格式可以直接导入 Jira、TestRail 等测试管理工具。

按这个速度，两年后的 Skills，能做到什么程度？这不是一个可以“再等等看”的问题。

5.2 被替代的是岗位职责，不是这个人

这里有一个重要的区分：Skills 替代的是测试工程师职责描述里的某些任务，而不是测试工程师这个人的所有价值。

一个对业务有深度理解的测试工程师，在 Skills 出现之后，能做的事情只会更多，能产生的影响只会更大——因为他不再被繁琐的用例写作所困，他的时间可以全部投入到真正需要人类判断力的地方。

但一个只会“写用例、跑回归”的测试工程师，确实面临着岗位价值被稀释的风险。

这是一次行业洗牌，而洗牌对有准备的人来说，是机会。

结语

回到开头那个私信问题：“我的价值在哪里？”

我现在可以给他一个完整的答案：

你的价值，不在于你能写多少用例、跑多少脚本。你的价值在于：你知道什么东西值得测、知道某个 Bug 会伤害多少用户、知道在 AI 输出的 100 条用例里哪 3 条最重要——这些判断，需要你在这个产品上积累的所有经验和业务感知。

Skills 正在接管测试工程的生产层。这是不可逆的趋势。

你有两个选择：等着被替代，或者主动把自己变成那个能驾驭 Skills、让 Skills 产生十倍价值的人。

后者，才是接下来三年真正稀缺的能力。