别再让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目录。增量更新很方便——新增文档只处理新文件，不重新处理旧的。检索方式就是关键字搜索，简单直接，但缺乏语义理解（你搜"打卡"就找不到"签到"的文档）。
怎么选？
路径
适用场景
工具推荐
向量检索
不确定关键词、模糊语义搜索
Dify知识库、AnythingLLM
知识图谱
需要理解业务关系全貌
LightRAG、Neo4j
本地Markdown
个人/小团队快速搭建
IMVK技能
实战建议：别只选一条，全都要。 我们团队现在是三条路并行——向量库做模糊召回，知识图谱做关系补全，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时代的底层资产正在变成"知识库+工作流"——知识库是"地图"，工作流是"导航路线"，两者配合，让AI每一次都能走对路。
你今天花半天建一个知识库、搭一条工作流，以后每一个项目都能复用。你积累的不再是一堆零散的用例，而是一套能持续产生用例的"生产线"。
核心技术栈就三样：业务知识库建设 + RAG检索 + 工作流编排。
不是让AI替你干活，是让AI知道该怎么替你干活。
下次你拿到一份几百页的需求文档合集，别再一份份上传了。花点时间建知识库、搭工作流，然后输入一句话：
"基于知识库，生成这个功能的全部测试用例。"
半小时后，你会看到结果。
