Twin：一种可能的 AI 上下文重建解决方案

在过去的几个月里，我意识到自己花了大量（且荒谬的）时间和金钱，一遍又一遍地教 AI 相同的内容。关于我项目的信息早已存在。Slack 里包含讨论和决策。GitHub 里包含提交和拉取请求。会议、邮件和文档都记录了同一个故事的不同片段。然而，每次我与 LLM 开始新的对话时，我都要重新收集这些片段，并将它们注入提示词中，让模型重建一个昨天已经存在的理解。某个时刻，我不再问如何检索多个上下文片段，而是开始问一个不同的问题：软件如何随时间形成、修订和复用理解？这个问题促使我开始构建 Twin，一个开源工程研究项目，探索如果 AI 系统持续构建理解而不是在每次对话中从头重建，会发生什么。 大多数现有项目似乎在优化检索、记忆或上下文构建。Twin 探索的是流水线的不同层面。它持续观察分布式事件，对它们进行关联和反思，并形成可复用的情境模型，成为可复用的计算理解。Twin 不是将一批 Slack 消息、拉取请求或文档交给下游语言模型，期望它们自己串联起来，而是提前完成这项工作。 我最近达到了第一个里程碑，它真正让我相信这个方向可能是可行的。使用 Claude Sonnet 4.6，Twin 持续处理了一个公开软件项目中的 GitHub 活动和 Slack 对话，通过随时间推移的反思来关联事件并构建理解。之后，我开启了一个全新的 Claude 对话。Claude 没有自定义记忆、没有项目特定规则、没有描述仓库的提示词，也无法访问本地项目文件。唯一可用的集成是 Twin 的 MCP 服务器和自动上下文注入。当我询问有关项目的问题时，Claude 并没有收到 Slack 消息或拉取请求，也没有自己去推断情况。Twin 已经综合了这些理解。Claude 解释了为什么某个功能会成为发布阻塞项、它是如何实现的、哪个拉取请求解决了该问题，以及这如何改变了项目的状态，尽管这些关系在任何地方都没有被明确写出来。 第一次看到它奏效，彻底改变了我对 AI 记忆的看法。我不再认为真正的问题是记住更多内容。我认为关键在于将理解向前传递（也就是认知连续性）。如果你对这个想法有共鸣，所有内容都是开源的，评论区见。过去三周我几乎只想着这件事，因为我真心相信这个方向有潜力改变我们构建 AI 系统的方式。README 更深入地解释了动机和研究假设，仓库中还包含了这里展示的完整演示，以及更多细节和技术背景。我真心希望听到你的想法，尤其是如果你认为我错了的话。