我是看出来了，第一你是真闲，能写这么多。第二你这套理论受众也确实多，都比较同意 “软件测试不是一场永远追逐新工具的竞赛，也不是一场用技术给同行排座次的游戏。”，也就是说明了真的有很多人被新工具伤害到了。
我也被伤害过，但是我运气好，挺过来了。
AI 的发展特别快，包括你举的例子：
“他问了几个问题。
第一，系统推荐执行的测试，依据是什么？如果需求本身存在遗漏，或者变更影响分析不完整，系统如何发现那些没有被识别出来的风险？
第二，AI 可以调整自动化操作，但它调整之后，如何证明测试仍然验证着原来的业务规则，而不是为了完成任务，绕开了原本应该检查的条件？
第三，发布页面上的质量结论，是建立在完整、可信的验证证据上，还是只是把现有工具的执行结果汇总到了一起？”
我觉得都是一年前的困惑了，现在早就不是在研究这个了（甚至 deepseek 4.1pro 都已经突破这些问题了），大家还是要真的用起来 AI，来面对一些更有挑战的问题。
我更喜欢能实际落地的文章，这篇空谈太多，我自己不喜欢，耽误大家喜欢了，不好意思。

评价一个事物好不好，是要看长期的量化结果，一个特例就开始否定了不是什么好习惯。
AI 时代，最值钱的不是代码了，而是 AI 的规则。
说了这么多，都是在说 AI 的结果不可信，这本质上是 AI 的规则不可信，是要优化规则，我觉得更有价值的是把之前 AI 规则差在哪里，发现问题之后 AI 规则怎么迭代的更好，你对规则的认识有了什么上升，而不是在这唱衰和抱怨。
没想到这么久了大家还没认识到这个。

这篇文章最核心的一句话是：AI 可以帮测试人员干活，但 “该测什么、怎样才算对、值不值得这样测”，仍然需要人判断。

1. 作者一直想让机器自己完成测试，但每前进一步，都会发现新的困难。

他的经历大致是：

• 最开始用自动化工具操作界面，发现有些控件操作不了。
• 改成识别图片、模拟点击，能操作了，但界面稍微变化就容易失效，维护很累。
• 再尝试让 AI 自己探索操作，又遇到训练数据、计算资源和效果不稳定的问题。
• 后来用大模型生成测试脚本，发现模型会写错；为了提高可靠性，又需要人整理场景和规则。 这个故事要说明的是：生成或执行脚本只是测试的一部分，真正难的是让它持续、可靠地解决实际问题。 作者分享的是这一路的尝试和代价。

1. 技术先进，不代表适合你的问题。

作者反复强调，要看实际场景、成本和质量目标。一个工具展示时很惊艳，放进自己的项目后，可能需要大量准备和维护，收益未必抵得过投入。原文

拿我们的情况举个例子——这是我的解释：

假设 AI 十分钟生成了 100 条自动化用例，但你还要花两天修数据、纠正预期、排查误报。那么 “十分钟生成 100 条” 这个数字，并不能说明效率提高了。

反过来，它只帮你写了 5 条，但准确覆盖一个经常出问题的支付流程，而且以后维护很省心，这就有实际价值。

所以作者关心的是：最后解决了什么问题，总共花了多少代价。

1. AI 能操作、能写脚本，不等于它知道业务结果是否正确。

文章认为，测试仍然需要理解人的需求、建立评价标准，并判断系统有没有满足这些需求。这些工作不会因为工具升级就自动消失。原文

还是用支付举例：

商户发起一笔付款，接口返回成功，页面也显示成功。

到这里，机器已经能证明 “请求发出去了，页面有成功提示”。但你真正想知道的是：

• 钱有没有准确到账？
• 有没有多扣、多记一笔？
• 手续费对不对？
• 重复回调后会不会再入一次账？ 操作走完了，与业务做对了，是两件事。

AI 可以帮助检查这些问题，但首先要有人把 “对” 的标准说清楚，并提供可信的判断依据。这就是测试人员仍然重要的地方。

1. 对 AI 的宣传，要看证据，不能只看演示。

作者提醒，少量特定场景上的成功，不能直接证明换个项目也好用；要在自己的实际任务里评价效果。原文

这也不意味着必须搭一个复杂的盲测平台。我们刚才说的日常观察就能提供有用证据：
这次 AI 有没有漏关键场景？生成的用例能不能抓住错误？我纠正它花了多久？下次类似任务有没有改善？

这些观察比 “它能自动生成多少代码” 更接近我们关心的价值。

文章后面还讨论 AI 将来能否理解个性化需求、能否生成没有缺陷的软件，那部分是作者的设想，没有给出确定答案。你不需要顺着那些宏大问题想下去；对现在的工作，最值得记住的就是：让 AI 承担更多执行工作，人把精力放在业务预期、风险判断和结果可信度上。

你这是比较低端的工作方式，甚至是没有岗位空间的，如果工作这么简单，那一个脚本就能做了，还要人干嘛。
会用 不等于 用好。

说下我的最新进展吧，完全用 AI 做测试比之前预计的要累，QA 这个岗位不会消失，QA 是个力气活。
我验证的，仅 pc 浏览器功能的产品，是可以达到 AI 100% 覆盖的，所以大会上说的，5% 靠手测是完全可能的，并且和普通的理解不同，是 100%AI 都能覆盖，但是有 5% 的核心功能人类不放心所以要复查下，5%-10% 应该是这么来的。
但是这个 100% 的 AI 覆盖比想象中要累，原因是 AI 的质量标准太高了，举例吧，如果外包能设计出 20 条用例，正式最资深人能想到 50 条，那么 AI 能想到 100～150 条，会不会更多我还不知道，因为我在尝试并且 AI 大模型也在快速发展。
20 条用例耗时 1 天比如，如果 AI 测这 20 条确实洒洒水，一小时搞定了，但是要测 100～150 条的极其深入的测试，AI 的耗时也少不了，所以整体的测试耗时并没有下降太多，跟研发的开发时间仍然是一个合理的比例。
并且还有一个弊端，极其发散的用例，创造的场景和复现 bug、验证 bug 的深度也是非常恐怖的，研发可能改几遍也改不好，所以研发的能力，造数的能力等，都耗时很高。
所以回到最初的说法，QA 是个力气活，极端的质量仍然是明珠，很难摘的。
当然肯定有公司对质量是得过且过，甚至我都见过有些 QA 对自己的工作也是得过且过，那不在我上述范围内。
其实 QA 是一个靠运气吃饭的工作，就啥都不测、糖化，但是线上就不出问题事故，照样很稳……都是玄学。

QA 的生死线：QA 测试质量显著高于研发的自测。
如果达不到，基本就看命了，比如你亲哥是研发负责人，或者是你可以在极短的时间内比项目组的人更懂业务，提出更有价值的业务方向或者 bug。
靠自学迈过生死线的，现在连硕士、博士都找不到工作，你比他们学习能力更强吗？也不排除有，但是看你的问题描述没看出来。

写了很多又撤回了，你能看到，有缘的话就私聊吧。不想动太多人的蛋糕。

测试不是例外啊，AI 对 QA 的提升是非常非常非常巨大的，从高质量到高效率都是巨大的提升，AI 不会让质量保障的水平降低，相反是提高到了一个非常高的水准。
真不知道业内为什么在说测试越来越忙，是反向宣传吗……也是，再宣传岗位都没有了。
再说需求多就累的事情，QA 确实有效率的上限，但是据我的估计，AI 加持下的 QA 的上限被打穿的话，真的是超负荷的在跑的话，每个月 AI token 的成本是非常高的，如果是国外的模型是肯定过 2 万人民币的（估计 40 亿 token+），国内的模型也得大几千，AI 的 token 额度都到了么就在这里喊打穿了……
并且 token 能花到 40 亿的 QA，我觉得都不会喊累，因为那真是乐在其中。

这平台没什么大用甚至没用。
LLM 确实可以做生成用例的事情，但是不应该这么用。
看了后面的服务设计，从一开始 LLM 就不是这么用的， “屎上雕花” 的项目。

首先你要以无限 token 的终态去思考问题，如果 token 无限，你们目前这套还会痛苦么，如果还痛苦那么你们公司处境会很难，就像诺基亚对上安卓，没有跟上时代。
其次现状是没有任何 token，只能按老方法来思考问题，1 建议小功能，比如开发 5pd 内的，研发自测 + 上线即可，qa 不参与，具体时间你们得充分调研，把业务测试的压力降下来。2 回归方案的改革，比如主功能看看就行了。3 怀疑你们人效没打满，还是从自身上找找原因。

直接问豆包就行，知识都泛滥了。

我第一次回复你是不是陈述句，什么叫那么喜欢反问。另外做东西之前，多和 AI 交流一下，你做的这个提效落地实战，还有很多提高的地方，多问问豆包吧。

是啊，你的基建不是已经搞的非常好了吗，所以随便一个人贴一个链接就行了，这不是你开发 agent 的目标么？另外会 AI 的人有很多啊，为什么一定是 QA。

作为一个 QA，我的真实感受是：不是 AI 要取代 QA，是会用 AI 的 QA 会取代不会用 AI 的 QA。
持保留意见，也可以是会用 AI 的其他人（毕竟你就贴个链接没有任何操作门槛了）会取代（无论你会不会 AI）的 QA。

能打通，很快通用的解决方案就会来了，比如大佬们吃个饭碰一下，投几个人力就做出来了。但是打通干嘛呢，好好就业呗，多好。

很厉害啊，和硬件结合的 AI 才是最强的。

你搞错了吧，有确定答案的肯定还是 true 和 false 的断言，这个不用变啊。
不确定答案的，你想说大模型的幻觉吧，这部分都是一般是人工抽检 + 另一个更厉害的大模型做判断（时间长）。另外你得想办法降低大模型的幻觉啊，比如 RAG、长文本、多轮会话下的解决方案，乱答之后的报错机制等。不是来这里吐槽呀。
AI 测试目前是要把手工点点点的完全代码化（AI 效率特别高），让问题尽量的前置/左移比如 CR、单测、接口自动化、UI 自动化、数据库的对账、监控巡检等，然后手搓 agent（agent 测试开发？？）给所有人提效。你说的是断言判断的部分吧，这地方和之前一样就行。

没懂大模型体量很小是什么意思，MOE 下，体量很小也很强大了，你要干啥不够用，是你用的不好吧。

不要想的太复杂：把 AI 当人来问，来请教就行了。
不要炫技：AI 面前，大家都是学生。
选择最合适的：QA 的最终目标是帮助业务成功。
不要选择最好的：还是选择最合适的吧，最好的可能搞不定。

面你会的呗，另外可以去看看牛客网的面经（我大受启发）。

浅答一下，最近在看 ai 的东西。1. 你可以去看下高飞的接口测试代码生成提效的录屏，他那里有解决方案，比如自动生成 rag 文档，代码结构/格式，提示词的写法等，你的 80% 目标没问题，并且不用 coze 这种可视化流程编排工具，直接 cursor 等就行。2. 我建议数据层要写好，这里要投入大精力，包括边界 Case 也是边界的数据构造。3. 你可能想说 agent 的开发/测试比较重，不是你的工作核心，实际上 qa 的工作核心就要转变到 agent 开发上来，agent 开发是 2-3 年的未来，你不做别人做了，别人就把你干掉了。

真的感慨啊，本文中 Ptest 的 QA 实现者现在是我的实线 leader，圈子是真的小啊，哈哈，我当初崇拜了那么久，感慨万千！

以导出功能新增一个字段为例，头条这边 QA 介入的方式如下吧：

1. QA 参加需求评审和技术评审，评估影响面。
2. QA 对自动生成的 Case 做检查，看 Case 是不是都包含了，尤其是边界场景。
3. 研发自测，流水线上会执行 QA 之前写好的底线 Case。（你这里问的其实是此需求涉及的可能是 P2 级别的非核心 Case 自动化要怎么改怎么执行，如果你们 P0 的场景都自动化覆盖完了，那么写 P2 的没关系，如果 P0 的都没写完，这部分 Case 就是没有），研发来保证质量。
4. 验收阶段，PM 和 QA 、RD/FE 一起在测试环境演示一遍，什么问题当场就演示就问，确认效果。
5. 上线后的线上回归，也是 RD/FE 来执行。

你问的这个其实是个大问题，如果你这套跑通了，实际上你的工作就没了。
那么你问的问题能不能实现呢？如果是新增导出功能这个例子，我觉得是可以实现的，AI 来生成这些自动化代码，很快。

“所以 AI 的出现并没有拉进普通人和专家的距离，反而把差距拉的越来越大”，对这句话，目前的我是想反驳的，AI 无限拉进了普通人和专家的距离，普通人和专家比就剩两步了，一是专家才能给 AI 纠错的能力，不过这点大模型越来越准确了。二是专家对知识的融会贯通，可以创新。但是普通人也可以创新，这个知识积累的门槛已经破了。
此刻的我的心情是很复杂的，没想到能亲身经历这次技术革命，很兴奋，但是革的是我的命，很 x 蛋。
工业革命那一次，机器替代的是体力。一个靠力气吃饭的人，突然发现机器比他有力气，比他持久，比他便宜。那场革命打碎了一个延续了几千年的结构，体力稀缺这件事，从那以后，不再成立了。这一次，替代的是智力。——取自知乎。
我现在很悲观，ai 真的太强了，我也是后知后觉，真希望我能找到解法。