夜雨聆风提示词写得好就算掌握 AI 测试？
AI 测试是五层叠加
不是一项技能
AI 测试认知 · 五层能力全景 · 自下而上的依赖关系
AI 测试工程化实战 · 02
📦 本文目录 · 10 PARTS + CONCLUSION
01 你以为 AI 测试 = 写提示词，那是因为你只看到了第一层
02 五层是一张自下而上的依赖图
03 第 1 层：工具认知层
04 第 2 层：能力封装层
05 第 3 层：指令标准化层
06 第 4 层：流程纪律层
07 第 5 层：协作架构层
08 自测：5 个问题看你在哪一层
09 这五层的常见误区
/// 写在最后
AI 测试不是一项能力，而是五层叠加的能力结构。
01
PART
你以为 AI 测试 = 写提示词，那是因为你只看到了第一层
ONLY SEE LAYER 1
身边转 AI 测试的同事大致分两种。
一种是听说 AI 能写代码，立刻去背了几十条“万能提示词模板”，回来发现对自家项目一点不灵；另一种跳过提示词，直接找多 Agent 协作的脚手架，结果三个 Agent 跑起来反而更乱。
两种人的共同点是：把 AI 测试想成了“一项技能”，学会就够。
真实情况是，AI 测试是五层叠加的能力结构。
前两层决定你能不能开始用：知道有哪些工具（工具认知），能把经验封成可复用资产（能力封装）。后三层决定你能不能稳定、可规模地用：把模糊需求换成结构化工单（指令标准化），把“AI 一次答对”变成“AI 每次都答对”（流程纪律），让多个 Agent 分担复杂任务（协作架构）。
卡在哪一层的人，缺的不是勤奋，而是还没看见下一层的存在。
02
PART
五层是一张自下而上的依赖图
DEPENDENCY MAP
把这五层画出来，其实就是一张倒三角的依赖图：
— 复用上一篇《AI 不会直接替代测试工程师》的五层全景图。这一篇把它逐层打开。
五层之间是强制依赖：下面一层没站稳，上面的层跑起来就会塌。工具还没认全就封 Skill，封出来的是“垃圾进、垃圾出”的资产；Task Spec 还没稳定就上多 Agent 协作，多个 Agent 只是把混乱放大。
每一层都回答同一个问题——“上一层的输出，在你这里变成什么”。
工具给你调用能力；Skill 把能力打包成可复用单元；Task Spec 决定 Skill 何时被谁调用；GRR 与三层审核确保每次调用结果过得去；多 Agent 协作把多次调用编排成完整流水线。
下面一层一层拆开。
03
PART
第 1 层：工具认知层——你得先知道手里有什么
LAYER 1 · TOOLING
管什么
知道现在有哪些 AI 工具、它们各自能解决哪类问题、怎么接入你的项目。
AI 测试工具大致分成四大类：
IDE 端命令行端个人助理类平台类
分别是 Trae / Cursor 这类与代码编辑器深度集成的；Claude Code / OpenCode 这类直接吃代码库的；OpenClaw / Hermes / Qwenpaw / WorkBuddy 这类在 IM 里跑的；以及企业内部搭的测试平台。
关键产出物
一张你自己的“工具清单 + 选型判断”。不是哪个火就上哪个，而是这个工具适合我哪类场景、我用它解决什么、它的边界在哪。
卡在这一层的样子
还在到处收集“AI 测试工具盘点”文章，工具列表越攒越长，但自己真正用熟的没几个。
一份脚本能在 Cursor 里跑通，换到 Claude Code 就报错，反复配环境。
团队里有人推荐新工具就立刻试用，结果每个工具都没用深。
往下一层走的标志
能稳定用 2-3 个工具分别解决不同问题；换工具时知道哪些能力会丢、哪些得自己补。
04
PART
第 2 层：能力封装层——把“我做过一次”变成“团队都能用”
LAYER 2 · SKILL
管什么
把你“用 AI 成功完成过的某件事”沉淀下来，下次别人或别的 AI 不用再从零试。
这种沉淀物叫 Skill——一种标准化技能包：提示词 + 例子 + 反例 + 验收清单。
Skill 不是更长的提示词，而是把“我脑子里的判断”显式化。
关键产出物
Skill 文件本身。一个能复用的 Skill 至少要有这些部分：
它解决什么具体问题（不要写“辅助测试”这种空话）。
适用场景和不适用场景。
输入是什么、输出长什么样。
一个能照着做的范例，一个能对照避开的反例。
完成判定的清单（什么是“做对了”）。
卡在这一层的样子
团队里每个人都重新写一遍自己的提示词，谁也没省下时间。
自己的“Skill 文件”其实就是一段很长的提示词，没例子没验收清单。
Skill 越攒越多，但每次用还得现场改，效果不稳定。
往下一层走的标志
团队里有人接手新需求，能直接套用已有 Skill 跑出可用的初稿，而不是每次重新对话。
05
PART
第 3 层：指令标准化层——把“帮我写用例”换成工单
LAYER 3 · TASK SPEC
管什么
把 Skill 调用变成可重复、可交接、可审计的任务工单。
这叫 Task Spec，比提示词多了七要素：角色与背景、输入、任务、约束、验收、输出格式，外加一条工单级别的可追溯信息。
核心差别是：提示词是“对话”，Task Spec 是“工单”。对话可以含糊，工单必须能交付。
Task Spec 写完，任何人（人或 AI）拿过来按同一份工单跑，结果应该在可接受范围内一致。
关键产出物
六类测试场景模板：需求评审、测试点生成、用例生成、缺陷报告、测试报告、产物审核。这些模板不是填空表，而是把“工单的边界”提前约定清楚。
卡在这一层的样子
Task Spec 写得“模板好看”，但跑出来 AI 产出还是飘。
同一份 Task Spec 换个人跑，结果差很多。
工单里写不到验收标准，最后靠“看上去对”放行。
往下一层走的标志
同一份 Task Spec 由不同人或不同模型执行，结果差异收敛在可接受范围内；验收标准可以脱离具体执行者被复核。
06
PART
第 4 层：流程纪律层——把“AI 答对一次”变成“每次都答对”
LAYER 4 · GRR · REVIEW
管什么
让 AI 协作的产出在每一次都过得去。
前三层解决了“怎么让 AI 干活”，第四层解决“怎么让 AI 不出废品”。
这一层有两道防线——GRR 单次闭环（Generate / Review / Repair 三步循环，AI 出活、对照清单自查、按结构化反馈定向修，在每一次调用内自检）；三层审核门禁（业务逻辑与需求一致性 / 技术规范与格式合规 / 运行验证与可执行性，逐层放行，在交付前把关）。
两道防线是互补的：GRR 让单次产出自洽，三层审核让交付在团队级别被信任。
少一道，AI 协作要么“看起来好但翻车”，要么“每次都靠人肉救火”。
关键产出物
GRR 自检清单、三层审核的判定标准、异常退回与重入规则。通常把这套规则写进规则文件（如 AGENTS.md），跨工具跨会话生效。
卡在这一层的样子
审核变成走过场，签发时没人敢拍板。
AI 产出第一次看着没问题，跑到生产才暴雷。
错误反复出现，但每次都得重新修，没有沉淀为新的约束。
往下一层走的标志
常见错误被前置到 GRR 清单或审核标准里自动拦下；交付失败时可以清楚指认“是第几层没拦住”。
07
PART
第 5 层：协作架构层——让多个 Agent 分担复杂任务
LAYER 5 · COLLAB
管什么
把一个复杂任务拆给多个 Agent 分工，并保证整条流水线可控、可追溯。
典型分工
一种典型的分工是 Planner / Coder / Reviewer：规划者拆任务与定方案，执行者生成资产并自查，审核者做质量校验。
围绕它们还要做三件事：
上下文管理规则一致性协作边界
分别是系统级 / 项目级 / 会话级三层内容的分类治理；AGENTS.md 这种全局文件让 IDE 端、命令行端、平台端拿到同一份行为约束；以及职责隔离、权限分级、循环熔断、人工卡点、全链路留痕。
关键产出物
多 Agent 协作的任务流图、上下文分级方案、规则文件、人工卡点清单。
卡在这一层的样子
多个 Agent 跑得起来，但结果收不回来，没人敢上线。
出了错不知道是哪个 Agent 的问题，只能整体重来。
自动化表面漂亮，实际每次背后都靠人盯着。
往下一层走的标志
复杂任务可以无人值守跑完整条流水线；出问题能在 5 分钟内定位到具体 Agent 与具体环节；人工卡点只在必要环节出现，不是全程围观。
08
PART
自测：5 个问题看你在哪一层
SELF CHECK
下面 5 个问题，挑最贴近你日常状态的那一项，看自己落在哪一层。可以转发给同事做对照。
Q1你现在最常用 AI 做什么？
A. 还在装环境、试 API、配 IDE 插件 → 工具认知层
B. 把“我做过一次的事”封成 Skill 或模板 → 能力封装层
C. 写结构化的 Task Spec 给 AI 派工单 → 指令标准化层
D. 给每次 AI 产出过 GRR + 三层审核 → 流程纪律层
E. 让多个 Agent 协作完成一整条任务流 → 协作架构层
Q2团队里别人能用上你的 AI 经验吗？
A. 不能，全在我脑子里或本地对话里 → 偏第 1-2 层
B. 能，他们照 Skill 跑出差不多结果 → 至少到第 3 层
C. 能，他们独立完成且交付稳定 → 至少到第 4 层
Q3AI 出错时，你们通常怎么发现？
A. 上线后被业务投诉 → 流程纪律层缺位
B. 测试同事人工跑出来 → 至少在做三层审核
C. AI 自检或流水线门禁就拦下了 → 流程纪律层到位
Q4你们的 AI 资产存在哪？
A. 散落在每个工程师的 IDE 里 → 偏第 1 层
B. 仓库里有 Skill 文件，但没人维护 → 偏第 2 层
C. Skill + Task Spec + 规则文件 + 审核清单都在仓库里 → 至少到第 4 层
Q5最近一次多 Agent 协作，结果怎么样？
A. 没跑过 / 跑崩了 → 还不到第 5 层
B. 能跑通但要全程盯着 → 第 5 层初级
C. 跑完即可发布，必要时人工复核 → 第 5 层到位
如果四个以上答案都指向同一层，你大概率正卡在那里。
下一层的工作，是把上面那一层的产出物先稳定下来。
09
PART
这五层的常见误区
MISCONCEPTIONS
误区一：以为第一层最重要
装好工具、调通 API 容易，难的是后面四层。第一层只是入场券。
误区二：跳过中间层直奔多 Agent
前两层没稳就上第 5 层，多 Agent 只是把混乱放大；第 3 层没稳就上第 5 层，工单含糊，多个 Agent 各自理解各自跑。
误区三：把五层当考试科目，做完归档
AI 工具迭代很快，能力封装层与指令标准化层要持续维护；流程纪律层要随团队规模调整；协作架构层要随业务复杂度演进。
五层要长期运营，不是做完一次归档。
误区四：以为“流程纪律”会拖慢速度
流程纪律把“上线后翻车”提前到“上线前拦下”——上线前拦一次的成本，通常低于上线后救火一次。
误区五：把第 5 层当终极目标
不是所有团队都需要多 Agent 协作——很多场景单 Agent + Skill + Task Spec 就够。把不必要的事做复杂，是另一种浪费。
10
PART
总结
WRAP-UP
AI 测试是五层叠加的能力结构：工具认知 → 能力封装 → 指令标准化 → 流程纪律 → 协作架构。
下面是入场券，上面是稳定可规模的能力；缺哪一层，哪一层就会成为瓶颈。
定位自己在哪一层，最直接的两个信号：手上的产出物是什么，以及质量问题是怎么被拦下来的。
五层之间是强制依赖，跳层不会更快，只会更乱。
下一篇会沿着这条线再往里走一层：为什么“会写提示词”不等于“掌握 AI 测试”——它会把第 2、3 层的常见误解拆开，并回答一个更具体的问题：为什么团队里同样会用 AI 工具，有人产出稳定交付，有人反复返工。
互动你目前落在哪一层？卡得最久的是哪一层？留言告诉我，下一篇会挑出现频率最高的卡点专门拆开。
///
LAST
写在最后
WRAP-UP
我是程序员小濠，专注 AI 测试工程化与实战落地。这是「AI 测试工程化实战」系列的第 2 篇。
下一篇会把“会写提示词”这个最常见的错觉拆开，看清团队里同样的工具为什么产出差距很大。
既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。
THANKS FOR READING