Theo 为什么反对编程智能体自动保存记忆

编程智能体需要了解代码仓库、文件位置和工作方式。许多系统试图自动保存这些上下文供后续会话使用。我怀疑单独的记忆库是否适合存放不断变化的代码库事实。

我先看一段 Pi 创建者 Mario 和 Flask 创建者 Armin 的对话。他们关于记忆和精简工具的讨论促使我检查自己的 Claude Code 配置，并解释我更愿意在项目指令中放些什么。

Mario 认为代码是事实来源，而且会不断演变。单独的记忆系统又增加了一处需要维护的地方。我同意：即使普通注释也可能在代码变化后变得有害，因为它仍会告诉读者或智能体旧的信息。

维护的知识副本越多，就越容易出现偏差。旧计划和 Markdown 文件可能在假设早已失效后仍留在仓库中，而这些过时上下文可能把智能体引向错误方向。

Mario 认为模型可以从相邻代码推断风格，简短的目录地图则有助于导航。他对没有评估证明能改善输出的复杂检索系统持怀疑态度。这是他的观点，并非对所有检索方法的受控测试。

我把这与 Cursor 等编程工具的演变作比较。早期工具投入大量精力为模型收集上下文；较新的编程智能体则可以使用命令行和文件工具自己寻找相关代码。我更倾向于提供有用的工具，而不是假定复杂索引是必需的。

Mario 描述了一个 Slack 机器人，它用 jq 搜索只追加的提示和响应日志。机器人不必依赖单独维护的摘要，可以查找底层记录。这个例子也说明，对话历史和不断变化的代码仓库是不同问题。

我认为在一般聊天中，记忆可能比在编程中更有用。个人问题可能与先前看似无关的细节有关，而代码通常有明确的路径和引用可以调查。不过，个人上下文也可能让回答过度受无关历史细节影响。

Pi 的讨论接着谈到小工具与命令行组合。Armin 介绍了自己制作的 Sentry skill：它按他喜欢的方式认证，把结果下载为 JSON，只向模型展示少量样本，同时保留按需查看其余内容的能力。

我认同控制工具输出量的价值，但不太相信每次集成都需要新建一个 skill。强模型通常可以使用普通工具并决定读取什么。合适的方法应在工作流程中评估，而不是由名称决定。

我询问 Claude Code 保存了哪些关于 T3 Code 的信息。一台机器上，它报告只有一条关于功能规格的记忆，而我甚至不打算发布这个功能。这让我想知道其他地方还保存了哪些临时细节。

在另一台机器上，清单覆盖多个项目目录，包括配置实验、基准测试、计划和项目的记录。有些信息当时可能有用，但如果状态已经变化，就可能误导后续工作。

智能体的清单显示，T3 Code 主克隆有 45 个记忆文件，其中包括引导流程和设计工作。我询问智能体哪些条目现在仍有价值，因为我担心的不只是数量，还有旧记录是否仍准确、相关。

智能体估计这 45 个文件中约三分之一仍有用。它把其他条目归为与 AGENTS.md 重复、描述已发布功能，或记录可能已变化的时间点状态。这是智能体对我自己文件的评估，而不是独立研究。

我查看了一些例子：已经解决的 CLI 问题、旧计划以及探索某个集成时留下的记录。有些条目记录了一次调查的细节，却没有说明现在是否仍然成立。其中一条 worktree 警告可能仍有用，这也说明并非每条记录都一样差。

其他记忆描述了某次开发期间 T3 Connect 的工作方式和可能的状态冲突。我能推测智能体为何写下它们，但不确信它们适合放在可能影响后续工作的持久存储中。

我决定让自己的机器归档现有记忆并关闭该功能。这是针对我自己工作流程的选择；读者在更改或删除可能需要的信息之前，应检查自己的情况。

智能体的记录审计报告称，在该机器约 355 个 T3 Code 会话中，19 个打开过单条记忆文件，约 80 个写入或编辑过记忆。它还说，45 条记忆中有 26 条创建后从未被读取。这些数字只描述该本地样本和方法，不能证明记忆对所有用户的价值。

我希望得到什么？两件相关但不同的事情：减少可以避免的错误，以及让智能体不需要提示中的每个细节就理解我的方向。我不认为不加区分地保存更多记忆能可靠地同时做到这两点。

每次出错后增加一条“不要再这样做”的规则可能有帮助，但值得退一步思考。真正的问题可能是沟通不清、架构不直观，或团队与智能体对产品的理解不一致。

我更喜欢用指令传达希望智能体如何思考，以及团队重视什么。当智能体理解方向后，我发现许多小错误也会减少。这是我自己工作流程中的观察，并非保证。

Lauren 提出一个防止重复错误的顺序：先通过架构或数据结构消除故障；然后用 lint 规则或测试；再考虑 skill 或规则；最后依赖人工审阅。我喜欢用这个顺序思考哪一层能够防止问题。

例如，我重视 tRPC 和 Convex，因为共享类型和架构可以消除某些前后端不匹配的问题。让代码库更容易供人类贡献，也可能让智能体更容易安全地导航和修改。

如果仅靠架构无法防止回归，就让 CI 能发现它。T3 Code 有一个具体性能问题：通过 WebSocket 加载线程要传输几十兆字节，在手机弱网或飞机网络上尤其难受。

我降低了传输量，并用大型示例线程建立本地重放测试，但几天内又出现回归。因此我加入了 CI 测量，重放 Codex 和 Claude 的线程，并让 PR 评论显示变更带来的影响。

优化后，这些示例的传输量稳定在 100 KB 以下，大多数不到 10 KB。我把上限设为比优化基线高约 30%；超过就让检查失败。我看到它捕获了真实回归，并在智能体报告完成前给出反馈。

我的偏好是在增加其他 skill 或规则前，尽量用好架构和自动测试。对于难以直接在代码库表达的流程，例如远程暴露开发服务器，skill 可能有用。它是后备方案，不是设计的万能替代品。

自动方法不足时，人工审阅仍是另一层保障。我也用同样的思路考虑可能的 SwiftUI 重写：现有的 Web、Electron 和 React Native 端共享 TypeScript 数据加载代码，而单独实现可能出现偏差。

以我的经验，SwiftUI 应用已经因为这种共享关系不那么直接而出现过回归。我们暂时没有合并一个我原本喜欢的版本，因为这种架构取舍可能让共享实现目前避免的错误再次出现。

Theo 播放了 Uncle Bob 的一段讲话：他认为人的价值观对智能体很重要，即使机械地施加人的工作纪律未必合适。我喜欢这种表述：传达我们关心的结果与标准，再考虑智能体如何实现。

我的 T3 Code AGENTS.md 从产品是什么、服务器如何包装供应商 CLI 并服务 Web、桌面和移动客户端开始。我希望智能体理解产品，而不仅仅是它正在编辑的文件，这样提出的建议才能符合项目方向。

文档还列出原则：保持项目开放、保护性能、支持远程使用，以及照顾所有端。我观察到，性能提醒减少了一些回归，CI 则捕获其他问题。这是我在这个项目中的经验。

远程可用性很重要，因为一项修改可能通过本地桌面测试，却在网页或手机上失败。明确列出所有端，能提醒贡献者和智能体检查眼前环境之外的行为。

我加入了个人说明、共享术语表，以及关于可能中断开发所用服务器的操作警告。术语表帮助人和智能体使用同样的词，而具体警告针对的是我实际遇到过的问题。

其他章节涵盖开发服务器、代表性测试数据、验证、PR 和代码位置。“品味”章节记录了复杂度应该放在哪里、避免不必要的类型，以及让注释与所描述代码保持同步等偏好。

目标是让智能体足够理解你的意图，从而能适时建议相关工作或提出异议。在我的工作流程中，精心编写的项目上下文比我检查过的自动记忆更有帮助。

每个新线程开始时都没有先前对话，因此持久上下文需要以某种方式提供。我的建议是把重要目标和当前项目事实放在可以维护的地方，而不是假设自动保存的笔记会一直有用。尝试并观察什么适合你的团队。