avatar洪显学
← 返回

X-wiki

更新于 2026年8月4日v2.0.0
X-wikiLLM Wiki第二大脑Knowledge SystemKnowledge CompoundingFeishuHuman-in-the-loopPython
X-wiki 第二大脑项目

X-wiki 是我对卡帕西提出的 LLM-wiki 方向持续思考后，逐步形成的个人第二大脑项目。它不是把资料堆进一个检索库，而是把长期输入、判断、复盘和行动连接成一个可以被我和 Agent 共同维护的本地知识系统。

项目定位

X-wiki 回答的是一个更具体的问题：如果 AI 能读写我的知识库，那么这个知识库应该如何组织，才不会变成新的信息垃圾场？

当前答案是把知识系统拆成三层：

  • raw：保存原始材料和真实输入，优先保证保真
  • kernel：保存高复用、高压缩、可迁移的稳定知识
  • work：保存项目、决策、实验、输出和正在形成的判断

它的核心公式是：

知识库价值 = 保真 × 压缩 × 连接 × 复用 ÷ 维护成本

为什么做

单次对话很容易产生有用想法，但如果没有结构，这些想法很快就会散掉。传统笔记软件可以保存内容，却不一定能帮助我持续压缩、连接和复用。

X-wiki 的目标，是让输入不只停留在收藏和摘要，而是进入一个可追踪的循环：捕获、整理、晶化、审核、编译、验证、行动，再把行动反馈回知识系统。

当前版本

当前版本是 v2.0.0。这一版没有继续寻找一个包办所有动作的万能入口，而是把不同频率的行为放回合适的位置：飞书承担高频、低摩擦的记录，Control Center 承担低频、需要判断的审阅；AI 负责理解与连接，程序负责守住写入边界。

已经形成的部分包括：

  • 本地 Markdown 知识库结构与 OKF 元数据规范
  • raw / kernel / work 三层知识组织方式
  • Python 控制平面，处理路径、哈希、状态、写入、lint 和 verification receipt
  • FastAPI + React + Vite 的本地 Control Center，用于复杂审阅和系统状态检查
  • 飞书无命令采集、夜间批量整理与次日审阅卡片
  • Inbox、全文搜索、Knowledge Browser、轻量知识图谱和系统健康面板
  • Proposal / Review / Apply 的审核边界，避免未经确认的语义写入
  • 语音、剪贴板、文件上传与多端 Quick Capture 等输入尝试
  • 不可变的复用回执与追加式结果反馈
  • 围绕当前问题生成、带解释理由的知识激活队列
  • 基于真实使用证据生成待审提案的睡眠式巩固
  • 云文档元数据基线、变化发现、候选清单与人工选择
  • 人工审核前不自动批准、不自动写入稳定知识

这次 2.0 的完整变革过程，见：X-wiki 2.0：对人更轻，对 AI 更严。知识复利机制的专项设计，见：X-wiki 二次进化：从“存下知识”到“让知识产生复利”。

版本记录

v2.0.0

  • 把高频采集与低频审阅拆开：飞书先收下，Control Center 看清楚再决定
  • 飞书入口从命令式交互收敛为一个动作，并保留夜间整理与人工审阅
  • 建立知识激活、真实使用、复用回执、结果反馈与睡眠式巩固闭环
  • 增加云文档变化发现，只生成候选清单，不替人决定是否入库
  • 复用回执绑定实际问题和使用结果，不把搜索或访问误判为复用
  • 知识激活提供少量、可解释的候选，并保留搁置与忽略边界
  • 睡眠式巩固只根据有界证据生成待审提案，不自动升级知识内核
  • 明确人、LLM 与 Python 的责任：人判断意义，LLM 理解连接，程序守住写入边界

v1.0.0

  • 明确 raw / kernel / work 三层知识组织方式
  • 建立 Python 控制平面与 OKF 元数据规范
  • 形成 FastAPI + React + Vite 的本地 Control Center
  • 接入 Inbox、全文搜索、Knowledge Browser、轻量知识图谱和系统健康面板
  • 明确 Proposal / Review / Apply 的审核边界

我在其中承担的角色

这个项目由我同时承担产品定义、知识架构、规则设计、真实使用验证和持续维护。

它对我来说不只是一个工具项目，更像是一套个人认知基础设施：我需要它帮我记住事实，也需要它帮我保留判断变化的轨迹；需要它服务 AI，也需要它保护人的审核权。

技术实现

  • Markdown 作为长期可迁移的数据底座
  • OKF frontmatter 记录类型、状态、来源、权重和验证状态
  • Python 脚本与库承担确定性控制平面
  • FastAPI 提供本地 API 和任务接口
  • React + Vite + TypeScript 构建本地控制中心
  • SQLite FTS5 支持本地全文搜索
  • Obsidian、飞书、语音和文件入口承担高频输入
  • lint、verify 和 receipt 机制支撑可验证维护

不变原则

  • 原始材料优先保真，不轻易改写
  • 进入 kernel 的内容必须值得复用
  • 链接表达依赖，不做装饰
  • AI 可以合成和建议，但关键写入必须可审核
  • 结构越少越好，除非它明显降低未来维护成本

下一步

下一步不会急着增加更多入口，而是继续观察三件事：飞书记录能否形成稳定习惯，知识复利是否真的改善长期判断，以及每日自动发现与审阅能否长期可靠运行。