别再让AI每次从零读文档了，给一张"知识地图"，它自己知道去哪找答案

大家好，我是某互联网公司的测试架构师。

上个月，团队接了一个大项目——考勤管理系统的全面改版。需求文档12份，原型图30多张，代码库10万行。测试组长看到资料清单的时候，脸都绿了。

“这怎么整？一份文档都80页了，AI上下文根本塞不下。”

我说：“你还在让AI每次都从头读文档？”

他愣了一下：“不然呢？”

我打开DeepSeek Harness，调出了三条知识库路径和一套工作流。半小时后，AI已经能从12份文档中精准定位每个功能点的业务规则，生成了覆盖考勤机打卡、WiFi打卡、HR审批全流程的完整用例集。

测试组长看完之后说了一句：“这个好，以后不用每次都重新喂文档了。”

一、先搞清楚：为什么"临时读文档"的策略失效了？

很多人第一次接触AI生成用例的时候，流程是这样的：打开Chat，上传一份PDF，输入"帮我生成测试用例"——AI读了几页，输出了几条用例，看起来还行。

问题是，真实项目不是一份文档，是十几份文档加起来几百页。AI的上下文窗口有限，根本塞不下。你只能挑着喂，今天喂登录模块，明天喂支付模块。

更麻烦的是，文档之间有关联关系——"考勤机打卡"的规则在A文档里，"HR审批"的规则在B文档里，但它们业务上是一起的。AI不知道这个关系，生成的用例永远是割裂的。

关键突破：核心是把知识从AI的"临时记忆"变成"长期资产" ——建立知识库，让AI每次需要的时候自己去查。

二、三条知识库路径：没有完美的方案，只有适合的搭配

知识库这件事，市面上有三条主流技术路线。

路径一：向量检索（Vector RAG）

它是什么？  把文档切成小段，每段转成向量（数学向量，可以理解为文本的"语义指纹"），存入向量数据库。你问问题时，系统把你的问题也转成向量，去找最"语义相近"的文档段落。

用什么工具？  Dify知识库、AnythingLLM、Qdrant

它擅长什么？  模糊查询、语义匹配——你不知道具体关键词，但想找"和考勤机相关的内容"。

它不擅长什么？  精确的关系查询——它只知道"这段内容和那段内容有点像"，不知道"考勤机和审批流程是上下游关系"。

实测感受：  在Dify里测试"考勤机如何用"，向量检索能召回相关文档片段。但如果文档里"考勤机"和"审批"隔了几十页，它可能召回"考勤机"这一段，但不一定能带回"审批"那一段——虽然它们业务上紧密相关。支持混合检索（关键词+向量）后效果会好一些，但语义理解在涉及关联逻辑时还是不够精准。

路径二：知识图谱（Graph RAG）

它是什么？  不像向量检索把文档切成碎片，知识图谱是先把文档"读懂"，提取出实体（考勤机、HR人员、WiFi打卡、管理后台）和实体之间的关系（考勤机→产生打卡记录→HR审批→入薪资），然后存入图数据库。

用什么工具？  LightRAG、Neo4j

它擅长什么？  关系查询——"考勤机和什么有关？“能精准返回"审批、WiFi打卡、HR人员、管理后台”。

它不擅长什么？  存储大段原文——它存的是"关系"，不是"文档"。

实测感受：  用Cypher语法或自然语言查"考勤机"，返回的不只是相关文档片段，而是一张关系网——考勤机连着打卡记录，打卡记录连着HR审批，审批连着薪资核算。你能看到业务的全貌，而不是零碎的片段。  更难得的是，每个返回节点都带原文出处，方便追溯校验。

路径三：本地Markdown库（IMVK方案）

它是什么？  把PDF、Word等文档全部转换成Markdown格式（一种轻量级纯文本格式，结构清晰、AI解析成本低），建立本地文件索引。需要用的时候，用Grep正则表达式直接搜关键词，找到对应的Markdown文件片段。

用什么工具？  Devika的IMVK技能

它擅长什么？  简单、本地化、不用钱——适合个人或小团队快速搭建知识库。

它不擅长什么？  跨团队协作——知识库只在你本地，别人用不了。

实测感受：  安装IMVK后，它会自动扫描根目录下的PDF文件，转成Markdown存入本地Wiki目录。增量更新很方便——新增文档只处理新文件，不重新处理旧的。检索方式就是关键字搜索，简单直接，但缺乏语义理解（你搜"打卡"就找不到"签到"的文档）。

怎么选？

实战建议：别只选一条，全都要。  我们团队现在是三条路并行——向量库做模糊召回，知识图谱做关系补全，Markdown库做本地备份。三条路的结果汇总在一起，才是完整的上下文。

三、从"临时读文档"到"建知识库"：一个真实工具演示

这里以IMVK技能为例，演示本地知识库怎么搭。

第一步：安装并执行IMVK技能

安装后执行，IMVK自动探测根目录下的PDF文件→分析内容→转换为Markdown→存入本地Wiki目录。

增量更新：  新增文档后，IMVK只处理新文件并更新知识库，不用重新处理全部文档。

第二步：多源知识库整合

不止是需求文档，UI稿、代码仓库、历史用例都能喂进去。

代码分析可以用understand工具——扫描源代码结构，生成代码级知识图谱。后端接口、函数调用关系、模块依赖，都能梳理出来。

第三步：混合检索

实际生成用例的时候，同时去三个地方查：

• 向量库查语义相关内容
• 知识图谱查业务关系
• Markdown库查精确关键词

三个结果汇总，AI拿到的是一份"带上下文的完整业务视图"。

四、从Skill到工作流：为什么需要"升级"？

知识库建好了，下一步是"怎么让AI用这些知识生成用例"。

很多人第一反应是用Skill。没错，Skill能完成"从知识库查资料→生成用例"这个任务。但当任务变复杂时，Skill开始撑不住了。

Skill的本质是提示词工程，适合无分支的线性任务。当遇到分支、循环、并行、路由、反思等复杂逻辑时，用自然语言描述流程既不精准，也无法保证稳定性——说白了，一个长Prompt很难严谨地描述一套带判断和循环的流程。

工作流Workflow就是来解决这个问题的。  它是一个可编排的结构化流程——把"多路检索→汇总→拆分功能点→细化场景→生成用例"完整串起来，每一步怎么走、什么条件下走哪条路，全都能用代码或可视化节点精准控制。

简单判断：

• 任务是一步到位的 → Skill就够
• 任务需要多步、分支、循环 → 上工作流

五、两种工作流实现方式

方式一：Dify图形化工作流

Dify提供拖拽式节点编排界面——你可以把"知识检索"拖成一个节点，"大模型调用"拖成另一个节点，用线串起来。

优点：  直观、上手快、适合入门。缺点：  复杂流程维护困难。

如果用Dify，你需要先创建一个知识库（在Dify后台导入文档），然后在工作流里加一个"知识检索"节点，配置好知识库ID，再把检索结果传给"LLM节点"生成用例。

方式二：DeepSeek JS脚本工作流

DeepSeek Harness支持生成JavaScript工作流脚本。你描述"我想搭一个工作流"，它帮你把JS代码写好。

优点：  代码精确控制流程，适合复杂逻辑和团队协作。缺点：  需要一点代码基础。

JS工作流的核心结构：定义输入→配置子智能体（每个子智能体负责一个步骤）→定义输出

验证方法：  像测试普通工具一样，对工作流输出做断言——检查用例格式是否规范、覆盖是否完整、有没有遗漏关键场景。

上手建议：  新手从图形化工作流入门，想精细控制流程就切到脚本化工作流。

六、避坑指南

坑一：知识库建完就放着不管了

文档在更新、代码在迭代、需求在变——知识库不更新，生成的用例永远是"上个版本"的。

解法：  建立知识库更新机制。每次需求变更，同步更新知识库。用IMVK这种支持增量更新的工具，新增文档自动处理，不用每次都全量重建。

坑二：向量库、图谱库、Markdown库各跑各的

三条知识库路径互不通信，AI拿到的还是碎片化信息。

解法：  在工作流里做检索融合——同时查三个库，汇总结果后再喂给大模型。三个来源的上下文拼在一起，才是完整的业务视图。

坑三：工作流写得太死，AI的推理能力被压制

工作流是"结构化流程"，AI是"推理引擎"。如果工作流把每一步都写死了，AI就没法发挥自己的判断力。

解法：  工作流负责"检索和汇总"这些确定性环节，AI负责"理解和生成"这些需要判断的环节。各司其职。

关于我们

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。