AI 写用例，和测智能体，不是同一件事

功能测试刚接触「AI 测试」时，Feed 里会同时出现两种教程。一种是 B 站上播放量很高的「AI 写用例、AI 点界面、7 天精通自动化」。另一种是英文文档里的「给智能体做评测、在流水线里把门禁变红」。它们用了同一个「AI 测试」四个字，解决的痛点不是同一处。这篇只做对照，方便你决定先学哪条。不讲榜单，也不教攻击步骤。

各解决什么，不解决什么

播放量高，只说明标题击中了「传统测试会不会被淘汰」的焦虑。那些课程的目录通常是：测试基础、生命周期、pytest、再用模型生成用例或讲智能体架构。这是测试职场的入门，不是评测方法。顾翔在腾讯云写的智能体分层（规划、动作、反思）是方法文，和 B 站课程不是同一类。文中的效果倍数是作者自述，不能当成你能复现的数字。

用痛点选，不要用热度选

痛点是用例写不完、回归点不过来。 先走 B 站那条的方法，但把预期放低：模型适合根据需求文档列场景草稿、把你已经会的用例改成脚本骨架。你仍然要用等价类、边界值、错误猜测把草稿删一遍。生成的用例没有执行过，就不能写进「已覆盖」。它不解决「AI 功能说错了怎么办」。

痛点是已经有一个问答、客服、知识库或会调接口的机器人，测试环境里不敢发。 英文圈这条才对症。先不要学榜单。最小做法是：从真实问题和刚修过的 bug 抄 10 到 20 条输入；能用原句说清的用 Promptfoo 的 contains / not-contains；意思对不对、又拆不成关键词的，用 DeepEval 配人手写的 expected_output。轨迹（它调了哪个工具、参数是什么）是第二周的事。没有轨迹，你只能看见最终那句话，看不见它是不是调错了接口还碰巧答对。

两个痛点都有。 不要合成一门课。上午用模型起草传统用例，下午给对话接口加门禁。

三条容易混的话

「AI 自动生成测试用例」生成的是测试设计草稿。它没有运行被测系统，也没有证明这些用例能抓到缺陷。研究里已经有过这种结果：让智能体多写测试，最终问题并没有因此多解决。测试数量不是保障。

「用 AI 做 UI 自动化」解决的是脚本怎么写、元素变了怎么找。按钮从「确定」改成「提交」，模型也许还点得中。这和「回答是否符合退货政策」无关。界面绿了，对话仍可能承诺「随时可退」。

「测智能体」不是把传统用例换成英文工具名。智能体的失败常常是：最终答案对，工具选错；或者连续三轮之后把前面的限制忘了。只断言最后一句话，会放过这种失败。反过来，传统功能里那些确定的接口状态码、数据库落库，仍然用原来的断言，不要改成模型裁判。裁判更贵，也会自己漂。

转行的人怎么排第一周

1. 若你还没负责过一个会对话的功能，把时间花在原来的测试设计上。用模型当草稿员，人来删。这条线 B 站材料够用，挑有 pytest 和真实项目步骤的，跳过「学完即就业」。
2. 若你这周就要给一个问答或客服发版，忽略榜单和红队全量扫描。做一条门禁：Promptfoo 管必须出现和绝不能出现的句子，DeepEval 只留几条有手册依据的规则。做法见《功能测试的第一条 AI 门禁：Promptfoo 管死规矩，DeepEval 管答得像不像》（https://openqa.cn/articles/first-gate-deepeval-promptfoo ）。站点有静态缓存，刚发布时链接可能还打不开。
3. 门禁连续两周会真实变红、并且红的原因你分得清是产品错了还是断言写错了，再加轨迹和工具调用检查。在那之前，平台、多模型对比、完整红队都是在加报告，不是在加保障。

你现在可以做的一件事：写下你这周真正的痛是「用例来不及写」还是「对话功能不敢发」。是前者，就让模型起草 20 条用例然后亲手删掉一半。是后者，就从手册抄 10 句必须出现的话，放进 Promptfoo，先看到一次失败。