自闭环知识库使用说明

这套 knowledge-vault 的目标，是让它脱离原仓库也能被人读、被网页渲染、被后续 Skill 检索使用。换句话说，把整个文件夹单独拷走，也应该能看清楚：评审规则从哪里来、每个案例发生了什么、依据和合同原文片段在哪里、哪些内容是人工沉淀的评审经验。

它包含什么

1. 人工整理后的评审知识

   • 如何评审一份合同：评审入口。
   • 审核清单：把内控部审核要点拆成格式合同、非格式合同两套清单。
   • 条款库：按付款、验收、违约责任、争议解决、安全环保等主题解释风险。
   • 合同类型：按垃圾清运、污泥运输、生物质燃料、场地租赁、施工服务等业务类型说明重点。
   • 案例复盘：把真实 OA 审批、合同修改、差异和评审意见还原成可读案例。

2. 可回跳的来源材料

   • 提取材料来源索引：从原始合同、OA、格式模板、审核依据抽取出来的 Markdown 化材料。
   • 90-来源/案例证据包/：每个案例关联的关键证据包，便于按案例复核。
   • 维护与审计材料：保留必要的结构化结果，供后续程序核对漂移、来源和生成一致性；普通阅读和默认 Agent 审查不应优先打开。

3. 网页渲染所需的内部链接

   • 人读页面使用 Obsidian/Quartz 的双中括号链接，构建网页时会渲染成可点击页面。
   • 来源材料、案例证据包和页面之间都应该能互相跳转，避免只看到一段孤立结论。

它不包含什么

• 不直接复制原始 Word/PDF 文件：原始文件体积大、格式复杂，也更容易包含不必要的敏感信息。本库保留的是抽取后的 Markdown 来源页、证据包、hash 和来源说明。
• 不把所有机器 JSON 当成人读知识：JSON/JSONL 只作为证据快照或一致性检查，不是评审人主要阅读入口。
• 不把未复核线索直接当制度口径：自动提取或初筛线索可以帮助发现问题，但必须经过人工整理，才进入条款库、合同类型或案例复盘。

人应该怎么检查

先从如何评审一份合同进入，按下面顺序核对：

1. 看合同属于格式合同还是非格式合同。
2. 打开对应审核清单，确认每个检查项是否能落到合同原文。
3. 对有疑问的项，跳到条款库看风险理由和修改建议。
4. 按业务类型打开合同类型，检查有没有该类业务常见风险。
5. 打开相似案例复盘，看 OA 审批意见、合同修改和最终留痕。
6. 点击案例或条款里的来源链接，回到提取材料来源页核对原文片段。

判断一条知识是否可靠，最低要求是：它能说明“来自哪份材料”，能指向合同/OA/差异/审核依据中的具体内容，并且不是只凭未复核线索或模型推断写出来的。

后续 Skill 应该怎么消费

后续如果基于本库写合同审批 Skill，应把 knowledge-vault 当作主要知识入口，而不是回头读取旧的提取目录。

推荐流程：

1. 先读 00-起步/如何评审一份合同.md 和 10-审核清单/审查路由索引.md，判断问题属于哪类合同、哪类条款、是否涉及 OA 或模板偏离。
2. 用命令行搜索能力按需检索，例如围绕“付款”“验收”“违约金”“格式合同偏离”“OA 审批意见”查找页面。
3. 只加载命中的少量条款页、合同类型页、案例页和来源页，不一次性塞入整个知识库。
4. 输出评审结论时，同时引用用户提供的待审合同原文和 vault 内部页面或来源页，不引用本机旧路径。
5. 如果发现知识不够或来源断裂，应回到知识库补页面或补来源链接，而不是在 Skill 里写死规则兜底。

这种设计的核心是：人读 Markdown，模型按需搜索，程序在维护/审计模式下检查一致性，所有结论都能跳回来源。

修改与维护规则

• 手写页：00-起步、10-审核清单、20-条款库、30-合同类型、40-案例 是主要人工维护区。
• 生成页：index.md、各分类 index.md、90-来源/提取材料/、90-来源/案例证据包/ 和维护清单由脚本生成或同步，不应手改。
• 来源错误：如果来源页内容错了，优先修上游提取或同步脚本，再重新生成 vault。
• 知识错误：如果条款解释、案例复盘或建议措辞错了，直接修人工页，并保留能回跳的来源。
• 新增案例：先确认 OA、合同原文、合同修改、差异、必要证据是否进入来源层，再写案例复盘。

目前仍要注意的边界

1. 本库是辅助评审资料，不替代最终法律意见。
2. 维护与审计材料保留了结构化证据，但不适合作为普通评审人的主要入口。
3. 原始 Word/PDF 没有复制进 vault；如要做正式归档或举证，应另有受控原件库。
4. 如果后续要上线审批工作流，应该先让 Skill 只读本 vault，再由评测验证它能否按需找到正确清单、条款、案例和来源。