现在用 AI 写测试用例，已经不是什么新鲜事了。

需求复制进去，再加一句：

帮我从功能、异常、边界等维度生成测试用例。

几十秒，一堆测试点就出来了。

但真正用到项目里，很快就会发现问题：

历史 Bug，AI 不知道。公司业务规则，AI 不知道。接口文档、测试规范、已有用例，它也不会自己去找。

如果每次还是靠测试人员：

复制需求 → 写 Prompt → 整理结果 → 人工校验

那其实只是把：

“手工写用例”

变成了：

“手工操作 AI 写用例”。

真正值得关注的，是下一步：

能不能把 AI 从一个聊天工具，变成真正参与测试工作的智能体？

这也是我们这周「智能化软件测试训练营」想和大家聊的重点。

01 AI 写用例，只是起点

理想中的 AI 测试，不应该只是回答一个 Prompt。

而应该是：

读取需求

↓

检索历史用例、Bug 和业务知识

↓

分析测试风险

↓

拆解测试场景

↓

自动生成结构化测试用例

↓

测试人员审核补充

再进一步，甚至可以继续调用接口、数据库、自动化框架和 CI/CD 工具完成更多测试任务。

到了这个阶段，AI 才真正开始进入测试流程。

02 测试工程师真正该关注的是 Agent

最近你可能经常看到这些词：

Agent、MCP、Skill、CLI、Harness、RAG。

看起来很像 AI 开发工程师才需要研究的东西。

但实际上，它们正在决定：

AI 到底只能陪你聊天，还是能真正干活。

比如：

RAG，让 AI 能读取企业自己的知识。

MCP、Skill、CLI，让智能体可以调用更多工具和能力。

Agent / Harness，让大模型能够围绕一个任务持续分析、调用工具并完成工作。

当这些能力和测试结合起来，就可能出现：

测试用例生成智能体、接口测试智能体、缺陷分析智能体、自动化执行智能体……

所以未来真正拉开测试工程师差距的，可能不只是：

会不会用 AI。

而是：

能不能让 AI 按照你的测试思路去工作。

03 这次训练营，我们直接讲实战

这周的「智能化软件测试训练营」，我们会把整条链路串起来：

• 行业大模型特性与能力测评
• 智能体工具与 Harness 工程
• Skill、CLI、MCP 工具体系
• RAG 检索增强生成与知识图谱
• 测试用例生成智能体实战

最终会落到一个测试人最熟悉的场景：

测试用例智能生成

不是只教你写几个 Prompt。

而是带大家真正理解：

一个测试用例生成智能体，到底是怎么搭出来的。