重复交代技术栈和禁止改动的文件，通常不是因为你没说清楚，而是因为这类约束散落在对话里、没落到可复用的位置。MemoraX Code 这类记忆能力接进需求流程，判断标准只有一条：这条信息下一个需求还要不要用。要用的写进长期记忆，只在本次需求成立的写进当次会话或需求单，别混在一起。写入点一般有三个——开工前交代约束时、执行中撞到可复现的坑时、验收完收尾时；其中开工前那一笔最值得花时间，它决定后面几次协作要不要重来一遍。

值得长期留的是跨需求复用的约束：技术栈与版本、目录职责、禁止改动的文件、接口约定、命名与错误码规则。只对当前需求有效的临时改法、当次调试日志、一次性开关，不建议写入长期记忆。写入点放在开工前、执行中、验收后三处，每次验收后补一条或删一条，再用读取开关控制生效范围与注入量。具体字段名和存储路径以你所用工具的文档为准，先小范围试。

把一次提需求过程拆成写前、执行、验收三段

把一次提需求拆成三段，是为了看清每段产出的信息类型不同，留存价值也不同。写前段产出的是约束类信息，执行段产出的是过程类信息，验收段产出的是结论与遗留项。三段的写入点分别落在需求开工前的交代、执行中出现新事实时、验收通过后的收尾动作。

三段的写入顺序建议不要颠倒：先把写前段的约束落进项目级记忆，执行段只补事实性的例外，验收段做增删。如果一上来就把执行段的临时信息写进长期记忆，后面很难分辨哪条还有效。

筛掉只对当前需求有效的内容

筛选的办法很朴素：问一句“下个不相关的需求还需要这条吗”。答案是否，就不写进长期记忆。下面是常见的几组对照，可以直接照着自己的场景替换。

• 本次临时改动方案（例如为了赶进度先硬编码一个字段）：不写。需求合并后这条就是错的。
• 接口约定与返回结构：写。同一接口在后续需求里会被反复引用。
• 目录规则与文件放置位置：写。新增文件放哪里，是每个需求都会问的事。
• 禁止改动的文件清单：写。迁移中或公共基础文件，改动代价高。
• 当次报错堆栈与调试日志：不写。除非这个错会因同一原因复发，那时写成一句原因加规避方式即可。
• 一次性的开关或命令行参数：不写。长期开关才写，且要标注它控制什么。

写入时用一句话一条，别把一段对话原文贴进去。一条记忆里混了三件事，后面想删其中一件时只能整条删掉，反而更容易留下过期内容。

用配置骨架设定写入与读取开关

接入配置的关键是先把自动写入关掉。自动写入方便，但容易把当次会话里的临时信息一起固化。下面是一份通用骨架，字段名、层级和默认值都需要按实际文档替换，不要照抄字段名。

# 通用配置骨架，字段按实际文档替换
memory:
  enabled: true
  store:
    path: ./.memory/store.json   # 存储位置：项目内随仓库走，或用户级目录跨项目共享
    scope: project               # project | user，按需要选一个
  write:
    auto: false                  # 先关自动写入，避免临时信息固化
    require_confirm: true        # 写入前人工确认
    sources:                     # 允许写入的阶段
      - pre_task
      - post_review
  read:
    enabled: true
    max_items: 20                # 每次注入的记忆条数上限，按上下文预算调
    sections:                    # 只注入这几类，避免无关内容占上下文
      - constraints
      - conventions
      - interfaces
  retention:
    ttl_days: null               # null 表示不自动过期，靠每轮人工复核
    review_after_each_task: true

开关对应的行为要能验证：把 write.auto 设为 false 后，新增一次需求，检查存储文件是否没有自动多出条目；把 read.enabled 设为 false 后，新开会话看是否不再注入约束。存储位置要确认是跟着项目走还是跟着账号走，跟着项目走的内容会进版本库，敏感信息不要写进去。scope 设错会导致换个项目就找不到记忆，或者把 A 项目的规则带进 B 项目。

在同一需求下对比接入前后的重复沟通次数

验证做法是拿同一个需求做对照，而不是看整体感受。选一个中等规模的需求，先按原来的方式走一遍，记录你重复交代了哪些条目；再开一次同样范围的需求（或把同一需求在新会话里重做一遍），让记忆注入生效，记录同样的问题条目还剩下几条。

记录格式建议固定成这样，只做条目计数，不做效率承诺：

需求：列表页增加按时间筛选
重复交代条目（接入前）：
- 技术栈与版本约束
- 禁止改动的公共组件文件
- 接口返回结构与字段命名
接入后仍需要重复交代的条目：
- （逐条勾掉或保留，人工判断）

判断标准是“同一条约束是否还需要在对话里再说一次”，不是“省了多少时间”。如果接入后仍需重复交代，通常是三种原因：这条没写进记忆、写进去了但读取开关没覆盖到、写得太笼统导致模型无法照做。三种原因的处理方式不同，别混着改。

每次验收后补一条记忆或删一条过期记忆

维护动作放在验收这一步，和回归测试一起做，才不容易忘。补写的触发条件通常是：验收时新确认了一条跨需求约定；执行中踩了一个会复发的坑并找到了规避方式；这次需求改变了目录结构或文件职责。删除的触发条件通常是：记忆里提到的文件已改名或删除；接口已下线或返回结构已变更；需求结束，之前为它临时加进记忆的约束已经失效。

每轮复查建议按这个顺序走一遍：打开记忆列表，逐条问“下个不相关的需求还需要它吗”；对需要保留但描述过时的条目，直接改内容而不是再加一条；同一件事出现两条以上时，合并成一条。复查频率可以跟着需求节奏走，一个需求收尾时看一次，几周没有变化就不必强行增减。