QUOTE
搜索只是手段，让 AI 的记忆 连续不断裂，才是目的。
—— 九歌
大家好，我是九歌。
今天跟大家分享一个我自己开发的 开源Skill——cross-tool-chat-indexer。
说起来也是被逼出来的：我同时用 Codex、Claude Code 和 WorkBuddy 三个 AI 编码助手，每次换工具或开新对话，AI 就跟失忆了一样，之前聊的全忘了。
本文看点
01
三工具记忆各自为政，上下文反复断裂
02
项目级上下文召回：开新对话前把记忆续上
03
中文按字分词，跨工具精准命中本地记录
01
THE PROBLEM
AI 助手最大的问题，不是不够聪明，是太健忘
你有没有过这种经历？
上周在 Codex 里跟 AI 讨论了一个项目的架构方案——选 PostgreSQL 而不是 MongoDB 的理由、踩过的连接池坑、最终定的分表策略。这周打开 Claude Code 想继续做这个项目，结果——AI 把你当陌生人。
你得从头再说一遍背景，重新解释一遍约束条件，重新喂一遍上周已经聊过的上下文。它不是不想帮你，它真的不记得了。
更要命的是，你可能连“上次聊过”这件事本身都忘了。工具一多，时间一长，那段对话就像从没发生过。
问题不是 AI 不够聪明，而是你和 AI 之间的 上下文，一直在断裂。
上下文断裂发生在三个层面
工具间断裂
Codex 里聊的，Claude Code 不知道；WorkBuddy 里做的，Codex 看不到。三个工具各自封闭，记忆互不相通。
会话间断裂
同一个工具里，开一个新对话就是一张白纸。上周的架构决策、踩坑记录、技术选型，全部清零。
你自己的脑断裂
你也记不清“上次在哪聊的、聊了什么”。工具一多，时间一长，连找回的线索都断了。
这三层断裂叠起来，就是 AI 编码助手最大的效率黑洞。
02
THE LANDSCAPE
三个工具，三种格式，记忆各自为政
如果你同时是 Codex、Claude Code 和 WorkBuddy 的用户，下面的情况应该很熟悉：
Codex把对话存在~/.codex/sessions/下的 jsonl 文件里，每次会话一个 rollout 文件。
Claude Code也用 jsonl，但路径在~/.claude/projects/下，按项目目录分文件夹。
WorkBuddy更特殊——会话元信息在本地 SQLite 里，但 聊天正文在腾讯云端，本机只有标题和工作目录。
三种格式，三套路径，三种数据结构。每个工具都在忠实地记录你和 AI 的交互，但这些记忆彼此隔离，就像三个各自为政的“电子牛马”，谁也不理谁。
这正是 cross-tool-chat-indexer 要解决的问题——不是做一个更好的搜索框，而是建一座桥，把断裂的上下文重新连起来。
03
HOW IT WORKS
一个 Skill，重建你的 AI 记忆
cross-tool-chat-indexer 是一个开源 Skill，符合标准目录结构。核心目标不是“搜得快”，而是 让你的 AI 编码助手拥有跨工具、跨会话的连续记忆。
实现起来分三步，每个步骤对应一条命令：
STEP 01 统一索引——把散落的记忆收回来…bash
python scripts/indexer.py index –source all
一条命令，三个工具的历史全部抽取、归一化、写入 FTS5 全文索引。从此 Codex、Claude Code、WorkBuddy 的历史不再各自为政，汇入同一个记忆库。
STEP 02 跨工具检索——想找什么，一条命令搞定…bash
python scripts/indexer.py search "wireguard 配置"
不用管当初在哪个工具里聊的，直接搜。结果标注来源，附带原始文件路径。搜索是手段——真正帮你省掉的，是“翻三个工具找一段对话”的时间。
STEP 03 项目级上下文召回——这才是核心，也是最实用的部分…bash
python scripts/indexer.py recall "D:/3D汽车/enginecar" –top 5
给一个项目目录，自动找出所有相关历史对话，压缩成精简卡片，直接贴进新对话的 system prompt。
这一步是整个 Skill 最有价值的部分。不是搜索，是记忆的延续。
04
RECALL
为什么“项目级上下文召回”最实用
如果说搜索是“找回一段话”，那 recall 是“找回一个项目的完整记忆”。开了一个新对话，AI 把你当陌生人——你上周讨论过的架构设计、踩过的坑、最终选的技术方案，全部清零。cross-tool-chat-indexer 的 recall 命令就是来终结这个循环的。
1
路径侧：把项目目录拆成 token，跟每条历史记录的 cwd（工作目录）做匹配打分，项目名命中权重最高。
2
内容侧：用项目名 + 顶层文件名（README、package.json 之类的）在全文索引里查相关记录。
3
合并排序：两边分数加起来取 top N 条。
4
压缩输出：压成「意图 + 关键问答」的精简卡片，支持 –format md 直接输出 Markdown。
开新对话前跑一次 recall，把输出贴进 system prompt——AI 就能“想起来”之前在这个项目上做过什么。选了什么技术栈、踩过什么坑、做了哪些决策、上次停在哪里。不是从零开始，而是从上次结束的地方继续。
05
SEARCH
中文搜索这件事，比你想的坑多
“找回记忆”的前提是能搜到。但如果你用过 SQLite FTS5 的默认配置，你就会知道——中文搜索默认是坏的。
原因在于 FTS5 默认分词器 unicode61 会把连续中文当成一个整体 token。比如对话里有“淘宝排名优化方案”，整个被当成一个词，你搜“淘宝”根本搜不到——因为它不是一个独立的 token。cross-tool-chat-indexer 的解决方案：在每个汉字之间插空格，强制按字分词。
“淘宝排名优化方案” → “淘 宝 排 名 优 化 方 案”。unicode61 按单字建索引，搜“淘”能命中，搜“淘宝”也能命中。同时还建了一张 trigram 索引表兜底——按三字符滑窗切分，对子串匹配更精准。两张表并集检索，中文单字、双字、长词、中英混合都能搞定。
实测结果
| 搜索词 | 命中情况 |
| — | — |
| “淘” | ✅ 命中（单字生效） |
| “淘宝” | ✅ 命中 WorkBuddy 淘宝排名会话 |
| "wireguard" | ✅ 命中 Codex K3S/WireGuard 配置会话 |
| “wireguard 配置” | ✅ 中英混合，OR 语义正常 |
| “K3S” | ✅ 跨源命中 Codex + Claude Code |
中文开发者的记忆检索，不再有语言障碍。
06
PIPELINE
四阶段流水线：大白话讲技术原理
如果你好奇它底层怎么实现“记忆连续”的，这里用大白话讲一遍。整个流程分四层：
1
抽取：三个工具各写一个解析器，Codex 读 jsonl 事件流，Claude Code 读项目目录下的 jsonl，WorkBuddy 读本地 SQLite 元信息 + AI 生成的文件。每条记录额外记录 cwd（工作目录），这是做项目级召回的关键。
2
归一化：三个来源格式各不相同，统一成同一张表。不管记忆从哪来，进了这张表都是同一种格式。三份独立记忆，合并成一份完整记忆。
3
存储：写入 SQLite FTS5，建两张虚拟表 ftsunicode（unicode61 分词 + 中文按字分词）和 ftstrigram（trigram 分词器，擅长子串匹配）。两张表并集检索。
4
检索与召回：查询时先做特殊字符处理，再同时在两张 FTS 表里搜，结果取并集。recall 命令额外做路径匹配 + 内容匹配 + 合并排序 + 压缩输出。
07
BOUNDARIES
说句实话：能做什么，不能做什么
✅ 它能做的
统一记忆
三个工具的本地记录统一成一份连续记忆，跨工具检索不用分别翻找。
中文检索
中文关键词 / 子串检索（单字、双字、长词、中英混合都行）。
项目召回
按项目目录召回历史上下文，压缩后注入新对话——终结“开新对话就失忆”循环。
增量索引
新增对话后重跑即可，记忆只增不减。
零依赖
只用 Python 标准库，不需要 pip install 任何东西。
❌ 它做不到的
1
WorkBuddy 聊天正文不在召回范围：内容在腾讯云端，本机只有标题和生成物文件。不是 bug，是数据可得性的客观限制。
2
多词查询是 OR 语义不是 AND：搜“wireguard 配置”会召回包含任一词的记录。需要 AND 精排得自己后处理。
3
是关键词检索不是语义向量检索：能精确找到包含某词的对话，但找不到“意思相近但没出现这个词”的对话。需要语义相似度的得额外接 embedding 层。
知道边界在哪，才能用对地方。
08
DATA
真实数据：拿本机跑出来的
不是 demo 数据，是我自己机器上的真实会话：
| 指标 | 数值 |
| — | — |
| 总索引记录数 | 25,323 条 |
| 独立会话数 | 466 个 |
| 索引库大小 | 190 MB |
| Codex 记录 | 22,405 条 |
| Claude Code 记录 | 2,733 条 |
| WorkBuddy 记录 | 185 条 |
增量索引也验证了：从零重建 25,323 条，立即再跑一次，还是 25,323 条。第三次再跑，依然 25,323 条。不重复、不丢失，稳定。
466 个会话的记忆，从此连续不断裂。
09
INSTALL
安装使用：三个工具都能用
cross-tool-chat-indexer 符合标准技能目录结构，零依赖，纯 Python 标准库实现。话不多说，直接上干货。
GitHub 地址（cross-tool-chat-indexer 子 skill）：https://github.com/JiugeLi/JiugeSkills/tree/main/cross-tool-chat-indexer
STEP 01 获取代码…bash
git clone https://github.com/JiugeLi/JiugeSkills.git
STEP 02 安装到你的 AI 编码工具
安装到 WorkBuddy：
cp -r JiugeSkills/cross-tool-chat-indexer ~/.workbuddy/skills/
安装后 WorkBuddy 自动识别 SKILL.md，对话中提到“搜索之前的对话”等需求时自动调用脚本，无需手动输入命令。
安装到 Codex：
cp -r JiugeSkills/cross-tool-chat-indexer ~/.codex/skills/
如果 Codex 版本不支持自动 skill 调用，也可以直接手动运行：
python ~/.codex/skills/cross-tool-chat-indexer/scripts/indexer.py index –source all
python ~/.codex/skills/cross-tool-chat-indexer/scripts/indexer.py search "wireguard"
安装到 Claude Code：
cp -r JiugeSkills/cross-tool-chat-indexer ~/.claude/skills/
Claude Code 读取到 SKILL.md 后自动加载，对话中出现“之前怎么配的”等意图时自动调用。
STEP 03 构建索引
python cross-tool-chat-indexer/scripts/indexer.py index –source all
一条命令三个工具全搞定。之后新增对话后重跑一次即可（增量 upsert，不会丢旧数据）——你的 AI 记忆库只增不减。
前提条件与隐私
前提条件：你机器上有 Python 3（建议 3.10+），不需要装任何第三方包。
隐私说明：索引只读本地文件，不修改源数据，不联网。索引库建在 data/memory.db，随时可删了重建。不读取 Codex 遥测日志、WorkBuddy 的 secret:// 配置和各工具缓存目录，检索结果不含凭据。
∞
THE END
总结一下
AI 编码助手越来越强，但共同的硬伤是 没有连续的记忆。换工具记忆断了，开新对话上下文清零。你和 AI 花了半小时讨论出的架构方案、踩坑经验——下次见面全忘了。
cross-tool-chat-indexer 做的事情，本质上是给 AI 编码助手装一个“外置记忆体”：三个工具里散落的对话统一收进来，按项目归类，需要的时候自动召回，压缩后注入新对话。
搜索只是手段。让上下文连续不断裂，让 AI 不再每次从零开始，才是这个 Skill 真正想解决的问题。
不是让 AI 更聪明，而是让 AI 不再健忘。
如果你也是多工具用户，被“开新对话就失忆”折磨过——赶紧动手试试吧！有什么问题评论区留言，我们一起交流。
开源，零依赖，一条命令开始。
GitHub 地址（cross-tool-chat-indexer 子 skill）：https://github.com/JiugeLi/JiugeSkills/tree/main/cross-tool-chat-indexer
END
我是九歌，平时专注于 AI 编码工具与效率实践。
