从手工 QA 到 agent QA：哪些能力真正能迁移

结论

决定测什么，仍然稀缺，agent 在这件事上不稳定。等价类、边界值、基于风险的优先级，以及一份让别人能行动的缺陷报告，这些可以从手工测试原样带走。执行变便宜之后，它们更贵，而不是更便宜。

不再有回报的，是把时间卖在重复点击上，以及用手工维护一堆脆的、绑死定位器的套件。

哪些能力原样迁移

测试设计。 划分等价类、找边界、决定哪条路径代表一批输入。模型可以列出候选，但不能替你承担「漏了这一类，上线会怎样」。把设计写成清单，agent 才能执行；没有清单时，公开评测里的网页测试任务，领先模型的 F1 往往过不了可用线。有人把「没有人工清单时低于 30% F1，给了清单之后 Claude Sonnet 4.5 约 49.2%」当作 2026 年的说明。这组数来自单一架构评论，只说明方向：agent 是执行者，不是计划者。不要把 49.2% 写进招聘标准。

风险排序。 支付、权限、数据导出，和改一个文案，不是同一优先级。agent 默认把所有失败都喊成红色。人的工作是规定什么阻塞发布。

缺陷报告。 复现步骤、实际结果、期望结果、影响面、环境。agent 生成的报告常常把日志贴满，却不写用户影响。审报告的能力因此还在。

探索式提问。 「如果中途断网」「如果权限在第二步被收回」。这些问题来自领域，不来自覆盖率百分比。

哪些工作应停掉

• 按脚本把同一条回归每天点一遍。这条路径交给流水线。
• 为每个小改动重录选择器。选择器维护如果占了你一周的大部分，说明套件的抽象错了，不是你还不够勤奋。
• 用「我跑过了」当作证据。证据应是可重放的命令、产物和判定规则。

一条走得通的转型

不要先把自己改名为「提示词工程师」。先成为规定质量门禁的人，再把门禁写成技能。

1. 写出发布前必须绿的检查：哪几类失败阻塞，哪几类只记录。
2. 给每条检查一个验收阈值和证据位置。例如：拒答题的失败率单独统计，不和忠实度平均。
3. 把判定写成技能或流水线，让团队的 agent 执行，人只看失败和抽检。
4. 每月复盘一次误报。门禁如果人人绕过，问题在阈值，不在执行者。

手工测试的资历在这里的用法，是你知道哪些检查曾经放过真正的事故。把它写成规则，比把它留在个人经验里有用。

和团队沟通时可以怎么说

「我不再负责把 2,000 条用例点完。我负责这 2,000 条里哪 30 条失败就必须停，以及失败记录是否够别人修复。」这句话能被排期，也能被评审。

材料边界

文中的 F1 数字只作为二手评论中的方向性例子，出处是 2026 年 5 月 TestQuality 对 Playwright agent 架构的综述，不是独立复现。其余是测试设计的既有实践，不依赖某一家模型的榜单。