---
layout: post.njk
source: https://yage.ai/share/four-lanes-of-ai-memory-20260812.html
speaker: yage.ai
title: 你纠正了 AI 十几次，它为什么还是记不住
date: '2026-08-12'
summary: 文章探讨了AI在记忆和经验固化方面的局限性，指出AI记不住要求或经验的关键不在于模型智商或措辞，而在于经验的存放位置。作者提出了经验的四层结构（对话上下文、外部记忆、项目版本化文档、模型微调），并建议根据经验的性质选择最合适的落点，强调先外化再执行的策略，以平衡风险和成本。
area: PAI
category: ai-workflow
tags:
  - ai-memory
  - workflow-tools
  - knowledge-meta
  - ai-tooling
people: []
companies_orgs: []
products_models: []
media_books: []
draft: true
status: evergreen
---

跟 AI 助手一起干活，很容易碰到这种循环：第一天提醒它分析 EMEA
数据时要排除测试账号；到了第三天，它又把测试账号算进去了，你顺手纠正了一次；到了第五天，同样的问题再次出现；等进了第二周，你发现自己不得不第三次重复同一句话。

遇到这种情况，大家很容易觉得是模型理解能力有限，或者怀疑自己的 prompt
没表达清楚。但多观察几次就会发现，AI
记不住你的要求，往往无关乎模型智商，也无关乎措辞表达，关键在于那句修正从一开始就落在了错误的位置。

## 大家第一反应是两种极端，而且看起来互相矛盾

面对怎么让 AI
记下经验这个问题，大多数人的直觉会落在两个极点上。一头是
prompt，把所有规矩和要求写进输入，让模型按部就班执行。另一头是微调，直接拿数据去修改模型的权重，把特定行为固定下来。

两种思路在日常讨论里经常打架。偏好 prompt
的人觉得现在的模型能力已经足够强，只要对话上下文给到位，没必要花精力微调。主张微调的人则认为，每次重新对话都得把规则重复一遍太吃资源，只有把行为固化进权重，才能一劳永逸。

这种对立有着明显的历史脉络。在 BERT
时代，大家使用模型的标准流程就是微调，每来一个新任务，就安排 GPU
重新训练一遍。到了 2020 年 GPT-3
出现，玩法改变了：用自然语言描述清楚任务，再补充几个示例，模型就能直接出结果。我在之前一篇关于基础模型的文章里聊过，基础模型之所以叫基础，核心就在于无需改动权重就能完成
few-shot 学习。当时我还观察到，像 CLIP
这样的模型很难通过微调来发挥效果，不改权重、专注优化输入反而是更好的选择。

有趣的是，几个月之后，我又写了一篇关于微调的文章，记录了如何通过微调让模型学会我自己的写作语气，而且效果很理想。同一个作者，两篇前后发表的观察，一篇说基础模型不需要微调，另一篇又在强调微调解决掉了
prompt 搞不定的痛点。

这两段经历其实对应着不同场景下的事实。这也引出一条界线：到底什么样的经验放在
prompt
里就能运转得很好，什么样的经验又非得写入模型不可？答案往往就藏在这两个极点之间的空白地带。

## 细想一下，其实是四层

把让 AI
记下一条经验这件事沿着状态存放的位置拆开，落点其实超越了模型内外这两个端点，可以清晰地划分为四个层级。最浅的一层存在于当前对话的输入上下文里。你下达要求，AI
在当次生成中跟进执行。这种方式生效最快，生命周期也最短，对话窗口一关，记忆便随之清零。

往下一层是外部记忆，比如向量数据库或检索系统。把经验整理成记录存入库中，在未来的对话里按需检索。它的工作方式有点像
Google：假设信息已经躺在某个地方，提问的时候靠相似度匹配把它找回来。它打破了单次对话的寿命限制，但也带来了一系列新的不确定性：记录可能没能成功写入，检索时可能出现漏检，召回的内容可能与旧数据冲突，或者记录本身早已失效。

再往下一层，是跟项目一同版本化的文档、配置文件与规则集。把踩过的坑或固定的流程写成独立文件，存放在
AI 能读取到的目录里。每次执行任务前，让 AI 优先读取这份文档。它更像
Yahoo 早期的人工编目：不靠提问时碰运气，而是在事先就把知识组织好。OpenAI
自己的数据 Agent
也走了类似的路线，用大模型离线把数仓代码编成结构化描述，在线再检索这些已经加工过的材料，而不是直接对原始数据做实时搜索（详见这篇分析）。与依赖相似度匹配的检索机制不同，这种方式具备确定性的触发机制，只要指定位置存在对应文件，模型就能稳定读取。同时，它支持完整的版本管理，出现偏离时随时可以执行回滚。

最深的一层则是微调，将特定行为直接写入模型参数。在冻结的基础模型外侧训练一组轻量级的附加参数（比如
LoRA），把特定的响应习惯固定下来。训练完成后，无需在 prompt
里反复交代背景，模型就会自然表现出预期的行为。

在日常实践中，第三层最容易忽视。大家习惯于在临时交代和重训模型这两个极端之间摇摆，却常常漏掉了中间这份可版本化的规则文件。实际上，第三层在大多数场景下是最先该做的一层。

第一层的记忆无法跨越会话，第二层依赖检索的运气，第四层的构建成本又过于沉重。相比之下，第三层提供了确定性的触发条件、清晰的审计路径与低廉的回滚成本，且完全不需要消耗训练资源。我在关于 Skill
的文章里提过先外化再执行的落地思路，核心就是把工作方法与避坑经验沉淀为文档，让
AI 每次读取后按图索骥，这正是第三层落点的直接体现。

## 每一层都有它不可替代的位置

这四个层级并非简单的替代关系，各自有着明确的应用边界。搞清楚每一层擅长解决什么问题、又会在什么地方失灵，才能为不同的经验找到合适的落点。

AI 经验的四个落点

第一层最适合承载临时的、一次性的操作偏好。比如这次分析只需要处理过去三个月的数据，这种要求即时生效、成本极低，对话结束后便完成使命。如果发现某句话自己在日常工作中频繁重复，就意味着这条经验需要向更深的空间迁移。

第二层适合存放需要查证、要求精确且带有明确出处的动态信息。例如某位客户的历史偏好记录，这类数据既不适合硬编码到模型权重里，因为信息会发生变动；也不可能全靠单次对话来维持。知识检索系统的强项在于灵活，可以随时追加任意数量的带时效记录。不过，这一层的失效模式往往非常隐蔽：很多时候你以为系统成功调取了上下文，实际上它可能根本没有命中。虽然现在的长上下文窗口给人一种容量无限的错觉，但屏幕上能塞进的文本量，并不等同于模型真正生效的记忆容量。

第三层应当留给触发条件明确、需要长期保持一致的硬性规则。比如分析 EMEA
数据时过滤测试账号、撰写报告时避免使用破折号，或者调用搜索工具时优先使用
Tavily。这类规则一旦定型，就不该寄希望于检索时的运气，也不必每次手动粘贴。把它们整理成文档存入指定的系统路径，模型在每次启动任务时就能稳定遵守。更关键的是，这些规则完全处于可掌控的状态：内容清晰可见，发现偏差随时修正，修改后也能轻松回滚。实际积累规则时，只记录
AI
真正犯过的错误，不要凭空预测它可能踩什么坑，否则过多的预设规则反而会带来干扰。

第四层的参数化写入，主要应对那些高频出现、且需要精细调控的稳定行为模式。在实践中有两个典型的适用场景。

一个场景是处理那些很难用自然语言精准界定的行为细节。我在之前的微调实践里记录过调整写作语气的过程。如果用
prompt
去约束，要求不要太正式，生成内容往往会变得过于随意；要求平实一点，语气又总是欠缺一点韵味。这种微妙的度落在正式与随意的中间地带，文字很难精准定位。微调则绕开了这种语言表达的瓶颈：无需费力用文字去界定那个平衡点，只需提供大量自己撰写的真实样例，模型就能自动收敛到预期的表达习惯上。

另一个场景是将高频出现的长 prompt
内化进权重。如果每次请求都需要附带几百字的风格指南、工具说明和格式约束，不仅单次推理的延时居高不下，计算成本也会持续累积。通过微调将这些固定要求固化进参数，后续只需给出一个极短的指令，模型就能直接输出符合规范的结果。

不过，微调也有一条清晰的边界：它改变的是模型的行为习惯，无法赋予模型全新的事实性知识。我曾做过将整个知识库微调进模型里的实验，结果证明模型很难通过微调真正掌握全新的事实性知识。面对知识更新的需求，检索系统显然是更合理的选择。微调的作用更像是唤醒与激活模型既有的能力，把这两者混为一谈，是不少人在微调上踩坑的主要原因。

实际上第四层不只是单个 LoRA 这么简单，怎么把多个 LoRA
组合起来用已经是一个相当成熟的研究方向。一条路线是多任务组合：训练多个各自专精的
LoRA，再在推理时按需加载或融合。比如 LoRAMoE 用 router
把输入分发给不同专家，在多任务混合数据上缓解了部分冲突，同时尽量保留基座中的世界知识。另一条路线更进一步，直接面向时间序列上的持续学习：任务按顺序到达，旧数据不可访问，每来一个新任务就新增一组
LoRA 专家并冻结旧的，阶段性地回测所有旧任务。代表工作如 D-MoLE，它冻结旧专家、只训练新专家，并报告了旧任务回退指标。这些工作说明，第四层正在从训练一个外挂参数，进化到管理一组外挂参数的生命周期。

参数化的探索也在持续演进。比如 Macaron-V1
这项工作，在冻结的基础模型上设置了四个分别负责 chat、agent、coding 和
GenUI 的
LoRA，并在每轮推理时选择其中一个。项目开源了模型权重与可审计的代码框架，不过从目前的形态来看，它更接近一个面向持续学习的开放架构尝试，尚未验证具备成熟的跨代学习能力。第四层正从单一外挂参数走向多参数组合管理的探索阶段，但这依然属于发展中的路线图，尚未成为完全兑现的技术形态。

## 经验应当分层递进，不必试图一步到位

理解了四个层级的作用机制后，日常使用时不必陷入非此即彼的选择，可以直接遵循从轻到重、按需升级的演进路径。

分层晋升路径：从轻到重，按需升级

绝大多数经验默认从第一层开始尝试。能在对话里顺手交代清楚的要求，没必要急着整理成文件；可一旦发现同一条提醒自己在短期内讲了三次以上，就该考虑将它提升至第二层或第三层。需要动态更新、附带出处来源的信息，适合沉淀入第二层的检索库；要求明确、触发条件清晰的刚性流程，则应当整理为第三层的本地规则文件。只有当特定行为持续高频出现、用文字难以准确描述，或者长
prompt
已经对响应速度和成本造成明显负担时，才需要开启第四层的微调尝试。

这种推进顺序的依据是风险和成本，跟学习质量没有直接关系。在对话里改一句话，尝试成本和风险都最低，即便效果不好也仅影响当次生成；写成规则文件，成本略微增加，但修改与回滚都非常可控；微调是最繁重的路径，需要清洗数据、安排训练和做回归测试，而且一旦行为发生偏移，很难逐条定位是哪一条训练样本引发了副作用。

在实际生产中，选择先外后内（context-first,
parameter-later）的策略，本质上是在把控风险与发布节奏。这也意味着，并非所有经验都有必要最终写入参数层，许多规则保留在文档和检索系统中反而更容易维护。

无论一条经验最终落在哪一层，在交付验收时都有五个很实在的问题可以拿来对照：变化究竟写到了哪里？多久能够生效？能否跨越会话保留？未来能否准确调取？出现偏差时如何撤回？

把这五个问题回答清楚，AI
吸收经验的闭环才算真正建立完成。如果答案模棱两可，哪怕积攒了再多的记忆条目、编写了再复杂的技能文档、训练了再多的
LoRA
模块，也只是在系统中堆积了更多的状态，并没有真正把这些经验消化吸收。