夜雨聆风本文是”AI之旅”合集 LLM Wiki 系列的第 1 篇。
AI 助手在通用题上很强，一接公司代码库就好像换了个人——反复迷路、刚解释过又忘。问题不在它笨，而在它没真正”入职”你的项目：上下文塞不下、RAG 是临时翻书、长期记忆欠奉。
图片制作：Nano Banana 2
AI 助手在你项目里到底”看到”了什么
你大概有过这种经历。
让 Claude、ChatGPT、Cursor 写一段独立的小工具，它写得行云流水；让它讲一个开源算法的原理，它讲得头头是道。但你一旦把它丢到自己公司的代码库里——让它帮忙改一个跨三个模块的 bug，它立刻就开始迷路：函数名找不到、调用关系搞混、明明你十分钟前刚解释过的概念又反过来问你一遍。
不是它变笨了。是它进入了一个全新的世界。
一个 AI 助手在它的训练数据里见过整个开源界的代码：React 是怎么写的、Linux 内核长什么样、流行的 Python 库怎么用。但你公司的代码它没见过。不仅没见过，而且每次和你对话都是从零开始的——上一次会话里你跟它讲明白的事情，下次开个新窗口它一点都不记得。
它能”看到”的，只有你这次会话里主动塞进去的那些东西。这就好比你雇了一个很厉害的咨询顾问，简历亮眼、知识渊博——但他不在你公司上班，每次来都是初次见面，你得现场把项目重讲一遍。讲完一阵子，他回去了，下次再来又是一张白纸。
这才是问题的真正形状：不是 AI 不够聪明，而是它从来没有真正”入职”你的项目。
上下文窗口：再大也塞不下整个项目
你可能会想：那我把整个项目都贴给它不就行了？反正现在的模型上下文都很大。
确实大。最近这两年，主流大模型的上下文窗口（一次对话里它能”看见”的 token 数量）翻了好几番。最新版本的 Claude Sonnet、Claude Opus 都支持 100 万 token 上下文，Google 的 Gemini 也宣传过类似量级。听起来非常宽敞。
但我们做个简单的算术。
一个中等规模的真实项目，几千个文件、几十万行代码并不夸张。哪怕一个普通的中后台业务系统，源码加上配置、文档、测试，token 数动辄上千万。一百万 token 听起来很大，但还塞不进一个真实的中型项目——更别说要给模型留出”思考”和”回答”的空间。
更麻烦的是：上下文不是塞得越满越好用。学术界有个很有名的发现，叫”中间迷失”（Lost in the Middle）——当上下文塞得很长时，模型对开头和结尾的信息记得清楚，对中间段落的信息明显遗忘。你把整本项目代码塞进去，最关键的那部分八成正好掉进了中间这个”记忆塌陷区”。
这就像你给一位新顾问递了一本一千页的项目手册说”看完就懂了”。他确实可以翻，但翻到第五百页时，前面看过的早忘了，后面还没翻到——真要他答某个具体问题，多半还是要重新查。
上下文窗口再大，也代替不了”先消化、再上场”。
RAG：临时翻一翻就上场答题
既然全塞不行，那能不能”用到什么塞什么”？
这就是目前业界最流行的方案：RAG（Retrieval-Augmented Generation，检索增强生成）。思路是这样的——
把项目里所有文档、代码切成一小段一小段（叫 chunk）； 用一个专门的模型把每一段变成一串数字向量（叫 embedding，可以理解成”语义指纹”）； 你提问的时候，先把问题也变成向量； 在向量库里找出”和问题最像”的几段，塞进上下文给主模型； 主模型基于这几段答你。
这个方案非常聪明，目前几乎所有”和你的文档聊天”的产品背后都是它。但它有几个绕不开的硬伤，尤其是在真实大项目里：
第一，切片本身就在丢上下文。你把一个 200 行的类切成五片，每一片单看都不知道这个类整体在干嘛。如果一个函数引用了另一个文件里的常量，切片之后这两段可能根本不会同时被检索出来。
第二，“语义相似”不等于”真正相关”。你问”为什么订单结算这里要加锁”，向量库找回来的可能是十段都包含”加锁”两个字的代码——但其中真正解释”为什么”的那段评论，可能因为措辞不一样根本没被检索到。
第三，找回来的是一堆碎片，没有结构。模型拿到的是”片段 A、片段 B、片段 C”，它必须在回答你的问题之前临时拼出这些碎片之间的关系。每一次提问都拼一遍——拼得对不对全凭运气和模型的脑补。
打个比方：RAG 像考试时翻书找答案。考场上你可以查书，但你不知道考什么，每次翻都是被题目带着翻，找到几句字面相关的就抄上去。结果就是：字面在书里能找到，但你其实不懂这本书。
RAG 不是没用——它在很多场景下都是合理选择，特别是动态变化的资料、海量的低价值文档。但在”让 AI 真正理解你项目”这件事上，它有结构性的天花板。
“刚解释过的东西”为什么又忘了
还有一个让人抓狂的现象。
你昨天花了半小时跟 AI 解释清楚你们项目里”用户态”和”商户态”的区别，让它改完一段代码，关掉对话窗口。今天打开一个新会话，让它接着改下一段——它问你：“这里的’商户态’是什么意思？”
你心里一万头草泥马奔过。
但这不是 AI 在偷懒。它的设计本身就是这样：每一次会话都是独立的。模型没有跨会话的长期记忆——上次会话里你输入的那些话，没有进入它的”大脑”，没有变成它的知识。它只在那一次会话的上下文窗口里”看见”过那些话，会话一关，全没了。
你可能会说，那 ChatGPT、Claude 不是都有”记忆”功能吗？有，但那是产品层面的小补丁：把你说过的几句”重要的事”存进一个小记事本，下次会话开始时塞回上下文里。它不是真的”记住”，而是”被重新告知”。能存多少？各家产品没公布过明确数字，但这种”小记事本”式的记忆都不大——够你存”我喜欢喝美式咖啡”，不够你存”整个项目的架构”。
所以为什么”刚解释过的东西又忘了”？因为根本没有一个地方在帮你积累这些解释。每次新会话，你都得从零再讲一遍。
这就像每天换一个聪明的新员工：再聪明，第一天都要从头带。要是你的项目复杂一点，带新人的成本最后比项目本身还高。
一个新思路：让 AI 提前做好功课
把前面这几个症状放一起看，根源其实是同一件事——
AI 助手对你项目的了解，都是临时的：临时塞进上下文、临时检索、临时听你解释。
那能不能换个思路？
不再每次都临时给它喂，而是提前给它做一份”入职手册”：把项目里最重要的概念、模块、约定、设计决策，整理成一份持久存在的、结构清楚的、互相链接的资料库。AI 每次开工，先读这份手册。读完才进项目。
这份资料库不是 RAG 那种切碎了散在向量库里的片段——而是一份完整的、有目录、有章节、有交叉引用的知识网络，最关键的：它是被一遍遍消化、整理过的，不是原始代码的拷贝。
这就是 Andrej Karpathy（OpenAI 创始成员之一、特斯拉前 AI 总监）最近在公开场合反复提到的一个思路。他给它起了个名字——LLM Wiki。意思很直接：给大模型用的、由大模型主导整理的、维基百科那样的项目知识库。
最近不少公司开始在内部要求每个项目组建自己的 LLM Wiki，正是因为大家在实际用 AI 编程助手时都撞到了我们这一篇说的那些墙——上下文塞不下、RAG 找不准、长期记不住——而 LLM Wiki 提供了一个绕开这堵墙的具体做法。
但 LLM Wiki 到底是什么？它和我们已经在用的项目文档、README、Wiki 页有什么不同？它和 RAG 又是什么关系？
下一篇，我们把这件事讲透。
