我给AI喂了200页文档,用例还是不准

知识库不是文档仓库。问题不在喂得少，在你喂的方式。

一、先说个让我怀疑人生的事

去年我们团队第一次试 AI 生成用例，我把能找到的文档全塞了进去——PRD、接口文档、历史用例、测试计划、几份过期的规范，加起来两百多页。

结果生成出来的东西，评审的时候被问得一句话都答不上来。

最典型的一条：它写了个"验证订单金额可以手动修改"的用例。我们系统里订单金额是服务端算的，前端根本没有可编辑的入口。它编的。

而且它编得特别自信，前置条件、步骤、预期结果一应俱全，看着比人写的还规整。

后来我才想明白一件事：我塞进去的两百页文档，跟它生成这条用例之间，几乎没有关系。 它压根没检索到我真正需要的那几条规则，是自己"合理想象"出来的。

这不是个例。快手研发效能团队公开过一条完整的演进曲线，我觉得是每个做 AI 测试的人都该看一眼的：

看 V2.0 到 V3.0 那一跳——从 12% 到 35%，接近三倍。这中间模型没换，算法框架没大动，唯一的变化是：开始给它喂"知识"了。

快手自己的总结是 V3.0 这一阶段"揭示了知识比算法更关键的本质规律"。

同一时间另一组数据也印证了这点。阿里云开发者社区有一篇从 0 到 1 做测试用例生成智能体的实战记录，对比了三种配置下的人工审核通过率：

• 纯大模型：32%
• 大模型 + RAG 知识库：58%
• 再加知识图谱和智能体：89%

关联场景覆盖率则是 41% → 63% → 94%。

但故事还有另一面。有团队看到"喂知识有用"，就开始疯狂地喂——把五年的聊天记录、旧 SOP、历史文件一股脑全倒进知识库，指望 AI 变得无所不知。

结果出了一次事故：新员工拿着 AI 生成的 SOP 去执行，里面引用的是一份 23 年前的旧政策，罚款标准完全是错的。

因为那五年的文件里，新旧版本混在一起，没有任何版本控制和隔离。AI 随机检索到了最老的那一份，然后理直气壮地输出了。

这两件事放在一起，就是这篇文章想讲的全部：知识库不是"文档越多越好"，也不是"传上去就完事"。你喂得不对，两百页和零页的效果差不多；喂了脏东西，甚至比不喂更糟。

二、先想清楚一件事：AI 到底缺的是什么

很多人建知识库，是把"我觉得重要的资料"传上去。这个出发点就偏了。

正确的问法是：通用大模型已经会什么，还缺什么？

已经会的，你不用喂：等价类划分、边界值分析、场景法、判定表、正交表……这些测试方法早就在它的训练数据里了，你写篇文档教它怎么做边界值，纯属浪费 token。

它缺的是另外四样东西，而这四样只存在于你们公司内部：

1. 你们的字段和取值空间
订单状态到底有哪几种？是"待支付/已支付/已取消"，还是还有"已发货/退款中/已完成"？优惠券有没有"已冻结"这个中间态？

这些如果不给，AI 就会自己造。它造出来的状态名往往听起来很合理，但你们系统里根本不存在——这就是最常见的幻觉来源。

2. 你们的业务规则
满减能不能和折扣券叠加？库存为 0 的时候是拦截还是允许超卖？同一个用户 5 秒内重复提交会怎样？

这些是它最缺的，因为这类规则通常散落在老员工的脑子里、几年前的会议记录里、或者早就没人维护的 wiki 里。

3. 你们踩过的坑
上个月那个超卖的线上故障，是因为"库存为 0 没有拦截"——这条知识，通用模型再聪明也不可能知道。

4. 你们认可什么样的用例
用例要多细？要不要写前置条件？预期结果写到什么颗粒度？优先级怎么分？

这不是能力问题，是规范问题。得给它看你们评审通过的样本。

一句话概括：AI 缺的不是"测试方法论"，是"你们公司的事实"。

所以有个比喻我觉得很准——把 AI 当成一个"聪明但不了解业务细节的实习生"。

实习生适合干的：枚举边界值、穷举异常输入组合、补充已有场景的细节、按格式批量产出。

实习生不适合干的：定核心功能的验收标准、判断哪个模块出事会要命、决定测试深度。

你喂知识库的目的，就是把这个实习生不了解的那部分业务，补上。

三、四类资料，分别该怎么喂

不是所有文档都值得喂，喂法也不一样。我按"该先喂什么"的顺序排。

1. 结构化事实层——先喂这个，性价比最高

这是最该优先整理、也是最容易被忽略的一类。包括：字段字典、状态机、枚举值、业务规则表。

关键是：别用自然语言描述，要转成机器能理解的结构。

比如"订单状态"这一项，不要写成：

订单有多个状态，包括待支付、已支付、已取消等，用户下单后是待支付，付款后变成已支付……

要写成：

order.status ∈ {待支付, 已支付, 已取消, 已发货, 退款中, 已完成}

业务规则同理，从自然语言转成像断言一样的表达：

IF user_type = 'VIP' THEN shipping_fee = 0
discount_amount <= order_amount   （优惠金额不能超过订单金额）

为什么这么写有效？因为它把 AI 的"合法取值空间"限定死了。

你给了 status ∈ {待支付, 已支付, 已取消}，它就不太可能编出一个"已锁定"出来。你给了 discount_amount <= order_amount，它就不会生成一个"优惠 150 元、订单 100 元"的用例。

这类结构化事实，是抑制幻觉性价比最高的一份投入。阿里云那篇实战里，从 32% 提到 58%，主要就是靠这一层加上历史用例。

2. 历史缺陷库——最值钱的一份

如果要我只能保留一份资料，我选这个。

原因很简单：它记录的是你们公司真实出过事的地方。通用模型的知识来自全世界的公开代码，但它不知道你们上个月为什么加班。

喂的时候，一条缺陷至少要包含这几项：

• 模块
• 触发场景
• 复现步骤
• 根因
• 修复方案
• 最关键：当初为什么没测出来（缺失的测试场景）

最后那一项是最容易被漏掉的，但恰恰是最有价值的。因为它直接告诉 AI："这类场景，以后必须覆盖。"

快手在分享 V3.0 的时候提到，RAG 召回给用例生成带来的价值里，最重要的一条就是"带入了历史缺陷经验"——他们举的例子是并发重复扣款、支付超时重复订单。这两个场景，纯靠模型自己想，几乎不可能想到。

他们还有个 Badcase 驱动的闭环例子很值得抄：用户反馈"直播送礼场景缺少并发送礼的测试点"，追根因发现是知识库里没有并发场景的历史缺陷数据。于是补进缺陷库、在规则库加一条"支付场景必验并发"，后续生成自动召回，这类 Badcase 就不再出现了，场景覆盖率提到 92%。

注意这个循环的方向：不是去改提示词，而是回去补知识库。

3. 历史优质用例——教它什么叫"我们这儿的好用例"

挑已经评审通过的、线上验证过的用例喂进去。别把没评审的、废弃的也一起倒进去，那等于给它看范文的同时混了一堆错字。

这份资料解决的不是"测什么"，而是"写成什么样"——步骤粒度、命名规范、前置条件要不要写、预期结果写多细。

快手 V1.0 阶段做过一个 Few-shot 的对比测评，有两个发现我觉得挺实用：

• 给 3 个样例是性价比最优的，再往上加边际收益就平了
• 样例质量远重于数量：1 个高质量样例 > 5 个低质量样例

所以挑样本这件事，宁缺毋滥。

4. 需求和接口文档——当次输入，别当常驻知识

PRD、Swagger 这类文档，我建议每次生成的时候作为当次输入给进去，而不是全量塞进常驻知识库。

原因是这类文档迭代太快，塞进常驻库很快就会变成"僵尸内容"——下个版本改了，旧的还留着，检索的时候新旧混在一起，AI 自己都分不清该听谁的。

（如果一定要入库，务必带上版本号和生效时间，检索时按版本过滤。下面第六节会讲怎么管。）

四、你传的是文档，AI 读的是碎片

这一节是我觉得最"反直觉"、也最容易翻车的地方。

很多人以为：我把文档传上去了，AI 就"读"了这份文档。

不是的。它读的是一个一个被切碎的片段（chunk）。 你的文档在入库那一刻就被切成了几百个小块，检索的时候只能捞到其中几个小块。

所以——切片切错了，你文档再全也白搭。

按文档类型分别切，别用一把尺子

这是最核心的一条。不同文档有完全不同的"自然语义边界"，切错了意思就断了。

有个特别具体的坑：接口文档如果按固定字数硬切，一个 endpoint 的请求体在 chunk A、响应码在 chunk B，那 AI 生成的用例里，断言就开始编了。

一个马上能用的技巧：把小标题前置到每个块

切出来的块脱离了原文，AI 是不知道自己在读什么的。

解决办法很简单——在每个块的开头，把它的上级标题拼上去：

## 订单状态机 > 已取消
（块内容……）

这样哪怕这个块只有一两句话，AI 也知道它属于"订单状态机"下的"已取消"。这个改动成本极低，但对准确率的提升很明显。

还有个"找对了文档但缺上下文"的解法

有时候检索确实命中了正确的位置，但那个块太小，缺了前因后果，AI 还是答不好。

这时候用 parent-child 检索：用小块去做索引和匹配（匹配更精准），命中之后，把它的父级大块喂给模型（上下文更完整）。

这一招专门治"明明文档里有，但 AI 就是没读全"的情况。

参数给个起点，别纠结

• 块大小：256–512 token（要精准检索）到 512–1024（要更完整上下文），先从这个范围起步
• 重叠 overlap：**10–15%**，防止关键信息正好被切断在边界上

这些数字不是圣旨。真正该做的是拿几条真实需求去试，看检索回来的块对不对——直接查向量库、不经过模型，看 top 结果相不相关，这是判断切片好坏最快的方法。

五、检索：别让 AI 在全库里瞎找

喂对了、切对了，还有最后一道关：检索。

先过滤，再检索

检索之前，先用元数据把范围缩到最小。

每个块都应该带上元数据：来源文件、文档类型、模块/组件名、版本、日期、标签。

比如你要生成购物车的用例，就先过滤"模块 = 购物车 或 支付"，然后再在这个小范围里做语义检索。别上来就在全库里搜——全库越大，噪声越多，越容易捞到看起来相似、其实无关的东西。

语义 + 关键词，两个都要

纯语义检索有个致命弱点：精确词匹配不到。

订单号格式、错误码 ERR_20031、SKU 编码、内部缩写——这些对语义模型来说就是一串没有意义的字符，但它对你的用例来说可能至关重要。

所以要用混合检索：语义（向量）召回 + 关键词（BM25）召回，再把两路结果融合排序。产品码、错误码这类东西，只能靠关键词捞。

捞一堆，再精选，别一股脑全塞

检索 10–20 个候选，然后重排序（rerank），只把最相关的 3–5 个喂给模型。

这一步很容易被跳过，但它很重要。上下文不是越多越好——塞进去一堆勉强相关的碎片，反而会干扰模型，还会让成本飙升。

另外有个细节：最相关的块放在上下文的开头和结尾，中间的权重最低。模型对一长段输入的"中间部分"注意力最弱，这是有实验依据的。把最关键的东西放两头。

六、减法比加法重要：这些东西喂进去是毒药

前面都在讲"喂什么"，这一节讲"绝对不能喂什么"。

有一句话我认为是这一整件事里最该记住的：AI 不修复坏数据，它放大坏数据。

以前有份过期的 PDF 躺在知识库角落里，一年也没人点开过。现在接上 AI 之后，它会用无比自信的语气，把那份过期内容念给每一个提问的人听。

头号杀手：过期和僵尸内容

已下架模块的手册、过期活动的规则、没人删的旧版本、写着"最终版_v2_真的最终"的文件……

对语义检索来说，一份 2023 年的旧促销规则和今天的有效规则权重是一样的。它甚至可能因为措辞更接近你的提问而被优先捞出来。

前面那个"23 年前旧政策"的事故，就是这么来的。

落地做法（这是一套现成的减法流程，可以直接抄）：

1. 打标签：所有文档标上生效日期 / 失效日期、版本
2. 归档隔离：历史版本移到 _ARCHIVE 目录，明确禁止 AI 检索
3. 清垃圾：删掉未定稿的草稿、纯情绪化的聊天记录、没有结论的会议纪要
4. 定期扫：每月全库扫一次，让 AI 帮你标出"超过一年且没标生效中""内容自相矛盾""纯流水账无结论"的文档，人工确认后处理

矛盾文档：AI 会随机站队

A 文档说退货期 30 天，B 文档说 15 天，内部 FAQ 写"问一下主管"。

人看到会去核实，AI 不会——它按提问的措辞随机捞一个，然后言之凿凿地输出。

所以入库前必须做一次矛盾排查：挑五条最重要的规则，全库搜一遍，看是不是有多个版本。

部落知识：最值钱，也最容易被忽略

真正要命的规则，往往只存在于老员工的脑子里——"这个接口其实有个隐藏的限流，压测的时候要注意""这个字段虽然允许为空，但下游会崩"。

这些没写下来的东西，对 AI 来说等于不存在。

而把这些隐性知识写下来，是整件事里最值钱的工作——因为它是别人抄不走的护城河，而且没人能替你做。

敏感内容：分区隔离

薪资数据、未发布战略、个人隐私……这类内容应该在源头就隔离掉。

一个简单原则：凡是 AI 能读到的，它迟早会说出去。

可以分三个区：绿区（公开，AI 可全量访问）、黄区（内部，审批后可访问，月度复核）、红区（AI 禁止访问，物理隔离）。

七、从哪开始：别建全系统知识库

最后一个建议，也是最重要的一条：不要一上来就想建一个覆盖全系统的知识库。

阿里云那篇实战里列的第一条坑就是这个——"知识图谱建得太大，一上来就想覆盖全系统，结果建了三个月还没建完，项目直接烂尾"。

最小启动：啃一个模块

第一步，选一个模块。 挑规则密集、价值高的——订单、支付、优惠券、审批流这类。别选那种逻辑简单、怎么测都不出事的模块，看不出效果。

第二步，准备一个最小知识包。 就四样东西：

1. 字段字典 + 状态机 + 枚举值（结构化，写成断言/集合）
2. 业务规则表（自然语言转 IF-THEN）
3. 近半年的历史缺陷（含"当初为什么没测出来"）
4. 5–10 条评审通过的优质用例（当范文）

这个量，一个人一两周能整理完。

第三步，拿真实需求跑一遍，然后——收集 Badcase。

这一步是整套东西能不能转起来的关键。不要指望一次建好。

跑出来不准的用例，别急着改提示词，先问一句：是知识库缺了什么？

缺了才补。这是快手 V3.0 到 V4.0 的核心方法——Badcase 是进化燃料，每个不准的用例都是一次给知识库补货的机会。

（顺带说一句，快手在 V3.0 阶段维护了 170+ 套业务模板，后来发现人工维护跟不上，改成让系统从历史数据里自动提炼。他们的提炼规则挺有意思，可以借鉴：保留出现在两个及以上场景中的规则（这是共性），过滤只属于单个需求的特殊逻辑（这是个性），并且必须列出具体的验证点，不能写"参考历史模板"这种笼统的话。）

怎么验收：看采纳率，不看生成量

判断知识库有没有用，最实在的指标就是人工审核通过率 / 采纳率——生成的用例，人看一眼能直接用（或微调就能用）的占多少。

几个可以参考的基线：

• 纯大模型起步：30% 左右（阿里那个案例是 32%）
• 加上结构化知识 + 历史用例：能到 55–60%
• 再加上历史缺陷库和检索优化：80%+ 是够得着的

别盯着"生成了多少条"。有个团队一开始追求一次生成几十条，后来发现与其生成一堆要大改的，不如精准上下文加严格约束，一次生成 3–5 条高质量的——团队接受度反而高得多。

写在最后

回到开头我那个翻车的例子。

"验证订单金额可以手动修改"——这条用例之所以会被生成出来，不是因为模型笨，是因为**我给它的两百页文档里，没有一条明确写着"订单金额由服务端计算，前端不可编辑"**。

这条规则当时存在于哪里呢？存在于我们组一个老同事的脑子里。他知道，所以他从来不会写错。但它从来没被写下来过。

后来我把这类"老同事脑子里的规则"一条条抠出来，整理成一张不到两页的规则表，重新喂进去。再生成的时候，这类低级幻觉基本消失了。

这件事让我真正想明白的是：建知识库这件事，表面上是个技术活，实际上是个"把隐性知识显性化"的活。

你整理知识库的过程，其实是在给整个团队的经验做一次盘点。哪怕最后 AI 一个用例都生成不好，这张规则表本身就已经值回票价了。

📚 参考来源

这篇文章里的两组核心数据都来自公开分享，建议直接看原文：

1️⃣ 快手：生成率从 8% 到 60%

《生成率从 8% 到 60%：快手智能测试用例生成系统的四阶进化》——快手研发效能团队

完整讲了 V1.0 到 V4.0 每一阶段的做法、踩过的坑和测评数据。想知道"喂知识"到底带来多大变化，看这篇最直观。

🔗 https://www.163.com/dy/article/KQ5LAF1T0511D3QS.html （长按复制链接到浏览器打开）

2️⃣ 阿里云开发者社区：从 32% 到 89%

《从 0 到 1 打造测试用例生成智能体：RAG+知识图谱实战全记录》

对比了纯大模型 / RAG / RAG+知识图谱三种配置的通过率与覆盖率，文末还有一份避坑指南——知识图谱别建太大（建了三个月烂尾）、RAG 和图谱要做融合检索、图谱要能自进化。

🔗 https://developer.aliyun.com/article/1759748 （长按复制链接到浏览器打开）

你们团队的知识库，是怎么建的？

有没有踩过"文档喂了一堆但没用"的坑？或者整理出过什么特别好用的资料？评论区聊聊，我挑几个典型的在下期做一期合集。

另外——如果你们卡在"AI 生成的用例到底该怎么评审"这一步，可以看这篇：《AI 生成的用例，该怎么审？》

后台回复「AI测试」，获取测试工程师 AI 技能提升路线图 + 常用提示词模板。