概述

llmwiki 是一个人机协作的个人知识管理 Wiki。核心设计理念:agent 负责语义判断、撰写和综合;Python 脚本(wiki_cli.py)负责确定性的校验、归档和索引维护。整个系统由 5 个 Skill 驱动,覆盖从原料收集到博客发布的全生命周期。

三层目录体系

知识在三个层次间流动:

层次 目录 角色
原料层 00_收件箱/ 原始材料,只读入口
草稿层 99_AI初稿/ agent 产出的草稿,带 frontmatter,待人审
正式层 01_项目/ 02_领域/ 03_资料库/ 06_术语/ 稳定可引用的正式 Wiki
归档层 04_归档/ 降级/历史页面
导航层 05_导航/ 入口、地图、Canvas、graph.html

工作流 1:llmwiki-capture(沉淀)

触发条件:对话中得出新的稳定结论;用户说”沉淀/入库/把 X 写成笔记”;00_收件箱/ 有新文件;llmwiki-query 答完后判定需要回写。

执行步骤:重复检测 → 概括标题 → 参考 taxonomy 选 tags → 按 Schema 写草稿到 99_AI初稿/validate 校验 → find-similar 影响面分析 → 汇报用户 → 用户确认后 archive --post 归档。

职责分工:agent 做语义清洗与撰写;脚本做落盘、校验、影响面分析。

工作流 2:llmwiki-query(查询问答)

触发条件:用户提出 Wiki 主题相关问题;需要综述、对比、决策回顾。

执行步骤search 语义检索 top-5 → 读 index.md 补漏 → 读候选页面正文 → 综合给出带引用链接的回答 → 判断是否值得沉淀 → 若值得,显式问用户”是否沉淀” → 确认后转入 capture。

三种模式:quick(不沉淀)、standard(判断后决定)、deep(必须明确问是否沉淀)。

工作流 3:llmwiki-check(健康体检)

触发条件:用户说”体检/lint/巡检/保鲜/检查过期”;大量归档后;定期周检;query 中发现某页陈旧。

执行步骤check --json 一次性输出三段——lint(结构)、evolution(保鲜)、tag 近义词建议 → agent 按优先级汇报 → 用户决定是否 --fix 或降级。

职责分工:脚本检测问题;agent 做语义判断和汇报;破坏性操作绝不自动执行。

工作流 4:llmwiki-term(术语建页)

触发条件:用户问”X 是什么”;query 中发现某术语多次出现但无专属页;用户说”给 X 建个术语页”。

执行步骤:查 06_术语/ 是否已有 → web 检索(至少 2 源交叉验证)→ 草稿落 99_AI初稿/术语/validate → 用户确认后 archivefind-refs 扫描裸文本 → link-term 批量加双链。

工作流 5:llmwiki-publish(发布到 Hexo)

触发条件:用户说”发布/部署/生成博客/hexo”。

执行步骤:脚本做确定性转换(wikilink/callout/embed/图片 → Hexo 格式)输出到 98_发布/ → agent 修复残留 Obsidian 语法 → 部署到 Hexo 工程。

典型触发对话

用户说的话 触发 Skill
“帮我把刚才的结论记下来” / “把这段入库” llmwiki-capture
“Wiki 里有没有关于 XXX 的记录?” / “对比一下 A 和 B” llmwiki-query
“做一次体检” / “看看有没有过期页面” llmwiki-check
“RTOS 是什么?” / “给 DMA 建个术语页” llmwiki-term
“把这篇发布到博客” / “hexo 部署一下” llmwiki-publish

贯穿所有流程的硬约束

约束 说明
草稿先行 写正式页前必先写草稿到 99_AI初稿/
搜索先行 回答前必先跑 search 语义定位
写入必刷新 任何正式层写入后必跑 refresh
校验必过 写完草稿必跑 validate
人工确认 破坏性操作(删除/降级/批量改名)必须用户拍板
审计留痕 log.md 追踪所有重要操作