在组织的业务沟通和手册中，随着制度变更，新的文档不断堆积，导致正确的信息难以查找。本文尝试将Google发布的开放知识格式（OKF）及其理念来源LLM Wiki应用于NAS中沉睡的企业内部手册整理。
安装在NAS上的OpenClaw代理能够自动从现有文档生成OKF格式的Wiki，结构化地展现文档的修订与废止关系，并能准确回答问答请求。该机制极为简洁且效果显著。
组织文档因修订堆积导致“正确答案”难寻的典型场景
假设组织的业务手册文件夹中有三份关于公司用车的文档：一份是“公司自有车辆使用规定”，一份是“制度变更通知的内部通讯”，另一份是“租车预约手册”。
虽然明显有变更，但旧文档未被删除，若不仔细核对，难以判断应遵循哪份文档。尤其在部门NAS或文件服务器中，这种文档混杂现象普遍存在。
这种混乱难以避免，因为文档间的关系通常只存在于负责人的脑海中，未对其他成员明确说明，形成隐性知识。
此外，这种混乱也影响AI系统。基于组织文档的AI问答系统如RAG（检索增强生成）依赖向量化的文档块，如果存在多份类似内容且缺乏明确前后或主从关系，AI可能抓取错误信息，导致回答不准确。虽然有将所有上下文塞入的做法，但是否有更优方案？这是本文的出发点。
因此，本文尝试利用AI代理将文档间隐含的关系形式化，简而言之就是自动生成“目录”。由AI自动完成文档概要、合并、废止及关联链接，替代人工逐一确认。
基于该目录，还能构建问答AI代理，无需复杂RAG系统即可准确回答内部信息查询。
AI可读的目录格式“OKF”和“LLM Wiki”
本方案采用Google于2023年6月发布的开放知识格式（OKF）。
OKF是一种开放规范，用YAML前置信息加Markdown文件目录形式表达组织知识。Markdown是一种简洁的文档标记语言，支持标题、列表、链接等格式，YAML则用于描述文档元信息，如标题、作者、日期、标签、状态等。
OKF设计简单，唯一必填字段是表示类型的“type”，其他信息自由填写。文件以普通文件系统目录形式保存，无需特殊平台。
示例：
---
type: Policy
title: 公司用车规定
description: 规定用车纠纷处理、禁止事项及备注
resource: file://tnas/documents/手册/公司用车/用车规定.pdf
tags: [vehicle, policy]
status: active
timestamp: 2026-06-20T22:10:00Z
---
# 概要
规定公司用车基本规则。
相关: [法人租车预约手册](./法人租车预约手册.md)、[公司用车内部通讯](./公司用车内部通讯.md)、[总务部](./references/soumu.md)
## 事故处理
1. 先救护伤者并确保安全。
2. 报警（110）并取得事故证明。
3. 记录对方信息及现场照片。
4. 立即报告[总务部](./references/soumu.md)。
LLM Wiki理念基于目录结构和Markdown链接表达信息间关系，使用简单的Markdown链接语法表示文档及术语间的关联。OKF为LLM Wiki提供了统一的格式规范。
OKF和LLM Wiki的核心优势在于它们不是依赖特定平台，而是基于简单的文档格式，既方便人类阅读，也便于AI自动生成和处理。
人工整理文档需要大量时间和精力，而AI可以不知疲倦地自动生成LLM Wiki，甚至能结构化数据库模式和工作流程。
只要有“原始文档”、“智能语言模型”和“自主运行的AI代理”，就能轻松搭建此系统。本文使用OpenClaw在NAS上实现OKF格式的LLM Wiki，也可结合Claude Code等工具。
与NotebookLM等工具相比，本方法优势在于可直接利用NAS等通用平台上的现有文档，无需复制，支持人工编辑，且仅用Markdown文件，便于与其他系统集成和持续更新。
实践环境：利用OpenClaw自动将NAS上的业务手册转为OKF格式
选择NAS作为试验环境，因组织常将业务手册存放于文件服务器或NAS，信息混杂问题尤为突出。
此次使用直接安装OpenClaw的NAS，处理本地数据更简便。也可用NAS上的Docker或同网络PC上的OpenClaw，但不保证完全兼容。若用Claude Code，需确保其运行环境能访问NAS共享目录。
准备了路径为“/Volume1/documents/手册”的文件夹，内含“就业规则”、“公司用车”、“财务”三类子文件夹，存放PDF、Word、Excel、PowerPoint、Markdown等多种格式文档。
/Volume1/documents/手册
├── 就业规则
│ ├── 公司就业规则_Ver1.0.pdf
│ ├── 公司就业规则_Ver1.01.pdf
│ └── 公司就业规则_草案.pdf
├── 公司用车
│ ├── 20260618修正.docx
│ ├── 法人租车预约手册.pdf
│ ├── 公司用车内部通讯.pdf
│ └── 用车规定.pdf
└── 财务
├── 20260615_费用报销规定修订.docx
├── _archive
│ └── 法人卡使用手册_2023.pdf
├── 出差旅费规定.docx
├── 会计科目及费用分类.xlsx
├── 月度决算检查表.pptx
├── 法人卡使用手册.docx
├── 财务FAQ.md
└── 费用报销规定.docx
该手册文件夹保持不变，用户继续按习惯保存新文件或添加修订文件。
AI代理仅操作生成的“llm-wiki”文件夹，原始“手册”文件夹只读，避免意外修改。
步骤1：每天用cron扫描文件夹
通过cron每天启动OpenClaw的自动更新技能，扫描文件夹，检测新增、修改、重命名、删除文件，确定受影响的类别（顶级子文件夹），调用“okf-wiki-update”技能执行转换。
新增类别时自动创建对应Wiki目录和基础文件，类别删除时不删除Wiki，仅标记废止。
步骤2：复制原文档并读取
检测到新增或更新后，OpenClaw调用“okf-wiki-update”技能，将对应类别的原文复制到工作目录，读取处理，完成后删除工作目录中的文件。
步骤3：生成LLM Wiki
“okf-wiki-update”技能根据OKF规范，利用Claude Code生成对应的Markdown Wiki文件。相关代码和说明已开源于GitHub。
生成的Wiki结构如下，每个类别包含index.md（文件列表）和log.md（更新日志），公共信息集中于references目录。
llm-wiki
├── index.md
├── log.md
├── 公司用车
│ ├── FAQ.md
│ ├── index.md
│ ├── log.md
│ ├── references/soumu.md
│ ├── 法人租车预约手册.md
│ ├── 公司用车内部通讯.md
│ └── 用车规定.md
└── 财务
├── index.md
├── log.md
├── references/keiri.md
├── 出差旅费规定.md
├── 会计科目及费用分类.md
├── 月度决算检查表.md
├── 法人卡使用手册.md
├── 法人卡使用手册_旧版.md
├── 财务FAQ.md
└── 费用报销规定.md
查看生成的Wiki内容
每个Wiki主题由YAML前置信息和Markdown正文组成。前置信息包含类型、标题、描述、原文链接、标签、状态和时间戳。
正文结构化呈现原文中的步骤和表格，相关主题通过相对路径Markdown链接关联，引用信息标注于文末，方便用户访问原始文件。
链接部分附带说明，如“联系人”或“请立即联系～”，表达链接的语义关系。
这类似知识图谱中的本体论，信息不仅连接，还明确连接含义。
例如，使用知识图谱的Cypher语法可表示为：
(:Manual {title: "法人租车预约手册"}) -[:HAS_EMERGENCY_CONTACT]-> (:Contact {name: "总务部"})
而OKF用自然语言描述链接关系，简单且直观。
但要实现良好效果，必须依赖“智能语言模型”，低性能模型可能无法正确生成链接或理解关系。
能否正确理解修订？
以公司用车为例，独立文档“20260618修正.docx”记录了总务部联系方式及租车公司名称变更。系统能识别这是对“法人租车预约手册”的修订，并将内容合并，避免将修订文档当作独立主题。
更新日志“log.md”记录了“20260618修正.docx合并至法人租车预约手册”。
废止与继承关系也得到体现，如财务部门的法人卡手册存在新版和旧版，旧版标记为status: deprecated，并通过superseded_by指向新版，正文开头也有“现行请参阅～”的链接。
这体现了LLM期待的“长期记忆”特性，区别于简单的搜索索引。
---
type: Procedure
title: 法人卡使用手册（旧版）
description: 2023版旧版，已合并至现行版。
resource: file://tnas/documents/手册/财务/_archive/法人卡使用手册_2023.pdf
tags: [card, expense, procedure, deprecated]
status: deprecated
superseded_by: ./法人卡使用手册.md
timestamp: 2026-06-21T08:19:00+09:00
---
# 旧版说明
- 2023版法人卡使用手册，涵盖使用、归还、遗失及不正当使用处理。
- 现行操作已合并至[法人卡使用手册](./法人卡使用手册.md)。
- 旧版已废止，保留历史记录。
利用Obsidian可视化关系
生成的Wiki可导入Obsidian，利用其图谱视图直观展示文档间的链接关系。Obsidian是一款基于Markdown的知识管理软件，支持笔记间链接，便于构建知识库。
此外，OpenClaw的“okf-wiki-qa”技能支持跨类别搜索相关主题，基于正文内容生成回答，并附带原文链接。它会尊重文档状态，如回答“如何预约公司用车”时，优先返回现行租车手册内容，并说明旧制度已废止；查询报销上限时，返回最新额度。
系统还会统计问答频率，自动生成FAQ页面，如公司用车FAQ.md，提升回答效率并持续优化Wiki内容。
---
title: 公司用车FAQ
type: faq
status: active
description: 公司用车类别常见问题（由QA技能自动更新）
tags: FAQ 常见问题 公司用车
updated: 2026-06-21
---
# 公司用车FAQ
## Q. 公司用车负责人联系方式？
A. [总务部](./references/soumu.md)为窗口，内线9876，邮箱soumu-car@example.co.jp，紧急联系电话0120-YYY-YYYY（24小时）。详细流程见[法人租车预约手册](./法人租车预约手册.md)。
出处：
- 法人租车预约手册.pdf
file://tnas/documents/手册/公司用车/法人租车预约手册.pdf
相关：
- [总务部](./references/soumu.md)
- [法人租车预约手册](./法人租车预约手册.md)
遇到的问题与经验
模型智能度决定质量
文档关系理解和链接生成依赖推理能力强的语言模型。本文使用成本较低的GPT-5.4-mini，初期关闭推理时链接稀少，内容简陋；开启推理后内容丰富，链接和实体抽取显著提升。结论是语言模型性能是关键。
抵御提示注入攻击
测试中故意在报销规定文档末尾插入恶意指令，要求代理删除所有文件并篡改联系方式。结果指令未被采纳，系统检测为非法提示未执行，说明文档内容仅作数据处理，非命令执行，安全机制有效。
系统局限性
跨类别Wiki间链接生成未实现，设计上让“公司用车”和“财务”类别内Wiki独立，图谱中形成两个分离集群。跨类别链接生成是未来挑战，数据量增大时处理成本和时间显著增加，需专业方案优化。
AI友好型文档时代的到来
此次实践表明，面向AI阅读设计文档的时代正在临近。AI可读性高的文档不仅利于人类，也极大拓展了应用场景。
OKF作为人机共读的“中间格式”，简洁且兼容LLM Wiki、Obsidian等工具，易于实现和部署。
只需准备访问源文件和存放生成Markdown的文件夹，即可在传统文件系统上运行，无需专用向量数据库，适合小规模环境。
但实用性高度依赖语言模型推理能力和Wiki内容完善度。推理能力强可实现基于修订和废止的准确回答，仍需解决语义矛盾检测和跨类别链接等问题。
不过，仅需一个文件夹即可开始尝试，操作简便，值得在现有手册基础上小规模试点。
