Skip to content

手工·场景与阶段

有些事 AI 给不出靠谱结论,就该人来——别上框架、别让 AI 跑

速查

  • 就该手工的场景:探索性「点点看哪不对」、UX 主观判断、需求验收走查、准入抽查复现、QA 深度验证、难自动化(视觉/手感/真机)
  • 适合阶段:需求早期走查 / 提测准入抽查 / QA 深度验证 / 发布前冒烟
  • 核心观点:这些场景别上框架、别让 AI 跑——人脑的判断力是这里的核心生产力,自动化反而碍事
  • 唯一例外:能稳定复现的回归别一直手工点 → 沉淀成自动化(让 AI 写成 spec 进回归网)
  • 别误会:手工不是「落后」「没时间写自动化的将就」,它是有自己最优场景的一等公民

我为什么坚持手工有不可替代的地盘

AI 时代有个很流行的错觉:「凡是手工的,迟早都该自动化掉。」我不同意。有一类测试,它的断言本身就是人的判断力——好不好用、像不像需求方脑子里想的、这个新页面有没有「看着就不对劲」的地方。这种判断你写不成 expect,也没法让 AI 替你拍板。硬把它自动化,等于把最值钱的环节阉割掉。

所以我的主张很直接:下面这些场景,别上框架、别让 AI 跑,就该手工。

就该手工的场景

探索性测试:让人自己点点看哪里坏

没有剧本地点点看——随便填、乱点、试边界、看哪里崩。它的价值恰恰在「意料之外」:你事先不知道哪会坏,所以写不出对应的自动化断言。

为什么不能让 AI 跑:AI(包括 MCP 驱动浏览器)只会按你给的剧本走。你让它「测登录」,它就规规矩矩走登录,发现不了「登录页 Tab 键焦点乱跳」这种你没提的问题。探索性的灵魂是发散,AI 是收敛,错配。

UX 主观判断:好不好用只有人知道

一个表单填起来顺不顺手、一段加载动画是不是太长让人焦虑、错误提示是不是说人话、整个流程绕不绕。这些没有客观断言,全是主观体验。AI 能告诉你「按钮存在、可点击」,但告诉不了你「这个按钮放这儿别扭」。

需求验收走查:像不像需求方要的样子

拿着需求文档(或者把需求方拉过来)走一遍真实流程,确认做出来的东西是不是需求方脑子里想要的那个。这是「正确性」之上的「合意性」——代码可能完全符合 spec,但 spec 本身理解偏了。这种走查必须人来,而且最好是懂业务的人。

准入抽查复现:QA 不直接信报告

研发提测附了自测报告,QA 不直接开测,先抽 3~5 个关键用例(优先鉴权反例、副作用分支、业务语义)本地复现,确认报告所述「全绿」属实。这一步是人对人的信任校验——抽查复现失败就直接退回,不进测试排期。AI 能帮 QA 跑这些用例,但「抽哪几个、信不信得过」是 QA 的判断。

QA 深度验证:业务语义而非 200 响应

准入通过后,QA 做的深度测试——业务语义(CRUD 产物 → 真实使用 → 验证生效,而不只是接口返 200)、集成、兼容性、跨角色数据权限。这些需要对业务的深入理解和「这里会不会有坑」的直觉,是 QA 最值钱的产出。

难自动化:视觉、手感、真机

像素级视觉还原、手势/拖拽的手感、真机上的性能与兼容(不同机型、弱网、刘海屏适配)。这些要么自动化成本极高、要么自动化根本测不出「人感觉到的那点不对」。真机上手点,比写一堆设备 farm 脚本实在。

各阶段怎么用手工

阶段手工做什么为什么不自动化
需求早期拿原型/早期实现走查,确认方向对不对还没定型,写自动化是浪费;要的是人的「合意性」判断
提测准入QA 抽查关键用例复现,核对自测报告「信不信得过」是人的判断;抽哪几个靠经验
QA 深度验证业务语义、探索性、集成、兼容最值钱的是人对业务的理解和找坑直觉
发布前冒烟上线前人工过一遍核心主流程临门一脚要人的「整体感觉对不对」兜底

唯一的例外:稳定回归别一直手工

我坚持手工有地盘,但有一条不能犯懒能稳定复现的回归,别一直靠手工点。

某个 bug 修了 → 每次发版都得手工验它没复发

   ▼ 这就是「稳定可复现」的信号

让 AI 把它写成框架 spec(带 fail-first 复现用例)→ 进回归网 → CI 天天跑

判断标准很简单:这件事每次都用同样的步骤、期望同样的结果吗?

  • → 它是回归,沉淀成自动化(见 AI 写框架用例),别让人肉重复点。每次发版手工重点一遍核心流程,又慢又漏,是纯浪费。
  • (每次关注点不同、靠判断、找意料之外)→ 它就该一直手工,自动化反而把它做死。

别把两件事搞反

  • 把「探索性 / 主观体验」硬塞进框架 → 测了个寂寞,断言不出「好不好用」
  • 把「稳定回归」一直手工点 → 人肉浪费,迟早漏 两种错配都常见。判断锚点就一句:这件事的断言是「人的判断」还是「固定的期望值」?

下一步