用 OKF 规范把代码转成可导航知识库
通过概念文件、元数据和链接索引，系统化沉淀数据库与 API 知识。
原始内容
第一个提示词： 请阅读理解当前项目代码全链路，并按照 Google Open Knowledge Format (OKF) 规范，在项目根目录创建一个 `docs/okf/` 文件夹。 要求： 1. 为每个核心数据库表或 API 创建一个独立的 `.md` 概念文件。 2. 每个文件必须包含 YAML frontmatter 头部，包含 `type`（如 table/api）、`title`、`description` 和 `resource` 等字段。 3. 使用标准 Markdown 链接在这些概念文件之间建立关联。 4. 生成符合 OKF 规范的 `docs/okf/index.md` 索引文件。
深度解析
是什么 这是一段面向代码助手的文档工程提示词，目标不是修改业务逻辑，而是把项目中的数据库表和 API 转换成结构化、可互相引用的知识资源。它要求先理解当前项目的完整链路，再在 docs/okf/ 下建立概念文件与统一索引。
核心设计 其方法由三层组成：以独立 Markdown 文件承载单个资源，以 YAML frontmatter 提供类型、标题、描述和资源标识等机器可读元数据，再通过标准链接连接相关概念，最终由 index.md 作为导航入口。这种结构兼顾人类阅读、自动解析和后续增量维护，适合接入 AI agent、文档检索或知识图谱流程。
关键洞察 真正有价值的不是文件数量，而是资源边界和关系质量：表、接口、领域概念应有稳定命名，引用关系应能反映调用、依赖或归属。索引也不应只是文件清单，而应成为从领域到实现的最短路径。
边界与风险 提示词没有定义 OKF 的正式 schema、校验器、核心资源判定标准和链接失效检查机制，执行结果可能在不同项目中不一致。若缺少自动生成与持续校验，文档容易随代码演进而过时。内容价值主要来自知识架构和研发效能，而非视觉、交互或体验设计。
精选追评与案例
原作者后续补充的第二个提示词，给出 OKF 解析器 OKFReader 的完整功能要求与过滤、注入上下文思路，可直接复用。
第二个提示词： 我想让我的应用能够消费/读取 OKF (Open Knowledge Format) 格式的知识文件。 请帮我用 [Python] 编写一个 OKF 解析器类 `OKFReader`： 功能要求： 1. 能够扫描指定目录下的 `.md` 文件。 2. 使用 [比如 python-frontmatter / gray-matter] 解析文件顶部的 YAML 元数据和 Markdown 内容。 3. 支持根据 YAML 中的 `type`（如 table, metric）或 `tags` 过滤知识。 4. 提供一个方法，将解析后的知识结构化格式化，并注入给我们的 LLM 提示词上下文（Prompt Context）。