我们来看一下经常能在网络上看到的话：
某老板：开发已经用 AI 提升了数倍的效率与产出，那测试呢？如果测试在 AI 时代掉队了，那是不是不需要测试了？
下面是我们测试领域的：
某测试人员：我折腾了大半个月的 AI，AI 根本没办法给测试人员提效，它就像个弱智一样。
我相信很多同学都在网络上捡到过上面那两句话， 甚至亲身经历过这两句话。因为我就经历过，我本身在国内的顶级大厂。公司对 AI 的重视程度之高，前所未有。为员工分发的 token 数量十分丰厚，就是希望员工能利用 AI，成本的提效。而上面引用的老板的话，就是我们管理了整个部门几万人的大老板所担心的。
实际上，这个担心已经变成了现实。我们业务线上的开发人员，全部都在用 AI 编程，产出效率提升的十分恐怖。所以整个质量部的老板们，也都陷入了焦虑中。他们最怕的，就是业务团队反馈测试人员的效率跟不上节奏。
所以，测试领域的 AI 提效路线，基本上是整个行业板上钉钉的大趋势。如果测试人员想在这个行当里混到第一梯队，那 AI 测试的能力是绕不开的一道坎儿。昨天有个同学加入星球后找我聊天，还说现在的面试都在考核 AI 技能了：
所以，我们回到一开始的那两句话来。 第一个我们已经有答案了，AI 测试是大势所趋，非万钧之力不可违抗。那我们来说说第二个，为什么很多测试人员感受到的是 AI 并没有给测试领域带来什么有效的提升？
其实这个问题不仅仅是测试人员会感受到，很多其他角色也会有此感受。这是为什么呢？答案很简单，使用 AI 也是需要学习的，它跟很多人的第一印象是不一样的，很多人想的是把需求扔给 AI，再用一两句话就可以让 AI 干活了。但事实上，如果真这么干了，一些简单的任务还没什么问题。但场景稍微复杂一点，大模型就会开始放飞自我，各种跳步，幻觉，自欺欺人的事情就会出现。这就是为什么很多人会觉得 AI 不是很靠谱。
使用 AI 也是需要学习的，是需要专业知识的，它根本就不是一个傻瓜式的，谁都可以用的东西。
很少有开发人员会抱怨 AI 的能力，是因为开发同学天然就会去学习这些东西，如果大家去看各种开发社区，甚至只要去 B 占上搜一下，就会发现各种 Agent 设计方法论十分流程，很多人在很早的时候就开始讨论 harness，讨论渐进式披露，讨论多 Agent 协同，讨论如何让 Agent 稳定高效的执行一个需要几十个小时的大型的复杂的任务。
而测试领域呢？我很少看到有人讨论这些，反而是很多人在高举反对 AI 的旗帜，妄图对抗大势。即便不反对，也是在发帖各种抱怨。有些时候，我们跟开发同学的差距就在这里。实际上我很喜欢开发人员，他们永远都在拥抱最新的技术，永远都在探索更好的方案。
OK，说了这么多，那测试人员当前应该怎么办？说一些我自己的观点，当前阶段，我们应该跟开发人员一样，去学习如何更高效的运行一个 Agent 任务，如果有关键词，那就是harness 。harness 是目前行业里广泛被认可的，用来保证 Agent 稳定高效运行的方法论。事实上，这个关键词并不重要，重要的是要不停的去学习更好的让 Agent 来辅助工作的方法。然后用在我们的日常工作中。就目前而言，我用 AI 做的事情：
- AI 分析需求并生成测试用例。
- 把测试用例转成接口自动化测试用例
- AI 驱动 UI 自动化测试
- AI 执行性能测试
- AI 执行容灾测试（高可用测试）
以上都各自有相关的 skill，而这些 skill 也都是按照 harness 的原则进行设计。我工作中基本上 90% 的内容，已经交给 AI 来完成。而这些工作量，在没有 AI 之前，大概需要 4 到 5 个人才能完成。
学习如何使用 AI 是测试人员以后的硬通货
当然我提到了这么多次 harness，那 harness 究竟是怎么来的，这里我也介绍下 harness 的发展历史。借由这个发展历史，我们也可以给大家说明一下，为什么不同的人用同一个模型，会有完全不同的效果。
提示词工程 → 上下文工程 → harness 工程
先抛一个现象：同样一个大模型，在不同人手里产出的效果可以差出几个量级。
为什么？我自己总结下来，主要是三个原因：
- a. 模型本身有非常广阔的知识，但它不知道在你当前这个具体场景下，应该调用哪一部分知识。
- b. 模型同样有知识盲区，尤其是你公司内部的业务、私有 API、历史遗留的奇怪约定，这些它从训练数据里学不到，需要你来补。
- c. 哪怕模型知识齐全了，它也不知道在你这个场景下"先做什么、再做什么、最后做什么"——也就是工作流。
于是就有了我们最熟悉的提示词工程（PromptEngineering） ，它要做的事情其实就两件：
- 补齐缺失的知识和经验 （把场景、约束、术语、示例喂给模型）；
- 指导模型按什么样的工作流去完成任务 （步骤、顺序、判断点、产出格式）。
下面这张图大致能说明这件事：
- 图左：模型像一个塞满知识的大球，但它自己也不知道当前该用哪些。
- 图右：那颗球上其实是有"洞"的，那些洞要靠用户去填。
- 图下：用户通过提示词，把"该走哪条路"明确告诉模型。
结论很朴素：模型再强，也需要"人"来指导，它的能力才能真正释放出来。
从提示词工程走向上下文工程
提示词工程能解决不少问题，但用着用着会发现新的痛点：
- 业务场景越来越复杂；
- 对话轮数越来越多；
- 每次新开一个会话，都要重新交代一遍背景、规范、目录结构、历史决策……
人会烦的。于是大家又提出了上下文工程（ContextEngineering） ：把每一轮对话里沉淀下来的信息——背景知识、决策、产物、约定——结构化地"记住"，让用户从重复输入中解放出来。
这些上下文是可以被压缩、复制、删除、挑选 的，可以在不同的会话之间流转，也可以在不同的 Agent 之间共享。本质上，它给模型外挂了一份"项目记忆"。
上下文太多，模型反而会"腐化"
但事情没完。当上下文越堆越多之后，新的问题又出现了：
- 模型开始忘记 前面定下的关键规则；
- 海量信息互相干扰，模型被带偏，给出南辕北辙的答案；
- 越长的上下文，越容易出现"看起来在认真做，其实早就脱轨"的情况。
这种现象，可以粗暴地称为上下文腐化 。
为了应付这件事，又有了harness 工程 （harness 本意是"马具"）。
harness 的思路非常直白：给模型套一层约束，让它不要那么跳脱，而是必须在规定好的框架和工作流里完成任务。
具体表现可能是：
- 把一个大任务拆成若干个明确的阶段，每个阶段有固定的输入产物和输出产物；
- 用多个子 Agent 各司其职，互相之间通过文件而不是口头转述传递信息；
- 对每一步都设置检查点：不通过就不允许进入下一步；
- 即使重试，也要在受控的范围内进行，不允许模型自由发挥。
我们这套 AI 驱动的 UI 自动化工程里，用来编写自动化测试用例的那个 skill，本质上就是基于 harness 理念做的。 它把"分析—实现—验证"拆成三个 agent，按状态机推进，产物落在固定目录，失败重试有上限，未经审批不允许改老函数——这些都是 harness 的味道。
回到那个问题
所以，为什么同样的模型，在不同人手里效果差这么多？
- 有的人希望一两句话就让模型干活，剩下全凭模型自由发挥；
- 有的人则会认真给模型设计一套严格的工作流、约束和反馈机制。
差距就出在这。
顺带说一句：这篇文章的正文也是 AI 生成的，但大纲是我写的 。这本身就再一次印证了上面的观点——AI 是放大器，输入端的"人"决定了它的产出质量。
以上就是 harness 的由来。
*开发都用 AI 提效了，质量风险被放大，测试人员怎么办？ *
我们再回到这个问题上， 现在的情况其实挺微妙的：
- 开发同学普遍开始用 AI 写代码，单人产出效率被显著放大 ；
- 但有些开发同学并不懂 harness 那一套，或者用的不是太好，他们用 AI 的方式更接近"提个需求、复制粘贴、能跑就行"；
- 结果就是：代码产出变多了，但每行代码里潜在的质量风险也变多了 ——逻辑漏洞、边界遗漏、隐蔽的安全问题、莫名其妙的副作用，都比以前更难一眼看出来。
与此同时，老板们的关注点是怎样的？
- 效率 是看得见的：上线快了、需求吞吐量上去了；
- 质量风险 是看不见的：它要等到线上出问题那一刻才变成数字。并且认为如果测试时间无法被压缩，将是测试人员自身的问题。
这就导致一个尴尬的局面：AI 带来的提效被高估，AI 带来的质量风险被低估，而中间承压的恰恰是测试人员。
那怎么办？焦虑是没用的，唯一的出路是：我们自己也用 AI 把自己的效率拉起来，跟上行业节奏。
我自己的几个落地方向，分享一下：
1. 用 AI 快速沉淀自动化资产
以前很多自动化工程跑不起来，不是因为技术不行，而是人力成本算不过账 ：写一条用例的时间，够手测跑很多遍了，而且写完还要长期维护。产品一变，就要修改很多东西。
而 AI 介入之后，这笔账完全不一样了：
- 用例生成、定位元素、写断言这些"机械活"，AI 干得又快又稳；
- 维护成本也被压缩——失败用例可以让 AI 先做一轮归因；
- 配合 harness 化的 skill（比如我们教程里的那一套），用例质量是可控的，不会越积越烂。
结果就是：以前因成本太高而被砍掉的自动化覆盖面，现在可以重新捡起来。
2. 思维切换到 AI First
这一点是态度问题，不是技术问题。
遇到任何事情，不管自己会不会，先问一句："这件事 AI 能不能帮我先走一遍？"
- 需求分析：让 AI 先帮你拆解、提问、找疑点；
- 用例设计：让 AI 先生成一版，你来做减法和补充；
- 专项测试（性能、安全、兼容性）：让 AI 帮你列检查清单和工具选型；甚至执行让 AI 来运行。
- 技术方案调研：让 AI 先做信息整合，你来做判断；
- 文档、周报、总结：这些是 AI 收益最高的场景之一，没必要硬扛。
不一定每次都用得上，但养成"先问 AI"的反射 ，长期下来差距非常明显。
3. 把 AI 当作随身学习入口
测试这个岗位本身就涉及大量横向知识：新业务、新技术栈、新协议、新工具，遇到知识盲区是常态。以前的做法是搜索引擎 + 文档 + 社区，效率不算高。现在的做法是：先让 AI 帮你建立一个 60 分的认知框架 ，然后再去看一手资料补细节。这中间省下来的，是大量"我现在到底该看哪本书、该从哪里入手"的时间成本。
三、写在最后
我个人对未来的判断是这样的：
- AI 现在势头很猛，但短期内，绝大多数企业仍然需要大量人工来做测试工作 ，所以也没必要陷入那种"我马上要被替代"的焦虑；
- 但长期看，行业里能留在第一梯队的人，画像基本都是"特种兵 +AI" ：方向感强、判断准、产出快，AI 是他们的放大器，不是替代品。 最终再重申一遍：
以后测试行业能混在第一梯队的人，一定是 特种兵 + AI 的组合模式。我们需要持续的去学习如何利用好 AI 的能力。
最后再推销一下自己的星球， 后续更多优质的一线大厂测试教程，都在星球中更新：
