用 Hermes 建个人知识库：从对话碎片到可检索上下文

认知：AI 助手的价值在积累，不在单次回答

个人知识库失败，常见原因不是工具不够多，而是 没有稳定捕获路径：链接丢进 Notion 却从不回看，微信收藏上千条却永不检索。Hermes 的优势在于对话本来就发生在你每天用的 Telegram 或 Slack 里，捕获成本低于再开一个「笔记专用 App」。

但这里有一个前提：你要用固定格式把决策、结论、待验证假设写进对话，而不是只扔链接让模型猜。模型无法从你粘贴的 URL 里自动提炼出「你赞成还是反对」，它需要你用结构化语言明确表达立场。

三层结构

捕获层

所有值得留下的东西，尽量在同一线程用统一前缀。不要写散文式的感想，要用模型容易检索的短句：

[KB] 结论：选用 PostgreSQL，因团队已有运维经验
    [KB] 待验证：新缓存方案在峰值 QPS 下是否达标
    [KB] 风险：订单服务拆分后，分布式事务可能超时
    

模型与网关记忆都更容易在后续检索里命中结构化句子，而不是散乱口语。关键是把「结论」和「理由」一起写，只写结论没理由的话，两周后你自己也忘了为什么。

归纳层

每周一次，让 Hermes 执行固定任务：「根据本周带 [KB] 的消息，生成三条结论 + 两个未决问题」。具体 prompt 可以这样写：

请扫描本周所有包含 [KB] 的消息，按以下格式输出：
    1. 已确认结论（附原始消息日期）
    2. 仍未决问题（附阻塞原因）
    3. 建议下周一条可执行行动
    禁止编造未出现过的项目名或技术选型。
    

若已接 Honcho，它会额外沉淀沟通风格与长期目标，减少你重复解释「我是谁、在做什么」。Honcho 的归纳不是简单汇总，而是尝试推导你的偏好模式，比如「此人倾向于先写测试再重构」。

检索层

内置 SQLite FTS 适合关键词与短语搜索。FTS5 虚拟表建立在消息文本上，检索语法支持前缀匹配和布尔组合。比如你想找缓存相关决策，直接问：「我之前关于缓存的结论是什么？」网关会在 FTS 表里匹配「缓存」关键词，返回相关消息。

Honcho 适合「我上次关于缓存说了什么倾向」这类语义追问。区别是 FTS 需要关键词命中，Honcho 能理解近义词和上下文。不要混用期待：FTS 搜不到时，先检查是否用了 [KB] 标记，再考虑上 Honcho。

五步操作流程

1. 选主通道：只选一个做 KB 入口，建议 Telegram，因为手机端发消息最方便。避免三端各记一份，否则同一结论在不同渠道里重复或矛盾。

2. 写 5 分钟背景卡：在首条会话发送结构化自我介绍，例如：

   职业：后端工程师，主语言 Go
       技术栈：PostgreSQL, Redis, Kubernetes
       进行中项目：订单服务重构（目标：拆分支付模块）
       偏好：结论先行，代码示例用 fenced block
       

   背景卡不是一次性写完就不管，项目切换时要主动更新。

3. 坚持 [KB] 前缀：只对结论、决策、可执行待办使用，闲聊不加标。泛滥的标记等于没有标记。

4. 周五复盘：同一线程执行周总结，把输出复制到你的正式笔记系统做冷备份。Hermes 做热数据，Obsidian 或 Notion 做冷存储。

5. 探针测试：下周一问「上周五 KB 里未决问题有哪些」，不通过则调整前缀格式或考虑开启 Honcho。

与 Notion AI、纯向量笔记的对比

方案	强项	弱项
Notion AI	文档结构、团队协作	对话发生在 IM 时仍要搬运
向量笔记 + 插件	精细排版	捕获仍靠人工粘贴
Hermes 网关	IM 原生、跨会话	需要自律的标记规范

实测路径：Hermes 做 流动捕获 + 周归纳，Notion 做 权威归档。不要让 Hermes 唯一承载合规存档，网关 SQLite 文件可能损坏或误删。

常见失败模式与修正

失败 A：只丢链接不写结论

Agent 无法从 URL 稳定提炼你的立场。修正：粘贴链接后补一句「我认为这个方案可行，因为兼容现有 CI 流程」。

失败 B：KB 标记泛滥

什么都加 [KB]，检索噪声爆炸。修正：只对决策、风险、待办三类加标，且每条不超过 50 字。

失败 C：从不冷备份

网关磁盘损坏等于知识库归零。修正：周五把周总结同步到 Notion/Obsidian，同时导出 SQLite 文件到外部存储。

# 每周五执行
    sqlite3 ~/.hermes/memory.db ".dump" > ~/backups/hermes_kb_$(date +%Y%m%d).sql
    

隐私分级建议

级别	内容示例	能否进 Hermes
公开	技术选型倾向	可以
内部	客户代号	脱敏后
机密	合同金额	不要

个人 KB 不等同公司 Wiki。涉及合规、客户名、未公开财务的内容，不要进入个人 Telegram Bot 线程。

检索探针（24 小时与 7 天）

探针	操作	通过标准
T+24h	问「昨天 [KB] 里未决问题」	列出原文，不编造
T+7d	问「本周三条结论」	与周五复盘一致
跨端	在另一 IM 问同一事实	网关记忆命中

任一失败：先查是否未用 [KB]、是否多通道未隔离、是否未备份导致库损坏。不要先换模型。

局限与不适合谁

没有标记规范，任何记忆系统都会退化成聊天记录堆砌。若你从不复盘、也不要求检索，KB 流程是负担而非帮助。高度结构化文档（法条、论文精读）仍应用专业文献工具，Hermes 适合 决策与项目脉络，不适合替代 Zotero。

团队若要求所有知识进企业 Wiki 审计，需另做导出与权限设计。网关 SQLite 的权限默认只对当前用户可读，但备份文件如果放在共享目录里就会暴露。FTS 检索对中文分词的支持取决于 SQLite 编译选项，某些版本可能把「缓存方案」拆成单字匹配，导致噪声增加。Honcho 的语义检索更准确，但需要额外费用和出网权限。