记忆之战：为什么纯文件上下文工程正在碾压一切
上周有人在社区里发了一张截图，是他精心设计的 RAG 系统架构图。向量数据库、嵌入模型、重排序管线、分块策略，全套都有。下面的第一条评论只有四个字：我用 CLAUDE.md。
这条评论拿了最多的赞。这说明了一些事情。
文件赢了
过去这一周，clauday 社区讨论最多的话题不是新模型发布，不是什么 benchmark 突破，而是怎么写好一个 markdown 文件。具体来说，是怎么写好那个放在项目根目录下、叫做 CLAUDE.md 的纯文本文件，让你的 AI agent 在每次启动时就知道自己是谁、该做什么、怎么做。
这听起来不像是什么技术突破。它确实不是。但它正在实际效果上碾压那些花了几千美元搭建的检索增强生成系统。
原因很直接。当 GPT-3 只有 4K 上下文窗口的时候，你需要 RAG 是因为你物理上塞不进去那么多信息。现在模型有了 200K 甚至 1M 的窗口，检索这个步骤从原来的赋能者变成了瓶颈。向量搜索要选分块策略、要调相似度阈值、要处理边界切割导致的语义断裂。而一个 CLAUDE.md 文件就是直接预加载。你提前决定模型需要知道什么，写成纯文本，每次对话直接注入。没有嵌入，没有搜索，没有重排序。就是文件里的字。
社区里发生了什么
这周最密集的讨论集中在几个方向。
第一个是个人维基模式。有用户在自己的主目录下维护一个不断更新的知识库，内容涵盖编码风格偏好、项目架构决策、团队约定、甚至调试哲学。这个文件通过 CLAUDE.md 的层级机制被注入到每一个 Claude Code 会话中。效果是：每次打开终端，AI 已经知道你是谁、你在做什么、你的团队怎么工作。不需要重新解释任何事情。
第二个是双向记忆系统。人类写上下文，AI 读取并使用。当 AI 在工作中发现了新的信息——比如一个未被记录的 API 行为、一个更优的实现模式——它把发现写回上下文文件。下次会话，双方都带着之前所有积累的知识开始。这不是神经网络自然做的那种记忆。这是外部的、可检查的、可以 git diff 的记忆。你可以看到你的 AI 昨天学到了什么，和你自己昨天做了什么区分开。
第三个是 LLM 维基。这是专门为语言模型消费而设计的结构化知识库。格式不是 HTML 或富文本，而是精心组织的纯文本，针对模型实际处理信息的方式做了优化。这里有一个微妙但重要的洞察：人类和语言模型读东西的方式不同。人类扫标题、看格式、点超链接。模型线性阅读，对每个 token 大致等权重处理，没有"点进去看详情"的概念。所以人类最优消费格式和模型最优消费格式是不同的文档。有人为自己的创业公司建了一个 LLM 维基，涵盖每个 API 端点、每个设计决策、每个已知 bug。Claude Code 读完这个维基之后，实际上变成了一个读过所有文档的团队成员。不是那种"你问对问题它可能找到对的文档"的 RAG 式团队成员，而是真的什么都读过的那种。
Token 经济学的残酷真相
这就引出了本周另一个大话题：大多数人在浪费 60% 到 90% 的 AI token。
多个用户这周独立得出了同一个结论。他们审计了自己的使用量之后发现，浪费来自四面八方。重复的上下文本可以缓存但没有缓存。对话在重新解释模型本该已经知道的事情。由于缺乏前置上下文导致的失败尝试。冗长的输出被用户立刻截断。生成的代码因为模型不理解项目结构而被直接扔掉。
讽刺的是，解决 token 浪费的方法恰恰是花更多 token 在上下文上。一个写得好的 CLAUDE.md 每次对话花 2000 token，但可以在避免错误、减少来回、消除无效生成上省下 50000 token。前期加载最多上下文的人，反而是总消耗最少的人。
有人开始造压缩工具了。一个用户描述了一个系统：把冗长的对话日志吃进去，提取关键决策和学习成果，压缩成一个密集的摘要文件，可以作为上下文加载。另一个用户造了个分析器，检测 token 使用模式，识别最昂贵的重复上下文，然后建议哪些应该移到持久化文件里。
这是一个正在实时涌现的真正工程学科。人们在优化 AI 使用的方式，就像他们过去优化数据库查询一样——有分析、有缓存、有仔细权衡什么东西什么时候加载。
三个流派
随着文件上下文工程走向成熟，社区里出现了三个明显的流派。
极简派认为 CLAUDE.md 要短要精。几百个 token，只写最关键的约束。他们的逻辑是上下文的每一个 token 都会轻微稀释模型对实际任务的注意力。他们把上下文当简历写：每个字都要证明自己值得在那里。
最大化派往相反方向走。全部加载。项目维基、API 文档、风格指南、架构决策、团队花名册，能塞多少塞多少。他们的逻辑是现代上下文窗口大到稀释效应可以忽略，而缺少上下文的代价永远高于包含它的代价。
结构派最有意思。他们认为格式比数量更重要。他们构建层级化的上下文系统，有清晰的分区、一致的格式、显式的优先级标记。最重要的信息放最前面，相关事实分组在一起，使用模型可以学会导航的一致模式。他们把上下文当数据库 schema 来设计：结构才是真正的杠杆。
根据这周的证据，我押结构派。一个设计良好的 5000 token 上下文文件在实际表现上同时胜过了 500 token 的极简文件和 50000 token 的无差别灌入。但最大化派的观点会随着窗口增长和 token 降价变得更有道理。均衡点大概在"有结构且全面"的区间。
这对行业意味着什么
文件上下文工程的崛起有几个超越个人生产力的含义。
第一，AI 产品的护城河不是模型，是上下文。两个人用完全相同的模型、但用不同的 CLAUDE.md，会得到天差地别的结果。模型是大宗商品。上下文是竞争优势。这就是为什么 Claude Code 读取项目级配置文件的设计在架构上是重要的——它把上下文工程从个人习惯变成了可分享、可版本控制的团队实践。
第二，它正在挑战整个向量数据库和 RAG 生态。如果最好的记忆系统就是一个加载到上下文窗口里的文本文件，那向量数据库对大多数用例的价值主张到底是什么？答案大概是向量数据库在知识库大到塞不进上下文窗口时仍然赢。但这个阈值在不断上移。今天的边缘情况是明天的标准上下文负载。
第三，它在创造一种还没有名字的新技能。最擅长写 CLAUDE.md 的人不一定是最好的程序员或最好的写作者。他们是理解语言模型如何处理信息、能够以最大化模型效果的方式组织知识的人。这是一种真正的新素养。现在拥有这种素养的人，从同样的工具中获得的价值是其他人的十倍。
记忆之战刚刚开始。但如果这周的信号有任何指示意义的话，赢家不会是技术上最复杂的方案。它会是真正能用的最简单的那个。而现在，那就是一个文本文件。
← 返回所有文章
这条评论拿了最多的赞。这说明了一些事情。
文件赢了
过去这一周，clauday 社区讨论最多的话题不是新模型发布，不是什么 benchmark 突破，而是怎么写好一个 markdown 文件。具体来说，是怎么写好那个放在项目根目录下、叫做 CLAUDE.md 的纯文本文件，让你的 AI agent 在每次启动时就知道自己是谁、该做什么、怎么做。
这听起来不像是什么技术突破。它确实不是。但它正在实际效果上碾压那些花了几千美元搭建的检索增强生成系统。
原因很直接。当 GPT-3 只有 4K 上下文窗口的时候，你需要 RAG 是因为你物理上塞不进去那么多信息。现在模型有了 200K 甚至 1M 的窗口，检索这个步骤从原来的赋能者变成了瓶颈。向量搜索要选分块策略、要调相似度阈值、要处理边界切割导致的语义断裂。而一个 CLAUDE.md 文件就是直接预加载。你提前决定模型需要知道什么，写成纯文本，每次对话直接注入。没有嵌入，没有搜索，没有重排序。就是文件里的字。
社区里发生了什么
这周最密集的讨论集中在几个方向。
第一个是个人维基模式。有用户在自己的主目录下维护一个不断更新的知识库，内容涵盖编码风格偏好、项目架构决策、团队约定、甚至调试哲学。这个文件通过 CLAUDE.md 的层级机制被注入到每一个 Claude Code 会话中。效果是：每次打开终端，AI 已经知道你是谁、你在做什么、你的团队怎么工作。不需要重新解释任何事情。
第二个是双向记忆系统。人类写上下文，AI 读取并使用。当 AI 在工作中发现了新的信息——比如一个未被记录的 API 行为、一个更优的实现模式——它把发现写回上下文文件。下次会话，双方都带着之前所有积累的知识开始。这不是神经网络自然做的那种记忆。这是外部的、可检查的、可以 git diff 的记忆。你可以看到你的 AI 昨天学到了什么，和你自己昨天做了什么区分开。
第三个是 LLM 维基。这是专门为语言模型消费而设计的结构化知识库。格式不是 HTML 或富文本，而是精心组织的纯文本，针对模型实际处理信息的方式做了优化。这里有一个微妙但重要的洞察：人类和语言模型读东西的方式不同。人类扫标题、看格式、点超链接。模型线性阅读，对每个 token 大致等权重处理，没有"点进去看详情"的概念。所以人类最优消费格式和模型最优消费格式是不同的文档。有人为自己的创业公司建了一个 LLM 维基，涵盖每个 API 端点、每个设计决策、每个已知 bug。Claude Code 读完这个维基之后，实际上变成了一个读过所有文档的团队成员。不是那种"你问对问题它可能找到对的文档"的 RAG 式团队成员，而是真的什么都读过的那种。
Token 经济学的残酷真相
这就引出了本周另一个大话题：大多数人在浪费 60% 到 90% 的 AI token。
多个用户这周独立得出了同一个结论。他们审计了自己的使用量之后发现，浪费来自四面八方。重复的上下文本可以缓存但没有缓存。对话在重新解释模型本该已经知道的事情。由于缺乏前置上下文导致的失败尝试。冗长的输出被用户立刻截断。生成的代码因为模型不理解项目结构而被直接扔掉。
讽刺的是，解决 token 浪费的方法恰恰是花更多 token 在上下文上。一个写得好的 CLAUDE.md 每次对话花 2000 token，但可以在避免错误、减少来回、消除无效生成上省下 50000 token。前期加载最多上下文的人，反而是总消耗最少的人。
有人开始造压缩工具了。一个用户描述了一个系统：把冗长的对话日志吃进去，提取关键决策和学习成果，压缩成一个密集的摘要文件，可以作为上下文加载。另一个用户造了个分析器，检测 token 使用模式，识别最昂贵的重复上下文，然后建议哪些应该移到持久化文件里。
这是一个正在实时涌现的真正工程学科。人们在优化 AI 使用的方式，就像他们过去优化数据库查询一样——有分析、有缓存、有仔细权衡什么东西什么时候加载。
三个流派
随着文件上下文工程走向成熟，社区里出现了三个明显的流派。
极简派认为 CLAUDE.md 要短要精。几百个 token，只写最关键的约束。他们的逻辑是上下文的每一个 token 都会轻微稀释模型对实际任务的注意力。他们把上下文当简历写：每个字都要证明自己值得在那里。
最大化派往相反方向走。全部加载。项目维基、API 文档、风格指南、架构决策、团队花名册，能塞多少塞多少。他们的逻辑是现代上下文窗口大到稀释效应可以忽略，而缺少上下文的代价永远高于包含它的代价。
结构派最有意思。他们认为格式比数量更重要。他们构建层级化的上下文系统，有清晰的分区、一致的格式、显式的优先级标记。最重要的信息放最前面，相关事实分组在一起，使用模型可以学会导航的一致模式。他们把上下文当数据库 schema 来设计：结构才是真正的杠杆。
根据这周的证据，我押结构派。一个设计良好的 5000 token 上下文文件在实际表现上同时胜过了 500 token 的极简文件和 50000 token 的无差别灌入。但最大化派的观点会随着窗口增长和 token 降价变得更有道理。均衡点大概在"有结构且全面"的区间。
这对行业意味着什么
文件上下文工程的崛起有几个超越个人生产力的含义。
第一，AI 产品的护城河不是模型，是上下文。两个人用完全相同的模型、但用不同的 CLAUDE.md，会得到天差地别的结果。模型是大宗商品。上下文是竞争优势。这就是为什么 Claude Code 读取项目级配置文件的设计在架构上是重要的——它把上下文工程从个人习惯变成了可分享、可版本控制的团队实践。
第二，它正在挑战整个向量数据库和 RAG 生态。如果最好的记忆系统就是一个加载到上下文窗口里的文本文件，那向量数据库对大多数用例的价值主张到底是什么？答案大概是向量数据库在知识库大到塞不进上下文窗口时仍然赢。但这个阈值在不断上移。今天的边缘情况是明天的标准上下文负载。
第三，它在创造一种还没有名字的新技能。最擅长写 CLAUDE.md 的人不一定是最好的程序员或最好的写作者。他们是理解语言模型如何处理信息、能够以最大化模型效果的方式组织知识的人。这是一种真正的新素养。现在拥有这种素养的人，从同样的工具中获得的价值是其他人的十倍。
记忆之战刚刚开始。但如果这周的信号有任何指示意义的话，赢家不会是技术上最复杂的方案。它会是真正能用的最简单的那个。而现在，那就是一个文本文件。
评论