让 AI「好像」记住你

墨问版： 让 AI「好像」记住你

Claude Code + Warp 是真的无敌，在体验了 Z Code之后，我回到了 CC 的怀抱。或许 Terminal 确实是软件工程师最终的归宿。不过，IDE 一时半会也不会退场，毕竟可视化降低了使用门槛，但 JetBrains 系列对我来说已沦为查阅和简单调整代码的配角（买了一年 AI Pro，不能浪费 😳）。JetBrains 从 2025.3.1 版本开始，智能补全终于好用了那么一点点 🤏。是的，一点点，差不多是 Cursor/Trae 四五成的水平吧。

有时候，你不得不感慨，老牌玩家在时代转身时的速度，比蜗牛还慢半拍。智谱，MiniMax 先后上市，最早 All-in-AI 的百度推出了啥好用的大模型？如果不去搜索，我真的不甚了解，因为热点里面很少看见它的身影。无所谓啦，对于查阅代码这种传统功能来说，JetBrains 系列依然是做得最好的。此刻的我，一边让 CC 卖力干活（当然，我出钱……），一边在学习 Claude Skills 相关内容：

• 王树义：Claude Skills 入门：一篇文章搞懂 AI 怎么从「嘴替」升级成「打工人」
• PlayWithAI：Claude Skills 并不新鲜，模型即产品

然后一些跟 AI 记忆相关的内容引起了我的注意：所有的手段都是为了让大模型的注意力更集中，不轻易因为上下文太长而失去焦点，然后放大幻觉，偏离主线任务。

• 卓克：大语言模型是怎么记住我们的
• 季逸超：AI代理的上下文工程：构建Manus的经验教训

如何让 AI 懂「我」，如何让 AI 知道和理解更多细节，然后在工程上把任务做到 90 分以上，这些也是此刻的我正需要的。但随着任务的进行，上下文在不断变化，如何让大模型在对话的过程中不断跟进目标，而不是跑偏，应该怎么做呢？

首先就是环境。2016 年 AlphaGo 战胜李世石，一年后 Google 通过强化学习搞出了 AlphaGo Zero，它和 AlphaGo 的战绩是怎样的？100 比 0。可是这么多年过去了，强化学习为何到 GPT-3.5 才重新燃起？因为环境，在一个奖励信号过于稀疏的环境中，是很难聚焦的。

大家最初以为只要让 AI 胡乱点击鼠标、敲击键盘，就可以通过训练获得奖励，就能让 AI 自己找到恰当的参数，训练出一个好模型，学会完成任何复杂的任务，玩游戏、翻译、计算、分析、推理。

基于环境的这个大前提来思考，我们与大模型对话也需要控制在一个环境（背景）下，这个环境就是你的业务系统（或者叫业务上下文）。熟人日常交流，一般都知道一点对方背景（比如对方是男是女，大概多大年纪，住哪里，做什么，熟悉什么等），但 AI 不知道，所以我们对话时总是会先输入一句「你是一个 xxx 领域的专家」，先画个边界。内容太少，没法干活，内容太多，又抓不住重点——最终的结果好像都是似是而非。

Y：我会想这个问题，是因为上周有个朋友学了大半年荣格，然后用 Ai 对谈，感觉自己学的不值一提；但我自己的使用感受，和他可能是反的。就是他之所以觉得 Ai 强，是因为他对荣格的理论有了一定的基础了解。当前 ai 的能力边界，给我的感觉很大程度还是依赖于使用者本身。ta 更像是 1 面镜子或者说提供了 1 个对谈的空间。

C：也可能是使用者在让渡自己的边界。这两天合伙人一直在疯狂地和 GPT 讨论策略，听取 GPT 的建议，各种修改材料，结果到昨天晚上被券商全盘否定了，现在在返工。所以我这两天的感受就是在「我们的经验、判断」和「AI」之间要有道防火墙，适度听取和甄别建议……否则很容易掉进似是而非的陷阱中。

M：看能不能抗拒充盈知识带来的诱惑了。

C：……随着我们对 AI 的使用越来越深入，这样的情况早晚会出现，怎么去判断界限，需要保持警惕。

为了让大模型懂「我」，一般有两种方式：一是把业务放到模型外面，通过提示词输入让大模型了解，这里面可能包括业务内容，工具列表、样本案例以及输出要求等。另一种则是把业务放到模型里面，也就是我们常说的大模型微调。但微调是一个炼丹的过程，不仅费钱，而且不一定靠谱，连 manus 也是一言难尽：

在遥远的 BERT 时代（是的，已经过去七年了），模型必须先进行微调——和评估——才能迁移到新任务。这个过程通常每次迭代需要数周时间……这种缓慢的反馈循环是一个致命缺陷。这是我上一个创业公司的惨痛教训，当时我从头开始训练模型用于开放信息提取和语义搜索。然后 GPT-3 和 Flan-T5 出现了，我的内部模型一夜之间变得无关紧要。

所以，押注上下文工程也成了各种 Agent 的首选。上述文章中一位国外大佬就尝试破解了 ChatGPT 的记忆模式：这里没有向量库，没有 RAG，主要就下面四层逻辑：

• 元对话数据：也就是当前会话者的基本信息，比如当前时间，账号年龄，账号时区，账号活跃情况等；
• 用户记忆：从对话中提取的人物画像，比如你是一个软件开发工程师，你喜欢吃面食等。这份数据会随着对话不断更新，保证跟你当前的人设一致；
• 近期对话摘要：每次对话前，先拿到前面 15 次对话的摘要，并且这些内容只有用户输入的部分，没有 LLM 输出的内容；
• 当前对话：核心关注点，不让 AI 偏离主线。

可以看到，没有过往全部历史会话的 RAG，有的仅仅是前面 15 轮对话的摘要，而这也符合一般情况下熟人聊天时的上下文。毕竟上下文窗口大小有限，让 AI 真正记住「我」是不现实的。但上述一波操作下来，却可以让 Ta「好像」记得「我」，工程实现也不复杂。

下面就基于前人的心血（以及生成 token 耗费的 money），简单梳理一下上下文工程中的部分最佳实践：

1. KV 缓存：这是 LLM 提供的能力，对于相同的内容，LLM 支持缓存加载，不用重复计算 token。

   • 在构建提示词时，将不变的内容放在最前面
   • 上下文只追加内容，不删除内容
   • 在上一条的基础上，通过掩码工具让一些选择不可见

2. 上下文窗口就那么大，在描述完核心需求后，所剩空间就不多了。既如此，那就用时间换空间，把工具函数、MCP、Skills 都封装起来，你需要时就去拿，只不过多费点时间。

3. 再进一步，给你一个完整的文件系统，甚至是一个完整的 OS，里面啥都有，只不过运行在一个独立的沙箱内，安全可靠。

4. 为了不让复杂任务跑着跑着就偏离目标轨道，可以在上下文中复述任务目标，这也是为什么 Cursor/Trae 等工具在干活之前会先生成 TODO LIST 的原因：
   
   

   通过不断修改这份 TODO LIST，保证航行角度不会偏。对于我自己，每天的工作也会有一个 TODO LIST，这很好理解，当你被其他任务打断时，这个列表会让你回归主线。
   
   

5. 保留错误内容，让 LLM 可以从错误中学习，这也是强化学习的另一种案例。

6. 对于复杂任务，少样本学习和历史对话消息本身可能也是一种束缚，会导致同质化的输出，此时可以引入一些噪音。

由于最近在写一个 Agent，关于上面的最佳实践，我已应用了一小部分，其他的也会逐渐加入，并根据业务侧的反馈不断调整。上下文工程真是一门大学问，我要继续站在巨人的肩膀上。下一站，认真过一遍《Google Prompt Engineering》。