给 AI 做一套“像人一样”的记忆系统：Trunk → Task → Skill → Recipe

很多人做 AI 记忆，一上来就想：

能不能把所有聊天记录都存起来？下次直接让 AI 查。

听起来很合理，对吧？

但真做起来你会发现，问题一堆：

• 记了太多废话，召回时全是噪音
• 同一件事重复存了八遍
• 用户偏好和临时任务混在一起
• 旧经验和新经验打架
• 上下文塞爆了，模型开始胡说

AI 记忆要像人，不是像硬盘。

人类不会把每一句对话原封不动背下来。咱们会记住：

• 这个人喜欢什么
• 他上次做过什么事
• 哪个方法有效
• 哪个坑踩过
• 下次遇到类似问题该怎么处理

所以，好的 AI 记忆系统，核心不是“存更多”，而是“记得更聪明”。

我更推荐一套四层结构：

Trunk → Task → Skill → Recipe

它能把碎片信息变成任务，把任务变成经验，把经验组合成方案。

用在人类身上，大概就是：

• Trunk：你脑子里零散的印象
• Task：你判断出对方要干什么
• Skill：你做完之后留下的方法
• Recipe：你反复验证后形成的一套打法

下面咱们拆开讲。你照着这个结构做，AI 助手会明显更“懂你”。

一句话理解这套记忆架构

这套结构解决的是一个问题：

AI 怎么从零碎对话里，沉淀出长期可复用的经验？

别让 AI 每次都从头想。

你每天让它写日报、整理会议纪要、生成小红书标题、分析客户反馈。如果它永远只记得当前对话，那它就是个临时工。

真正好用的 AI 助手，应该像老同事：

• 知道你喜欢短句
• 知道你讨厌空话
• 知道你们公司周报格式
• 知道上次那个方案哪里被老板喷了
• 下次再写时会主动避开坑

这就需要把记忆分层。

Trunk：所有原始碎片都先扔进这里

Trunk 是原始信息层。

它像一个杂物箱，先别急着判断价值，先接住信息。

常见来源包括：

• 用户聊天记录
• 用户上传的文档
• 操作日志
• 会议纪要
• 网页内容
• 邮件内容
• 用户手动写下的偏好
• AI 执行任务时产生的中间过程

比如用户说：

“以后帮我写文章，别写太官方。我喜欢像朋友聊天那种，短句多一点，最好带点吐槽。”

这句话原样进入 Trunk。

再比如用户说：

“上次那个标题太平了，老板说没点击欲望。”

也进入 Trunk。

这里不要过度加工。

Trunk 的职责很简单：

• 保存原始上下文
• 保留细节
• 给后面抽取任务和经验提供材料

Trunk 不要犯的错

很多人会把 Trunk 当成长期记忆库，直接用于召回。

这很危险。

因为原始信息里有大量噪音：

• 临时情绪
• 过期偏好
• 反复试错
• 没有确认的猜测
• AI 自己生成的废话

如果你把这些东西一股脑塞回上下文，AI 很容易变成“考古学家”。翻半天旧账，还抓不到重点。

Trunk 可以大，但召回要克制。

Task：从碎片里识别用户真正想做什么

Task 是任务层。

它负责从 Trunk 里抽取用户意图，并整理成一个可执行任务。

用户说话经常很散。

比如：

“我这个月想发点 AI 教程，但别太硬核。最好让小白也能看懂。之前发的那篇收藏不错，就是标题一般。”

这段话里混了好几类信息：

• 用户想做 AI 教程内容
• 目标读者是小白
• 风格不要太硬核
• 之前某篇文章收藏不错
• 标题需要优化

Task 层要做的事，就是把这些碎片整理成任务：

{
  "task_name": "创作面向小白的 AI 教程文章",
  "user_intent": "生成更容易理解、更有收藏价值的 AI 教程内容",
  "constraints": [
    "不要太硬核",
    "适合小白",
    "标题要更有点击欲望"
  ],
  "success_criteria": [
    "读者能照着做",
    "文章结构清晰",
    "标题比之前更吸引人"
  ],
  "source": "用户对内容方向的描述"
}

这一步很关键。

因为 AI 真正要执行的不是“记住这句话”，而是理解：

用户现在要完成什么任务？

Task 应该包含什么字段？

建议至少记录这些：

{
  "task_id": "task_202601_ai_tutorial_001",
  "task_name": "任务名称",
  "intent": "用户意图",
  "inputs": ["输入材料"],
  "constraints": ["限制条件"],
  "preferences": ["用户偏好"],
  "output_format": "期望输出格式",
  "status": "pending / running / completed / failed",
  "created_at": "创建时间",
  "updated_at": "更新时间"
}

如果你的 AI 助手能稳定抽取 Task，后面就好办了。

因为经验沉淀不是从聊天记录里直接来的，而是从任务里来的。

Skill：任务完成后，沉淀可复用经验

Skill 是经验层。

这层最有价值。

Task 是“这次要做什么”。

Skill 是“下次遇到类似任务，应该怎么做”。

举个例子。

用户让 AI 写一篇小红书文案，改了三轮后终于满意了。

这时不要只保存最终文案。

更应该沉淀出 Skill：

{
  "skill_name": "小红书 AI 工具教程文案写法",
  "applicable_scenarios": [
    "AI工具教程",
    "小红书种草内容",
    "面向新手用户的操作指南"
  ],
  "method": [
    "标题用痛点或结果开头",
    "开头直接说适合谁",
    "步骤控制在 3 到 5 个",
    "每一步配一个具体使用场景",
    "结尾给收藏理由"
  ],
  "user_preferences": [
    "短句",
    "口语化",
    "少用专业术语",
    "可以轻微吐槽"
  ],
  "avoid": [
    "不要写成官方说明书",
    "不要堆功能名",
    "不要用空泛口号"
  ],
  "evidence": "用户第三轮修改后确认满意",
  "version": "1.0"
}

这就不是普通记忆了。

这是可复用经验。

下次用户再说“帮我写一个 AI 工具教程”，系统不用从零开始猜。直接调用这个 Skill，效果会稳很多。

Skill 要处理去重和升级

Skill 不能无限堆。

不然你会得到 20 条“用户喜欢口语化”的记录。看着很努力，其实很乱。

推荐给 Skill 做三件事：

1. 去重

如果新经验和旧经验高度相似，不要新建一条。

应该合并。

比如旧 Skill 写着：

用户喜欢短句、口语化。

新任务里又发现：

用户希望像朋友聊天，不要太官方。

这两条可以合并成：

用户偏好朋友聊天式表达，短句、自然、有轻微情绪，不喜欢官方腔。

2. 置信度

不是用户随口一句话，就要当圣旨。

可以给 Skill 加一个置信度：

{
  "confidence": 0.82,
  "confirmed_by_user": true,
  "usage_count": 6,
  "last_success_at": "2026-01-15"
}

用户多次确认有效，置信度提高。

某次使用翻车，置信度降低。

3. 版本迭代

经验会过期。

去年有效的内容模板，今年可能没人点。

所以 Skill 要允许升级：

{
  "skill_name": "AI教程文章写作风格",
  "version": "1.3",
  "changes": [
    "减少开头背景铺垫",
    "增加避坑清单",
    "每个步骤增加可执行示例"
  ]
}

别把记忆做成博物馆。

它应该是训练场。

Recipe：把多个 Skill 组合成一套成熟方案

Recipe 是方案层。

它由一个或多个 Skill 组成，用来解决更完整的问题。

如果 Skill 是一个招式，Recipe 就是一套打法。

比如用户经常做“AI 教程文章”。这里面会用到多个 Skill：

• 标题设计 Skill
• 小白友好解释 Skill
• Markdown 结构 Skill
• 示例生成 Skill
• 避坑清单 Skill
• 口语化表达 Skill
• SEO 标签 Skill

这些 Skill 可以组合成一个 Recipe：

{
  "recipe_name": "高质量 AI 教程文章生产流程",
  "goal": "把原始素材整理成可发布的 AI 教程文章",
  "skills": [
    "AI教程标题设计",
    "小白友好解释",
    "Markdown结构编排",
    "操作步骤拆解",
    "避坑清单生成",
    "口语化表达优化"
  ],
  "workflow": [
    "识别素材主题和目标读者",
    "提炼核心观点",
    "设计教程结构",
    "补充操作步骤和示例",
    "加入避坑提醒",
    "统一语言风格",
    "生成标题、摘要和标签"
  ],
  "quality_checklist": [
    "读者是否能照做",
    "是否有具体场景",
    "是否避免空话",
    "是否有示例",
    "是否有避坑清单"
  ],
  "version": "2.0"
}

这层最接近“人类专家”。

一个新手会说：

我会写标题。

一个熟手会说：

我知道一篇 AI 教程从选题到发布该怎么走。

Recipe 就是熟手的工作流。

为什么召回顺序要反过来：Recipe → Skill → Task → Trunk

很多系统召回记忆时喜欢从原始记录开始找。

我不建议这么做。

更稳的顺序是：

Recipe → Skill → Task → Trunk

也就是从高层经验往底层材料查。

原因很简单：AI 上下文有限。

你不能把所有东西都塞进去。塞得越多，模型越容易抓错重点。

Recipe 优先：先拿成熟方案

如果用户说：

“帮我把这段素材写成 AI 教程文章。”

系统应该先查有没有对应 Recipe。

比如查到：

高质量 AI 教程文章生产流程

那就直接拿来用。

这比去翻 200 条聊天记录靠谱多了。

Skill 补充：再拿关键经验

Recipe 给流程，Skill 给具体做法。

比如：

• 用户喜欢短句
• 要有避坑清单
• 标题不要太虚
• 示例要接地气

这些 Skill 会让结果更贴合用户。

Task 对齐：确认当前任务约束

同一个 Recipe，不同任务也有差异。

今天用户可能要写公众号。

明天用户可能要写小红书。

Task 层负责确认本次任务的要求：

• 输出格式
• 字数范围
• 目标平台
• 风格要求
• 输入材料

Trunk 兜底：需要细节时再翻原始材料

Trunk 不应该默认全召回。

只有需要查证细节时再用。

比如：

• 用户提到“上次那篇文章”
• 需要引用原始会议内容
• 需要确认某个历史版本
• Skill 之间发生冲突，需要看证据来源

这时再去 Trunk 找原话。

这样既省上下文，也减少记忆打架。

一套可落地的记忆写入流程

你可以把 AI 每次对话后的记忆处理，拆成 5 个动作。

1. 收集 Trunk

保存原始信息。

包括用户输入、关键输出、文件摘要、操作结果。

建议给每条 Trunk 加元数据：

{
  "trunk_id": "trunk_001",
  "content": "用户希望文章更口语化，像朋友聊天，不要太官方。",
  "source": "chat",
  "created_at": "2026-01-15T10:00:00Z",
  "related_task_id": "task_001"
}

2. 抽取 Task

从 Trunk 里判断有没有明确任务。

如果有，就生成 Task。

{
  "task_id": "task_001",
  "task_name": "改写 AI 教程文章",
  "intent": "把原始素材整理成适合发布的 Markdown 教程",
  "constraints": [
    "口语化",
    "短句",
    "有示例",
    "有避坑清单",
    "输出 JSON"
  ],
  "status": "completed"
}

3. 任务结束后提炼 Skill

等任务完成，再问一个问题：

这次有什么经验下次还能用？

比如：

{
  "skill_name": "AI教程文章结构优化",
  "method": [
    "开头直接指出常见误区",
    "用具体场景解释抽象概念",
    "每个核心概念配一个 JSON 示例",
    "结尾给避坑清单"
  ],
  "avoid": [
    "不要堆概念",
    "不要用官方腔",
    "不要写没有操作价值的背景铺垫"
  ]
}

4. 合并或升级 Skill

检查已有 Skill。

如果相似，就合并。

如果冲突，就记录版本和证据。

比如：

{
  "conflict": {
    "old": "用户喜欢详细解释",
    "new": "用户要求短句，不要长篇铺垫"
  },
  "resolution": "保留详细解释，但拆成短段落和要点列表",
  "updated_skill": "复杂概念短句化解释"
}

这个处理很重要。

不然 AI 会一边写“详细”，一边写“简短”，然后交出一篇又长又空的东西。看完只想关电脑。

5. 如果多个 Skill 高频组合，就生成 Recipe

当你发现某几个 Skill 经常一起出现，就可以升级成 Recipe。

比如这些 Skill 经常同时被调用：

• 教程结构
• 标题优化
• 口语化表达
• 避坑清单
• Markdown 输出

那就生成一个 Recipe：

{
  "recipe_name": "AI教程文章发布模板",
  "trigger": [
    "用户要求写 AI 教程",
    "用户提供原始素材",
    "用户要求 Markdown 输出"
  ],
  "skills": [
    "教程结构搭建",
    "标题优化",
    "短句口语化",
    "案例补全",
    "避坑清单"
  ]
}

记忆召回的实战提示词模板

下面这段可以直接放进你的 Agent 系统里。

你需要为当前任务召回长期记忆。

召回顺序如下：
1. 优先查找可直接解决当前任务的 Recipe。
2. 如果 Recipe 不够具体，再查找相关 Skill。
3. 读取当前 Task 的约束、输入、输出格式和成功标准。
4. 只有在缺少证据、需要原始细节或存在冲突时，才查询 Trunk。

召回后请进行压缩，只保留对当前任务有帮助的信息。
不要把无关历史记录塞进上下文。
如果记忆之间冲突，请优先使用：
- 用户最近明确确认的信息
- 成功完成任务后沉淀的 Skill
- 高置信度 Recipe

输出格式：
- 命中的 Recipe
- 命中的 Skill
- 当前 Task 约束
- 必要 Trunk 证据
- 冲突处理说明

注意：模板里可以有编号，文章行文别硬靠“首先其次最后”就行。

记忆冲突怎么处理？别让 AI 精神分裂

AI 记忆最容易翻车的地方，就是冲突。

比如旧记忆写着：

用户喜欢专业、严肃、信息密度高。

新记忆写着：

用户喜欢口语化，像朋友聊天。

那到底听谁的？

建议用这套优先级：

用户明确指令 > 推测偏好

用户直接说“这次要轻松一点”，那就听这次的。

别拿老偏好压当前任务。

最近确认 > 很久以前

用户偏好会变。

三个月前喜欢严肃，不代表今天还喜欢。

成功经验 > 普通聊天

用户明确说“这版可以”，这种反馈价值很高。

比一句随口吐槽更值得保存。

Recipe > Skill > Task > Trunk

高层经验更稳定。

底层碎片只做证据，不要喧宾夺主。

一个完整例子：从一句话到长期记忆

用户说：

“以后你帮我写 AI 教程，别上来就讲大背景，太烦了。直接告诉我怎么做。最好有代码、有避坑、有例子。”

Trunk 记录

{
  "type": "trunk",
  "content": "用户要求 AI 教程不要大背景，直接讲操作，要有代码、避坑、例子。"
}

Task 抽取

{
  "type": "task",
  "task_name": "优化 AI 教程写作方式",
  "intent": "让 AI 教程更直接、更可执行",
  "constraints": [
    "不要大背景铺垫",
    "直接讲怎么做",
    "包含代码",
    "包含避坑",
    "包含例子"
  ]
}

Skill 沉淀

{
  "type": "skill",
  "skill_name": "直接可执行型 AI 教程写法",
  "method": [
    "开头点出问题和结果",
    "正文用步骤和示例推进",
    "必要时给代码片段",
    "每个关键步骤补充避坑提醒",
    "减少宏大背景介绍"
  ],
  "avoid": [
    "长篇介绍行业背景",
    "空泛讲价值",
    "只讲概念不给操作"
  ]
}

Recipe 升级

如果这个 Skill 多次用在文章生产里，就能升级成 Recipe：

{
  "type": "recipe",
  "recipe_name": "直接可执行型 AI 教程生产流程",
  "workflow": [
    "提炼读者当前痛点",
    "给出最终能得到的结果",
    "拆成可操作步骤",
    "补充代码或配置示例",
    "加入避坑清单",
    "给出可复用模板"
  ]
}

这就是从碎片到方案的全过程。

很像人类学习。

一次经历是素材。

多次完成任务后，形成经验。

经验反复验证，就变成方法论。

避坑清单：做 AI 记忆最容易踩的坑

坑 1：什么都记

别这样。

AI 不是仓库管理员。

原始信息可以进 Trunk，但长期召回必须筛选。

坑 2：把用户每句话都当长期偏好

用户说“今天想轻松点”，可能只是今天。

不要永久写成“用户永远喜欢轻松风格”。

坑 3：没有任务结束后的复盘

真正有价值的 Skill，往往来自任务完成后。

用户满意、用户修改、执行结果，这些才是经验来源。

坑 4：Recipe 太早生成

一次成功不要急着封神。

Recipe 应该来自多次验证。

不然你只是把一次偶然包装成了方法论。

坑 5：召回太多

上下文不是垃圾桶。

召回越多，模型越容易跑偏。

更好的做法是：少召回，高相关，先高层后底层。

坑 6：不处理冲突

旧记忆和新记忆一定会打架。

不设计冲突处理，AI 迟早写出一份“既要严肃又要活泼、既要详细又要简短”的怪东西。

推荐的数据结构简版

如果你想快速落地，可以先用这四张表。

trunks

CREATE TABLE trunks (
  id TEXT PRIMARY KEY,
  content TEXT,
  source TEXT,
  related_task_id TEXT,
  created_at DATETIME
);

tasks

CREATE TABLE tasks (
  id TEXT PRIMARY KEY,
  name TEXT,
  intent TEXT,
  constraints_json TEXT,
  status TEXT,
  created_at DATETIME,
  updated_at DATETIME
);

skills

CREATE TABLE skills (
  id TEXT PRIMARY KEY,
  name TEXT,
  scenarios_json TEXT,
  method_json TEXT,
  avoid_json TEXT,
  confidence REAL,
  version TEXT,
  updated_at DATETIME
);

recipes

CREATE TABLE recipes (
  id TEXT PRIMARY KEY,
  name TEXT,
  goal TEXT,
  skills_json TEXT,
  workflow_json TEXT,
  checklist_json TEXT,
  confidence REAL,
  version TEXT,
  updated_at DATETIME
);

别一开始就搞得特别复杂。

先跑起来。

等你发现 Skill 多了、冲突多了、Recipe 复用频繁，再加权限、衰减、评分、Embedding 检索这些能力。

这套方法适合哪些场景？

非常适合这些 AI 产品或自动化系统：

• 私人 AI 助手
• 写作 Agent
• 客服 Agent
• 企业知识库
• 会议纪要助手
• 内容生产工作流
• 编程助手
• 销售跟进助手
• 项目管理 Agent

尤其适合高频重复任务。

比如你每天都让 AI 写内容、改代码、整理客户信息。这套记忆结构能让它越用越顺手。

不是每次都像新来的实习生。

可以直接照抄的落地规则

给你一版短规则，适合放到系统设计文档里：

记忆分为四层：Trunk、Task、Skill、Recipe。

Trunk 保存原始信息，不直接作为主要召回依据。
Task 从 Trunk 中抽取，表示用户当前意图和任务约束。
Skill 从已完成 Task 中沉淀，表示可复用经验。
Recipe 由多个高频 Skill 组合而成，表示成熟解决方案。

写入顺序：Trunk → Task → Skill → Recipe。
召回顺序：Recipe → Skill → Task → Trunk。

召回时优先使用高层、稳定、已验证的记忆。
只有在需要原始证据或处理冲突时，才查询 Trunk。

记忆需要支持去重、合并、置信度、版本升级和冲突处理。

结尾：AI 记忆要像人，不要像硬盘

好用的 AI 记忆，关键不是“记得多”。

而是能做到：

• 从碎片里看出任务
• 从任务里沉淀经验
• 从经验里组合方案
• 召回时抓重点
• 冲突时有判断

Trunk → Task → Skill → Recipe 是写入路径。

Recipe → Skill → Task → Trunk 是召回路径。

一正一反，刚好对应人类学习和使用经验的方式。

我们经历很多事，但真正派上用场的，往往不是原始细节。

而是那些被反复验证过的方法。

AI 也该这样。