X-wiki

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

项目定位

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

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

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

它的核心公式是：

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

为什么做

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

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

当前版本

当前版本是 v1.0.0，这一版把 X-wiki 定义为“控制平面与真实使用闭环”的第一版公开快照。

已经形成的部分包括：

• 本地 Markdown 知识库结构与 OKF 元数据规范
• raw / kernel / work 三层知识组织方式
• Python 控制平面，处理路径、哈希、状态、写入、lint 和 verification receipt
• FastAPI + React + Vite 的本地 Control Center
• Inbox、全文搜索、Knowledge Browser、轻量知识图谱和系统健康面板
• Proposal / Review / Apply 的审核边界，避免未经确认的语义写入
• 飞书、语音、剪贴板、文件上传等真实输入入口

仍在继续打磨的部分，是把这些能力变成足够低摩擦的日常系统：每天能自然进入、能快速判断、能留下证据，也能从知识继续走向行动。

版本记录

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 可以合成和建议，但关键写入必须可审核
• 结构越少越好，除非它明显降低未来维护成本

下一步

下一步会继续围绕真实使用来推进：保持日常输入，观察哪些内容真正值得进入 kernel；完善 Control Center 的体验；补齐备份、恢复、可视化回归和更稳定的行动实验闭环。