没有万能方案，只有适合自己的工作流。

为什么我要搭知识记忆系统

上半年我一直在做一个卡牌对战游戏项目，4 个人的小团队加上将近 50 个 AI Agent 协同开发。几乎每天都在和 AI 进行高强度协作，写代码、调架构、讨论设计决策。

但是很快就暴露了很多问题，其中最主要的一块就是 AI 记忆总是缺失和知识方法调用繁琐的问题。

比如，我和 AI 在一个会话里讨论了两个小时的玩法设计，从回合机制聊到积分系统，从英雄行动点聊到机关交互，过程中做了十几个关键决策。到突然到了某个零界点，就会发现思考时间变长，出字速度变慢，接着就感觉到AI 的回复明显开始飘了，之前敲定的很多规则开始被忽视，并且开始提出一些和已有决策矛盾的建议，这其实就是上下文压缩把前面的关键讨论给丢掉了。

这还只是单会话内的问题，如果涉及到跨会话，那就更烦了。有时候花一个多小时设计的组件化 UI 架构，定下三层基类，但是换个会话想继续开发，它就完全不记得了，又要从零开始详详细细地阐述一遍或者是让AI总结成一个文档，然后在新会话里喂给它。我平时可能七八条线一起走，这么导来导去，有时候还忘记是哪个会话来衔接，就变得麻烦的不得了。

还有连续性工作。开发一个复杂的战斗系统，都是要跨好几天反复迭代。每天开工我都得啰哩吧嗦地手动给 AI 注入上下文，只要忘了注入某条规则，AI 的产出就会变得不稳定，而且很多时候都是要开发完了以后，才能够知道问题所在，这个时候改动的成本和反复出现BUG的概率就会大大增加。

还有就是方法论的沉淀问题。我在调试过程中总结出了很多经验法则，比如”GUT 测试框架的信号要记得用 await”、”DesignTokens 的颜色值不能硬编码”，但这些经验散落在不同会话里，AI 没法自动调用。每次遇到类似问题，我得手动翻聊天记录找当时的结论，然后复制粘贴给 AI 看，它才会按正确的方式来。

总结一下就是，AI 很聪明，但它没有持续的记忆，经常让我有一种和得了阿滋海默症的智慧老年人对话的感觉。

这个问题困扰了我将近两个月，我看了很多解决方案，从 Karpathy 的 LLM Wiki 理念到各种 RAG 架构，再到 memory-as-a-service 的产品，最终搭建了一套属于自己的三层记忆系统。

但是这篇文章绝不是某种标准答案，而只是我个人的实践经验。每个人的工作习惯不同，对知识库和记忆的需求也不相同。我走过的弯路、做过的取舍，可能比直接抄我的配置更有价值。

LLM Wiki：将知识编译成网

Karpathy 在他的博客里提出了一个简洁的理念：与其每次让 AI 从原始素材里检索碎片，不如预先把素材编译成结构化的 Wiki 页面。需要时直接读取已编译好的知识，而不是每次重新从散乱的文档里拼凑。

这个理念打动了我，于是我到处去找各种能落地的方案，最终参考了 GitHub 上的 yyswiki 项目来搭建自己的 Wiki 层。

我的 Wiki 目前在 Obsidian 里，结构很简单，主要是不想有太多的花费和复杂的结构，毕竟Obsidian里我还是经常会去手动处理不少笔记和内容。

wiki/
├── summaries/      # 摘要：万字长文的浓缩版（24篇）
├── concepts/       # 概念：一个知识点的完整解释（51个）
├── comparisons/    # 对比：两种方案的横向比较（6篇）
├── entities/       # 实体：具体的人、项目、产品（2个）
└── index.md        # 全局索引

每种页面类型都有固定模板。比如概念页：

---
created: 2026-04-07
status: 已完成
type: concept
domain: 人工智能
sources:
  - "[[来源文章]]"
---

# 页面标题

## 一句话定义
> 用一句话概括本质

## 详细解释
（完整解释，包括背景和发展）

## 核心组成
- 要素 1：
- 要素 2：

## 应用场景
| 场景 | 说明 | 示例 |
|------|------|------|

## 相关概念
- [[概念A]] — 关系说明

模板的价值在于一致性，无论谁写，无论 AI 辅助还是手动，出来的页面结构都很统一。统一意味着可预期，我知道我要在哪里找到我想要的东西。当然，还有一个更重要的原因是，我对于笔记有一种强迫症，希望看到它们都整整齐齐的。

可信源筛选：为AI降低幻觉打下基础

我个人在搭 Wiki 的时候很长一段时间困扰我的是哪些东西值得编译进去。

我的 Obsidian 库里有很多内容：剪藏文章、项目日志、闪念笔记、临时思考、待办清单……一开始我没想清楚这个问题，随手把日志和闪念笔记也丢进了编译流程。结果检索时很多临时的想法和未经验证的信息，被 AI 当成事实来用，严重影响到我的工作内容和质量。

没办法，最终我只能对 Wiki 进行了一次数据重构，只将”已完成”且”我确信”的内容编译进去。

具体标准：

• ✅ 已完成的深度阅读笔记，我认真读完并做了批注的
• ✅ 已落地的项目决策，讨论过、执行过、有结果复盘的
• ✅ 已验证的方法论，自己实践过、确认有效的
• ❌ 日志和过程记录，当天干了什么、完成到哪一步了
• ❌ 闪念笔记，突然冒出的点子、还没验证的假设
• ❌ 临时思考，聊天时顺口的，随时可能推翻的

这些高度可信的信息源，以原始资料的形式存放在 03-🗃️Areas/和 04-📚Resources/ 里不动，因为它们是经过筛选的高可信度内容，所以最终会被编译进 wiki。编译过程本身也是一次再确认，在整理成 Wiki 页面时会重新审视信息是否准确、完整、仍然有效。

目前 Wiki 有 248 页，覆盖 AI 工程、游戏设计、道教玄学等领域。规模不大，但每一页都是确定且极富价值的。

Wiki 层的局限

Wiki 以 Markdown 的格式存在，对人来说是很友好的，加上 Obsidian 的双向链接和关系图谱，很适合阅读和思考。但单纯以索引为主的 Markdown 文档，本质上其实是给人看的。对于 AI 而言，未必需要这样的格式和结构，AI 更需要的是能直接用的内容，能自动检索、自动写入、自动关联的信息结构，而不是每次都手动把文档内容贴给它。

更关键的是，Wiki 解决的是”知识存储”问题，没有解决AI 在连续工作中不断丢失上下文这个问题。

Second Brain：让 AI 记住工作方式和思维链路

为什么先搭这套，而不是直接上重型方案

我先搭建了 brain-sync 这套轻量系统，没有直接启动更重度的 GBrain ，原因很简单，我当时的核心痛点不是”大规模知识检索”，而是”AI 记不住我的工作方式”。

我需要的是，AI 记住我的偏好和习惯、记住项目的各项规则和约束、记住我之前做过的决策和原因、记住我总结出的方法论。这些东西加起来可能就几百条信息，不需要太复杂的功能和知识图谱，但需要精准、可靠、自动化地在对话中被调用出来。

在我看来，这也是 Harness Engineering 的一部分，让 AI 更懂你的上下文，在你的约束条件下工作。

架构演进：从强制触发到静默召回

brain-sync 经历了两次大的迭代。

V1 版本很粗暴，每次会话的第一条消息，Skill 强制 AI 调用记忆查询工具。不管你说的是”早上好”还是”帮我查个 bug”，它都要先停下来查一遍记忆库。

实际体验后，感觉很不好。比如，有一次我打个招呼，想测试下是否在线，AI 居然回复”在呢！让我先查一下您的记忆……”就为了一个问候，它硬生生调了一次 MCP 查询，我意识到这不仅仅是一种资源的浪费，也会因为过度查询造成另一种上下文污染。而且如果仅依靠 Skill 来触发，其实并不稳定，不是每次都能命中。于是我对触发进行了重构。

V2 版本（当前）的重构，把”自动召回”从 Skill 里抽出来，放到 Hook 层：

核心思想是 Hook 负责自动的部分，Skill 负责用户显式触发的部分。

Hook 在系统层面静默运行。AI 看到的只是上下文里多了一段召回结果，直接纳入思考，不需要主动调任何工具。对话也会变得自然，感官上给人 AI 看起来本来就知道的感觉，而不是总看到 AI 说”让我先查一下”。

记忆分类

不是所有对话内容都值得记。我定义了四类：

Preference（偏好），代码风格、输出格式、工作习惯等。

Decision（决策），项目架构选择、已确定的技术方案、已执行的配置变更。

Method（方法），验证过有效的调试流程、最佳实践、踩坑后得出的经验法则。

Insight（洞察），对某个技术的深度理解、跨领域迁移的认知模型、需要长期保持的当前最佳认知。

举个真实场景：有一次我在项目 A 里处理了一个”回合时序不同步”的 bug，排查了很久，最终方案是在 TurnManager 里加一个时序校准步骤。我让 AI 记住了这个方法。两周后我在另一个项目里遇到了几乎一样的问题，AI 在处理这个问题时触发了记忆召回（我提到了”时序”和”不同步”这些关键词），它直接从 Second Brain 里调出了之前的解决方案，问我要不要复用。我看了一眼确认适用，整个修复过程很快就完成了。如果没有这套记忆系统，我可能已经忘了当时怎么解决的，又得从头排查一遍。

写入前有查重流程。每次写入先查 Second Brain 中是否已有类似主题的记忆，有的话就不再新建，而是更新旧条目的 Current Best Understanding，在 Evidence Trail 中追加新的证据来源。

---
type: method
title: 回合时序不同步的修复模式
tags: [memory, method]
confidence: high
created: '2026-05-08'
---

## Current Best Understanding

回合时序不同步问题的根因是……修复方式是……

## Evidence Trail

- 2026-05-08: A项目战棋玩法调试 → 发现 TurnManager 时序校准方案有效
- 2026-05-22: 项目B遇到同类问题 → 复用方案，确认通用性

Evidence Trail 的设计借鉴了司法证据链的思路，不仅记录”我知道什么”，还记录”我为什么知道”。两条记忆冲突时，时间戳和证据来源就是裁决依据。

API 选型：不需要顶级模型

搭建过程中一个反直觉的发现，处理向量化和批量任务不一定需要 GPT-4 或 Claude 这种强力模型。

我的 API 用的是接口AI（第三方 OpenAI 兼容接口），Embedding 模型是 text-embedding-3-large。实际的文本处理、事实提取、记忆整理用的是 Kimi 2.6 和 DeepSeek V4。

原因很简单：记忆提取本质上是信息抽取+结构化的任务，不需要最前沿的推理能力。国产大模型在这个场景下表现已经很好，成本只有 GPT-5.5 和 Claude Opus4.6 的1/5-1/10。

所以我的模型使用策略是深度推理用顶级模型，日常批量任务用性价比模型。

brain-sync 的局限

当记忆规模增长到上千条时，简单的关键词匹配开始不够用，需要向量搜索、语义理解、相关性排序。更重要的是，我在 Mac 和 Windows 双端工作，AI工具涉及到 Hermes、Workbuddy、codebuddy、openclaw、codex，我希望的是在一端沉淀的记忆需要在其他端也能用上。

GBrain：当记忆需要跨平台和规模化

当 Wiki 增长到几百页、记忆超过上千条时，我遇到了新瓶颈：关键词匹配召回不相关内容、跨文档关联缺失、手动维护成本越来越高。

这时我引入了 GBrain，这是 Garry Tan 开源的个人 AI 记忆基础设施。

GBrain 本身的安装部署不展开讲，Github 上写得很清楚，把链接丢给 AI 基本上就能自动完成。我想重点说的是为什么选择 Supabase 云端方案，以及它带来的实际价值。

Supabase 云端：解决多端共享问题

GBrain 支持本地 PGLite 和云端 Supabase 两种存储方式。一开始我用的本地方案，数据只在一台机器上。但我的工作环境是 Mac + Windows 双端，还有其他各种 AI 工具和平台，公司用 Windows，家里用 Mac，经常需要切换。

本地方案意味着换一台电脑，AI 又失忆了。所有的偏好、决策、方法全部丢失，或者我得手动同步数据库文件。

迁移到 Supabase 云端 Postgres + pgvector 之后，这个问题彻底解决了。两台机器连接同一个 Supabase 实例，共享同一套记忆库。我在 Mac 上沉淀的方法论，切到 Windows 开发时同样能被召回。新配一台开发机，只需要配好 GBrain 的连接参数，所有历史记忆立刻可用，不需要迁移任何文件。

这对我的工作方式影响很大，不再被绑定在某一台特定的机器上。

GBrain 的核心能力

简单概括：

• 混合搜索：向量相似度 + 关键词匹配 + RRF 融合 + 多查询扩展
• 知识图谱：自动提取实体关系，零 LLM 调用
• 自动丰富：新内容进来后自动补全信息、建立链接

通过 gbrain serve 启动 MCP Server 后，AI 可以直接调用 30+ 个工具进行查询、写入、维护。

不要过早引入

虽然 GBrain 有各种有点，但我还是想说，如果你的 Wiki 只有几十或百来页，记忆条目很难上千，这个时候装了 GBrain，结果就是大部分功能用不上，知识图谱里几个孤零零的节点，自动丰富也没什么价值，每天还要审阅它自动生成的关联建议，使用起来会显得笨重，未必是最好的选择。所以建议 Wiki 和记忆条目达到一定规模后，或明显感觉到检索效率下降或有多端需求时，再考虑 GBrain。

三层如何协同

┌─────────────────────────────────────────────────────────────┐
│                    人类交互层（Obsidian）                       │
│              LLM Wiki：可读、可浏览、可手动修正                  │
└──────────────────────────┬──────────────────────────────────┘
                           │ 人工编译 / AI 辅助编译
┌──────────────────────────▼──────────────────────────────────┐
│                    记忆管道层（WorkBuddy）                      │
│     Hook：自动召回、周期检查、会话补漏                           │
│     Skill：用户显式触发时的精修写入                              │
│     四类记忆：preference / decision / method / insight         │
└──────────────────────────┬──────────────────────────────────┘
                           │ MCP 调用
┌──────────────────────────▼──────────────────────────────────┐
│                   检索基础设施层（GBrain + Supabase）           │
│     混合搜索 + 知识图谱 + 自动丰富                              │
│     多端共享同一套记忆库                                        │
└─────────────────────────────────────────────────────────────┘

写入流：对话产生有价值信息 → Hook 自动提取 → Hot Memory → 用户说”记住这个” → Skill 查重、精修 → 写入 Second Brain

读取流：用户提问 → Hook 检测关键词 → 查询 Second Brain → 注入上下文 → AI 基于记忆响应

人工作业：定期审阅 Wiki 和自动生成的记忆，修正错误，驱动知识复利。

一天的真实场景

早上打开 WorkBuddy 继续昨天的工作。第一条消息：”继续昨天的战棋玩法调试。”

Hook 检测到”继续”和”昨天”，自动召回相关记忆。AI 直接回复：”好的，昨天修好了机关交互的渲染问题，今天继续看敌人 AI 第二回合后卡住的 bug。需要先回顾代码结构吗？”

上午排查完敌人 AI 卡住的BUG 。我说：”记住这个BUG修复经验。”AI 查重后写入 Second Brain。

下午在 Obsidian 里把开发经验和心得写下后编译进 Wiki 页面。下次 GBrain 同步时自动导入。

晚上和 AI 讨论新功能时提到”敌人 AI 优化的问题”，Hook 召回上午写入的记忆，AI 直接引用方案，不用我重新解释。

整套流程，可以实现记忆在对话中自动沉淀，知识在 Wiki 中被结构化整理，GBrain 负责在需要时精准召回。

最后

写到这里想回到开头那句话：没有万能方案，只有适合自己的工作流。

yyswiki 的理念很好，但你的可信源标准可能和他的完全不同。GBrain 很强，但你可能还不需要这么重的基础设施。brain-sync 的 Hook 架构对我而言很顺畅，但你也许并不需要。

我的分享并不希望大家照搬，而是希望能提供一种思路。

• 知识层：什么值得被记住？
• 管道层：怎么自动记住和召回？
• 基础设施层：规模大了、多端跨平台想要共享知识记忆库怎么办？

你可以只搭第一层，Obsidian + 手动编译就能让知识复利。也可以只搭第二层，一个 Markdown 文件就能解决会话失忆。甚至可以只用 GBrain 的模式让机器自动管理。

关键是先理解自己的需求，再选择工具，而不是被工具定义需求。

我花了几个月迭代到今天的架构，中间也推翻重来了几次，但每一次推翻都让我更清楚自己真正需要的是什么。

参考链接

• Karpathy LLM Wiki 理念
• yyswiki 教程：https://github.com/aresbit/yyswiki/blob/main/TUTORIAL.md
• GBrain 开源项目：https://github.com/garrytan/gbrain
• 接口AI（OpenAI 兼容 API）：https://api.jiekou.ai/