AI知识库新思路：基于Skill元数据匹配的非RAG方案

背景

原作者长期从事技术博客写作，习惯按“方案+代码”的思路分享。但进入vibe coding时代后，他转向了opencode结合codex（AI编程工具）的工作流，并逐渐认同“code is cheap, show me the prompt”这一理念。本系列旨在分享他在构建AI标书智能体时的提示词工程思路，并希望读者能学会搭建自己的AI智能体。

在AI知识库领域，大多数人第一时间想到RAG（检索增强生成），原作者也曾如此。早在GPT-3.5时代（仅有4k上下文），他研究过RAG，发现精准度一般。如今主流知识库仍然依赖RAG，但RAG的精准度问题始终未被解决。以写标书场景为例：知识库包含“装修改造施工项目”和“消防工程”两类。当需要撰写“消防改造施工项目”标书时，理想情况应参考“消防工程”知识，但多数embedding模型会优先匹配到“装修改造施工项目”，因为二者的语义更接近。原作者认为，给AI一个错误的参考还不如不给，让AI凭自身经验写反而更精准。

核心内容

原作者提出的知识库方案灵感来源于AI的skill（技能）管理机制。在AI agent中，如何让AI从众多skill中自动选择当前任务应执行的skill？每个skill开头有一段元数据（描述信息），简单说明AI应在何时使用该skill。每次AI请求时，会携带所有已安装skill的描述，由AI判断是否使用，确定使用后才去读取skill的真正内容。作者意识到：这不就跟知识库一样吗？于是将这套逻辑迁移到标书知识库的构建中。

具体流程如下：

1. 构建block（块）：上传文档后，按标题、段落、表格、列表切分原文，再做语义合并，给每个原文片段赋予唯一编号，以便后续精确匹配。

2. 清理无效block：过滤掉页码、目录、封面、签章、过短碎片、格式残留等垃圾内容，避免它们进入知识库。

3. 第一轮提取条目：AI从全文提取可复用的主题，只输出“标题”和“使用方式”。这一步先判断“这份资料有哪些可复用内容”。

4. 第二轮补漏：AI检查是否有遗漏主题，只补充新增条目，减少漏掉小但常用的内容。

5. 合并候选条目：去重、编号，生成稳定的条目ID，得到可匹配的候选知识条目。

6. 分批匹配原文：AI判断每个条目对应哪些block，只返回block范围（即编号区间），然后将真实原文挂回条目。

7. 遗漏block补漏：没有被匹配到的原文block，再让AI跑一遍匹配，防止有价值原文未进入任何条目。

8. 保存最终条目：程序按block ID拼回原文内容，最终知识条目由三部分组成：标题 + 使用方式 + 原文素材。

该方案经用户反馈基本可行，作者也欢迎更好方案指正。

关键要点

• RAG的精准度瓶颈：embedding模型在语义接近但不同类别的文档上容易匹配错误，导致AI获得错误参考。
• 方案核心思想：模仿AI agent的skill选择机制，让AI先根据“使用方式”元数据判断是否要调用某条知识，而非依赖向量检索。
• 文档预处理采用分层切分（标题、段落、表格、列表）再加语义合并，保证block粒度合理。
• 无效block清理必须严格，否则垃圾内容会被AI当作知识源。
• 提取条目分两轮：第一轮提取主要主题，第二轮补漏，减少遗漏。
• 匹配原文采用block编号区间方式，避免直接输出大段原文，降低开销。
• 最终知识条目的结构包含“标题”（知识主题）、“使用方式”（何时调用）、“原文素材”（实际内容），三者缺一不可。
• 方案完全开源：OpenBidKit_Yibiao项目已在GitHub公开源码和提示词。

意义与影响

该方案跳出传统RAG的框架，提供了一种基于AI自身判断能力的知识库构建思路。在写标书这类领域敏感、输出格式严格的场景中，错误的知识引用比没有知识更致命。通过让AI先理解知识的“用途描述”再决定是否调取，可以大幅减少因语义误匹配带来的错误引用。

此外，该方法将知识库的构建过程拆解为可复现的流水线（切分→清理→提取→匹配→聚合），且每一步都依赖AI进行逻辑判断，而非机械的向量相似度。这实际上是将“检索”从“统计近似”升级为“语义理解驱动”，更适合需要精准知识支撑的复杂任务。

对于AI应用开发者，该方案提供了一个可落地的替代RAG的范例，尤其适合那些需要高质量、高可靠知识库，且对上下文敏感度要求高的行业（如法律、医疗、投标等）。同时，作者完全开源的做法也降低了技术门槛，让更多人能基于此思路改进自己的知识管理方式。