用产品测试用例训练垂类 AI Agent：让 Agent 真正「懂」一个产品

用产品测试用例训练垂类 AI Agent：让 Agent 真正「懂」一个产品

最近带团队做垂类 AI Agent，我遇到一个老问题——通用模型对业务的理解永远停留在表面。问它「这个用户画像页应该展示哪些字段」，它能给出一个行业通用答案；但问它「我们的付费转化漏斗为什么第三步比第二步跌得厉害」，它两眼一抹黑。不是模型不行，是它没「住」在我们的产品里。

后来同期在推进产品 QA，我突然意识到一件事：我们每写一条测试用例，本质上是在把产品的业务规则、边界条件、预期行为翻译成可验证的自然语言。这不就是最理想的领域知识语料吗？于是我们把 Agent 训练和产品测试合成了一件事做，收获比预期大得多。

一、为什么测试用例是训练垂类 Agent 的最佳载体

大多数团队做领域知识灌注，第一反应是扔文档。但产品文档有三个通病：写得晚（功能上线才补）、写得糙（只讲 what 不讲 why）、跟代码脱节（改了代码不一定改文档）。测试用例恰好相反——它必须写在功能之前或同步、必须覆盖正反路径、必须和真实产品行为严格一致，否则测试根本跑不通。

也就是说，一份高质量的测试用例集合，本身就是产品行为的「可执行规范」。Agent 吃这种语料，不只是在学事实，而是在学这个产品的「判断标准」——什么是正确的，什么是异常的，什么算边界情况。这和读一份 PRD 完全不是一个量级的信息密度。

二、我们具体怎么做的

流程很朴素：让 Agent 作为主执行者去跑测试，而不是由人工 QA 执行、Agent 事后被动学习。每跑一个用例，Agent 需要做四件事——读懂用例的业务意图、在真实环境里执行验证、记录实际表现和预期的差异、把差异归类（是 bug、是规格不清、还是测试用例过时）。

关键细节在这里：我们强制要求 Agent 在每个用例跑完后，用自己的话把「这个功能在做什么、为什么这么设计、跟哪些上下游耦合」写成一段摘要，沉淀到知识库。这一步看着多余，但它是质变的来源——Agent 不再是一个执行器，而是在一边跑一边构建产品心智模型。三百条用例跑下来，它对产品的理解深度，已经超过刚入职三个月的新人。

三、一举两得的经济账

这个做法最让我意外的是它的 ROI 结构。传统路径下，训练领域 Agent 要单独投入语料整理成本，做 QA 要单独投入测试执行成本，两份工作互不相通。而我们这条路径里，测试执行过程的每一秒都同时产出两个交付物：一份可交付给产品经理的测试报告，一个对产品理解持续加深的专家 Agent。语料不是额外成本，是测试工作的自然副产品。

还有一个隐性红利：当测试用例和 Agent 知识库共用同一份源，规格和实现之间的漂移会被自动捕捉。文档不会再有「上个版本写的」这种问题，因为它和测试执行在同一条管线上。

可复用的三条原则

**原则一：选择本身就是规范的知识载体。**文档不是好语料，因为它可以和现实脱节；测试用例是好语料，因为它必须和现实一致，脱节就跑不通。

**原则二：让 Agent 做执行者而非旁观者。**被动灌输得到的是死知识，主动执行才能积累出可迁移的判断能力。这一步不能省。

**原则三：把过程产物做成交付物。**不要单独为 Agent 训练付成本，找到那条能同时产出业务交付和知识沉淀的工作流，ROI 才立得住。

如果你在构建 AI 工程团队，欢迎参考我们开源的 Synapse 框架——它把 Multi-Agent 协作、知识沉淀和任务执行整合成一套可复用的 Harness，这篇文章里的实践就是在 Synapse 上跑起来的。