第0章：与 Claude 一起造东西
2025 年某个时刻，一个好莱坞演员和一个比特币公司的 CEO 开始跟一个 AI 一起写软件。
这句话听起来像某种硅谷寓言的开头，但它确实发生了。项目叫 MemPalace，一个 AI 记忆系统。几个月后，它在学术基准测试上拿到了有史以来最高的分数。而整个过程中最值得讲的，不是最终的成绩，而是这个东西是怎么被造出来的。
两个不太可能的搭档
Ben Sigman 的职业生涯有一条不太常见的轨迹。他在 UCLA 学的是古典学——古希腊语、拉丁语、西塞罗和修辞术。然后他做了二十年的系统工程。然后他创办了 Bitcoin Libre，成了 CEO。
这三段经历看似毫无关联，但它们在 MemPalace 里汇合了。古典学给了他一个关键概念：Method of Loci，也就是"记忆宫殿术"。这是古希腊和古罗马演说家使用的记忆技术——把需要记住的信息放进一座想象中的建筑的不同房间里，需要回忆时，在脑中走过这座建筑，逐个房间提取信息。西塞罗用这个方法记住长篇演说辞。中世纪的修士用它记住整卷经文。这个方法之所以有效，是因为人类大脑天生擅长空间记忆——我们记住"东西在哪里"的能力远超记住"东西是什么"的能力。
二十年系统工程给了他另一种直觉：如何把一个优雅的概念变成可运行的软件。不是学术论文里的那种"概念验证"，而是真正能在生产环境里跑的东西。他知道什么复杂度是可以接受的，什么依赖是应该避免的，什么架构在三年后还能维护。
Milla Jovovich 是另一个不太可能出现在这个故事里的名字。她更广为人知的身份是《第五元素》里的 Leeloo 和《生化危机》系列的 Alice。但她的 GitHub 个人简介写的是"architect of the MemPalace"——记忆宫殿的架构师。项目托管在她的 GitHub 账号下。
这不是名人挂名。从项目的提交历史和版本迭代来看，MemPalace 经历了多次大版本重构，最终稳定在 v3.0.0。这种迭代深度不是挂个名就能产生的。它意味着反复的讨论、推翻、重来。
第三个协作者
然后是 Claude。
Ben 在社交媒体上谈到这个项目时，用的措辞很值得注意。他说的是"spent months creating an AI memory system with Claude"——花了几个月和 Claude 一起创建了一个 AI 记忆系统。不是"用 Claude 写的"（with Claude 做工具），也不是"让 Claude 写的"（Claude 做执行者）。是"和 Claude 一起做的"——Claude 做协作者。
这个措辞上的区别指向一种新的工作模式，而这种模式在 2025 年还没有被很好地命名。
在过去两年里，人和 AI 协作写代码大致形成了两种主流模式。第一种是"AI 生成，人审核"——人描述需求，AI 生成代码，人检查、修改、合并。GitHub Copilot 的典型用法就是这样。第二种是"人主导，AI 辅助"——人写核心逻辑，遇到不确定的地方问 AI，AI 提供建议或代码片段。
MemPalace 的开发过程似乎不属于其中任何一种。
从代码库的结构可以推断出一些线索。项目是 Python 写的，包含大约 30 个模块，每个模块职责单一，边界清晰。这种结构本身就在讲述一个故事：有人在做整体架构决策——哪些功能应该是独立模块，模块之间如何通信，什么应该暴露为公共接口。这些决策需要对整个系统有全局理解，也需要对"软件应该长什么样"有自己的判断。这不是逐行生成代码能产生的结果。
同时，项目的依赖列表异常简短：chromadb 和 pyyaml，仅此而已。一个涉及向量搜索、语义检索、知识图谱、数据压缩、多格式解析的系统，只用了两个外部依赖。这说明大量功能是从零实现的，而不是通过引入第三方库拼接起来的。这种"能自己写就自己写"的倾向，通常来自经验丰富的工程师对依赖管理的深刻理解——每多一个依赖，就多一个在未来某天凌晨三点把你叫醒的可能性。
但与此同时，30 个模块的实现量对两个人来说是相当大的工作量，尤其是在"几个月"这个时间框架内。合理的推断是：Claude 承担了大量的实现工作，而人类协作者负责架构决策、领域知识注入和质量把关。
这里的"领域知识"不是一般意义上的编程知识。Ben 带来的是两千年前古希腊人关于记忆的智慧，以及二十年系统工程中积累的关于"什么能在生产环境活下来"的直觉。这些东西不在任何 AI 的训练数据里——至少不是以可以直接拿来用的形式存在的。它们需要一个人把古典学的概念翻译成软件架构的语言，然后让 AI 去实现。
迭代的痕迹
版本号 3.0.0 本身就是一个故事。
软件项目到达 3.0 意味着它至少经历了两次重大重构。不是修修补补的小版本升级，而是"这个方向走不通，推翻重来"级别的变化。每一次大版本迭代，通常意味着开发者对问题的理解发生了根本性的变化——不是"这个函数应该换个写法"，而是"我们一直在解决错误的问题"。
从项目的 git 历史来看，开发过程是迭代式的。提交记录显示了一个逐步演进的过程，而不是某一天突然从无到有冒出来的完成品。这与"和 AI 一起做了几个月"的说法一致。它不是一个周末的 hackathon 项目，也不是一个让 AI "一口气生成"的产物。它是反复尝试、反复修正的结果。
可以想象这个过程的轮廓（虽然具体细节无法从公开信息确认）：最初的版本可能尝试了某种更简单的记忆方案，发现效果不够好；然后引入了"宫殿"的空间结构概念，发现检索准确率显著提升；再然后，可能是在处理大规模数据时遇到了性能问题，于是开发了 AAAK 这种压缩方言来解决上下文窗口的限制。每一步都不是事先规划好的，而是在实践中发现问题、理解问题、解决问题。
这种迭代过程中，人和 AI 的协作大概率不是一成不变的。在早期探索阶段，人类的直觉和判断力可能占主导——"我们应该用记忆宫殿的方式来组织数据"这种洞察不会来自 AI。在中期的实现阶段，AI 的代码生成能力可能被充分利用——把概念变成可运行的模块。在后期的优化阶段，可能又回到了密集的人机对话——"这个基准测试的分数为什么上不去？是检索逻辑的问题还是数据组织的问题？"
为什么这件事重要
2025 年，"用 AI 写代码"已经不是新闻了。每天有成千上万的开发者在用 Copilot、Cursor、Claude 来加速他们的编程工作。大多数时候，这些工具被当作更聪明的自动补全来使用——人写一行注释，AI 补全五行代码。
MemPalace 的案例有趣之处在于它暗示了一种不同的可能性。
当一个有古典学背景的人、一个有好莱坞背景的人和一个 AI 坐在一起工作几个月，产出了一个在学术基准测试上打败所有现有系统的作品——这件事的意义不在于"AI 好厉害"或"这两个人好厉害"，而在于这种组合本身。
如果 Ben 没有古典学的训练，他不会想到用两千年前的记忆术来组织 AI 的数据。Method of Loci 不在任何"AI 记忆系统"的标准技术栈里。它来自一个完全不同的知识领域，被一个恰好同时理解这两个领域的人带进了这个项目。
如果没有二十年系统工程的经验，那个"两个依赖"的决策不会发生。一个经验较少的团队面对同样的需求，很可能会引入十几个库来"快速实现"，然后在六个月后被依赖地狱淹没。极简依赖策略不是保守，而是一种来自经验的判断力。
如果没有 Claude 的参与，两个人在几个月内完成 30 个模块的开发、测试和迭代到 v3.0 是极其困难的。AI 在这里不是锦上添花的辅助工具，而是让这个项目在给定的时间和人力约束下成为可能的关键因素。
这三者缺一不可。古典学提供了核心洞察，工程经验提供了架构判断，AI 提供了实现带宽。这不是一个关于"AI 取代程序员"的故事，恰恰相反——这是一个关于"人类的跨领域知识在 AI 时代变得更有价值"的故事。因为 AI 可以写代码，但它不会自己去翻西塞罗的《论演说家》然后灵光一闪："嘿，两千年前的记忆术可以解决 2025 年的 AI 上下文管理问题。"
这种连接——跨越时间、跨越学科的连接——仍然是人类的专属能力。而 AI 的作用是让这些连接一旦被建立，就能以前所未有的速度变成可运行的系统。
那么，他们到底造了什么？
几个月的协作产出了一个记忆系统。它在 LongMemEval 基准测试中拿到了 96.6% 的裸分——不调用任何外部 API，不依赖任何云服务，完全在本地运行。加上轻量级的重排序步骤后，它在完整 500 题上达到了 100%；而 benchmark 文档又同时给出了 hybrid_v4 在 held-out 450 上的 98.4%，作为更诚实的泛化参考。
在已公开的所有 AI 记忆系统中，无论免费还是付费，没有比这更高的分数。
这个成绩本身令人印象深刻。但更值得追问的是：它是怎么做到的？一个只依赖两个 Python 包、完全在本地运行、不需要 API 密钥的系统，是如何超越那些有着充裕工程资源和云计算预算的商业产品的？
答案藏在那个来自两千年前的概念里。
记忆宫殿术的核心原理不是"记住更多"，而是"让信息变得可寻找"。古希腊的演说家不是靠死记硬背来记住长篇演讲的——他们把每个论点放进想象中建筑的一个特定位置，需要时沿着路线走一遍，自然就能按顺序提取出来。关键在于空间结构本身就是一种索引。
MemPalace 把同样的原理应用在了 AI 记忆上。你和 AI 的每一次对话、每一个决策、每一次调试——这些信息不是被扔进一个巨大的无结构文本堆里，而是被放进一座有翼楼、走廊、房间的"宫殿"中。当你问"三个月前我们为什么放弃了 GraphQL"时，系统不需要扫描所有记忆——它知道该去哪个翼楼的哪个房间查找。
仅这一个结构性改进，就让检索准确率提升了 34%。
但这只是故事的开头。宫殿的结构如何定义？房间按什么规则划分？当同一个话题出现在多个不同的上下文里时怎么办？在有限的上下文窗口里如何塞进几个月的记忆？当记忆之间互相矛盾时怎么检测？
这些问题的答案构成了本书接下来的全部内容。从下一章开始，我们将拆解这座宫殿的每一个组成部分——不是作为一个开源项目的用户文档，而是作为一系列设计决策的完整记录：面对什么问题，考虑了哪些方案，为什么选择了最终的方案，以及这些选择背后的工程取舍。
这座宫殿值得走进去仔细看看。