Anthropic 给 Claude Code 设计了一个专门的记忆文件叫 MEMORY.md。但是，我把正确的产品链接存在第 175 行，AI 写链接时根本没去查，凭印象写了一个错的。设计者自己在文档里承认：这只是上下文，不是强制配置。"Memory"这个命名，给了用户一个错误的预期。
记忆文件第 175 行
前两天我在用 AI 帮我写 Newsletter。流程很顺，从结构到正文都没什么问题，最后一步生成 CTA 链接，我扫了一眼，看起来也没问题。
其实之前就出过链接写错的情况，所以我专门把正确的产品链接表存进了 AI 的记忆文件（MEMORY.md）。这次应该不会再错了。
邮件群发了。
发完之后我想随手验证一下，点了一下链接，页面不存在。
链接又错了。而正确答案就在 AI 的记忆文件第 175 行，没有被截断，没有任何技术原因导致它看不到。
我问 AI：你不是应该随时查这个文件吗？这不就是你的记忆吗？
AI 的回答倒是比它写的链接靠谱得多：
"MEMORY.md 在对话开始时作为系统上下文的一部分加载进来，但随着对话变长，它在注意力中的权重会下降。当我在执行一个多步骤工作流的某个具体环节时，我的注意力集中在当前任务结构上，不会主动回头去翻一个离当前执行点很远的参考文档。"
"这就像一个人桌上放着一本手册，手册里有正确答案，但他在专注写东西的时候不会停下来翻到第 175 页去核对一个链接。"
当然，AI 对自己行为的解释不一定反映真实的内部机制。但这个类比很准确地描述了外在表现：问题不是 AI 没有这个信息，而是它在写 CTA 的时候根本没去查。
加载不等于激活
你可能会说：信息放进上下文不一定被用上，这不是常识吗？needle in a haystack 测试早就证明了这一点。
没错。但 MEMORY.md 不是随便塞进去的一段文本。它是 Claude Code 专门设计的记忆机制，Anthropic 官方叫它 "auto memory"，设计目的就是"跨会话积累知识"，每次对话开始时自动加载。我专门把链接表存进去，就是因为之前出过错。
如果连一个专门为"记忆"而设计的机制都不能保证信息在关键时刻被调用，那它跟我随便给 AI 丢一份参考文档有什么区别？
有意思的是，Anthropic 自己在文档里写了一句话："Claude treats them as context, not enforced configuration." 翻译过来就是：这只是上下文，不是强制配置。换句话说，设计者自己都知道"加载"不等于"遵守"。但他们依然把它叫做 "memory"。
这才是让我真正警觉的地方。不是"加载到上下文的信息可能被遗漏"这个已知事实，而是：即使你用了专门的记忆机制，激活的问题依然存在。 "Memory"这个命名给了用户一个错误的预期，让人以为存进去就等于记住了。
你让 AI 在 system prompt 里写了一堆规则，它照样在某个环节违反。你在记忆文件里存了正确的链接表，它照样凭印象写一个错的。以前你可能觉得这是 AI 笨，或者觉得是自己 prompt 没写好。但问题可能不在能力，也不在指令，而在 AI 使用信息的方式。
就像 AI 自己说的那个类比：桌上放着手册，专注写东西的时候不会停下来翻。研究也证实了类似的现象。2023 年一篇被广泛引用的论文 "Lost in the Middle" 发现，LLM 在长上下文中检索信息时，放在中间位置的内容最容易被忽略，头尾的信息则更容易被用上。你的记忆文件里那行链接，可能就卡在了"中间地带"。
这也解释了一个很多人困惑的问题：为什么 RAG 检索出来一堆相关上下文，模型照样可能忽略其中的关键段落。问题不在检索，在激活。
这不是偶发的 bug，是当前架构下的常见失败模式。
同一个根源，更广的症状
记忆文件的问题只是冰山一角。AI 的注意力收窄不仅让它"有信息不去查"，还让它在执行任务时完全丧失外围视野。
我之前用 Codex 一天做了个 Mac 语音输入 App（VerbatimFlow）。所有 API 都是现成的，文档齐全，不存在信息缺失。但 AI 还是反复踩坑：
- macOS 把权限绑在应用签名上，每次重新构建签名变了，之前授予的权限全部失效。AI 完全没预判到这一点
- 热键按下后偶尔收不到释放事件，导致"按住说话"变成了"永远在录音"。试了好几轮方案，最终用双信号源交叉验证才稳定下来
这些坑跟 MEMORY.md 链接错误的性质不完全一样。链接那个是"信息在手边没去查"，VerbatimFlow 的问题更像是"专注于当前函数调用，不会抬头看一眼全局"。但根源是相通的：AI 在执行局部任务时，注意力会收窄到当前步骤，无论是记忆文件里的一行链接，还是系统层面的权限机制，只要不在当前焦点范围内，就大概率被忽略。
Karpathy 前两天聊 ephemeral apps 的时候也遇到了类似的事。他用 Claude vibe code 了一个心率追踪 dashboard，Claude 把公制和英制搞混了，日历的日期也对不上。所有的单位信息和日历规则都是公开的、可查的，不是 API 缺失的问题。
Karpathy 没展开的那一句
Karpathy 在那条推文里说，他的心率 dashboard 现在花 1 小时，但理想状态应该是 1 分钟。他把瓶颈归因于基础设施：99% 的产品没有 AI-native API。
这个判断大方向没问题。但他中间提到了一句话，没有展开：
"The AI would already have a lot of personal context."
这句话恰好点到了我踩过的坑。"有 personal context"听起来像是问题已经解决了，但我的 MEMORY.md 经验说明：有数据和能用上是两回事。AI 的记忆文件里躺着正确答案，它还是凭印象写了一个错的。
从 1 小时到 1 分钟，基础设施当然是瓶颈。但还有一个同样重要的瓶颈：AI 什么时候能学会在正确的时机调用正确的信息。Karpathy 描述的愿景要成立，这个问题绕不过去。
现在能做什么
既然 AI 自己靠不住，我们只能从工程层面去补。
最可靠的方案：把约束嵌入流程步骤。
MEMORY.md 里的链接表之所以没被用上，是因为它离执行点太远。但如果我把链接表直接写进 Newsletter 工作流的第 7 步（质量检查），AI 走到那一步时，信息就在眼前，不需要"记得去查"。
具体来说，我的 Newsletter 工作流里现在有这么一步：
步骤 7 · 质量检查：核对以下链接表，确认所有 CTA 链接与此表完全一致。不要凭记忆生成链接。
- MAPS 课程：/aiagent
- 精英圈 PRO：/ai-elite
- 免费入门课：/axton-free-course
这就是声明式记忆和程序式记忆的区别。声明式记忆说"你应该记住这些链接"，程序式记忆说"走到这一步时，查这张表"。后者不靠自觉，靠流程。
第二个手段：关键约束重复出现。
如果一条规则真的重要，不要只写在一个地方。我现在会把同一条约束同时写在记忆文件和工作流步骤里，甚至在 prompt 的不同位置重复提及。这看起来很笨，但很有效。AI 的注意力是概率性的，同一条信息出现的位置越多，在关键时刻被激活的概率就越高。
第三个手段：让 AI 在交付前自检。
在工作流的最后一步加一个 checkpoint："回头检查记忆文件和规则文件，逐条核对本次输出是否违反了任何约束。"这相当于强制 AI 在提交前"抬一次头"。不能保证万无一失，但能拦住大部分低级错误。
更理想的方案目前还做不到，但方向很清楚：
- 事件驱动激活：检测到 AI 正在写 URL，自动触发链接速查表。认知科学里叫前瞻记忆（prospective memory），不是时刻记着"要买牛奶"，而是路过超市时环境线索触发了这个记忆
- 分层记忆系统：工作记忆、情景记忆、语义记忆、程序记忆分开管理，不是一个扁平文件承担所有功能
这些是未来方向。但前面三个手段，现在就能用，不需要等架构升级。
瓶颈不是 API
回到 Karpathy 的愿景。他描述的未来很诱人：AI 了解你的偏好，调用传感器数据，编排生成定制软件，1 分钟搞定。
但要实现这个愿景，光有 AI-native API 不够。AI 还需要解决一个更基本的问题：在正确的时候调用正确的信息。
好消息是，这个问题不用等 AI 自己解决。把约束嵌入流程、关键规则重复出现、交付前强制自检，这三个手段现在就能把大部分坑堵住。
如果你也在用 AI 做有交付物的工作，可以回去检查一下：你的关键约束，是放在一个离执行点很远的文件里，还是嵌在了工作流的具体步骤中？这个区别，往往就是"AI 好用"和"AI 不靠谱"的分水岭。
本期推荐
如果你想系统地学怎么设计这类工作流约束，MAPS 课程里有完整的方法。
→ 了解 MAPS 课程
Responses