你启动了一个编程助手，告诉它需要什么。它搜索仓库，读几个文件，思考片刻，写下修改。

成功了。

打开网易新闻 查看精彩图片

第二天，你让它做类似的事。它又搜索同样的文件，读同样的代码，问你昨天已经回答过的澄清问题。

这慢慢变得烦人。

这就是"记忆"进入视野的地方。但在急着"加个记忆功能"之前，值得先问：记忆对编程助手到底有什么用？什么时候真的有用？

编程助手通常在做什么

编程助手不是只做一件事。它们写新代码、改现有代码、生成测试、重构模块、帮忙处理bug、问题和PR。有些任务两分钟，有些要花一个下午。范围差异很大。

但工作的形态相当一致。

它们怎么做

编程助手处理任务大致是这样的流程：

搜索相关代码

读取那些代码

检查附近的文件和依赖

分析代码在做什么

规划修改

执行修改

审查并验证结果

这就是循环。大多数助手是轮流工作的，但思考记忆时，有用的单位是"任务"。任务是让理解建立、使用、然后要么延续要么丢失的地方。

记忆适合放在哪里

那个循环的前半段——搜索、读取、检查、分析——是助手花时间理解事物的部分。它读文件、追踪依赖、摸清模式、形成内部图景。

记忆就坐在这种理解和下一个任务之间。

它不是聊天的一部分，不在上下文窗口里。它活在代码本身和助手的工作上下文之间，在任务结束后保留有用的东西。

值得保留的东西包括：

关于代码库的事实

用户偏好和惯例

已经做过的决定

已知问题和失败模式

有用的流程和工作方式

这些单独看都是小事，但在多个任务间累积起来就不一样了。

明显的问题：为什么不用Markdown文档？

大多数项目已经有README.md、CONTRIBUTING.md、架构文档和惯例指南。这些文件保存稳定的项目规则，人类容易阅读和维护，存在仓库里，用Git版本控制，每个人看到同样的版本。

所以如果文档已经存在，编程助手为什么还需要记忆？

因为文档和记忆做不同的工作。

文档是以人为中心的。它们存储团队认同为真的事物——架构、惯例、共享定义。它们被设计为持久。但它们在任务期间更新很慢。没人想开个PR只是为了记录"助手搜索辅助函数时应该先看src/utils/"。

记忆是以助手为中心的。它存储助手工作时发现的更小、任务级别的事物。有效的搜索路径。上次绊倒它的文件结构怪癖。