在软件测试的前沿实践中，有一个越来越尖锐的矛盾摆在我们面前：产品迭代越快，测试覆盖的压力就越大；而业务规则越复杂，人工用例设计的质量差异就越明显。
当传统测试模式遭遇高速迭代的互联网产品时，症状显而易见——
-
测试用例编写占比仅 13%，而执行却要消耗 38% 的资源 -
经验丰富的 QA 和新手写出的用例质量天差地别 -
历史缺陷知识难以系统复用，团队反复踩坑 -
PRD 变更频繁，维护成本陡增
最讽刺的是，即便 AI 生成了大量用例，团队的反馈也往往是："生成得没错，但太泛了，没法直接用。"
这正是快手在过去两年AI+测试探索中，从Prompt工程一路走到Agentic自进化的核心驱动力。今天，我们以快手“研发Agent和智能质量平台”负责人苗星（他主导了快手智能测试策略分析、智能用例生成、智能用例执行、智能自测及质量风控等关键领域的探索和落地）的「第9届AI+研发数字峰会」（AiDD，2026年5月22-23日，上海）上的演讲《智能UI用例生成与执行》（下载地址：https://www.aidd.vip/dhrc-sh2026）为蓝本，系统复盘这条"从可行性到可用性、再到自进化"的四阶进化之路，揭示其背后的工程规律。
一、痛点诊断：为什么传统测试模式会失效？
在深入演进的四个阶段之前，先理解问题的根源很关键。
苗星的演讲清晰地给出了测试设计的核心痛点：
关键洞察：测试效率的真实瓶颈不在执行自动化（那已经不是 2010 年代了），而在"用例从何而来、质量能否保证、怎样能规模复用"。
"质参差"问题：知识孤岛化
团队中，资深 QA 和新手面对同一份 PRD 时：
资深QA：不仅测试"余额不足时提示充值"，还会主动验证"并发场景下的重复扣款防护机制"
新手QA：按需求字面意思"照抄"用例，遗漏隐含规则
这不是简单的经验差异，而是业务知识的沉淀与复用机制缺失。每一个缺陷教训、每一条业务规则，都成了某个人的"私产"，而非团队资产。
AI 范式升级的开始
正是在这三重压力下，快手团队提出了一个假设：
"用例不应该是'一次生成就完成'的产物，而应该像代码一样，经历设计、评审、迭代、沉淀的全生命周期。"
这个假设驱动了从 V1.0 到 V4.0 的整个演进。
二、V1.0：从零到一的验证——Prompt 工程探索
V1.0 的目标很简单：证明基础模型能否从 PRD/技术方案中自动生成可用的测试用例。
这一阶段的关键做法是：
Few-shot学习：精选3-5个高质量用例样本（质量优先于数量）
场景化Prompt模板：根据输入文档类型（功能 PRD、技术方案、全链路）分别设计不同的生成策略
输出强约束：通过缩进、标点、换行等格式锁定，保证模型输出的可解析性
核心逻辑是什么？简单说：
1）输入: PRD + Few-shot 样本 + 场景化 Prompt
2）LLM 推理（单 Agent，无外部工具）
3）输出: 结构化测试用例集合
但实际效果：可行但不足。当快手团队真正把这套方案上线时，数据打脸了——生成率仅8%。更扎心的反馈来自用户："生成得太泛了，没法直接用。"
这引出了三个根本性问题：
问题1：长文档理解衰减
当 PRD 超过 30K tokens 时，模型开始"遗忘前文"。技术原理其实是 Transformer 注意力机制的退化——长序列下，后面的 token 对前面上下文的关注权重下降。这意味着Prompt工程的"线性添加更多信息"这条路，从一开始就走不通。
问题2：业务知识缺失
PRD 中的"隐含规则"（比如支付场景必须验证并发机制）不会被模型自动推导。模型只能理解文本字面意思，无法在没有明确指示的情况下补齐"常识"。
问题3：生成过程黑盒
用户无法干预中间步骤。如果对"测试点拆分"或"用例结构"不满意，改进成本往往比从零手写还高。
V1.0 的价值：证明了"路通了"，但也明确指出了瓶颈不在"能否生成"，而在"能否可控地生成高质量用例"。
三、V2.0：Multi-Agent 协作——把 QA 的工作流复制出来
V2.0 的转折点来自一个简单观察：没有任何 QA 是"一步到位"地写用例的。正常的 QA 工作流是这样的：
这里的Review环节很关键——每一阶段都有反馈循环，及时发现"缺业务深度""结构不够清晰"等问题。
V2.0 把这个流程转化为三个专用 Agent 的编排：
V2.0 非常明确地划分了责任：
AI负责：快速生成、提供结构化框架、支持差异化参数
人负责：做关键的 Review 决策、纠偏、标注优先级
这个看似简单的分工，却带来了质的跃升：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
但新的瓶颈也显现了：生成的用例"正确但浅显"。
V2.0 的核心规律
"一个人的工作流，分解为多个专用 Agent 的协作，可以提高可控性和可审查性，从而减少端到端的错误。"
但同时暴露出来的问题是：缺乏业务知识的 AI，永远只能做到"覆盖表面"。
四、V3.0：知识工程——让AI具备"懂业务"的能力
假设 PRD 描述："用户支付时，余额不足则提示充值"。
- 新手 QA 的用例：输入金额 > 余额 → 期望弹出充值提示 ✓
- 资深 QA 的用例：
-
单笔支付测试✓ - 并发两笔支付，验证防重复扣款机制
← 关键测试点，历史缺陷 -
充值中途退出 → 确认幂等性✓ -
网络中断重试逻辑✓
同样的需求，经验差异导致的覆盖范围差10倍。这种差异无法通过更好的Prompt解决，因为Prompt本身就来自PRD，而PRD不会明确说"要检查并发扣款"。
V3.0 的解决方案：体系化知识注入
V3.0 的核心主张是：把测试相关的"知识资产"系统化地赋予 AI，让它在生成时能够主动调用。这些知识资产包括：
(1) 文本测试物料
-
PRD、技术方案、代码 DIFF - 关键：这些是"前台"信息
(2) 多模态测试物料
-
UI 原型图（Figma）、流程图、架构图 - 好处：直观展示交互逻辑，弥补纯文字理解的不足
(3) 历史用例知识（通过RAG召回）
-
有效历史用例库 -
历史缺陷记录（最重要） - 机制：当生成"支付"相关用例时，系统自动检索出历史的"支付并发扣款缺陷"，引导生成流程补齐这个测试点
(4) 业务私域知识（需要业务方维护）
-
业务规则图谱：支付流程有哪些核心规则 -
团队用例模板：特定业务场景的标准测试框架 - 核心价值：把"经验"变成"规则"，可复用
RAG（Retrieval-Augmented Generation）在这里的用法非常实用，例如，当生成"直播送礼"相关用例时：
查询：系统构造查询词“直播送礼场景 + 历史缺陷”
检索：从缺陷库中召回Top-K最相关的历史缺陷记录，如"并发送礼导致重复扣款"
增强：将这些缺陷记录注入到Prompt中，引导LLM生成相关的测试点
生成：LLM 基于原始需求+RAG 召回的知识，生成更全面的用例
关键指标变化：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 历史缺陷覆盖 |
|
76% |
|
最后这个数字特别重要——从12%跳到76%，说明知识工程的引入彻底改变了用例的"缺陷敏感性"。
V3.0 的代价与限制，演讲中坦诚的问题：
Review成本依然高：虽然采纳率提升，但QA的审核工作量没有显著下降
知识维护成本上升：快手维护了170+个业务私域模版，需要专人维护
知识更新滞后：新业务规则的上线和知识库的同步存在时间差
这引出了最后一个问题："知识能否自动沉淀和更新？"
五、V4.0：Agentic 自进化——闭环质量飞轮
V3.0 已经是一套完整的、性能不错的系统。但它仍然是"人工维护驱动"的——每一个新的业务规则、每一条历史缺陷，都需要人工加工、标签化、导入知识库。
V4.0 的核心创新是：让系统具备自我发现、自我纠正、自我进化的能力。
这包括三条主线：
(1) 自主决策 & ReAct Loop
用户提交任务后，系统进入一个自主推理→观察→行动的循环：
输出最终用例集合，关键的三层资产在这里被充分利用：Skills 技能包：全局/团队/个人，支持差异化扩展（快手内部已支持170+种定制 Skill）
Memory 记忆：用户偏好、历史会话、上下文关联
Knowledge 知识：业务知识图谱、历史用例、缺陷记录等
具体例子：
-
用户反馈："帮我标注优先级，PO 优先" -
系统记录到 Memory： 用户偏好 = {PO 用例置顶，优先级必须标注} -
后续生成：AI 自动在所有用例中标注优先级，并把 PO 相关用例置顶
(2) 自主评审 & Review-Critique机制
V3.0 时，Review 是人工操作。V4.0 把 Review 自动化成一个可迭代的 Agent 行为：
关键创新：评审不是 Yes/No 的二值判定，而是结构化的反馈维度。当评审发现"场景不完整"时，AI 会针对性地补齐场景；发现"步骤不清晰"时，会细化步骤。
模块级评审（对测试点拆分的评审）：
-
覆盖完整性：是否覆盖了 PRD 的所有功能点 -
结构合理性：模块划分是否合理 -
层级清晰度：逻辑层级是否清晰 -
命名规范性：命名是否符合团队规范
用例级评审（对单条用例的评审）：
-
PRD 覆盖度：这条用例覆盖了 PRD 的哪些需求 -
场景完整性：测试场景是否完整（正常/异常/边界） -
用例余性：是否有冗余步骤 -
步骤清晰度：每一步是否清晰可执行 -
预期明确性：预期结果是否能判定 -
优先级合理性：优先级标注是否合理
(3) BadCase 规则库 & 自进化场景规则模板
这是V4.0最"魔法"的部分——低质量用例本身成为改进的燃料。
机制设计：
BadCase收集：QA用户标记生成的低质量用例为BadCase
规则库构建：系统从BadCase中提取模式，这条用例为什么不好？覆盖不全？还是步骤模糊？分类存储为"规则"
自动召回：后续生成时，如果场景类似，系统自动触发规则纠正
知识沉淀：单一场景规则 → 相似场景聚合 → 通用规范
V4.0实施效果的关键数字：
"场景规则模板更新从天级降到 5 分钟，维护成本下降 99%"
这意味着什么？以前需要业务方和QA专家花一整天讨论、标准化"直播送礼"场景的测试规范；现在系统自动从历史用例中提取规则，整个更新过程不超过5分钟。
数据飞轮的形成
每一轮都会自动沉淀新的知识规则。随着使用次数增加，系统"学到"的业务规则越来越多，生成的用例质量越来越接近资深 QA 的水平。
V4.0 的成绩单
使用范围：全公司规模推广，支持 120W+累计生成用例。
六、智能用例执行：从"能生成"到"能可靠执行"
讲到这里，一个自然的疑问是：好的用例生成了，执行呢？传统业界通常有两条路：
路线A：UI 自动化脚本 + AI 自愈
优点：操作稳定性高，脚本定位元素很可靠
缺点：规则复杂时灵活性不足，一旦 UI 大改就全得重写
路线B：AI自由探索（纯AI代理）
优点：适应能力强，灵活应对 UI 变化
缺点：缺乏明确的测试意图约束，容易"漫无目的地探索"，成功率难以保证
快手的第三条路：测试意图驱动
快手提出了一条"中间道路"：
"让用例本身承载明确的'测试意图'，同时让执行引擎在这个意图约束下自主规划和执行。"
这要求两个前提：
前提1：用例必须是 AI-Friendly 的
区分两类用例：
AI-Friendly 用例的四个关键特性：
精简全面：不丢测试点，但不冗余
原子化步骤拆解：一个操作一个步骤，不含隐含假设
可观测预期结果：每一步都能对照判定
环境依赖显性化：登录状态、入口路径、运行环境都要写明
具体例子：
关键要素都在这里：明确的登录账号、路径、每一步的预期、没有"应该看起来差不多"这样的模糊表述。
前提2：执行引擎的"四觉"能力
演讲提出了 GUI 测试智能体的执行流程：
这个"四觉"（感知-决策-执行-反馈）配合上"意图约束"，形成了一套相比"纯AI探索"更可靠、相比"脚本自愈"更灵活的中间方案。
一站式流程：生成→执行→报告
演讲展示了完整的"KATE"平台体验：用户在一个界面上完成从"上传PRD"到"查看执行报告"的全流程。
七、四层架构方法论：为什么能持续进化？
V1→V4 的演进过程，本质上是通过四层递进的方法论指导的：
这四层并不是并列的，而是形成了"信息流→反馈流→知识流→能力流"的连续链路。第一层：场景分层——选对战场
不是所有功能都值得用 AI 生成用例。先攻容易成功的，再扩大战果。
演讲给出的优先级评估矩阵：
实践路径：
优先突破：覆盖类问题（遗漏/不完整）和质量类问题（步骤模糊），快速达到 50%+ 生成率，建立信心
重点攻关：垂类场景、主站核心功能，引入私域知识深耕特定领域，冲击更高覆盖率
快速扩展：基于已有模版，快速复制到新场景
开放共建：复杂场景邀请业务方参与
第二层：用户运营——BadCase 驱动闭环
这一层的关键思想是：低质量用例不是失败，而是改进的信号源。
这个循环每一轮都会自动累积经验，减少重复犯同样的错误。
第三层：知识运营——自动沉淀
将知识资产的生命周期自动化：
7.5 第四层：Agentic 架构——持续进化
以 Agent 为核心，构建支撑"自主决策→自主评审→知识自进化"的基础设施：
- System Prompt 动态组装
- Skills 快速差异化扩展
- Memory 用户偏好学习
- Knowledge 自动沉淀与检索
八、总结：端到端智能测试的未来形态
演讲的最后给出了一张蓝图——快手心目中的"端到端智能测试"应该是什么样子：
但更重要的是这个系统应该具备的三个"更"：(1) 更丰富的使用方式
-
Skill 化：定制化技能库，支持垂直行业与业务特色 -
使用方式多样化：不仅是"输入 PRD 生成用例"，还支持"基于代码 DIFF、基于原型图"等多种输入
(2) 更自主的知识沉淀
-
历史用例/缺陷库的自动学习 -
业务测试场景知识库的自动构建 -
评审 BadCase 库的自动优化
(3) 更高效准确的执行
-
历史执行记录与测试路径知识库的复用 -
成功步骤的智能复用与优化 -
业务数据构造 Skill 库的持续丰富
从业界的同时期探索来看，这条路径的正确性得到了多个维度的印证：
NVIDIA 的HEPH框架，强调从需求/架构文档到测试规范的追踪映射，并在执行后收集覆盖率数据反馈——与快手的"知识召回+自主评审+数据飞轮"方向完全同构。
Google Firebase 的App Testing Agent，允许自然语言定义测试目标，并将每个测试拆成步骤、为每一步提供成功标准——与快手的"AI-Friendly 用例结构化"思路一致。
开源Test-Agent社区，指出复杂测试流程需要与测试领域工具和工程体系融合，通过专用工具与模型协同提升鲁棒性——与快手的"Multi-Agent 分工"思路吻合。
这说明"从单体 LLM Prompt 到 Multi-Agent 协作，再到知识工程和 Agentic 自进化"是业界的共同演进方向，而非某一家公司的孤立探索。
核心规律总结
从 V1.0 到 V4.0 的四阶进化，我们可以提炼出几条关键规律：
规律1：任何工作流的自动化，都应该先复制其"分阶段审查"的结构，而非试图"一步到位"。
V1 的失败正是因为试图用单个 Agent 完成"从 PRD 到用例"的全流程；V2 通过分阶段拆分和中间 Review，显著降低了错误。
规律2：生成的质量上限由"知识的丰富度"决定，而非由"Prompt的精妙程度"决定。
V3 从 35% 生成率跳到 V4 的 70% 生成率，关键不是 Prompt 更聪明了，而是知识工程体系让 AI 能"见多识广"。
规律3：低质量数据（BadCase）的系统化收集和分析，是"自进化"的唯一可靠燃料。
V4 的自进化能力本质上来自"错误→规则→自纠正"的闭环，这个闭环必须由真实的用户反馈驱动。
规律4：AI 最终会取代人工最高频的工作，但永远取代不了人工的最关键决策。
从 V1 到 V4，AI 的自动化程度从 8% 生成率提升到 70%，看似是"接近人工"了；但真实情况是，AI 现在处理的是"标准、可规则化的部分"，而人工则集中在"审核、纠偏、知识维护"这些关键决策上。
九、对实践者的建议
如果你的团队也想沿着这条路走，演讲给出的建议非常实用：
优先级选择
从高价值、低复杂度场景开始，而不是一上来就用AI处理最复杂的需求。
快手的经验是：选择"遗漏/不完整"类的问题和"步骤模糊"类的问题作为切入点，快速建立50%+的生成率，团队信心上来了，后续扩张才会顺利。
知识资产的重视
第一优先级是"历史缺陷库"的建设和维护，其次是"业务规则模板"，最后才是"Prompt优化"。
因为知识决定了上界。花10个人日优化Prompt，收益有限；但花2个人日补齐一个关键的业务规则，收益是倍级的。
反馈闭环的设计
从 V1 就要开始设计"用户反馈→问题分类→改进验证"的闭环，而不是等到V3/V4 才考虑。
因为有效反馈的积累，才是后续版本迭代的养分。
人机边界的明确
不要试图让 AI"完全自动"地生成用例。要明确地定义"AI负责什么、人负责什么"，这样系统才能稳定可控。
快手的最佳实践是"AI负责生成、人负责Review"，这个分工看似简单，但在整个系统中起到了"降低失败率"和"快速反馈"的关键作用。
结语
从8%的可行性验证、到70%的规模化覆盖；从"正确但泛"的生成用例，到"懂业务、会自进化"的智能系统——快手在"智能 UI 用例生成与执行"上的四阶进化，不仅仅是一个技术演进的案例，更是一个"工程系统从脆弱走向稳健"的过程。
关键洞察是：真正的AI赋能，不是"AI 代替人"，而是"AI +人 +工程系统"的三角形共振。当这三个要素配合得当时，质量体系就能从"人工驱动"升级到"数据驱动"，再进一步到"自进化驱动"。
在这条路上，快手已经走出了一个"从 V1 的可行性到 V4 的自进化"的完整样本。而对于其他团队来说，这份样本最宝贵的地方，或许不在"具体用了什么 LLM"或"调用了哪些 API"，而在于"为什么这样拆解问题、为什么这样分阶段演进、为什么这样设计反馈闭环" ——这些才是真正可复用的方法论。
