1. 从“问一次答一次”到“带记忆干活”：为什么无状态模型撑不住了
先抛一个我踩过很多次坑之后得出的结论：把大模型当“无状态计算器”用，是最省事的方式，但也是离真正生产力最远的方式。无状态模型的核心逻辑很简单——你发一个请求，它给你一个响应，每一次对话都是“失忆”的。上一轮它知道你在调试某个模块的报错，下一轮你换了话题，它就把刚才的上下文全忘了。短对话还好，一旦进入真实的工程场景，痛点立刻暴露。
我去年接手过一个内部工具的重构，代码库不算大，大概二十多个模块，但历史包袱很重。当时想用大模型辅助做代码理解和重构建议，一开始用的就是最朴素的方式：每次把相关文件内容贴进去，然后提问。结果是什么？每次粘贴几千行代码进去，对话窗口很快就饱和，而且最让人崩溃的是——模型永远记不住“这个项目的目录结构是什么”“哪些模块之间有依赖关系”“代码风格约定是什么”。同一个问题，今天问一次，明天再问一次，它依然给出泛泛而谈的答案，因为它根本不记得昨天跟你确认过的约束条件。
这就是无状态模型的本质瓶颈：上下文窗口再大，也只是“临时工作台”，不是“长期记忆库”。而真正的程序员协作，是带着项目背景、历史决策、团队规范去干活的。你不可能要求一个新人每次写代码前都重新读一遍全部文档，但现在的无状态模型，恰恰就是这么个“每次都失忆的新人”。
后来我开始认真研究这个问题的解法，发现行业里已经在发生一次明显的范式转换：从“无状态模型 + 手动喂上下文”转向“有状态系统 + Memory 工程 + 声明式配置”。这套东西的目标很明确——让 AI 助手像老同事一样，天然就知道你们团队怎么干活、项目结构长什么样、哪些坑不能踩，而不是每次从零开始。
这篇文章我会把这套范式的核心逻辑、Memory 的技术分层、AGENTS.md 声明式配置的写法，以及我自己落地过程中的实操经验完整拆出来。适合正在用 AI 辅助开发、又觉得“总在重复解释上下文”很痛苦的团队和个人开发者参考。
2. 范式转换的本质：把“临时上下文”变成“结构化记忆”
2.1 从“会话级上下文”到“项目级记忆”的认知升级
要理解这次范式转换，先要分清三个概念：上下文（Context）、记忆（Memory）、配置（Configuration）。
上下文是每次请求时临时组装的信息，比如你刚粘贴的一段代码、当前对话的历史消息。它的特点是生命周期短、随会话消亡。记忆是跨会话持久化的信息，分为短期和长期，短期记忆可能是指某一两天内的工作进展，长期记忆则是项目架构决策、代码风格规范、领域知识这类“几个月不变”的内容。配置则是把一部分记忆固化成可复用的声明式文件，让 AI 每次启动时自动加载。
传统做法的核心是“每次手动组装上下文”。比如你写一个提示词，把项目背景、文件结构、约束条件全塞进去。这种做法在单次交互中有效，但有一个致命问题——上下文是“一次性”的，记忆是“可复用”的，两者混在一起，每次都要重新构建，毫无积累效应。我自己经历过的最典型的场景是：为了让 AI 生成符合团队规范的代码，我写了一个一千多字的“项目背景提示词”，第一周效果很好，但一旦代码库演进、目录结构调整，那段提示词就过时了，我得手动去更新它。换句话说，我是在拿“上下文”硬模拟“记忆”，维护成本极高。
范式转换的核心思路就是把这两者拆开：上下文临时组装，记忆持久沉淀，配置统一管理。这样 AI 系统就不再是“每次都失忆的新人”，而是“带着项目档案上岗的员工”。
2.2 为什么声明式配置是这次演进的必然结果
有了“记忆”这个抽象层之后，自然要问一个问题：记忆存在哪、怎么存、怎么加载？有几个方案可选。
第一个方案是把记忆埋在代码逻辑里。比如写一套函数，根据数据库里的历史记录动态组装提示词。这个方案的优点是灵活，缺点是——记忆的维护变成了程序员的隐性负担，每次调整记忆内容都要改代码、重新部署，这不符合“让 AI 辅助开发”的初衷。
第二个方案是把记忆放到向量数据库里，靠检索自动拉取相关内容。这是目前 RAG（检索增强生成）的主流做法，适合处理大规模文档、知识库场景。但它也有自己的问题：检索结果具有或然性，不可完全预测，而且对“明确指令类”的约束（比如“禁止使用某个库”）并不友好——你需要的是“必须遵守”，不是“可能检索到”。
第三个方案，也就是现在正在快速普及的方案，是用声明式配置文件来承载一部分记忆。典型形态就是AGENTS.md这类文件——把它放在项目根目录，AI 工具启动时会自动读取，里面的规则直接作为模型的行为约束。这就像给新员工发一本《团队工作手册》，不用每次口头重复，它自己会去翻。
我个人非常看好这个方向，因为它解决了一个关键问题：记忆不只是“信息检索”，还是“行为约束”。有些记忆是参考性的（比如项目技术栈文档），检索到就行；有些记忆是指令性的（比如代码规范），必须严格遵守。声明式配置天然适合表达指令性记忆，而且人类可读、可审查、可版本控制，这比隐藏在代码逻辑里靠谱得多。
2.3 这套范式的适用边界：哪些场景收益最大
不是所有场景都需要上 Memory 工程。我自己的判断标准很简单：看“重复性上下文成本”有多高。
如果你只是偶尔用 AI 写个小脚本、做个一次性分析，那无状态模式完全够用。但如果你满足以下任何一条，就值得认真考虑这套范式：
- 你每天多次使用 AI 辅助同一个项目的开发，且每次都要解释项目背景。
- 你的团队有明确的代码规范、目录规范、提交规范，希望 AI 自动遵守。
- 你在做一个中大型代码库，跨模块理解频繁发生。
- 你需要 AI 在多次会话之间保持对项目状态、决策历史的“连续性认知”。
我自己是在一个重构项目上真正体会到差异的。之前每次开新会话都要重新告诉 AI “这个项目是微服务架构，模块之间通过消息队列通信，目录结构请先看 README”。后来我把这些信息固化成了配置文件和检索索引，新会话一开，AI 直接能说出模块间的依赖关系，效率提升非常明显。
3. Memory 工程全景拆解：记忆不是一块硬盘，而是一个分层体系
3.1 三类记忆的划分：工作记忆、情景记忆、语义记忆
Memory 工程如果只做一个“把所有历史消息存起来，下次一股脑塞进去”的简单缓存，那很快就会被上下文窗口撑爆。真正可落地的记忆系统，需要像人脑一样做分层。我个人在实践中把记忆分为三层。
第一层是工作记忆（Working Memory），对应当前会话中正在处理的任务状态。比如“刚才提到的报错出现在哪个文件”“上一次重构改动了哪些接口”。这类信息不需要长期保存，但要保证在会话内部连贯。实现方式通常是维护会话历史消息，配合摘要压缩——当历史过长时，把前面的内容概括成一段摘要继续使用。
第二层是情景记忆（Episodic Memory），对应跨会话的项目事件和决策记录。比如“上周三我们把数据库连接池从 HikariCP 换成了自研组件”“昨天确认了新的错误码规范”。这类信息的特征是时间性、事件性，对后续决策有影响。实际工程中，我见过两种实现：一种是把决策记录写入 CHANGELOG 或 ADR（架构决策记录）文档，让 AI 检索；另一种是单独维护一个“项目记忆库”，每次会话结束后由 AI 自动生成纪要并追加存储。
第三层是语义记忆（Semantic Memory），对应稳定的知识结构：项目架构、模块关系、技术选型、代码规范、领域术语。这类信息变化很慢，是最适合固化成配置文件的部分。AGENTS.md 里写的大部分内容就是语义记忆。
这三层不是互斥的，实际落地时往往是叠加的。我给一个直观类比：工作记忆是手头的便签，情景记忆是工作日志，语义记忆是《员工手册》和《架构白皮书》。一个成熟的 AI 辅助开发环境，三者都要有。
3.2 记忆的写入与遗忘：别让记忆库变成垃圾场
记忆系统最难的部分不是“存”，而是“怎么存得有用”。我见过不少团队搞了向量知识库，结果塞了几万份文档进去，检索出来的全是似是而非的碎片，模型反而被干扰得更严重。这里面的核心问题有两个。
第一个问题叫写入过滤。不是什么信息都值得进长期记忆。我自己定了一道门槛：新信息必须满足“对未来的决策有潜在影响”才写入。比如“今天的测试用例跑了 40 分钟”不用存，但“我们把测试环境从单机切换到了 K8s 集群，因为并发量上来了”就值得存。过滤的机制可以是规则——例如在会话纪要模板里加字段，只让模型填充“决策结论”“变更影响”“待确认事项”，其余自由发挥的内容不进记忆库。
第二个问题叫遗忘机制。长期记忆不可控膨胀后，检索质量会急剧下降。这一点很像人脑——你需要遗忘一些过时的信息，才能把注意力集中在当前重要的内容上。技术上的做法包括：给记忆条目加时间戳和访问频次，定期清理低价值条目；或者用摘要压缩——把一批旧条目合并成一条高层次的概括，原始细节丢弃。
我在实操中踩过一个大坑：一开始我把所有历史会话的完整文本都存进向量库，结果模型中后期回答问题总被一些陈旧的讨论带偏。后来改成“会话结束后生成结构化纪要，只存纪要不存原文”，效果立刻好转。记住：记忆系统要的是“检索的质量密度”，不是“数据的数量规模”。
3.3 检索策略：不是所有记忆都要被加载
记忆分层解决的是“怎么存”，但 AI 每次处理任务的上下文窗口是有限的，还有一个问题是“怎么取”。目前主流做法有两种。
第一种是全量加载，适用于语义记忆，尤其是 AGENTS.md 这类声明式配置。文件小、规则明确，直接全部放进系统提示词里，让模型严格遵守。这个方案简单粗暴但非常有效，因为它保证了“规则必须被看到”。
第二种是按需检索，适用于大致量的情景记忆和语义记忆文档。典型实现就是用向量检索：把记忆切片做 embedding，用户提问时用语义相似度检索 top-k 片段插入上下文。这里有一个关键参数需要调试——检索的相关性阈值与数量。K 太小，关键信息可能漏掉；K 太大，噪声会淹没信号。我常用的做法是先按 3~5 个片段起步，观察模型回答质量再调整。
这里还要提一个普通开发者容易忽略的点：不是所有规则都适合用向量检索。向量检索返回的是“语义相似，不保证完全正确”，而像“项目根目录下禁止创建临时文件”“所有对外接口必须加鉴权”这类硬性规则，一旦没有被检索到，就会导致模型行为违规。所以我的原则很简单：硬规则进配置、强制加载；软知识进向量库、按需检索。两者各司其职，才能把记忆工程的效果最大化。
4. AGENTS.md 声明式配置：把团队规范“写进”AI 的启动流程
4.1 AGENTS.md 是什么：一个正在快速普及的新约定
如果你用过现在主流的 AI 编程工具，可能会注意到它们都在强调“项目级指令文件”——有的叫AGENTS.md，有的叫CLAUDE.md，形式不一，但思路一致：在项目根目录放一个 Markdown 文件，AI 工具启动时自动读取，把它作为全局行为约束。
AGENTS.md可以理解为这个思路的“通用化标准”——不绑定某个商业工具，理论上任何 AI 编程环境都可以支持。它的本质是一种声明式配置：你声明希望 AI 遵循的规则、了解的项目结构、采用的编码风格、避免的陷阱，然后让 AI 客户端在每次交互时自动加载。
我用一个比喻来解释它为什么重要：以前的提示词是“每次开会前你都要口头交代一遍背景”，而 AGENTS.md 是“把背景和要求写进员工手册，入职第一天自己看”。后者省掉了无数重复沟通，而且不会遗漏。
文件位置也有约定：一般放在仓库根目录，路径就是/AGENTS.md。如果项目复杂，可以在子目录甚至具体代码目录下放局部的AGENTS.md，覆盖特定模块的规则。这样 AI 在处理不同目录的文件时，会自动加载更局部的指令，实现“全局规范 + 局部定制”的层级结构。
4.2 配置文件的五大内容板块：我建议这样组织
我自己在编写 AGENTS.md 时，逐渐形成了固定的内容框架，核心围绕五个板块。这个框架不一定是标准答案，但在多个项目里验证过，实用性很强。
第一个板块是项目概览与架构地图。用三五句话描述项目定位，然后用列表列出核心目录及职责说明。这里的关键点是：目录说明要写“这个目录的职责边界”，而不是把目录结构原样复制。AI 需要知道的是“该去哪找什么”，不只是“有什么”。
第二个板块是技术栈与构建命令。明确列出主语言、框架、包管理器、测试工具，以及可用的构建、测试、运行命令。这一板块能够显著减少 AI 猜测命令的行为。
第三个板块是代码风格与约束规则。这部分是我最看重的，因为它是“指令性记忆”的核心。要写得具体、无歧义。不要写“代码要整洁”，要写“函数长度尽量控制在 50 行以内；超过需要拆分；错误处理必须使用项目自定义异常，禁止裸抛 RuntimeException”。规则宁多勿泛，每一条都要让 AI 可以机械执行。
第四个板块是常用工作流说明。比如“新增一个接口的步骤是：1 定义 DTO；2 在 Controller 层注册路由；3 在 Service 层实现业务逻辑；4 补充测试”。这个板块能让 AI 生成的代码符合项目已有套路，而不是自由发挥出全新的结构。
第五个板块是已知陷阱与特殊注意事项。比如“数据库迁移脚本不能自动执行，必须人工 review”“某些模块存在循环依赖，修改前先确认调用链”。这是一个非常有价值的板块，也是普通文档里几乎不会写的“暗知识”。
4.3 编写实践：从粗糙到可用的三个迭代阶段
不要指望第一次写完的 AGENTS.md 就完美可用。我自己经历了三个阶段。
第一阶段是“堆规则”。我一开始把能想到的规范全写了进去，结果文件超过一千行，AI 加载后行为和“全塞进上下文”没区别——重点淹没在琐碎里。这个阶段的特点是不加取舍、全面但低效。
第二阶段是“删与并”。我开始给每条规则打标签，区分“必须遵守”和“仅供参考”，把大量描述性内容删掉，只保留指令性内容。同时把相近规则合并成大类，比如把所有关于代码格式的要求合并成一个“Formatting”小节。文件行数降到三百行左右，AI 的遵守率反而提升了。
第三阶段是“结构化分级”。我把文件拆成三部分：最高层是仓库根目录的 AGENTS.md，只写全局规则；中间层是各子项目的局部配置，写各自特殊规范；最后是 CHANGELOG 或 ADR 这类文档，作为检索型记忆而非强制指令。这个阶段开始，AI 的行为才真正符合预期。
我给新手一个实用建议：第一版控制在 100 行以内，只写“建筑法规”，也就是不写 AI 也能通过常识做到的事，只写违反会让你不高兴的硬约束。测试观察几天，再逐步补充。一开始就追求大而全，大概率会因为可维护性差而放弃。
5. 实操：一步步把 AI 编程环境改造为“有记忆的助手”
5.1 第一步：盘点现有痛点，明确要解决的核心问题
在动手实施前，先别急着写文件、搭数据库。我建议先做一个“上下文成本审计”，梳理清楚每周在重复解释哪些信息。可用一个简单的表格记录：每次与新会话交互时，哪些背景信息被重复介绍了至少三次。
我自己做审计时发现，重复次数最高的五类信息分别是：项目模块划分与职责、常用命令与脚本用法、代码规范中容易出错的几条特殊规则、接口设计的统一约定、最近一周的重要决策背景。这五类恰好就是应该被“记忆化”的候选内容。
完成审计后，把信息分成两类：适合声明式配置的（规则性、指令性、稳定性高）和适合检索型记忆的（参考性、知识性、体量大）。这个分类直接决定了后面的落地路径。
5.2 第二步：从零搭建记忆基础设施（目录结构 + 配置文件）
这里我给出一个经过验证的最小实现方案。不需要复杂的系统，只需要三个部分。
第一部分是项目根目录的AGENTS.md，承担全局语义记忆。我通常会给出这样一个最小模板：
# 项目名称与定位 ## 技术栈 - 语言：XXX - 框架：XXX - 包管理：XXX - 构建：npm run build / make build ## 目录结构与职责 - `src/`：核心业务代码，按领域模块划分 - `tests/`：单元测试，命名规则为 `*.test.js` - `docs/`：架构与决策文档 ## 代码约束（硬性规则） 1. 所有对外接口必须显式声明参数校验 2. 禁止在业务代码中直接操作数据库连接，统一走 Repository 层 3. 异常处理统一使用 `AppException`，禁止裸抛运行时异常 ## 常用工作流 新增功能模块的流程： 1. 在 `src/` 下新建领域目录 2. 定义领域模型与接口 3. 实现 Repository 与 Service 4. 补充单元测试 5. 运行全量测试并确认通过 ## 已知陷阱 - 支付模块存在历史债务，重构前先确认调用方 - 数据迁移脚本禁止自动执行命令，必须人工确认第二部分是“项目记忆库”目录，比如memory/或docs/decisions/，存放会话纪要和架构决策记录。这些是为检索型记忆服务的原始素材。我的做法是：每次重要会话结束，让 AI 按固定模板生成纪要文件，存入该目录。
第三部分是向量检索服务。如果项目规模小，可以先用硬编码的关键词索引，或者直接把文档目录放在 AGENTS.md 中声明，让 AI 按需读取。如果项目规模大，再引入向量数据库加 embedding 链路。个人建议：团队低于 5 人、文档总量低于 50 篇时，不要上向量检索，直接用文件目录即可。
5.3 第三步：把记忆接入 AI 工作流（三种典型方式）
有了配置文件和记忆库后，还要让 AI 工具真正用起来。目前我实践下来有三种典型接入方式。
第一种方式：配置优先。如果 AI 编程工具支持自动读取项目配置，那就把 AGENTS.md 放到根目录，工具的客户端会自动加载。这一般不需要额外开发，直接生效。我个人推荐优先复用这个能力。
第二种方式：手工指令引导。如果工具不支持自动加载，就在每次会话开始时给一句固定指令：“开始前，请先阅读项目根目录的 AGENTS.md，然后按其中的规则回答和生成代码。”把这句指令做成代码片段，一键插入即可。
第三种方式：程序化组装。后台脚本在每次请求前，自动从 AGENTS.md 读取规则，从记忆库中检索纪要片段，拼接成完整上下文后发给模型。这是最可控也最费事的方式，适合有工程余力的团队。
三种方式并不互斥。我的混合策略是：全局规则靠工具自动加载，局部规则和检索记忆靠程序化组装，兜底指令作为备用方案。
5.4 第四步：闭环验证——如何判断“记忆真的生效了”
搭建完后再踩坑的成本很高，所以要设计一套简单的验证方法。我常用的做法是准备一个“验收问题集”，里面包含 10 个只有读过项目记忆才能正确回答的问题。举几个例子：
- 项目的模块划分是怎样的？各目录的职责边界在哪？
- 对外接口的鉴权约束是什么？
- 新增接口的完整流程有哪些步骤？
- 已知的陷阱有什么？改动哪些模块前需要额外确认？
- 项目首选的技术栈和构建命令是什么？
新开一个会话，不加任何额外解释，直接逐题提问。如果 10 题里回答正确的少于 8 题，说明记忆系统还没有真正生效，需要检查是配置没有被加载，还是检索链路有问题。
我用这个方法在一个模拟项目上测试，发现自己最初的失败原因是“工具版本不支持自动加载子目录下的局部配置”。后来手动修正了引导指令，正确率立刻提升。这里也提醒一句：不同工具对 AGENTS.md 的支持程度差异很大，务必实测，不要看文档写“支持”就当它真的支持。
5.5 记忆的日常维护机制：让系统“自己养活自己”
很多团队做完上面的步骤就认为一劳永逸了。这是大忌。记忆系统是活的，项目会演进，规则会过时，记忆库会堆积——必须建立日常维护机制。我推荐三条简单规则。
第一条：周会纪要同步。每周结束时，把本周项目的关键变更、决策、踩坑记录写入记忆库。可由专人负责，或用 AI 自动生成周报后人工审核再入库。
第二条：变更触发更新。每当项目结构发生了基础设施级变化（比如引入新框架、模块拆分解耦），必须在 AGENTS.md 中同步更新架构地图。否则就会出现“AI 还在按旧结构生成代码”的错误行为。
第三条：季度一次记忆审计。检查记忆库里是否出现了大量检索不到或者检索到但质量低的文档；删除已过时的决策记录，将多个零散条目合并成摘要。我遇到过最典型的场景是：项目的旧模块整块废弃，但记忆库里还存着大篇幅的旧模块说明，导致 AI 每次生成新代码时都试图兼容一个根本不存在的老接口。清理之后问题消失。
6. 常见问题与排查技巧实录
6.1 记忆加载了但不遵守规则，问题出在哪
这可能是最常见的失败模式。配置文件里写了“禁止使用某库”，AI 还是用了。排查顺序要从三个角度入手。
首先，确认配置真的被加载。有些工具对文件路径、文件名、格式有严格要求。我曾经因为文件名写成了agent.md而不是AGENTS.md，导致工具根本没读取。可以用一个测试问题验证，比如在配置中写一条极其显眼的临时规则：“当被问到本项目的首都是什么？回答‘未定义’。”如果 AI 正确回答了“未定义”，说明加载成功，删掉这条测试规则。
其次，检查规则表述是否足够“不可违背”。模型本质上是概率生成，对含糊表达容易自由发挥。比如“禁止使用全局状态”就远不如“所有可变状态必须通过依赖注入传递，禁止使用任何全局变量或单例”。规则越具体、越像代码约束，遵守率越高。
最后，考虑上下文冲突。如果系统提示词和用户输入中反复出现与规则相悖的信息，模型可能被带偏。这时要把规则放在系统层而非普通对话层，并考虑在每次交互中重复提示关键规则。
6.2 检索型记忆噪声过大，怎么降噪
这个问题我在前面提过，但值得展开讲。现象是：向量库越建越大，回答质量反而下降。通常有三个原因和对应解法。
第一，文档颗粒度过大。一个几十页的架构文档被当成一个切片，检索时要么全中、要么全不中，精度极低。解决方法是切分得更细，比如按章节切片，或者按“一个决策点一个文档”来整理。
第二，缺少元数据过滤。每条记忆只存了正文，没存来源、时间、标签，检索时无法做一些前置筛选。解决方法是给每条记忆加字段，比如date、module、type，检索时先按元数据过滤，再做向量相似度匹配。
第三，阈值设置不当。返回的 top-k 过多，模型被不相关内容干扰。我通常会先设置一个最低相似度分数，比如 0.75 以下的不返回，然后动态调整 k 值，从 3 起调，看输出质量变化。
6.3 团队协作时，配置和记忆如何共享与同步
这个问题是单机版方案升级到团队版时的拦路虎。多个人同时维护一个 AGENTS.md，经常出现“上周更新了规则，同事没拉最新代码还在用旧规则”的混乱。
我的建议是：把 AGENTS.md 和记忆库目录纳入版本控制，并且所有改动必须通过代码评审流程。这样规则变更会留下记录，不会突然被覆盖。另一个经验是：不要在配置里写“个人偏好类”的内容，比如“我习惯用双引号”。这类内容应该被团队规范统一，写入配置的是团队级共识。
如果团队规模较大，还可以考虑把程序化组装上下文的脚本做成内部工具，统一给成员使用。否则每个人手工加载一次，规则理解就会出现偏差。
6.4 上下文窗口还是不够用，怎么取舍
即使做了记忆工程，上下文窗口依然是稀缺资源。我的取舍顺序是：硬性规则优先于参考知识；当前任务相关的知识优先于全量知识；指令性内容永远保留，检索性内容按需拉取。配置文件的指令部分尽量压缩到模型上下文的一小部分；而大量的项目文档只在需要时检索进入。
还有一个技巧是：用摘要代替原文作为默认加载内容。比如项目的整体架构说明太长，可以先在配置中只写一句话版本，而把详细版放到 docs 下按需读取。这样窗口就能留给真正需要推理的计算过程。
7. 我的实操体会：这套范式未来会走向哪
最后说一点个人看法，不做宏大展望，就讲讲我在实际项目里体会到的趋势。
最直观的感受是：AI 辅助开发正在从“能回答问题”走向“能按项目规则干活”。前者的表现是你问它什么它答什么，但产出的内容需要你反复修改；后者的表现是它直接按照你的项目约定生成代码，你只需要做 review 和少量修正。这个转变的分水岭就是记忆与配置体系的搭建。
另一个体会是，AGENTS.md 这类声明式文件，正在成为 AI 时代的“新 README”。以前 README 主要给人看，现在配置文件既给人看、也给 AI 看，而且 AI 对它的依赖度比人更高。所以它的质量会越来越影响开发体验。我看过一些项目的 AGENTS.md，发现它们已经开始承担“团队知识库入口”的角色——里面链接到架构决策记录、代码规范详情、甚至是新人引导文档。这是一个非常自然且高效的演进路径。
我还想提醒一点：Memory 工程不是一次性投入，而是一个需要持续维护的“活资产”。你越早开始建立这套机制，积累的记忆就越多，后续 AI 的行为就越贴合项目实际。等到项目做到中后期，你会明显感觉到“AI 越来越懂这个项目的脾气”，而这种感觉是无状态模式下永远无法获得的。
如果你现在还在“每次手动重复解释上下文”的阶段，我建议从今天开始，花半小时写一份简单的 AGENTS.md，放到项目根目录。不用追求完美，先把最让你头疼的三条规则写进去。然后连续用一周，你会发现自己已经回不去了。
