北京
你启动了一个编程助手，告诉它需要什么。它搜索仓库，读几个文件，思考片刻，写下修改。
成功了。
第二天，你让它做类似的事。它又搜索同样的文件，读同样的代码，问你昨天已经回答过的澄清问题。
这慢慢变得烦人。
这就是"记忆"进入视野的地方。但在急着"加个记忆功能"之前，值得先问：记忆对编程助手到底有什么用？什么时候真的有用？
编程助手通常在做什么
编程助手不是只做一件事。它们写新代码、改现有代码、生成测试、重构模块、帮忙处理bug、问题和PR。有些任务两分钟，有些要花一个下午。范围差异很大。
但工作的形态相当一致。
它们怎么做
编程助手处理任务大致是这样的流程：
搜索相关代码
读取那些代码
检查附近的文件和依赖
分析代码在做什么
规划修改
执行修改
审查并验证结果
这就是循环。大多数助手是轮流工作的，但思考记忆时，有用的单位是"任务"。任务是让理解建立、使用、然后要么延续要么丢失的地方。
记忆适合放在哪里
那个循环的前半段——搜索、读取、检查、分析——是助手花时间理解事物的部分。它读文件、追踪依赖、摸清模式、形成内部图景。
记忆就坐在这种理解和下一个任务之间。
它不是聊天的一部分，不在上下文窗口里。它活在代码本身和助手的工作上下文之间，在任务结束后保留有用的东西。
值得保留的东西包括：
关于代码库的事实
用户偏好和惯例
已经做过的决定
已知问题和失败模式
有用的流程和工作方式
这些单独看都是小事，但在多个任务间累积起来就不一样了。
明显的问题：为什么不用Markdown文档？
大多数项目已经有README.md、CONTRIBUTING.md、架构文档和惯例指南。这些文件保存稳定的项目规则，人类容易阅读和维护，存在仓库里，用Git版本控制，每个人看到同样的版本。
所以如果文档已经存在，编程助手为什么还需要记忆？
因为文档和记忆做不同的工作。
文档是以人为中心的。它们存储团队认同为真的事物——架构、惯例、共享定义。它们被设计为持久。但它们在任务期间更新很慢。没人想开个PR只是为了记录"助手搜索辅助函数时应该先看src/utils/"。
记忆是以助手为中心的。它存储助手工作时发现的更小、任务级别的事物。有效的搜索路径。上次绊倒它的文件结构怪癖。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
