最近很多测试同学都在用 AI。

有人用它分析 PRD，有人用它写测试用例，有人用它总结 Bug，也有人用它整理周报和测试报告。

这些当然有价值。

但我越来越觉得：

只会用 AI 工具，很快会变成新的基础能力。

真正能拉开差距的，可能不是“你会不会问 AI”，而是：

你能不能把 AI 放进测试流程，搭出一套可复用、可验证、可治理的质量系统。

这也是我理解的“测试工程师 AI 全栈”。

它不是让测试工程师去训练大模型，也不是让测试工程师变成前端、后端、算法、运维都精通的人。

而是测试工程师要逐步具备一种能力：

懂测试业务
懂 AI 工具
懂基本工程
懂数据和接口
能把测试经验流程化
能把质量数据结构化
能把 AI 接入真实测试工作流

简单说：

测试工程师的 AI 全栈，不是为了替代测试，而是为了重新设计测试工作的方式。

---

一、只会用 AI 工具，很快会变成基础能力

现在很多人用 AI 的方式是这样的：

复制 PRD 给 AI
→ 让 AI 生成测试点

复制 Bug 列表给 AI
→ 让 AI 总结问题

复制测试进展给 AI
→ 让 AI 写周报

复制测试结果给 AI
→ 让 AI 生成报告

这类使用方式能提效，但它有明显上限。

因为整个过程仍然依赖人不断复制、粘贴、整理、修正。

AI 本身并不知道：

历史 Bug 在哪里
已有用例有哪些
哪些问题曾经反复出现
哪个模块风险最高
哪个需求属于哪个版本
哪些用例失败后会影响上线

所以很多时候，AI 只是一个“更会写文档的助手”。

它可以帮你写得更快、更顺，但还没有真正进入测试流程。

更大的问题是：如果没有约束，AI 很容易“看起来很完整，实际有风险”。

比如在需求测试设计中，PRD 没写清楚的地方，AI 可能会自己补规则。

审批通过后的终态没定义，它可能直接写成“审批完成”。

PC 和 H5 是否一致没有确认，它可能默认两端一致。

导出字段没有明确，它可能自己推断字段范围。

这些问题对于测试来说都很危险。

因为测试用例不是作文。

测试用例一旦进入测试平台，就会影响执行、回归、验收和上线判断。

所以，测试工程师用 AI，不能只停留在“让它帮我生成内容”。

更重要的是要思考：

AI 应该看什么数据？
AI 应该遵守什么规则？
AI 哪些地方不能推断？
AI 输出后怎么自检？
AI 生成的结果如何被审查？
AI 能不能沉淀成团队能力？

这就是从“会用工具”走向“会搭系统”的开始。

---

二、测试工程师用 AI，大概会经历三个阶段

我把测试工程师使用 AI 分成三个阶段。

阶段	典型表现	主要问题
会用工具	用 AI 写用例、周报、报告	个人提效，难以复用
会做流程	把 PRD 评审、测试点、用例自检串起来	有方法，但仍依赖复制粘贴
会搭系统	接入数据、建模对象、封装 Skill/Agent	能形成团队能力

第一阶段，是大多数人正在做的事情。

比如：

帮我分析这个需求有哪些测试点
帮我把这些 Bug 按模块分类
帮我把这段测试进展优化成周报
帮我生成一份测试报告

这个阶段很有价值，但主要还是个人效率提升。

第二阶段，是把单个 Prompt 变成测试工作流。

比如需求测试设计，不是直接问：

帮我写测试用例

而是拆成：

1. 需求摘要
2. 评审问题生成
3. 待确认项收敛
4. 测试点设计
5. 正式用例生成
6. 用例自检
7. 修正后输出

这个阶段已经开始接近真实测试工作。

因为它不是让 AI 一步到位，而是让 AI 按照测试思路逐步产出。

第三阶段，是把 AI 接入测试系统和测试数据。

比如：

AI 能查询需求
AI 能查询历史 Bug
AI 能查询已有用例
AI 能查询测试执行结果
AI 能根据版本范围输出上线风险
AI 能根据失败用例推荐回归范围

到这个阶段，AI 才真正从“文档助手”变成“测试工作流的一部分”。

这也是测试工程师 AI 全栈真正有价值的地方。

---

三、行业领先实践给了哪些启发？

我们不妨看一下行业里比较领先的 AI 实践。

这些实践不一定直接来自测试领域，但对测试工程师非常有参考价值。

它们共同说明了一件事：

领先团队不是在比谁用的模型更新，而是在比谁能把 AI 放进真实工作流。

---

四、Codex：任务可以委派，但必须可审查

很多人理解 AI 编程工具，还停留在：

帮我补全代码
帮我写一个函数
帮我解释报错

但 Codex 代表的是另一种方向：把软件工程任务委派给 Agent。

OpenAI 对 Codex 的定位是 cloud-based software engineering agent，可以在云端 sandbox 中并行处理任务，比如写功能、回答代码库问题、修 Bug、提出 PR；每个任务运行在自己的 cloud sandbox，并预加载代码仓库。(OpenAI)

这背后的重点不是“AI 写代码更快”，而是工作方式变了：

人描述任务
→ Agent 在隔离环境执行
→ 生成代码变更
→ 输出 diff / PR
→ 人或 AI review
→ 再修正
→ 最终合入

这对测试工程师有什么启发？

不要只把 AI 当成“测试用例生成器”。

测试工作里也有很多任务可以被委派：

分析 PRD 风险
生成评审问题
补充增量测试点
自检测试用例
根据失败日志修复自动化脚本
根据 Bug 列表生成复盘摘要
根据测试执行结果生成报告草稿

但这些任务必须满足几个条件：

输入明确
过程可控
输出可审查
结果可回滚
最终由人确认

这才是测试侧借鉴 Codex 的重点。

不是让 AI 替你“自动测完”，而是让 AI 参与一个可审查、可验证的工程闭环。

---

五、Claude Code：AI 要进入项目目录，而不是只在聊天框里

Claude Code 给测试工程师的启发是：AI 不应该只停留在聊天框里。

它可以进入项目目录，读取文件，理解结构，执行命令，修改代码，并通过 MCP 连接外部工具。Claude Code 官方最佳实践也强调从环境配置、上下文管理到并行 session 的使用方式。(Claude)

这对测试工程师非常关键。

以前我们使用 AI，经常是这样：

复制 PRD 给 AI
复制 Bug 列表给 AI
复制测试结果给 AI
让 AI 总结

现在可以变成：

把测试数据放进项目
把质量规则写进项目说明
把查询逻辑写成脚本
把能力封装成 MCP
让 AI 基于真实文件和工具回答

比如我最近做了一个很小的 Demo：

CLAUDE.md：约束 AI 行为
ontology.json：表达测试对象和关系
query_ontology.py：本地查询风险
mcp_server.py：暴露 MCP 工具
Claude Code：调用 MCP 输出上线风险速览

这个流程的价值在于：

AI 不再凭感觉回答，而是在一个有文件、有数据、有命令、有约束的项目环境里工作。

这对测试工程师是一个很重要的转变。

以后我们可以围绕这些资产建立项目：

测试用例仓库
接口自动化项目
测试数据生成项目
质量报告生成项目
MCP Server 项目
测试 Ontology Demo
上线风险分析工具

AI 进入项目目录后，能做的事情就不只是写文案，而是可以协作完成一类测试工程任务。

---

六、Palantir：先建业务对象，再让 AI 行动

如果说 Codex 和 Claude Code 偏工程工具，那么 Palantir 给我们的启发是：企业 AI 落地不能只靠大模型，还需要业务语义层。

Palantir 官方把 Ontology 描述为组织的 operational layer，位于集成到平台中的数字资产之上。(Palantir) Palantir 也强调 Ontology System 会编码企业的数据、逻辑、动作和安全，用于自动化运营中的决策。(Palantir)

这句话翻译到测试领域，就是：

AI 要真正参与测试，不只是要能查 Bug，而是要理解 Bug、用例、需求、版本和风险之间的关系。

如果没有语义层，AI 看到的只是一些表：

requirements
test_cases
bugs
releases
test_runs

但测试工程师真正关心的是：

哪个需求覆盖了哪些用例？
哪些用例失败了？
失败用例发现了哪些缺陷？
哪些缺陷阻塞版本？
哪些模块风险集中？
修复后应该回归哪些范围？
当前是否具备上线评估条件？

这就是测试质量 Ontology 的价值。

我们可以把测试对象建模为：

Requirement：需求
TestCase：测试用例
Bug：缺陷
Release：版本
Module：模块
Risk：风险
Owner：负责人
TestRun：执行记录

再定义关系：

Release includes Requirement
Requirement has TestCase
TestCase found Bug
Bug belongs to Module
Bug blocks Release
Bug causes Risk
Owner handles Bug

这样 AI 就不只是回答：

当前有 2 个 Bug。

而是可以回答：

REL-1.2.0 中，报销审批需求仍有 2 个未关闭 Bug，
其中 BUG-101 为 P1，影响 H5 提交状态确认，
建议修复后回归 H5 提交、撤回、驳回重提链路，
再由测试负责人评估上线条件。

这就是从“数据查询”到“质量判断辅助”的变化。

所以，Palantir 给测试工程师的参考不是去复制它的平台，而是学习它的思路：

先定义业务对象和关系，再让 AI 在这个业务世界里工作。

---

七、MCP：解决连接问题，但不解决理解问题

MCP 最近很热。

但要说清楚它在 AI 全栈里的位置。

MCP 解决的是“AI 怎么连接工具和数据源”。

比如：

需求系统
缺陷系统
测试平台
文档系统
代码仓库
CI/CD
日志平台
监控平台

在测试工作中，我们经常要把这些系统里的信息复制给 AI。

比如：

从需求系统复制 PRD
从测试平台复制用例执行结果
从缺陷系统复制 Bug 列表
从日志系统复制报错
从监控系统复制指标
从文档系统复制测试报告

如果有 MCP，这些动作可以变成工具调用：

query_requirement
query_test_cases
query_bugs
query_test_runs
query_release_risk
get_regression_scope

但这里有一个关键点：

MCP 解决的是连接问题，Ontology 解决的是理解问题。

只有 MCP，没有 Ontology，AI 可能能查到 Bug，但不一定知道：

Bug 影响哪个用例
用例覆盖哪个需求
需求属于哪个版本
这个 Bug 是否形成上线风险
修复后应该回归哪些范围

所以更完整的路线应该是：

MCP 负责连接系统
Ontology 负责表达对象和关系
Skill / Agent 负责执行标准流程
人负责最终判断和治理

这也是我前面做测试 Demo 时最深的感受。

mcp_server.py 只是把查询能力暴露出去。

真正让 AI 输出质量风险分析的，是背后的对象关系：

Release
Requirement
TestCase
Bug
Risk

没有这些关系，AI 只能查数据。

有了这些关系，AI 才能辅助判断风险。

---

八、Skill：把个人经验封装成团队能力

行业里另一个重要趋势，是把工作流封装成 Skill。

OpenAI Codex 的 Agent Skills 文档把 skill 定义为扩展 Codex 特定任务能力的方法，skill 可以打包说明、资源和可选脚本，让 Codex 更可靠地遵循某个工作流。(OpenAI开发者)

这对测试团队非常有价值。

测试团队里有很多经验，过去主要靠人记住：

PRD 评审怎么问
测试点怎么收敛
什么用例可以入库
用例自检要看哪些问题
上线风险怎么判断
测试报告怎么写
Bug 复盘怎么归因

这些经验如果只存在个人脑子里，就很难复用。

但如果封装成 Skill，就可以变成团队能力。

比如一个“需求评审 Skill”可以规定：

输入：PRD 原文

流程：
1. 提取需求摘要
2. 按业务规则、状态流转、权限、数据、多端、异常分类
3. 生成评审问题
4. 区分必须确认、建议确认、扩展风险
5. 输出评审会优先 5 问

红线：
- 不替产品补规则
- 不把未明确内容写成已确认
- 不直接生成正式用例

一个“用例自检 Skill”可以规定：

检查待确认项是否写成确定性用例
检查是否编造 PRD 外规则
检查预期是否可验证
检查是否默认 PC/H5 一致
检查是否默认审批通过终态
检查导出字段是否被过度推断
检查是否把批量导入待确认项写入正式用例

这就是测试工程师非常值得做的事：

把个人测试经验，变成 AI 可执行的标准流程。

Prompt 是一次性的。

Skill 是可复用的。

个人 Prompt 能提升一个人的效率，团队 Skill 才能提升整个测试团队的质量能力。

---

九、治理：只读优先，写入确认

AI 工具越强，越要重视治理。

因为测试工作很多时候和上线质量、数据安全、权限边界有关。

不要一上来就做：

AI 自动关闭 Bug
AI 自动修改上线结论
AI 自动删除测试数据
AI 自动触发发布
AI 自动修改生产配置

更稳的路线应该是：

第一阶段：只读查询
第二阶段：草稿生成
第三阶段：人工确认写入
第四阶段：低风险自动化
第五阶段：平台化审计

这也是企业级 AI 落地的基本思路。

AI 可以查数据，可以生成摘要，可以推荐回归范围，可以生成报告草稿。

但关键结论必须由人确认。

特别是测试场景下，AI 不应该直接给出绝对上线结论。

更合理的表达是：

当前存在 P1 未关闭问题，
建议修复并完成回归后，
由测试负责人结合影响范围评估上线条件。

这个边界非常重要。

AI 可以辅助质量判断，但不能替代质量责任。

---

十、一个最小实战：让 Claude Code 看懂上线风险

为了验证这条路是否可行，我做了一个很小的 Demo。

目标很简单：

让 Claude Code 通过 MCP 查询本地测试质量 Ontology，并输出版本上线风险。

项目目录大概是这样：

sqa-ontology-demo/
├── CLAUDE.md
├── README.md
├── ontology.json
├── query_ontology.py
└── mcp_server.py

其中：

文件	作用
CLAUDE.md	给 Claude Code 的项目约束和行为规则
ontology.json	定义需求、用例、缺陷、版本等对象
query_ontology.py	本地查询版本风险
mcp_server.py	把查询能力暴露成 MCP 工具
README.md	Demo 项目说明

ontology.json 里定义了这些对象：

Requirement：报销审批规则优化
Release：REL-1.2.0
TestCase：3 条测试用例
Bug：3 个缺陷，其中 2 个未关闭
Module：报销审批、H5端、数据导出

然后通过 query_ontology.py 本地查询版本风险。

本地脚本可以输出：

版本：REL-1.2.0
需求数：1
用例数：3
失败用例数：2
未关闭 Bug 数：2
Bug 优先级分布：P1 1 个，P2 1 个
Bug 模块分布：H5端 1 个，数据导出 1 个
风险结论：存在 P1 未关闭问题，需修复并回归后再评估上线。

接着通过 mcp_server.py 暴露三个 MCP 工具：

query_release_risk
query_requirement_quality
get_regression_scope

最后在 Claude Code 中提问：

请使用 sqa-ontology MCP 的 query_release_risk 工具，
分析 REL-1.2.0 的上线风险。

Claude Code 输出的结果不再是泛泛回答，而是基于本地数据生成风险速览：

REL-1.2.0 风险速览

需求：1
用例：3
失败：2
未关 Bug：2
Bug 优先级：P1×1，P2×1
阻断风险：有

关键 P1 风险：
BUG-101 H5端提交报销后状态未刷新，
可能导致用户重复提交。

建议回归：
1. H5 提交、撤回、驳回重提链路
2. H5 提交后状态变更
3. 报销数据导出
4. 空文件重试与异步任务状态

结论：
建议测试负责人结合 P1 影响范围和修复回归结果评估上线条件。

这个 Demo 很小，但它跑通了一个完整闭环：

测试对象建模
→ 本地风险查询
→ MCP 工具暴露
→ Claude Code 调用
→ 输出上线风险分析

它说明了一件事：

AI 要真正参与测试，不只是让它生成用例，而是要让它理解需求、用例、缺陷、版本和风险之间的关系。

---

十一、测试工程师的 AI 全栈能力模型

如果把上面的实践总结成能力模型，我认为测试工程师的 AI 全栈大概包含 7 类能力。

测试理解
+ Prompt 工作流
+ Python / API 基础
+ MCP 工具接入
+ 测试知识建模
+ Skill / Agent 封装
+ 质量治理意识

展开来看：

能力	说明
测试理解	能判断需求风险、用例质量、上线风险
Prompt 工作流	能把测试任务拆成稳定流程
Python / API 基础	能处理 JSON、调用接口、写脚本
MCP 工具接入	能让 AI 查询真实或本地测试数据
测试知识建模	能定义 Requirement、TestCase、Bug、Release、Risk
Skill / Agent 封装	能把经验沉淀成可复用流程
质量治理意识	知道哪些能自动化，哪些必须人工确认

这里面最重要的，不一定是技术最复杂的部分。

对测试工程师来说，最有差异化的能力反而是：

测试知识建模
质量规则设计
AI 工作流设计
风险边界控制

因为开发可能更懂代码，产品可能更懂业务，但测试最适合定义质量关系：

需求如何影响用例
用例如何发现缺陷
缺陷如何形成风险
风险如何影响上线
历史问题如何影响回归范围

这正是测试工程师在 AI 时代的独特价值。

---

十二、一条适合测试工程师的 AI 全栈路线

如果从现在开始，我建议按 5 步走。

第一步：个人提效

先把日常高频工作 AI 化。

PRD 分析
评审问题生成
测试点设计
测试用例自检
Bug 总结
周报整理
测试报告草稿

这一阶段不用追求复杂系统，先把个人效率提升起来。

---

第二步：流程化

把单次 Prompt 变成稳定流程。

例如需求测试设计流程：

需求摘要
→ 评审问题
→ 测试点
→ 用例生成
→ 用例自检
→ 修正输出

这一阶段的重点是：不要再直接问“帮我写用例”。

而是让 AI 按测试过程一步步工作。

---

第三步：结构化

把测试对象建起来。

Requirement
TestCase
Bug
Release
Risk
Module
TestRun
Owner

并定义关系：

需求覆盖哪些用例
用例发现哪些缺陷
缺陷影响哪些模块
缺陷是否阻塞版本
失败用例如何影响回归范围

这一阶段决定 AI 能不能真正理解测试工作。

---

第四步：工具化

通过 MCP 或 API 接入测试数据。

可以从只读工具开始：

query_requirement
query_cases
query_bugs
query_test_runs
query_release_risk
get_regression_scope

第一阶段不要急着写入。

只读查询已经能带来很大价值。

比如：

快速汇总未关闭 Bug
快速找失败用例
快速生成风险清单
快速推荐回归范围
快速生成报告数据

---

第五步：团队化

把稳定流程封装成 Skill 或 Agent。

例如：

需求评审 Skill
测试点设计 Skill
用例自检 Skill
上线风险 Agent
测试报告 Agent
Bug 复盘 Agent

每个 Skill 都要有：

输入要求
执行步骤
输出模板
质量红线
自检清单
禁止事项
示例

这一步的目标，是让 AI 能力从个人使用变成团队能力。

---

十三、不要一上来追求全自动

很多人一听 AI 全栈，就会想到：

AI 自动测完
AI 自动提 Bug
AI 自动判断上线
AI 自动发报告

这个方向很诱人，但不适合作为第一步。

测试场景里，很多动作都和质量责任有关。

所以更稳的路线是：

先只读
再草稿
再确认
再低风险自动化
最后平台化治理

例如上线风险分析：

第一阶段：

AI 查询未关闭 Bug，输出风险清单

第二阶段：

AI 生成测试报告草稿

第三阶段：

测试负责人确认后写入报告系统

第四阶段：

固定格式日报/周报自动生成

第五阶段：

沉淀为团队质量平台能力

这条路线不激进，但更现实。

AI 落地不是为了看起来“自动化程度很高”，而是为了真正可用、可信、可控。

---

十四、未来测试工程师的差距在哪里？

未来测试工程师之间的差距，可能不再只是：

谁写用例更快
谁提 Bug 更多
谁自动化覆盖率更高

更大的差距会体现在：

谁能把测试经验变成流程
谁能把测试数据变成结构
谁能把 AI 接入真实系统
谁能定义可靠的质量判断规则
谁能把个人方法变成团队能力

换句话说，未来更有价值的测试工程师，不只是会测试系统。

而是能设计：

AI 如何参与测试。

这是一种新的能力。

它要求测试工程师既懂质量，又懂工具；既懂业务风险，又懂基本工程；既能使用 AI，也能约束 AI。

---

十五、最后

测试工程师的 AI 全栈之路，不是盲目追热点。

也不是今天学一个工具，明天换一个模型，后天再追一个框架。

真正值得投入的是：

把测试流程 AI 化
把测试知识结构化
把测试工具标准化
把测试经验 Skill 化
把质量判断治理化

从个人提效，到团队能力。

从复制粘贴，到工具连接。

从泛泛生成，到基于数据和关系分析。

从让 AI 写几条用例，到让 AI 理解需求、用例、缺陷、版本和风险之间的关系。

最后总结一句：

测试工程师的 AI 全栈，不是为了替代测试，而是为了重新设计质量工作的方式。

未来优秀的测试工程师，不只是会发现问题，而是能搭出一套让 AI 参与质量、理解质量、放大质量的工作系统。