9 月 1 日晚的「智能化测试·测试用例生成公益训练营」，我们从一个更贴近研发现场的问题切入：面对一个已经运行多年的业务系统，怎样让模型找到正确资料、理解规则关系，再给出能被验证、被追溯、也能持续更新的测试用例？
截至 22:01 的现场截图，已有 3025 人看过。临近结束时，评论区里有人直接追问“项目中的 flaky 用例如何定位和管理”，也有人把关注点放到上下文、知识图谱粒度、代码与文档更新、开发实现与需求不一致等真正会影响落地的问题。
AI 测试用例生成，难的从来不是“写出来”
把一份需求丢给模型，再补一句“从功能、异常、边界等维度生成测试用例”，几十秒就能得到一大段输出。
问题是，看上去很全，不等于项目里能用。
模型默认不知道：
这个业务曾经踩过哪些历史 Bug；
某个“看起来正常”的流程，在哪些角色、时间、状态下会失效；
产品原型、接口约束、研发实现、已有用例之间，哪一份才是当前可信的事实；
一个结论来自哪段需求、哪条规则，测试人员该如何复核。
所以，AI 测试用例生成不应该理解成“换一个更厉害的 Prompt”。它更像一条有输入、有检索、有推理、有验证出口的工程链路：
业务资料进入知识库 → 检索与关联规则 → 识别测试风险 → 输出结构化用例 → 人工审核与持续更新。
评论区里有两个问题，正好把这条链路的难点说透了：知识图谱里要不要放前置条件、预期结果？只做到特性级关联，能不能生成足够细的测试用例？
答案不是“图谱越大越好”，而是要让它为测试决策服务。一个可用的测试知识结构，至少要把业务对象、状态、角色、规则、前置条件、异常分支、预期结果、历史缺陷与证据来源连接起来。
如果只有“功能 A 关联功能 B”这种粗颗粒关系，模型最多写出一份泛泛的检查清单；如果能进一步定位“某角色 + 某状态 + 某个时间条件 + 某条业务规则”，它才有机会生成真正可执行的边界与异常用例。
先让 AI 看见业务，而不是让它猜业务
这场实操中，一个很关键的环节是“业务知识库建设”。它不是把 PRD 一股脑塞进对话框，而是从多个信息源还原一个业务系统：
需求文档里的业务逻辑与业务架构；
原型设计里的页面结构与交互流程；
研发代码里的业务细节、数据类型与页面结构；
对被测系统的实际探索，包括真实流程、数据和最终呈现。
图片
这也是 RAG 在 AI 测试里的第一层价值：让模型在回答前，先从可信资料里取回证据。
但只做“相似文本检索”还不够。测试场景经常不是一句需求能解释的。例如“上下班打卡”这件事，可能同时受到早退、特殊日期、审批、设备、企业微信、补卡申请等规则影响。模型若只检索到“打卡”这一个词，很容易漏掉间接约束。
RAG 负责找证据，知识图谱负责找关系
这正是知识图谱进入测试场景的意义。
在直播实操画面里，可以看到“上下班打卡”“特殊日期打卡”“早退”等业务节点及其关联。它不是为了画一张好看的图，而是为了把散落在文档、代码和页面里的规则，变成可以被追踪、扩展和验证的关系网。
更实用的组合方式是：
RAG 先召回原始需求、接口说明、历史用例和缺陷记录，给模型可引用的事实依据；
知识图谱再补充业务对象之间的关联，帮助模型找到隐含的规则与影响范围；
Agent 按固定步骤拆解任务：识别范围、检索资料、补齐风险、生成用例、标出证据；
测试人员审核高风险边界，并把确认过的结果沉淀回用例库和知识库。
这样生成的用例，才不只是“模型觉得合理”，而是能回答三个关键问题：依据是什么？漏了什么？需求变了以后怎么更新？
DeepSeek Harness、Skill、MCP、Subagent：不是工具清单，而是工作流
这次公开课里出现的 DeepSeek Harness、Skill、CLI、MCP、RAG、Subagent，容易让人误以为测试工程师必须把所有工具都学一遍。
其实不必。
真正需要建立的是一条可控工作流：
Harness：把一次任务变成有步骤、有状态、有反馈的执行过程；
Skill / MCP / CLI：让智能体能按权限读取资料、调用检索、执行校验，而不只停留在聊天窗口；
Subagent：把检索、页面探索、用例设计、结果校验等任务适度拆开，避免一个 Agent 同时承担所有工作；
RAG 与知识图谱：把长期业务知识放在可复用、可更新的外部体系里，而不是赌模型一次会话“记得住”。
临近结束时，现场就有人追问：重复生成多个模块的用例，一旦超过上下文限制，即使用了子智能体，会不会还是丢信息？
这个问题非常专业。Subagent 不是“无限记忆外挂”。
跨任务要继承的，不该只留在某个 Agent 的聊天记录里，而要沉淀成可访问的共享资产：需求版本、规则节点、案例库、历史缺陷、检索索引、输出规范。子智能体负责的是把任务范围和职责划清；真正保证连续性的，是外部知识、引用关系和更新机制。
同样，开发提测内容和需求实现不一致时，AI 也不该替团队“猜一个答案”。更可靠的做法是让它把冲突标红：一边给出需求证据，一边给出页面或接口实际证据，并把“需要产品/研发确认”的项单独列出。AI 的价值不是掩盖不确定性，而是更早暴露不确定性。
测试工程师接下来要练的，是“让 AI 按测试思路工作”
未来的差距，可能不在于谁更快生成一百条用例，而在于谁能把下面四件事设计清楚：
知识从哪里来；
用例按什么标准生成；
模型输出如何被验证；
系统变化后如何更新。
从“让 AI 写用例”走到“让 AI 参与测试流程”，中间隔着的正是这套工程化能力。
