Fox / 工具与其思想

这是「复利系统」系列的第一篇。
我想讨论的不是“哪个 AI 工具更好用”,也不是再教一套 prompt 技巧。真正让我越来越在意的是另一件事:我们能不能为自己搭一个会积累的 AI 知识库?
很多人用了很久 AI,但每次开新对话还是要重新解释自己是谁、项目做到哪、文章要什么风格、代码有哪些约束、上次踩过什么坑。AI 在这一轮里确实越来越懂你,但对话一关,那些理解就散了。
一个好的 AI 知识库,解决的不是“存更多资料”,而是让你的判断、偏好、材料、错误记录、工作规则,变成 AI 下次可以直接读取的外部结构。
它的价值很朴素:
- 少重复解释一次背景;
- 少让 AI 犯一次旧错误;
- 少把材料临时翻出来再粘一遍;
- 少在聊天记录里打捞过去的决定;
- 多让每一次协作给下一次留下东西。
这就是我说的“复利系统”:不是 AI 自己神奇地变聪明,而是你围绕 AI 建起来的那套知识结构,开始让每次使用都不只是消耗,也变成积累。
这一篇先回答第一个问题:为什么你的 AI 没有越用越聪明?
0.为什么你的AI没有越用越聪明?
有没有一种很奇怪的感觉:
明明已经用了 AI 很久,跟它聊过很多项目,纠正过很多错误,解释过很多偏好,甚至有时候觉得它已经很懂你了。但过几天重新打开一个对话,它又像第一次见你。
它不知道你的进度如何,不知道你讨厌什么语气,更不知道你后续要写的内容。你昨天刚纠正它"不要写成行业报告",今天它又端上来一张产品对比表;你上周告诉它"不要推荐工具品牌,讲方法",这周它又开始列"十大最佳 AI 工具"。
这种体验真的很烦。
但更值得想的是它背后的事——很多人的 AI 使用其实没有"复利"。
复利原本是金融里的说法:利息生利息,把上一阶段的收益滚进下一阶段的本金继续生息。放到 AI 使用上是同样的逻辑——你每次和 AI 协作留下来的东西,应该让下一次直接站在更高的起点,而不是每次都从零开始。
可惜大多数协作不是这样。你每次开启新对话都像一次"从零编译"(计算机专业的学生熟悉的词叫 clean build):背景要重新讲、资料要重新粘、风格偏好要重新声明、约束要重新提醒。AI 在这一轮里确实越学越快,但对话一结束,那些聪明就跟着蒸发了。
这篇文章想说的就是这件事。你不是不会用 AI——你是在用一种"没有存档"的 AI。
1. 你每次都在重开一局
先看一个普通场景。
你让 AI 帮你写一篇文章。第一轮告诉它读者是懂一点 AI 但不工程的人,别写成教程、别推产品、别鸡汤,要有判断,要保留你的口吻。它写了一版,你说太像行业报告,少点产品盘点;它改了一版,你说还不够像你,你会更直接,先讲问题再讲结构。一轮下来,AI 确实越来越懂了。
问题是下次开新对话,它又不知道这些。你要重新说一遍读者是谁、不要什么、之前怎么改过。这就像你和一个临时实习生合作——很聪明、当天学得快,但每天早上失忆。久而久之真正消耗你的不是任务本身,是反复解释同一套背景。
AI 编程也是这样。它跑错命令,你告诉它正确命令;它改错抽象,你告诉它本项目习惯。如果这些没有沉淀成项目规则,下次它还会重新犯一遍。
很多人以为只要 prompt 写得越来越好,AI 使用就会自然复利。这个判断只对了一半。prompt 决定这一轮的起点,但它是一次性的——你写得再好,如果没有进入某个可复用结构,下次还是要重新支付。
真正值钱的不是某一条 prompt,而是那些能跨越对话留下来的东西:你的偏好、你的项目状态、你的判断、你的错误记录。这些东西合起来,先暂时叫它:状态层。
2. 问题不在提示词,而在无状态
要理解为什么 AI 不会自然越用越聪明,先要把三个词拆开看:上下文(context)、记忆(memory)、状态层(state layer)。

上下文是这一次推理时模型眼前的工作台一张桌子,上面摆着你的问题、系统指令、历史对话、上传文件、工具返回结果。模型不会凭空知道所有事,它就是根据这张桌子上已经摆出来的东西生成回答。所以"上下文"不是"记忆",更像"模型当前能看到的范围"。
记忆是应用层在下一次可能重新摆上桌的东西。比如某个产品"记住"你喜欢简洁回答、"记住"你在做某个项目。听起来像模型真的"学会了你",但多数情况下不是模型本身变了,而是应用在下次对话时把一部分用户档案或历史摘要重新塞进了上下文。
状态层则更进一步。一个东西算状态层,至少要满足三条:
用户能看见; 用户能编辑; 不绑死在一家产品里。
少一条,就只是厂商的"记忆"。它的形态可以是项目说明、规则文件、素材库、任务状态、错误记录、决策日志——形态不重要,重要的是它是一套你自己能维护、能跨工具复用的外部结构。
换句话说,记忆更像一张被产品帮你贴上桌的便签;状态层更像一个你自己整理的项目文件夹。
编程工具 Cursor 的规则文档里有一句话很直接:大语言模型不会在一次次回答之间保留记忆,规则文件的作用,是在提示词这一层提供"持续可复用的上下文"。
这句话把事情点穿了——所谓"AI 记住了",多数时候不是模型真的连续生活在你的项目里,而是有一层东西在替它保存状态,并在合适的时候重新塞回上下文。
所以我不太喜欢把问题简单归结为"提示词工程"(prompt engineering)。提示词工程关心的是这一句话怎么写、模型这一次能表现得更好。但我们现在遇到的问题更大:如何让上一轮协作的成果,成为下一轮协作的条件。这不是一句话怎么写的问题,是状态有没有的问题。
没有状态层,我们每次都在现场搭工作台——重新搬资料、贴便签、告诉 AI 这是什么项目。有状态层,AI 进入项目时就不是空手进来——它能先读到目标、历史决定、风格约束、常见错误。AI 每次能不能变聪明,不取决于它有什么神秘的成长性,取决于下一次推理时它能不能读到上一次留下的结构。
3. Per-prompt 经济:每次都在重新支付成本
我把这种状态缺失叫做 per-prompt 经济,直译就是"每发一条提示词都从头来"的行为。每次开新对话,你都在重新支付:上一轮的工作没有变成下一轮的默认条件。
最显眼的是 token 成本。token 是模型一次能看到的字数预算,你每塞一段背景就在花预算,长项目里光是"让 AI 进入状态"就要占掉很大一部分上下文窗口。
但比这更贵的是认知成本,要从脑子里把项目状态重新倒出来:上次定了什么、哪些方向否掉、哪些假设还没验证。很多人以为自己在"用 AI",相当一部分时间其实是在管理 AI 的失忆。
此外,最隐蔽的是质量成本。AI 拿不到过去的隐性约束就会反复犯类似错误,写得像营销稿、把教程和思考混在一起、忽略你定过的边界。你以为是模型不稳定,多数时候只是状态没保存。
写作、编程、研究里都会出现这种问题。如果你的提醒只停留在当前对话里,它就不是资产,只是消耗。AI 不会自动把你的工作变成复利,你得给它一个能复利的结构。

图注:你以为是在训练 AI,实际上每次都在重新支付背景、规则、偏好。
4. 那些新词到底在说什么
过去两年 AI 产品里冒出来很多新词:
Memory(记忆) Projects(项目) Rules(规则) Skills(技能) RAG(检索增强) Vector Store(向量数据库) Agent Workspace(智能体工作台) Context Engineering(上下文工程)
按产品看会很乱,每家命名不同、入口不同、宣传口径不同。但按结构看,它们都在围着同一个问题转:怎么让 AI 下次不要从零开始?

从个人来说,是记忆和项目。
记忆解决"你是谁",记你的偏好、习惯、写作风格,让 AI 更像熟人;但它的边界很清楚,记得你喜欢什么语气不代表它懂你这篇文章的论证。项目解决"这件事做到哪里",把聊天、文件、资料圈进同一个边界里。
OpenAI 的 ChatGPT Projects 和 Anthropic 的 Claude Projects 都是这个思路,因为真正的工作不是一问一答,是持续推进。
工程上说,是规则和技能。
规则(也常以 AGENTS.md、CLAUDE.md 这类文件形式出现)非常朴素,把反复出现的约束写下来让 AI 进项目时先读:"不要修改生成文件""提交前先跑这个测试命令""分析源码必须带行号"。
靠人提醒就是消耗,写进文件就是项目状态。技能比规则又重一层,它不只是几条规定,是一整套流程包。Anthropic 对 Skills 的设计是把一个技能做成一个文件夹,里面有说明、脚本、参考资料,按需加载而不是每次全塞进上下文。
关键词叫"渐进式披露"(progressive disclosure),意思是上下文不是越多越好,要在合适的时候加载合适的信息。
再往外,是资料层和执行层。
资料层对应 RAG 和 Vector Store。RAG 翻译过来叫"检索增强",思路是"资料太多不能全放上桌",先把外部资料放在知识库里,提问时再检索相关片段塞进上下文,像图书馆按需借书。它解决的是"找得到",不自动保证"用得对"。
执行层对应 Agent Workspace。光有聊天框不够,一个真正能工作的智能体(agent)需要代码仓库、文件系统、命令行、测试环境、任务记录。也就是它需要自己的桌面。
最后再往上一层,才是 Context Engineering(上下文工程)。它不是某一个具体功能,而是一种组织方式:这一轮让模型看什么、什么时候看、看完留下什么。真正的难点不是写一句漂亮提示词,而是把记忆、项目、规则、技能、资料和工作台调度成一套刚好够用的上下文。
所以这些新词不是同一类东西。Memory 和 Projects 偏向保存用户和项目状态;Rules 和 Skills 偏向保存流程和约束;RAG 和 Vector Store 负责把资料按需搬上桌;Agent Workspace 给 AI 一个能执行任务的环境;Context Engineering 则负责调度这些东西。
合在一起,它们指向同一件事:把模型从一次性聊天框推向可持续工作台。
5. 但"记住"还不是"复利"
讲到这里,我们很容易得出一个过早的结论:既然这些产品都有记忆、项目、规则,那是不是打开这些功能,AI 就能越用越聪明?
没这么简单。这里至少有三层东西:
第一层是存储:把信息留下来。 第二层是调用:下次需要时能把信息拿出来。 第三层是改进:把这次经验变成下次流程的一部分。
前两层解决的是"下次能不能接上";第三层解决的才是"下次会不会更好"。所以,一个系统把信息存起来,只能说明它有仓库。它能不能复利,要看它有没有把经验转成下一次的改进。"记住"和"复利"之间,差了一整套反馈闭环。
举个写作里的例子。你告诉 AI:以后不要写营销腔。它如果只是存下一条"用户不喜欢营销腔",当然有用,但还很浅。真正有复利的做法,是把这次错误继续拆开:哪些句式会触发营销腔?这类文章应该保留什么语气?下次生成前应该检查什么?有没有一段正例和反例可以作为风格参考?
这些东西被整理成规则、例子、检查项之后,才从"记住一个偏好"变成"改进一个流程"。
编程也是一样。AI 跑错了一次测试命令,如果只在聊天里道歉,下次还可能再错。更有用的做法,是把正确命令写进项目说明,把常见错误写进 failures.md,把提交前检查写进 rules。这样下次它进入项目时,不只是"记得自己错过",而是能直接读取一套更新过的工作流程。这才叫把错误转成系统改进。
也因此,我对"自动记忆"一直有点警惕。它确实舒服,减少了手工维护,但它经常把三个关键问题藏起来:什么值得存,什么时候该改,什么时候该忘。
第一,记忆可能是错的。AI 可能把一次临时需求记成长期偏好,把一个过期的项目状态当成当前事实。Drew Breunig 总结过几种"上下文失效模式",包括污染(poisoning,错误信息留在里面)、分心(distraction,无关内容把注意力带偏)、混淆(confusion,相似但不同的事被搞混)、冲突(clash,前后说法自相矛盾)。错误或无关信息一旦进入上下文,会持续污染后面的输出。(这个内容我会在另外一个栏目详细阐述)
第二,更长上下文也不是万能解法。很多人以为窗口越大越好,把所有东西塞进去就行。但 arXiv 上有一篇论文叫《LLMs Get Lost In Multi-Turn Conversation》,大意是"大模型在多轮对话里会迷路",给了一个刺眼的数字:六类生成任务里,信息分散到多轮对话后,测试模型平均表现下降 39%。这个数字不能直接套到所有场景,但它提醒了一件事:历史越多,模型未必越清醒。它可能被旧信息带偏,被无关细节分散,也可能被前后矛盾的上下文夹住。
第三,厂商记忆不一定是你的资产。如果一段记忆你看不到、改不了、导不出、不能版本控制、不能迁移到别的工具,那它更像租来的空间。比如 ChatGPT Projects 里上传的文件,关停那天能不能一键导出成 Claude 或者 Cursor 能直接复用的格式?大部分答案是"不能"。
这不是说厂商记忆没价值。偏好层、个性化、轻量项目上下文,这些它都能承担。但如果你真的想让 AI 协作形成复利,只靠黑箱记忆是不够的。你需要一套自己能维护的外部结构:可见、可编辑、可版本化,最重要的是不绑死在某一家产品里。
AI 临时读懂你,只说明这一轮上下文足够好;AI 进入你的工作系统,才说明你有一套能持续被读取、被修正、被复用的状态层。前者是好对话,后者才有复利。
6. 那我们自己能不能做一个这样的项目?
可以。而且不一定复杂。
我不是说每个人都要造 AI 产品,也不是说要搞一套庞大的知识库。第一步可以很朴素:为自己的工作维护一份 AI 能读取的项目状态层,至少包含"我"和"项目"两部分。
my-ai-workspace/├── profile.md # 可复用的“我”├── project.md # 可复用的“这件事”├── rules.md # 可复用的工作规则├── failures.md # 可复用的错误经验└── materials/ # 可复用的长期素材
"我"这一层我用一份 profile.md 承担(profile 就是"个人档案"的意思,文件名按个人习惯叫什么都行)。里面写清楚我是谁、背景是什么、写作偏好是什么、做研究时的引用标准是什么、写代码时的习惯是什么。不是为了自恋,是为了减少上手成本,AI 不用每次问"你想要什么样的语气"。
"项目"这一层是一份 project.md。这个项目要解决什么、当前进度到哪、已经做过哪些决定、哪些方向被否掉、哪些材料是核心、下一步要讨论什么。所有这些东西每次都现场说一遍是很大的浪费,写在文件里 AI 进项目时先读一次就够。
再往下还有几个文件分工同样朴素:rules.md 放反复出现的约束("不要写成工具推荐""引用事实带来源""修改文件前先说明意图"),failures.md 专门记踩过的坑,不是为了羞辱 AI,是把"这次出错了"翻译成"下次怎么避免"。比如:
错误:把行业调研写成产品推荐。修正:术语介绍部分只做概念翻译,不做产品评测。
错误:文章开头铺垫太久。修正:开头必须从读者的具体困惑切入。
错误:把后面几篇的理论框架提前展开。修正:第一篇只讲状态层,不讲四层模型。
一旦错误能进入 failures.md,它就不再是一次坏体验,而是系统的改进材料。
最后一层是 materials/,长期资料目录,文章素材、调研结果、读书笔记都先进这里,不再每次临时上传。
到这里一个最小的个人状态层就出现了。这几个文件不玄,更像给 AI 准备的一份项目文件夹。没有它 AI 每次都在等你现场解释;有了它 AI 进项目时能先读到一个可复用的"你"和"这件事"。值得积累的从来不是某一条神奇提示词,是这个能被反复读取的"我"和"项目"。
7. 结尾:从聊天框到工作系统
这篇文章其实只想完成一个判断转换:不要再把 AI 使用只理解成"我这次怎么问得更好"。这当然重要,但还不够。更值得问的是,我这次和 AI 协作之后有没有什么东西留下来?有没有一条规则被改写、一个状态被更新、一份材料被整理?如果没有,这次协作再精彩也很难复利。

所以"AI 越用越聪明"这句话其实需要重写。变聪明的从来不是 AI 本身,是你围绕它建起来的那套东西。你的工作流把一次次对话、错误、判断、资料,沉淀成下一次可读取的结构,这就是状态层真正的意义——让每次使用不只是消耗,也是积累。
到这里只是第一步。第一篇回答的是为什么你的 AI 没有越用越聪明,下一篇要继续往下问:什么样的系统,才真的会复利?因为不是所有存储都会复利,能复利的系统必须同时有状态、有控制、有反馈。下一篇就从这里开始。
8. 结尾:从聊天框到工作系统
这篇文章其实只想完成一个判断转换:不要再把 AI 使用只理解成"我这次怎么问得更好"。这当然重要,但还不够。更值得问的是,我这次和 AI 协作之后有没有什么东西留下来?有没有一条规则被改写、一个状态被更新、一份材料被整理?如果没有,这次协作再精彩也很难复利。
如果一个人每次都从零开始解释自己是谁、项目是什么、标准是什么、错误在哪里,那 AI 再强,也只能在这一轮里聪明。对话结束,聪明就散了。
真正值得积累的不是某一条神奇提示词,而是那套能被反复读取、修正、复用的外部结构。它可能只是几个 Markdown 文件,也可能是一套更复杂的知识库和工作流。形式不重要,重要的是:它让每一次协作都不只是消耗,也开始留下东西。
这也是我写这个系列的原因。工具本身会变,模型也会变,但“如何把一次次使用变成长期复利”这件事,会越来越重要。
资料来源
- [Cursor Docs, Rules](https://docs.cursor.com/context/rules)- [OpenAI Help Center, Projects in ChatGPT](https://help.openai.com/en/articles/10169521-using-projects-in-chatgpt)- [OpenAI Help Center, Memory FAQ](https://help.openai.com/en/articles/8590148-memory-faq)- [Anthropic Engineering, Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)- [Anthropic Engineering, Equipping agents for the real world with Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills)- [Philippe Laban et al., LLMs Get Lost In Multi-Turn Conversation](https://arxiv.org/abs/2505.06120)- [Drew Breunig, How Long Contexts Fail](https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html)
夜雨聆风