AI摘要
你可能一直在用错的方式理解 AI
大多数人（包括几个月前的我）对 AI 的理解是这样的：
写好 prompt → 得到好结果
听起来没毛病。但 Anthropic 之前在他们的研究文档里提了一个概念，让我重新想了想这事：
Context Engineering 是 Prompt Engineering 的自然演进。
等等，这不是换个说法吗？
不是。区别其实挺大的。
简单说：
- Prompt Engineering 关注的是「这条 prompt 怎么写」
- Context Engineering 关注的是「整个上下文怎么管理」
一个是写好一封信，另一个是管理整个邮件系统。
为什么 context 塞太多反而变蠢？
这事我自己踩过坑。
128K 的 context window，我心想：太好了，把所有文档、历史记录、说明文档全塞进去！理论上 AI 应该更聪明才对吧？
结果呢？AI 反而开始说胡话。
后来查了一下，学术上有两个概念解释这个：
Attention Budget — Transformer 的注意力不是均匀分配的。context 太长，每个 token 分到的「注意力」就被稀释了。关键信息可能直接被淹没。
Context Rot — 长对话里，早期的信息会慢慢「衰减」。聊两小时后，AI 基本忘了开头说的啥。
这就解释了为什么有时候聊着聊着，AI 突然「失忆」了。
Claude Code 的做法：Just-in-Time
Anthropic 在 Claude Code 里用的策略叫 Just-in-Time：
不是一次性加载所有信息
而是需要时才加载相关的
具体流程大概是：
跟传统的「把所有东西塞进 system prompt」完全不一样。
我自己搞的三层记忆架构
我在用 OpenClaw（一个 AI Agent 框架）的时候，折腾出了类似的架构：
asciidoc
记忆系统/
├── MEMORY.md # 核心记忆，每次都加载
├── memory/
│ ├── 2026-02-12.md # 每日日志
│ ├── 2026-02-11.md
│ └── archive/ # 过期的自动归档
└── memory_search # 需要时再搜索
层级设计：
L1 MEMORY.md — 每次会话开始就加载
L2 每日日志 — 只加载今天和昨天的
L3 历史归档 — 通过语义搜索按需召回
还搞了个自动过期机制：
[P0] — 永不过期（核心信息）
P1 — 90天后归档
P2 — 30天后归档
每天凌晨 4 点，一个 Python 脚本自动扫描，把过期的移到 archive。
效果？Token 用量降了 78%，但回答质量反而上去了。这挺反直觉的。
压缩前的保护：SESSION-STATE.md
还有个坑：AI 的 context 会被定期「压缩」来省 token。压缩就是把长对话总结成短的。
问题是，压缩会丢细节。
我的解决方案是搞了个 SESSION-STATE
SESSION-STATE.md 内容：
- 当前在干嘛
- 最近做了什么决定
- 还有什么没处理
- 任何不能丢的关键信息
压缩前先更新这个文件，压缩后先读这个文件。
相当于给「工作记忆」做了个持久化备份。
实战检查清单
如果你也在搞 AI 系统，可以问自己这些问题：
信息分层：
哪些信息需要一直在？
哪些信息有时效性？
哪些信息可以按需召回？
加载策略：
是不是在一次性塞满 context？
有没有 Just-in-Time 的机制？
搜索系统够不够快？
衰减对策：
长对话怎么保护早期上下文？
压缩前有没有保护机制？
关键决策有没有持久化？
最后
这不只是换个术语。
Prompt Engineer 想的是：「这个 prompt 怎么写更好？」
Context Engineer 想的是：「整个系统的信息流怎么设计？」
一个是战术问题，一个是架构问题。
AI Agent 会越来越复杂、运行时间越来越长。到时候 Context Engineering 会变得越来越重要。
文章来源：Jason Zuo@xxx111god
