企业官网建设流程全解析

平时做AI应用开发的朋友应该都有这种体验：Claude聊得好好的，各种偏好、项目背景、上次未完成的方案都交代清楚了，可一旦会话一关，下次再开，它就跟失忆了似的，什么都不记得。我一开始也觉得这是常态，毕竟大模型本身就是无状态的，但随着对话次数变多，同一个需求被反复解释，这种“金鱼记忆”带来的心智成本越来越让人抓狂。于是我开始研究怎么给Claude外挂一层长期记忆，翻了不少资料、试了不少方案之后，我围绕一个开源项目思路“claude-mem”做了一个自己的可落地版本——给Claude加上了跨会话的持久记忆能力。这篇内容就是把我实际踩过的坑、验证过的设计方案、能直接复用的代码结构都梳理一遍，如果你也在折腾AI助手的记忆增强，应该能帮你省下不少试错的功夫。

1. 先搞清楚要解决什么痛点

1.1 Context Window：AI的“金鱼记忆”本质

大语言模型的能力再强，它的工作方式也是“一次性”的：你把上下文塞进token序列，它给你输出结果，完了这轮对话的所有信息就只存在于这一轮。用户关掉页面、换一个新session、或者对话长度超过限制之后，前面的内容就彻底“消失”了。

这个限制跟模型聪明不聪明没有关系，纯粹是架构决定的。Transformer 的注意力机制在生成每个token时都需要重新扫描上下文，所以模型内部根本没有“持久存储”的概念，它所知道的一切，都来自当前这组输入文本。这就好比你在一个记忆力完全依赖便签的人对面说话，但每说完一句话，他手里的便签就被风吹走了——他记不记得住，完全取决于你这次递给他多少张便签。

对于个人助手、私人知识库、客服机器人这类需要累积理解用户的应用来说，这个缺陷是致命的。用户懒得每次重复自己的背景、偏好、项目进度，如果AI每次都表现得像个陌生人，那“助手”本质上就是个高级搜索引擎，谈不上“懂你”。

1.2 官方记忆机制的限制与空白

可能有人会问：现在不少AI产品不是也提供了“记忆”功能吗？比如让模型记住你的名字、偏好之类。这类功能实际背后是两套方案在跑：一套是把长期信息做成system prompt的一部分，每次请求都带上；另一套是用一个外部存储把历史对话摘要存下来，需要时再取回。

但这两种方案都有明显边界。第一，能塞进system prompt的字符有限，真正积累了十几轮、几十轮交互信息之后，全量塞进去既慢又贵；第二，官方记忆通常是产品层面自己控制的，开发者想深度定制、控制哪些记忆被写入、哪些被召回、如何做权限隔离，基本做不到；第三，很多场景下我们需要的是为特定项目、特定用户维护一套可编程的记忆体系，比如按项目分组、按时间衰减、按语义聚合——这套东西只能自己造。

所以“claude-mem”这类项目的价值就很清楚了：它不是替代模型本身，而是在模型外面加一层可控的、可检索的、能跨会话复用的记忆系统。模型的聪明大脑不变，但我们给它配了一个外挂的笔记本，让它可以在需要的时候翻看过去写下的东西。

1.3 项目核心定位：给模型外挂一个笔记本

“claude-mem”本质上是一个记忆管理中间层：它监听你和Claude的对话，把发生过的关键信息抽取、加工、存储起来，等到下一次对话开始时，把最相关的旧记忆拉出来，注入到新会话的上下文里。

这个“外挂笔记本”有三个核心设计目标。第一，记忆要是结构化的，不能只是把聊天记录原样保存，那等于没加工；第二，召回要是语义化的，不能靠关键词硬匹配，得让“上周讨论过成本优化方案”这种模糊表述也能命中相关记忆；第三，存储要是可干预的，哪些记忆要沉淀、哪些要丢弃、哪些按项目隔离，开发者必须能手动控制。

围绕这三个目标，我把整个系统拆成了四个环节：采集、加工、存储、召回。下面详细拆解这套流水线。

2. 整体设计：给Claude外挂一套记忆系统

2.1 记忆流水线：采集、加工、存储、召回

整个记忆系统可以类比成一个健康档案中心。患者的每次就诊记录（对话）会被整理成病例（结构化记忆），然后归档到一个索引库里，下次医生接诊时，根据症状（当前问题）从档案库里调出最相关的那几份病历，放在办公桌上参考。

落到技术上，就是四个模块：

采集模块：拿到用户与Claude的全部对话消息。最直接的途径是代理Claude API的请求，把所有对话输入输出记录下来。也可以把日志文件监听、数据库触发器这些方式作为补充，但核心都是“拿到完整且干净的消息流”。

加工模块：这是整个项目的灵魂。每次对话结束后，把这段对话的完整文本发给一个大模型（可以仍是Claude），让它抽取“用户说了哪些事实”“用户有哪些偏好”“当前任务进展到什么程度”“有哪几个待办事项”，输出成结构化的JSON。这一步把原始聊天压缩成高密度的记忆单元。

存储模块：加工出来的记忆单元不仅要存原文，还要存一个向量化表示——把一段话转成一串浮点数向量，这样后续才能做语义相似度检索。我用SQLite做底层，加了自定义向量检索函数，整个库就是一个文件，搬迁、备份都简单。

召回模块：新会话启动时，把当前用户的问题做同样的向量化，在记忆库里做最近邻搜索，挑出最相关的几条记忆，拼成一段“记忆摘要”，注入到Claude的对话前缀里。

这四个模块串成一个闭环，每轮对话结束后异步更新记忆，下一轮对话开始时自动召回。整个流程里唯一的大模型调用发生在加工和生成环节，存储和检索部分全是本地计算，成本和延迟都控制得住。

2.2 记忆存储的选型对比：为什么我选了SQLite

首先是存储方案的选择。我实际对比过几类方案：纯JSON文件、SQLite、独立的向量数据库（比如专业的向量数据库服务）、关系型数据库加外置向量索引。这里列一个我在实际测试中总结的对比表：

为什么最终选了SQLite？原因有三。

一是收敛性。一个个人AI助手的记忆规模，即使每天高强度对话，连续用一年，有效记忆条目大概率也就是几万条。这个量级在SQLite里做全表余弦相似度计算，单次查询通常只要几十毫秒，完全不需要引入分布式组件。二是可运维性。整个记忆库就一个文件，备份只需拷贝，换机器只需搬运，出了问题可以直接用SQL工具打开检查。三是可定制性。自己的检索逻辑可以随时改，比如我在里面加了一个时间衰减因子，超过30天没命中的记忆权重自动下降。

如果未来记忆规模涨到百万级，再把底层换成专业向量数据库也不迟。我特意在代码里把存储层封装成独立的MemoryStore类，换引擎时只需要替换内部实现，其他模块不用动。

2.3 上下文注入策略：什么该塞，什么不该塞

记忆召回之后，还有一个非常关键的问题：怎么把这些记忆塞给Claude？塞多少？塞什么？这直接决定了效果是“锦上添花”还是“灾难现场”。

我最初的做法是贪心的：把所有命中的记忆全部拼进system prompt，认为信息越多越聪明。结果很快就发现问题。一是token消耗飙升，一次对话带着几千字的记忆开头，成本从几毛钱直接涨到几块钱；二是记忆之间互相矛盾或噪音过多，Claude反而被无关信息干扰，甚至把别人的记忆误以为是当前用户的；三是旧记忆可能“喧宾夺主”，让模型对当前问题的判断偏向过去的内容。

后来我形成了三条注入原则。第一，按相关度截断，最多只取五条强相关记忆，宁可少而精，不要大而全；第二，按角色区分，记忆要标注清楚是“用户说过的”，还是“系统记录的”，避免Claude把记忆内容和当前事实搞混；第三，加入时间衰减权重，同样是关于“部署方案”的记忆，三个月前的和昨天的，相关度相同但优先级不同，时间越近越可能反映当前真实情况。

注入位置也有讲究。我习惯把记忆放在system prompt的最后，紧跟着一个分隔符，然后才是用户当前的问题。这样处理下来，既保证了Claude能看到记忆，又不会让记忆和当前指令混在一起，模型更容易区分“哪些是背景资料，哪些是现在要我做的事”。

3. 从零搭建：核心模块实测记录

3.1 环境准备与基础依赖

我一开始是在一台Linux服务器上搭的，系统环境要求不高，Python 3.9以上就行。依赖方面，我尽量让整个项目轻量化，核心只需要三个：openai风格的客户端库（用于对接Claude的API）、numpy（做向量相似度计算）、sqlite3（Python标准库自带）。嵌入模型那部分，我用的一个通用的云端嵌入服务，也可以换成本地开源嵌入模型，效果差别不算大。

项目的目录结构大概是这样的：

claude-mem/ ├── config.py # 配置参数：API Key、阈值、路径 ├── memory_store.py # 存储和检索层 ├── memory_factory.py # 记忆加工层 ├── memory_ingest.py # 会话采集层 ├── injector.py # 上下文注入组装 ├── main.py # 入口：启动代理、接收对话 └── conversations/ # 原始对话日志目录

我在环境变量里配了CLAUDE_API_KEY，程序启动时自动读取。这里有个小提醒：API Key千万不要写死在代码或提交到版本库里，我之前有一版图省事写在了配置文件里，后来不小心把配置传到了仓库，还好及时发现。现在所有敏感项都走环境变量，配置文件里只存非敏感参数。

3.2 会话采集模块：拿到完整对话流

采集层要做的事情，说白了就是把每次对话的“原材料”完整保存下来。实际开发中，最简单可靠的方式是包装一次API请求，在发出去之前把用户的消息记录下来，在拿到响应之后把助手的回复记录下来。伪代码逻辑是这样的：

# memory_ingest.py import json import os from datetime import datetime CONV_DIR = "conversations" def log_message(role: str, content: str): os.makedirs(CONV_DIR, exist_ok=True) filename = datetime.now().strftime("%Y%m%d") + ".jsonl" with open(os.path.join(CONV_DIR, filename), "a", encoding="utf-8") as f: f.write(json.dumps({ "role": role, "content": content, "ts": datetime.now().isoformat(), }) + "\n") def wrap_chat(messages): log_message("user", messages[-1]["content"]) response = call_claude_api(messages) log_message("assistant", response.content) return response

可能有人会问，为什么要记录成JSONL而不是JSON数组？因为JSONL是逐行追加的，每次写入不需要读整个文件，日志大了也不会撑爆内存，而且可以用tail命令随时查看最新对话，排查问题非常方便。我实际的日志文件是按天拆分的，比如20250321.jsonl，后续做数据清理的时候直接删掉对应日期的文件就行。

这个模块虽然是整个系统里最容易写的，但也是我改得最多次的。因为后续的记忆加工模块需要读取“完整的对话片段”，如果只记录消息而不记录对话的边界，加工时就很难判断哪些消息属于同一轮交互。我后来在消息里额外加了一个session_id字段，同一轮对话的所有消息共享同一个ID，加工时按ID分组。

3.3 记忆加工模块：把对话压缩成结构化记忆

这一层是整个系统的含金量所在。原始对话是不可能直接存入记忆库的——一来体积太大，二来噪音太多，三来没有语义索引入口。加工模块做的事情，就是让大模型当“写手”，把一段对话压缩成几条精炼的记忆。

我的做法是：攒够一组连续的对话消息之后，把它们拼成一个完整文本，然后调用Claude，让它按固定的JSON格式输出。提示词里我明确要求输出四类信息：

{ "facts": ["用户所在的城市是上海", "用户目前负责的项目代号为项目X"], "preferences": ["用户喜欢简洁的技术方案", "用户偏好Python而不是Java"], "progress": ["项目X目前处于架构设计阶段", "部署方案待定，下周二评审"], "todos": ["下周提交项目X的预算审批表"] }

加工时的提示词我写得很细，核心是“只保留可以长期复用的事实，丢弃一次性无关信息”和“不要主观评论，只做客观提炼”。这一步如果不加约束，模型经常会自由发挥，把“用户今天心情不错”这种垃圾内容也写进来，事后清理非常头疼。

我还设置了一个触发条件：不是每轮对话都立刻加工，而是等对话暂停一段时间之后才会触发。比如检测到距离上一条消息已经超过15分钟，或者用户主动关闭了对话，这时认为“这轮会话结束了”，才执行加工。这样做的目的是避免把一段完整的对话拆成两半来处理，导致记忆碎片化。

实际测试下来，一段30轮的闲聊式对话，加工之后大概产出5到8条有效记忆，压缩率能达到95%以上。这意味着用户重新开启一个会话时，系统只需要携带这5条记忆，就能复现大部分上下文，token开销低得多。

3.4 向量化与检索模块：让记忆可以被“想起来”

加工完成的结构化记忆，会作为一条记录存入SQLite。但光存文本还不够，还需要为每条记忆生成一个向量，也就是用一个稠密向量来表示这段文本的语义。这样，当用户提出新问题时，系统可以计算用户问题的向量和每条记忆向量之间的余弦相似度，找出最接近的那几条。

向量化我借用了通用嵌入服务的接口，代码大致长这样：

# memory_store.py import sqlite3 import numpy as np class MemoryStore: def __init__(self, db_path="memories.db"): self.conn = sqlite3.connect(db_path) self._init_table() def _init_table(self): self.conn.execute(""" CREATE TABLE IF NOT EXISTS memories ( id INTEGER PRIMARY KEY AUTOINCREMENT, session_id TEXT, memory_text TEXT, category TEXT, embedding BLOB, created_at REAL, last_hit_at REAL ) """) self.conn.commit() def add_memory(self, memory_text, category, embedding, session_id): self.conn.execute( "INSERT INTO memories (session_id, memory_text, category, embedding, created_at, last_hit_at) VALUES (?, ?, ?, ?, ?, ?)", (session_id, memory_text, category, sqlite3.Binary(embedding.astype(np.float32).tobytes()), time.time(), time.time()), ) self.conn.commit()

检索的时候，把用户问题也向量化，然后读出所有记忆的向量，用numpy批量计算余弦相似度，排序后取Top-K。我这边记忆条目还不到五位数，全表扫描完全没压力。代码也很简单：

def recall(self, query_embedding, top_k=5): rows = self.conn.execute("SELECT id, memory_text, category, embedding FROM memories").fetchall() results = [] for rid, text, cat, blob in rows: emb = np.frombuffer(blob, dtype=np.float32) sim = float(query_embedding.dot(emb) / (np.linalg.norm(query_embedding) * np.linalg.norm(emb) + 1e-8)) results.append((sim, rid, text, cat)) results.sort(reverse=True) return results[:top_k]

检索模块里我加了一个很实用的细节：每条记忆记录了一个last_hit_at时间戳，每次被命中的时候就刷新一次。这样一来，我能在排序的时候施加一个“近期活跃加分”，比如用score = cosine_sim + 0.1 / (days_since_last_hit + 1)。效果上，频繁被回访的记忆会更容易再次被召回，长期没提起的记忆会自动沉底，这模拟了人脑的“用进废退”。

3.5 注入模块：如何把记忆自然地塞给Claude

召回出来的记忆不会直接拼进对话，而是经过一个组装模块，生成一段固定格式的“记忆摘要”，插到system prompt末尾。这个组装的格式我反复调过好几版，最终固定成下面这种结构：

以下是一些关于用户的历史记忆，来自之前的对话记录： - [事实] 用户所在的城市是上海 - [偏好] 用户喜欢简洁的技术方案 - [进度] 项目X目前处于架构设计阶段 这些记忆只作为背景参考，如果记忆与当前对话内容冲突，以当前对话内容为准。

最后这句话特别重要。加上之后，Claude在遇到记忆和当前指令冲突时，会更倾向于信任当前对话，而不是被旧记忆带跑偏。我测试过一个场景：用户之前说过“周末不上线”，但这次明确说“紧急情况周末也可以上线”，加了这句提示之后，Claude正确理解了新指令的优先级。不加这句提示的时候，它甚至会反问“您之前不是说周末不上线吗”。

注入的位置我也测试过。放在system prompt最开头，模型容易把记忆当成指令主体；放在最后、紧跟用户消息，模型可能来不及建立完整的“记忆背景”。最稳妥的是放在system prompt末尾，用分隔符区分开，模型会把记忆读入但清楚它们的辅助定位。组装好之后，整个请求的结构就是：

System: [基础人设] + [记忆摘要] User: [当前问题]

这个组装逻辑在injector.py里单独封装，后续想调整prompt模板，只需要改一个函数。

4. 实测效果与参数调优

4.1 用三个真实场景验证系统能力

搭完全套系统之后，我做了三轮测试，分别验证记忆系统在不同场景下的表现。

第一个场景是跨会话连续任务。我让Claude在第一天帮我整理了一个开源项目的技术选型，列了备选方案、优缺点和推荐结论。第二天新开对话，直接问“昨天那个技术选型最后定的哪个，理由是什么”，系统成功召回了一条关于“技术选型”的记忆，Claude准确回答了方案名称和理由，还在回答末尾补了一句“需要我重新整理对比表吗”，这是记忆里提到的待办事项。

第二个场景是偏好积累。连续几天对话里，我多次提到“代码尽量用标准库，少引入外部依赖”“错误提示要中文”“我不喜欢过度设计”。到第五天，我让Claude帮我看一段代码并提出修改意见，它给出的建议里主动避开了引入第三方包，并且用中文写了注释建议。这说明偏好记忆被有效注入了。

第三个场景是抗干扰。我在测试集里故意混入了一条非常相似但错误的记忆（模拟记忆污染），让Claude回答关于项目进度的问题。由于我在注入模板里加了“冲突时以当前对话为准”的约束，并且召回了多条互相印证的真实记忆，Claude最终没有采纳错误记忆，回答正确。这轮测试让我确认了一个观点：注入模板的边界约束比单纯提高召回精度更重要。

4.2 三个关键参数的调节经验

这个系统里最值得调参数的三个点，我分别记录一下实测数据。

相似度阈值：我默认设置的是0.70。低于这个分数的记忆相关性太弱，塞进去纯属噪音；高于0.86的又太少，几乎只有完全复述的问题才能命中。实际使用中，0.72到0.78之间是一个比较舒服的范围。如果调太高，比如0.8以上，很多实质相关但表述不同的记忆就被挡在门外；调太低，比如0.6以下，召回结果里会混进大量无关信息。

召回条数Top-K：我测试了3、5、8、10四档。3条太少，经常漏掉关键背景；8条以上系统prompt膨胀，而且会开始出现低相关记忆；5条在成本和效果之间最平衡。如果你的应用场景本身上下文窗口很富裕，可以试到6到7条，但我不建议超过8条。

记忆加工触发延迟：这个参数是给采集层用的，表示“距离上一条消息多久才认为对话结束”。我试过5分钟、15分钟、30分钟三档。5分钟太敏感，用户只是去喝了杯水回来继续聊，对话就被切开，产生重复记忆；30分钟又太长，用户可能真的一天内不再回来，这段对话就一直没加工，下一次会话召不回内容。最终用15分钟比较合适，既能识别真正的“会话结束”，又不至于把连续的长对话切碎。

4.3 记忆质量评估：怎么看系统“记住”得好不好

跑完测试，你会发现一个维度的重要性远超其他指标：记忆的信噪比。系统不是记住得越多越好，而是记住得“刚刚好”才算好。我给自己定了一套简单评估规则：

• 有效记忆占比：所有已存储记忆里，三个月内至少被命中过一次的比例。这个比例高于70%，说明记忆库的召回效率不错；低于50%，就要检查是不是存了太多一次性内容。
• 无关记忆占比：在一次对话中，召回结果里和当前话题完全无关的条数。正常情况应该趋近于0，如果经常出现1条以上的无关记忆，说明相似度阈值过低。
• 回答重复率：同一个问题，开记忆和不开记忆，答案的信息量对比。如果开记忆之后，Claude仍然反复追问“您之前提到过……能不能再说一下”，说明记忆注入失败，问题多半出在加工环节，记忆内容本身不够结构化。

用这三条标准，我连续观察了一周的使用数据，逐渐把记忆库从最初的190多条规模压缩到120多条，删掉的都是“一次性信息概览”之类的低质量记忆，整体回答准确度和相关负责人体验都明显上了一个台阶。

5. 踩过的坑与排查技巧

5.1 记忆污染问题：旧记忆误导新决策

这是我在使用过程中踩过最深的坑，也是记忆系统最容易被忽视的安全问题。记忆一旦写入，就会长期影响后续所有对话。某次测试时，用户在半年前说过“我们团队只有三个人”，我把它存成了事实。半年后团队已经扩张到二十人，但记忆库里那条老事实还能被召回，导致Claude在讨论协作分工时提出了一个完全不符合现有规模的方案。

我后来引入了两层防护。第一层是时间衰减机制，超过30天没有命中的记忆自动降权，超过90天没有命中的记忆默认不召回，除非用户主动搜索。第二层是冲突检测，当新对话中出现了与旧记忆明显矛盾的信息时，系统自动把旧记忆标记为“待确认”，并在下一次召回时降低它的权重。

更根本的解决方案是让用户有主动管理记忆的能力。我在项目里加了一个命令行工具，支持查看全部记忆列表、删除单条记忆、清空某个分类。这个工具虽然简单，但价值巨大，相当于给系统装了一个“遗忘”的开关。很多AI应用避而不谈“让AI忘掉什么”，但实际用下来，不能主动遗忘的记忆系统就是一个不断膨胀的噪音库。

5.2 重复记忆与冗余摘要：记忆库的隐形杀手

另一个高产问题是重复记忆。由于对话切分或加工时机没把握好，同样的信息可能被存好几次，比如“用户所在的城市是上海”这句话，可能在三段不同的对话里被抽取了四次。重复记忆不仅浪费存储，更严重的是它在召回时会霸占多个Top-K位置，挤压其他真正有用的记忆。

我在写入前加了一道去重检查：新记忆生成后，先与库里同样分类的现有记忆做相似度计算，如果相似度超过0.92，就丢弃这条新记忆，只更新旧记忆的时间戳。这个去重检查虽然会多跑一次检索，但成本很低，换来的效果非常明显：运行一个月后，记忆库的冗余率从最初的22%降到了4%左右。

此外，加工提示词里我专门加了一句“如果某条信息已经在现有记忆中，不要重复输出”，这道保险直接作用于源头，效果比写入后再去重更好。

5.3 隐私与安全边界：记忆不是越多越好的东西

随着记忆积累得越来越厚，一个绕不开的问题浮上水面：这些记忆是高度隐私的用户数据。对话里可能包含账号信息、公司业务细节、家庭成员、健康状况等敏感内容。如果记忆库文件泄露，就相当于把最私密的聊天记录全文公开。

我的做法是从“采集”和“存储”两头同时收紧。采集端增加了一个敏感信息拦截列表，匹配到手机号、银行卡、身份证格式的字符串时，先把内容用占位符替换再进入加工流程。存储端则对SQLite文件做了加密处理，用对称加密包裹数据库文件，读取时解密后用内存副本访问，落盘始终是密文。虽然性能上有一点损耗，但这点代价换来的是安全感的极大提升。

我还建议每个使用这套方案的人，都定期检查记忆库里到底存了哪些内容。不要等到出了问题再去补救。记忆系统应该像人一样拥有“被遗忘的权利”，定期清理、主动删除，这不仅是技术问题，更是使用者的责任边界。

5.4 成本控制与性能优化：让记忆系统能长期运行

最后整理一套成本清单，给打算长期运行这套系统的人一个参考。记忆系统的开销主要来自加工环节，因为每次对话结束都要调用一次大模型做摘要抽取。我粗略统计了一下：

最有效的一招是在采集层加一个“价值过滤器”：在对话结束准备加工时，先对这段对话做一个简单判断，如果它没有任何需要长期记忆的信息（比如纯闲聊、纯寒暄），就不调用加工模型。这个判断本身也可以调一个小模型来做，或者用一个短提示词让大模型先输出一个“是否值得记忆”的布尔值，再决定是否深度加工。这一步能省下超过一半的加工成本。

性能方面，如果SQLite里存了太多记忆，检索速度变慢，我会先做两件事：一是检查索引是否失效，二是对memory_text字段加上全文索引。在我目前的规模下，SQLite全表扫描的延迟控制在50毫秒以内，完全不影响对话体验。真到了百万级记忆的规模，再迁移到专业向量数据库也不迟。

6. 最后再分享一点实践心得

写到这里，整个“claude-mem”方案的骨架已经摊开了：一条从对话采集、记忆加工、向量存储到语义召回的完整链路，以及我在每个环节里踩过坑、调过参、换过方案的真实过程。如果让我总结这套系统里最重要的三件事，我会说：结构化的记忆加工比存储方案更关键，注入模板的边界约束比召回精度更关键，可干预、可遗忘的设计比记忆容量更关键。

实际用的这段时间，我最惊讶的一点是这个外挂记忆系统改变了我和Claude协作的方式。以前我要么把背景信息打成一大段文字反复粘贴，要么忍着它的“失忆”多花好几轮对话补充上下文。现在我可以直接说“按我之前定的风格处理”，它真的知道“之前”是什么，那种连续感让我觉得AI助手第一次有了一点“老搭档”的味道。

最后再分享一个小技巧：不要一开始就追求记忆系统的完整自动化。我第一版就是全自动，结果调试起来无比折磨。后来改成半自动——加工自动，但召回结果保留一条“可供用户确认”的侧边栏入口，用户可以手动勾选哪些记忆在下一轮对话中生效。这看起来多了一步操作，但实际极大降低了误召回对对话质量的冲击，也让用户对记忆内容有掌控感。等跑顺了，再逐步放开全自动也不迟。