
你花 10 分钟对齐背景。AI 给了完美方案。下次对话,它又不认识你了。不是它笨,是它没有记忆。
大多数 AI 编程助手的一次对话,本质上是 15 分钟的记忆。
你说需求,它用当前对话的上下文理解,产出结果。对话结束,记忆清零。下次你说"继续昨天的任务",它从零开始猜。
这不是你的问题,不是 AI 模型的问题,是会话架构的默认设计。
我花了几个月搭建了一套跨会话记忆系统,踩了三个坑。这篇文章讲怎么搭建、怎么维护、怎么不翻车。
先说设计。我用了三层文件:
# 三层记忆系统
├── SOUL.md # 人格层:行为准则、价值排序、硬性规则
├── IDENTITY.md # 身份层:项目背景、里程碑、关键文件索引
└── MEMORY.md # 日常层:最近进展、开放问题、待办事项每层有不同的更新频率:
层 | 更新频率 | 内容举例 |
|---|---|---|
人格层 | 月度 / 里程碑 | 值 Stack 调整、新硬性规则 |
身份层 | 周度 / 重大变更 | 项目进展、关键索引更新 |
日常层 | 每次工作后 | 今天做了什么、遗留问题 |
启动协议: 每次新对话,AI 按顺序读取这三层 → 定位上一次的断点 → 直接开始工作,不需要"之前聊到哪了"。
听起来不复杂。真正的问题在维护。
日常层按"每次工作后追加一行"的方式运行了三个月。某天我打开 MEMORY.md,发现它 700 行了。
AI 读取 700 行上下文,前面 500 行和当前任务毫无关系。不仅仅是"浪费时间"——无关信息稀释了有用信息,它的判断质量在下降。
因为恶化的过程是渐进的。今天多一行,明天多一行。你不会在第 50 行感觉不对,只会在第 500 行时发现"最近 AI 的反应好像变慢了"。
# ❌ 只追加,不清理
def write_memory(entry):
with open("MEMORY.md", "a") as f:
f.write(entry + "\n")
# ✅ 基于时间窗口的清理策略
import os
from datetime import datetime, timedelta
def maintain_memory():
today = datetime.now()
daily_dir = "memory/"
# 1. 30 天内的日志保留原文
for fname in os.listdir(daily_dir):
if fname.endswith(".md"):
file_date = datetime.strptime(fname[:10], "%Y-%m-%d")
if file_date < today - timedelta(days=30):
# 2. 超过 30 天的,蒸馏核心信息到 MEMORY.md
distill_to_memory(fname)
# 3. 删除原文
os.remove(os.path.join(daily_dir, fname))两个关键动作:
蒸馏的本质:把时间线变成知识树。 原文是按时间排列的,蒸馏后是按主题排列的。AI 只需要知道"我们在这个领域做过什么、选了什么方向",不需要知道那次讨论是几点几分发生的。
某次我在 IDENTITY.md 里更新了"当前工作目录"的路径。但 SOUL.md 里的一个硬性规则引用了旧路径,MEMORY.md 里的待办事项也是基于旧路径写的。
三份文件的同一信息变成了三个版本。AI 读了它们后问我:"你确定这三个路径是对的?它们不一致。"——它把不一致当作bug来处理,而不是容忍模糊性。
因为每份文件单独看都是"正确"的。只是它们之间失去了同步。单独验证每一份都过,合在一起就矛盾。
# 在每份文件中加入互引用锚点
# SOUL.md 末尾
> 关联文件:IDENTITY.md(项目背景)、MEMORY.md(最新进展)
> 最后对齐日期:2026-05-11
# IDENTITY.md 末尾
> 关联文件:SOUL.md(行为准则 2026-05-01版)、MEMORY.md(日常日志)
> 最后对齐日期:2026-05-11同时在记忆中维护一个"对齐检查"逻辑:
# 启动时自动检查三份文件的时间戳
def check_alignment():
soul_time = os.path.getmtime("SOUL.md")
identity_time = os.path.getmtime("IDENTITY.md")
memory_time = os.path.getmtime("MEMORY.md")
max_gap = max(soul_time, identity_time, memory_time) - min(
soul_time, identity_time, memory_time
)
if max_gap > 7 * 24 * 3600: # 7 天没有对齐
warning = "检测到三份记忆文件超过 7 天未对齐,建议执行同步。"
return warning
return None关键原则:对齐不是"写完就不管",是定期检查。 频率不需要高,周次级别就够。但必须有这个检查,否则漂移是必然的。
启动协议规定 AI 要读三层文件。但某次我改了一个文件名,当天的 MEMORY.md 没有被读取。AI 启动后说我上次的工作"未知",然后从零开始重建上下文——花了 15 分钟才发现它的重建和实际状态完全对不上。
问题不是文件不存在,是文件存在但没被纳入读取范围。
# AI 新会话启动协议(不写进记忆,写进系统提示词)
每次新会话必须按以下顺序执行:
1. 读取最新交接文档(含 HANDOVER 的文件)
2. 读取 SOUL.md(人格层)
3. 读取 IDENTITY.md(身份层)
4. 读取 MEMORY.md(日常层,含最近日期文件)
5. 对比 MEMORY.md 与实际项目状态,确认一致再动手为什么这需要写在系统提示词里而不是记忆里?因为记忆文件本身可能漏读——你用一个依赖于"正确读取"机制的东西来保护"正确读取",是循环依赖。
启动协议必须在文件系统之外有一个独立的触发点。
把三个坑的经验总结成一张维护清单:
维护项 | 频率 | 检查方法 |
|---|---|---|
文件大小检查 | 每周 | MEMORY.md 超过 300 行 → 蒸馏 |
闲置条目清理 | 每月 | 待办事项标记超过 30 天未处理 → 删除或升级 |
跨文件对齐 | 每月 | 检查三份文件的"最后对齐日期"是否在一个月内 |
启动协议验证 | 每次启动 | 确认读取了三份文件,输出一致性报告 |
主题蒸馏 | 每季度 | 将日常日志中重复出现的主题提取到长期 MEMORY.md |
我给自己定了三个判断标准:
def memory_system_is_healthy(soul, identity, memory):
# 1. 启动耗时 < 5 秒
# → AI 读完就懂了,不用和你对齐
# 2. AI 首次回答命中上次断点 > 80%
# → 不需要"上次聊到哪了"这种对话
# 3. 跨文件矛盾查询 = 0
# → 三份文件说的是同一件事
pass满足这三个条件,就算一个合格的记忆系统了。不需要完美,够用就好。
给 AI 加记忆,本质上是在做一件反直觉的事:为一个设计上无状态的系统强行注入连续性。
它不会自己"记得"。每一次"记得",都是你设计的文件、规则、读取协议在起作用。
但这个门槛值得跨。一个没有记忆的 AI 是你每次都要重新教一遍的助理。一个有记忆的 AI 是你随时可以接着上次继续的协作者。
差距不是能力,是连续性。
本文所有示例均已脱敏处理。你的 AI 协作者有记忆吗?欢迎分享你的记忆系统设计。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。