Knowledge Wiki

把资料转化为一组小而稳定的知识单元，并保留每个结论的来源、状态和关系。遵循 LLM Wiki 的可组合知识结构，以及开放知识实践的可访问、可复用、可追溯和协作维护原则。

工作流

1. 解析知识库路径

• 按以下优先级确定唯一的知识库根目录：用户在当前请求中给出的路径；从当前目录向上找到的最近 .knowledge-wiki.yaml；当前目录本身（同时包含 wiki.yaml、index.md 和 wiki/index.md）。
• 将 .knowledge-wiki.yaml 中的相对 repository 路径相对于该指针文件所在目录解析。绝对路径只用于个人跨项目共享的中央知识库。
• 验证根目录包含 wiki.yaml、index.md 和 wiki/index.md。路径不存在、配置无效或找到多个同优先级候选时停止写入，并请用户确认；不要扫描整个主目录猜测位置。
• 查询任务保持只读。只有用户要求采集、更新、修复或初始化时才修改知识库。
• 详细规则和示例见 references/repository-layout.md。

使用内置 Demo

• 当用户要求演示、试用、回归测试或验证本 Skill，但没有提供自己的知识库时，使用 assets/demo-knowledge-base/。
• 只读问答和检索测试可直接读取 Demo。采集、更新、移动、废弃、修复等写入测试必须先把整个 Demo 复制到临时或用户指定目录，再对副本操作。
• 不把 Demo 内容混入用户的正式知识库，也不把 Demo 中的示例持仓、观点或来源当成当前用户事实。
• 按 references/demo-testing.md 执行测试并检查结果；不要只验证文件是否存在。

2. 确认任务边界

• 判断用户是在采集、更新、查询、审计还是导出知识。
• 查找工作区已有的 Wiki 目录、命名约定和索引；优先沿用，不要另起一套结构。
• 初始化新知识库时，读取 references/repository-layout.md，复制并按需调整 assets/personal-wiki-template/；不要把模板本身当成用户知识。
• 需要分层时，按“领域 → 子领域 → 主题 → 知识类型”建立目录；使用 parent_id、level 和 path 显式记录父子关系，不只依赖文件夹名称。
• 如果用户没有指定输出位置，询问或选择当前项目中最接近的知识目录，并在回复中说明。
• 不把未提供的内容当成事实；无法访问的链接或附件标记为待获取。

3. 采集与原子化

• 先把原始输入或其稳定引用放入 raw/，登记到 sources.yaml，再向 wiki/ 提炼；不要用整理结果覆盖原始资料。
• 将内容拆成“一个单元回答一个问题”的知识卡片：事实、定义、决策、约束、步骤、例外或待解决问题。
• 默认采用 balanced 粒度：一个主题或知识类型一个文件，可在文件内包含多条相关卡片。只有需要独立引用、独立更新、独立验证或存在冲突的知识才单独成文件。
• 删除重复的铺垫，但不要删除会改变结论的限定条件、时间、范围或反例。
• 对每条卡片标注 status：draft、verified、deprecated、conflicted 或 open-question。

4. 建立来源与关系

• 每条可验证断言必须有一个或多个来源；网页记录 URL 和访问日期，文件记录路径和版本或提交号。
• 区分直接引用、忠实改写和基于多条来源的推断；推断不得伪装成原文事实。
• 使用稳定的 id 和关系类型连接卡片。可用关系包括 supports、contradicts、depends-on、refines、例示 和 supersedes。
• 发现相同主题时先合并或建立关系，不复制两份近似内容。

5. 输出与更新

• 默认输出 Markdown 卡片，元数据使用 YAML front matter；需要程序处理时同时提供 JSON/YAML 数据。
• 按 raw → wiki → diff/report 维护知识生命周期：raw/ 保存来源，wiki/ 保存当前知识，diff/ 保存变化，report/ 保存审计或学习报告。
• 生成分层 Wiki 时，根目录和每一个知识目录层级都必须有且只有一个 index.md：raw/、wiki/、diff/、report/ 及其知识子目录均需维护索引；叶子知识文件不额外创建 index.md。prompts/ 是控制层，不强制索引。
• 每个 index.md 只列出直接子节点、摘要、状态和待处理项；不要在父索引中复制整棵子树。生成或移动节点后同步更新沿途所有父级索引。
• 更新时保留历史和变更原因。新来源不能自动覆盖旧结论；应将旧卡片标为 deprecated 或建立 supersedes 关系。
• 许可证、作者和来源信息按原资料记录；不擅自改变授权，也不批量复制受版权保护的全文。
• 完成后更新索引或目录，并报告新增、修改、冲突和待确认项。

知识卡片格式

遵循 references/knowledge-schema.md。最小卡片应包含：

---
id: kw-20260822-001
title: 一个清晰的结论
type: fact
status: verified
topics: [topic-a]
sources:
  - locator: https://example.com/source
    accessed: 2026-08-22
    kind: primary
    note: 支持结论的章节或页码
---

结论正文。必要时补充适用范围、前提和反例。

使用 type: inference 表示综合推断，使用 type: question 表示尚未解决的问题。日期采用 YYYY-MM-DD，ID 在同一知识库内保持唯一且不可复用。

分层卡片还必须提供：

parent_id: topic-caching
level: knowledge-type
path: 后端/缓存/Redis/概念

根节点使用 parent_id: null、level: root；目录节点使用 type: index，知识卡片使用 level: concept、use-case、decision 或 question 等稳定值。目录索引的 path 指向目录，叶子卡片的 path 指向去掉 .md 后缀的文件路径。每个目录节点的元数据放在该目录的 index.md 中。

基于 Wiki 的问答

回答知识库问题时：

1. 先读取根 index.md、wiki/index.md 和命中的主题索引，再检索相关卡片及其一跳关系；不要只依赖文件名或标题匹配。
2. 必要时通过 sources.yaml 和 raw/ 核对证据，但优先把 wiki/ 中已审阅内容作为当前知识状态。
3. 给出结论后列出对应卡片 ID 和来源定位。
4. 明确区分“Wiki 明确记录”“根据来源推断”“外部补充”和“当前资料无法确认”。
5. Wiki 没有覆盖时直接说明；不得用模型记忆伪装成 Wiki 内容。需要外部查询时先遵循用户要求和可用工具规则，并单独标识外部信息。
6. 遇到 conflicted 卡片，展示主要分歧及各自来源，不强行裁决。
7. 涉及时间敏感信息时检查 accessed、updated 和 deprecated 状态。

审计清单

执行更新或导出前检查：

• 是否每条事实都有来源？来源是否可定位、可访问或有明确的文件版本？
• 是否把推断、意见和事实分开？是否保留了关键限定条件？
• 是否存在重复卡片、孤立卡片、断开的关系或循环依赖？
• 是否标记了互相矛盾、过期或待确认的内容？
• 是否保留作者、日期、许可证和变更历史？
• 输出是否使用开放、可读、可迁移的格式，而不是不可解释的二进制状态？

交付格式

根据用户需求选择一种或多种：

• 知识卡片：适合增量采集和人工审阅。
• 主题索引：按主题、状态、更新时间和关系汇总卡片。
• 变更报告：列出新增、修改、废弃、冲突和待确认项。
• 证据问答：结论、证据卡片、来源定位和不确定性说明。
• 机器可读导出：YAML 或 JSON，字段与 Markdown front matter 保持一致。

详细规则见：

• references/repository-layout.md：仓库目录、生命周期、拆分粒度和文件职责。
• references/knowledge-schema.md：知识卡片和来源字段。
• references/linking-rules.md：层级索引、关系和冲突处理。
• references/demo-testing.md：内置 Demo 的测试场景和通过条件。