【Code with SOLO】重启客户端后 AI 把我 19500 行代码全忘了，于是我给它装了个"大脑"

SOLO挑战赛专区
1

那天晚上，AI 把我忘了

那天晚上我打开 TRAE SOLO 全新客户端，准备给儿子的饥荒游戏加个新功能。

AI 回了我一句：“你好！我是 SOLO，一个由专有模型驱动的 AI 助手。”

你是谁MTC
你是谁MTC1730×930 84.5 KB

它把我忘了。

19500 行代码、7 天的心血、38 个组件、16 份设计文档——全忘了。

我深吸一口气，开始重新"教"它认识我的项目：这个是 Vue 3 + Pinia 的饥荒风格生存游戏，目录结构是这样的，角色系统在那边，烹饪锅的代码在这个文件……

一个小时后，AI 终于"想起来"了。但我的下班时间也用完了。

这不是我第一次经历这种事了。每一次重启客户端、开启新会话，AI 都是从零开始。我花在"教 AI 记住事情"上的时间，比真正写代码的时间还多。

如果你也用 AI 编程，你一定懂这种感觉。

背景：一个 19500 行的"前传"

这个故事要从我之前的一个项目说起。

前两周，我用 TRAE SOLO 全新客户端给上小学二年级的儿子做了一个饥荒风格的网页生存游戏。从角色选择到四季轮转，从资源采集到智能挂机，7 天时间，SOLO 帮我完成了 19500 行代码、38 个组件、15 个逻辑模块、16 份设计文档。

秋天
秋天1920×1010 166 KB

（详细过程可以看我的上一篇帖子：【Code with SOLO】儿子说原版饥荒太可怕，我用 SOLO 7 天给他做了一个儿童友好版）

游戏做完了，儿子很开心。但我的噩梦才刚开始。

天塌了的版本迭代

游戏上线后，儿子每天回来都会提新需求：

  • “爸爸，冬天太难了，调一下！”

  • “烹饪锅能不能多做几种料理？”

  • “温蒂的幽灵姐姐能不能更强一点？”

每次我都兴冲冲地打开 SOLO，然后——

“你好！我是 SOLO，一个由专有模型驱动的 AI 助手。”

它又忘了。

我不得不重复这个过程：

  1. 先让 AI 读一遍项目结构（10 分钟）

  2. 解释之前的架构决策（10 分钟）

  3. 告诉它上次改了哪些文件（5 分钟）

  4. 终于可以开始写新功能了（如果还没下班的话）

最崩溃的一次，我问它"烹饪锅的代码在哪个文件"，它说"我没有看到这个项目的相关文件"。

那一刻我整个人都裂开了。

顿悟时刻

第三天晚上，我又花了一小时给 AI 讲项目结构。讲完之后我盯着屏幕发呆，突然意识到一个事实：

我花在"帮 AI 恢复记忆"上的时间，已经超过了真正开发新功能的时间。

AI 编程助手的能力已经很强了——它能写代码、能做设计、能当架构师。但它有一个致命的短板：它没有记忆。

每一次新会话，它都是一张白纸。不管你之前做了多大的项目、做了多少次迭代，它都一无所知。

那如果，我能给 AI 装一个"记忆系统"呢？

让它记住每次会话做了什么、改了哪些文件、做了什么决策。下次新会话开始时，自动把这些记忆"注入"回去。

这个想法一旦冒出来，就再也压不下去了。

于是，trae-mem 诞生了。

实践过程：用 SOLO 给 AI 做"大脑"

第一步：拆解"AI 记忆"到底需要什么

我没有直接说"帮我写一个记忆系统"，而是先和 SOLO 一起拆解了需求：

我给 SOLO 的核心 Prompt：


我要做一个 AI 记忆系统，通过 MCP 协议集成到 TRAE IDE 中。

核心需求：

1）每次 AI 操作（Edit/Write/RunCommand）后自动记录；

2）新会话开始时，自动注入项目历史上下文；

3）支持全文搜索，能按关键词检索历史记忆；

4）不能拖慢 AI 的响应速度（异步处理）；

5）支持中文搜索；

6）默认零外部依赖，开箱即用。

请先帮我设计系统架构和技术方案。

AI 失忆的具体场景有哪些？

  • 新会话开始 → 不知道之前做过什么

  • 上下文被压缩 → 中间的决策和讨论丢失了

  • 多项目切换 → 搞混了不同项目的上下文

理想的"AI 记忆"应该是什么样的？

  • 自动记录：不需要手动操作，AI 每次操作后自动记下来

  • 智能检索：能按关键词搜索历史记忆

  • 精准注入：新会话开始时，自动注入相关的历史上下文

  • 轻量无感：不能拖慢 AI 的响应速度

  • 隐私安全：敏感信息不能被记录

技术选型

MCP 协议是 TRAE 支持的 AI 工具调用标准（由 Anthropic 提出），通过 stdin/stdout 通信，零配置启动，让 AI 像调用内置功能一样调用记忆系统。数据库选了 SQLite——轻量、零依赖、单文件部署，配合 FTS5 全文搜索扩展，一个 .db 文件搞定所有记忆数据。

第二步：SOLO 搭建核心架构

我把需求翻译成 Prompt，SOLO 输出了完整的架构设计：


trae-mem/

├── src/
│ ├── mcp/ # MCP Server（14 个工具）
│ ├── store/ # SQLite 数据层（10 张表 + 3 张 FTS 索引）
│ ├── processor/ # 记忆处理器（压缩 + 队列 + Worker）
│ ├── middleware/ # 记忆注入（Token 预算控制）
│ ├── search/ # 全文搜索（FTS5 + 中文回退）
│ ├── service/ # HTTP API + SSE 实时推送
│ ├── cli/ # 命令行工具（14 个命令）
│ └── viewer/ # Web UI（React 19 + Vite 6）
└── package.json

关键设计决策：观察队列模式

AI 调用 trae_mem_record 记忆时，数据不是直接写入数据库，而是先进入一个队列。后台的 MemoryWorker 每 500ms 从队列中取出记录，批量处理（每次最多 5 条），经过压缩后存入数据库。

这样做的好处是：AI 的响应完全不会被记忆系统拖慢。记录记忆是异步的，AI 该干嘛干嘛。

关键设计决策：双压缩策略

从自然语言中提取结构化记忆，有两种方式：

  1. 规则压缩器（默认）：用正则表达式和模式匹配，从 AI 的操作记录中提取标题、类型、文件路径、事实、概念等信息。零外部依赖，不需要任何 AI API 就能运行。

  2. AI 压缩器（可选）：调用 Ollama/OpenAI/Anthropic API，用 AI 来理解和压缩记忆，质量更高。但如果 AI 压缩失败，会自动回退到规则压缩器，不丢失任何数据。

默认用规则压缩器，意味着 trae-mem 开箱即用，不需要配置任何 API Key。

实际效果：AI 的每一次操作都不遗漏

配置好 trae-mem 后，AI 在每次编辑文件、运行命令后，都会自动调用 trae_mem_record 将操作记录到记忆系统中。整个过程对用户完全透明：

在CodeWithSOLO中使用
在CodeWithSOLO中使用982×1368 157 KB

如上图所示，SOLO 在修复 TypeScript 类型错误后，自动调用了记忆系统记录这次修改。不需要手动操作，不需要额外指令——AI 自己就知道"这件事值得记住"。

第三步：踩坑记录——从"能记住"到"记得好"

开发过程中遇到了不少坑，这里记录几个最典型的：

坑 现象 原因 解决方式
中文搜索翻车 搜"记忆压缩"搜不到任何结果 SQLite FTS5 的 unicode61 分词器把中文当成单个字符，无法分词 检测到中文查询时，自动拆分为双字组合（“记忆”+“忆压”+“压缩”），用 LIKE 匹配
记忆"撑爆"上下文 注入太多历史记忆，AI 的可用上下文不够了 没有控制注入的 Token 数量 实现了 Token 预算控制器，精确估算每段记忆的 Token 消耗（中文 1.5 token/字），预算用完即停
队列积压 AI 高频操作时，队列处理不过来 单条处理太慢 改为批量处理（batch=5）+ Promise.allSettled 并行，吞吐量提升 5 倍
数据丢失 Worker 处理失败时，记录直接丢弃了 没有失败重试机制 加入 3 次重试 + 失败存档表，超过重试次数的数据保存到 failed_observations 表，永不丢失
懒加载崩溃 MCP Server 启动时加载所有模块，首次响应很慢 数据库初始化、Worker 启动都在启动阶段 改为懒加载：首次工具调用时才初始化，启动速度从 3 秒降到 50ms

中文搜索的坑值得多说两句。

SQLite 的 FTS5 全文搜索很好用，但它内置的 unicode61 分词器是为英文设计的。对中文来说，"记忆压缩"这四个字会被当成四个独立的 token，你搜"记忆"能匹配到，但搜"记忆压缩"就匹配不到了——因为它找的是连续的 “记忆压缩” 这个 token，而分词器根本没把它当成一个词。

我让 SOLO 设计了一个巧妙的回退方案：当检测到查询中包含中文字符时，自动将查询拆分为双字组合（bigram）。比如"记忆压缩"会被拆成"记忆"和"压缩"，然后在标题、叙述、事实等多个字段中用 OR 条件匹配。虽然不是完美的分词，但实际使用中效果很好。

第四步：Web UI——让记忆"看得见"

记忆系统在后台默默工作，但我想让它"看得见"。

UI界面
UI界面1814×1648 356 KB

我让 SOLO 用 React 19 + Vite 6 做了一个可视化管理界面：

  • 统计仪表盘：顶部实时显示观察数、会话数、提示数，一目了然

  • 项目隔离：左侧按项目分类管理记忆，切换不混乱

  • 类型标签：用颜色区分 decision（紫色）、bugfix（红色）、feature（绿色）、refactor（橙色）等类型

  • 实时推送：SSE 连接状态实时显示，AI 每记录一条记忆立刻可见

  • 全局搜索：支持快捷键 / 快速检索任何历史记忆

  • 暗色/亮色主题：跟随系统偏好自动切换

20 个组件、4 个自定义 Hooks、9 个 CSS 模块，全部由 SOLO 生成。

魔法时刻：AI 第一次"想起来"了

trae-mem 装好后的那天晚上，我打开一个新会话，试探性地问了一句：

“昨天做了什么？”

AI 没有说"你好！我是 SOLO，一个由专有模型驱动的 AI 助手。"

它调用了 trae_mem_context 获取历史上下文，又调用了 trae_mem_timeline 查看操作时间线，然后告诉我：

根据记忆系统记录，您昨天的工作内容如下：

  1. 22:57:40 - 创建了 demo.js 文件，编写了快速排序算法
  1. 22:57:44 - 运行了 demo.js 文件，验证算法正确性

昨天做了什么
昨天做了什么1544×966 91.7 KB

它记得。它真的记得。

我又试了另一个项目，问"今天做了什么"。AI 查询后回复：

今天还没有任何操作记录。这可能是因为：

  1. 这是您第一次在这个项目中使用记忆系统
  1. 今天还没有执行任何需要记录的操作

今天做了什么
今天做了什么633×428 60.1 KB

连"没有记录"都能给出友好的解释，而不是冷冰冰的"我不知道"。

那一刻，我感觉 AI 真的"活"了过来。

它不再是一个每次都要重新认识的陌生人，而是一个记得你、记得你的项目、记得你们上次聊到哪里的"老搭档"。

这才是 AI 编程助手应该有的样子。

意外收获：AI 变成了我的"周报助手"

trae-mem 上线后，我发现了一个意料之外的使用场景。

有一天快下班了，我突然需要交周报，但完全想不起来这周做了什么。我随口对 AI 说了一句：“帮我生成本周周报。”

AI 连续调用了 5 次 trae_mem_report 获取各项目的工作记录，又调用 trae_mem_context 补充细节，然后生成了一份结构完整的周报：

生成周报
生成周报1222×1144 77.8 KB

从那以后，"帮我生成本周周报"成了我每周五下午的固定动作。

trae-mem 不仅解决了 AI 失忆的问题，还意外地解决了我"每周五不知道周报写什么"的问题。谁能想到呢？

成果展示

项目数据

指标 数据
开发周期 约 3 天（每天下班后 2-3 小时）
源码文件 78 个
总代码行数 13,800 行
MCP 工具 14 个
数据库表 10 张核心表 + 3 张 FTS 索引表
CLI 命令 14 个
Web UI 组件 20 个
生产依赖 仅 3 个（better-sqlite3 + express + commander）
AI 生成占比 100%（全部代码）

14 个 MCP 工具一览

工具 用途
trae_mem_context 新会话开始时，自动注入项目历史上下文
trae_mem_record 每次操作后，自动记录到记忆队列
trae_mem_search 按关键词搜索历史记忆
trae_mem_decision 记录结构化决策（含备选方案和理由）
trae_mem_timeline 以某条记录为锚点，回溯操作时间线
trae_mem_summarize 为指定会话生成结构化摘要
trae_mem_report 生成项目周期报告（日/周/月/季度）
trae_mem_related_files 查找经常一起修改的关联文件
trae_mem_pin 置顶重要记忆，下次注入时优先展示
trae_mem_stats 查看记忆系统使用统计
trae_mem_toggle 随时开关记录（处理敏感数据时关闭）
trae_mem_update 更新已有记忆内容
trae_mem_delete 删除记忆/会话/项目记录
trae_mem_batch 批量操作

技术栈

层级 技术
语言 TypeScript (ESM)
数据库 SQLite + FTS5 全文搜索
通信协议 MCP (JSON-RPC 2.0 over stdio)
后端服务 Express.js + SSE
Web UI React 19 + Vite 6 + Recharts
包管理 pnpm (workspace monorepo)

仓库与安装

  • Gitee 仓库：https://gitee.com/iyitong/trae-mem

  • 一键安装：git clone + pnpm install + pnpm build + trae-mem init

  • 3 分钟上手：安装 → 配置 MCP → 添加用户规则 → 完成

效果与总结

trae-mem 改变了什么？

使用前：

  • 每次新会话都要花时间重新让 AI 了解项目

  • 上下文压缩后丢失关键决策信息

  • 多项目切换时频繁搞混上下文

  • 版本迭代像在"考古"

使用后：

  • 新会话秒级恢复上下文，AI 直接"记得"你之前做了什么

  • 重要决策自动记录，随时可搜索回溯

  • 多项目记忆隔离，切换不混乱

  • 版本迭代像在"续写"，而不是"重写"

SOLO 在 trae-mem 中扮演的角色

角色 贡献
需求分析师 帮我拆解"AI 记忆"的具体需求
架构师 设计 MCP Server + 异步队列 + SQLite 的整体架构
后端开发 实现 14 个 MCP 工具、双压缩策略、Token 预算控制
前端开发 实现 React 19 Web UI（20 个组件）
数据库设计师 设计 10 张表 + 3 张 FTS 索引 + 25 个索引
调试专家 定位中文搜索、队列积压、懒加载等问题
技术文档 生成 README、CLI 帮助文档

5 条核心经验

  1. 从真实痛点出发，而不是从技术出发。trae-mem 不是"我想做一个记忆系统"，而是"我被 AI 失忆折磨得受不了了"。真实痛点是最好的产品驱动力。

  2. 异步设计是关键。记忆系统绝不能拖慢 AI 的响应速度。观察队列 + 后台 Worker 的设计，让记忆记录完全异步化，AI 零感知。

  3. 默认零依赖，高级功能可选。规则压缩器不需要任何 AI API 就能运行，降低了使用门槛。AI 压缩作为可选增强，让进阶用户有升级空间。

  4. 永不丢失数据。3 次重试 + 失败存档表，确保即使处理出错，原始数据也不会丢。这是记忆系统的底线。

  5. 让 AI 自己来开发 AI 的工具。trae-mem 全部 13800 行代码都由 SOLO 生成——用 AI 来解决 AI 自身的问题，这本身就是一件很酷的事。

trae-mem 适合谁？

  • 用 TRAE IDE 或 TRAE Code 模式开发中大型项目的开发者

  • 受够了每次新会话都要重新"教 AI"的人

  • 希望在 AI 编程中保持连续性和上下文的团队

  • 对 MCP 协议和 AI 工具链感兴趣的技术探索者

如果你也在用 AI 编程……

你有没有遇到过 AI "失忆"的崩溃时刻？你是怎么解决的？

你觉得 AI 应该有"记忆"吗？欢迎在评论区聊聊 :backhand_index_pointing_down:

如果觉得 trae-mem 对你有用，欢迎 Star :star: 支持一下，也欢迎 Fork 后根据自己的需求定制。遇到问题可以提 Issue，我会积极回复。

项目地址：https://gitee.com/iyitong/trae-mem

前传：【Code with SOLO】儿子说原版饥荒太可怕，我用 SOLO 7 天给他做了一个儿童友好版