4.技能知识数据化存储方式选型分析

结论先行

如果是在做“技能里的大量知识数据化”，Markdown、JSON、SQLite 都能用，但适用场景差别很大。

可以先记住这个结论：

• 小规模、以“给模型读”为主：优先 Markdown
• 中等规模、结构明确、需要程序处理：优先 JSON
• 大规模、要检索、筛选、关联、增量维护：优先 SQLite

很多时候，最稳妥的方式不是三选一，而是混合使用：

• Markdown 负责知识正文
• JSON 负责轻量结构化配置和索引
• SQLite 负责查询、检索和统计

三种方式的核心差异

1. Markdown

Markdown 最适合存储偏文档型、说明型、经验型的知识内容。

优点：

• 人可读性最好，写作和维护成本低
• 很适合知识说明、规则解释、FAQ、案例总结
• 天然适合给模型作为上下文，阅读体验比纯结构化数据更自然
• 版本管理友好，配合 Git 很方便

缺点：

• 程序化检索能力弱
• 很难高效做字段过滤、关联查询、多条件筛选
• 数据一多之后，查找和复用会越来越依赖额外索引

适合场景：

• 技能说明文档
• 业务规则说明
• Prompt 素材
• 案例集
• 经验知识库

2. JSON

JSON 最适合存储结构清晰、字段明确、需要脚本处理的数据。

优点：

• 结构化明确，程序读写方便
• 很适合配置、元数据、标签、规则对象、映射关系
• 易于校验和转换，适合和脚本配合

缺点：

• 内容一长之后，人工阅读和维护体验明显下降
• 不适合承载大量长篇知识正文
• 不具备数据库级别的查询能力，通常要整文件读取后再自己筛选

适合场景：

• 配置文件
• 条目索引
• 标签体系
• Prompt 参数模板
• 规则元数据

3. SQLite

SQLite 是单文件数据库，适合知识量较大且需要强查询能力的场景。

优点：

• 不需要单独部署服务，便于分发和使用
• 查询能力强，支持筛选、排序、关联、聚合统计
• 适合大量数据、频繁查询、增量更新
• 很适合做全文检索、标签过滤、命中统计和中间索引层

缺点：

• 不适合作为主要写作介质
• 人工直接编辑不方便
• 如果只是少量知识文档，直接上数据库会偏重

适合场景：

• 大型知识库索引
• 案例库
• 术语库
• 检索缓存
• 分块数据管理
• 知识使用日志与统计

从技能场景看，关键判断维度

做选型时，建议先回答下面四个问题。

1. 你的知识主要是“给模型读”还是“给程序查”

- 如果主要是给人或模型阅读，优先 Markdown
- 如果主要是给程序处理结构化字段，优先 JSON
- 如果主要是做查询、筛选和召回，优先 SQLite

2. 数据量有多大

- 几十篇到一两百篇文档：Markdown 通常够用
- 几百到几千条结构化条目：JSON 或 SQLite
- 上万条记录或高频查询：优先 SQLite

3. 数据如何更新

- 主要靠人工编写和维护：Markdown 更友好
- 主要靠脚本生成或同步：JSON 更自然
- 需要持续增量写入、更新、清洗：SQLite 更合适

4. 未来是否需要复杂检索

如果未来会出现这些需求，就应该尽早考虑 SQLite：

• 按标签筛选
• 多条件组合查询
• 上下游知识关联
• 全文检索
• 使用统计
• 知识命中率分析

具体建议

方案 A：Markdown 为主，JSON 为辅

做法：

• Markdown 存知识正文
• JSON 存索引和元数据

例如 JSON 可以保存这些字段：

• 标题
• 标签
• 适用场景
• 优先级
• 来源
• 更新时间
• 对应文档路径

适合场景：

• 仍处于知识建设早期
• 需要频繁人工修改
• 知识内容偏说明型、经验型
• 模型会直接读取正文内容

这是最轻量、最容易启动的方案。

方案 B：Markdown + SQLite

做法：

• Markdown 仍作为知识源文件
• 用脚本把元数据、关键词、分块结果、标签等写入 SQLite
• 查询时先查库，再回源读取对应的 Markdown 内容或片段

适合场景：

• 知识正文较长
• 需要做召回和检索
• 想保留人工可读性
• 后续准备接入 RAG、全文搜索或向量检索

这是兼顾可维护性和扩展性的强方案。

方案 C：纯 SQLite

只有在知识天然就是结构化记录时，才建议把主要内容直接存入 SQLite。

适合场景：

• 规则表
• 术语表
• 映射表
• 参数模板库
• 高度结构化的案例标签数据

如果正文内容很多、需要大量人工写作，纯 SQLite 的维护体验通常不会太好。

推荐路线

如果是在做技能知识库，我更推荐按阶段推进，而不是一开始就做得很重。

阶段 1：知识建设期

优先使用：

• Markdown + JSON

原因：

• 启动成本低
• 写作效率高
• 调整结构灵活
• 对模型输入友好

阶段 2：知识运营期

在已有 Markdown 的基础上增加：

• SQLite

原因：

• 便于检索和筛选
• 支持统计和增量更新
• 可以减少每次都把大量文档直接塞给模型

这时的更推荐架构是：

• Markdown 做内容源
• JSON 做配置和轻索引
• SQLite 做查询引擎

什么时候不建议一开始就用 SQLite

如果你现在处于下面这些情况，不建议上来就把所有知识都做进 SQLite：

• 数据量还不大
• 主要是手工写知识文档
• 没有复杂查询需求
• 只是让技能读取少量参考资料
• 团队更习惯改文档，而不是写 SQL 或数据库脚本

这种情况下，Markdown + JSON 通常更轻、更稳，也更容易持续维护。

什么时候应该尽快考虑 SQLite

当你出现下面这些信号时，说明已经值得引入 SQLite：

• 知识条目很多，文档开始混乱
• 需要按多个维度筛选
• 需要全文检索
• 需要记录使用日志、版本或命中率
• 后面准备接向量检索或 RAG
• 不希望每次都把大量 Markdown 全量提供给模型

最推荐的组合方案

如果目标是做一个可持续扩展的技能知识库，推荐采用下面的分层方式：

• Markdown：存正文知识、规范、案例说明、经验总结
• JSON：存配置、索引、元数据、小型规则
• SQLite：存检索索引、分块、标签、统计、关联关系

可以概括为一句话：

Markdown 做内容源，JSON 做轻结构配置，SQLite 做查询引擎。

这是最不容易走弯路的一种架构。

一句话建议

如果你现在还在建设期，优先 Markdown + JSON。
如果你已经进入知识库运营期、检索期，升级到 Markdown + SQLite。
除非数据天然高度结构化，否则不建议一开始就用 SQLite 替代 Markdown。

后续可继续扩展的方向

如果后面要把这套方案落地，可以继续补充这些内容：

• 技能知识库目录结构设计
• Markdown 文档命名规范
• JSON 索引字段定义
• SQLite 表结构设计
• 从 Markdown 自动导入 SQLite 的同步脚本
• 检索和召回流程设计