OpenCode 记忆插件加入冲突审查机制

项目记忆积累得越久，AI 就越了解项目吗？未必。旧假设、重复规则和彼此冲突的约定，也可能一起被保留下来。OpenCode Plugin Memory v0.2.0 要解决的，就是记忆写进去之后由谁维护、怎样淘汰的问题。

这个版本的选择很明确：后台可以找出疑点，但不能直接改记忆；替换旧条目时，要把新旧关系记录下来。它值得关注的地方，是给持久记忆补上了一套可检查、可追溯的维护流程。

记忆需要替换，不能只管追加

原文指出了项目记忆的三类问题：过时的假设、重复的规则，以及不容易察觉的矛盾。它们有时可以同时存在。例如，一条旧约定还留在文件里，后来又追加了另一条做法，AI 读到的就不再是一份明确的项目规范。

v0.2.0 为此加入了原子替换（atomic superseding）：添加替代记忆与归档旧记忆一起完成。重点是把「新规则接班」和「旧规则退役」作为同一次操作处理，避免维护时只完成其中一半。

归档也不只是把内容挪走。新增的归档元数据会记录条目为什么退役，以及由什么条目替代。后续排查时，至少能沿着这些信息追问：这条规则为什么失效，现在该看哪一条？

不过，原文没有解释原子操作的具体实现，也没有交代异常中断时如何恢复。这里能确认的是功能设计，不能据此推断它已经提供了哪种数据库级事务保证。

后台负责找疑点，主会话负责改记忆

这次更新增加了受限的后台审计，可以识别三类候选关系：重复、细化和矛盾。

「细化」和「矛盾」需要分开理解。新条目可能只是给旧规则补充条件，也可能真的要求采用相反的做法。找到两个相关条目，并不等于已经知道应该删掉谁。

后台审计只把发现写入 review.json，绝不修改 MEMORY.md。

更新、替换还是归档，仍然由主会话决定。这条边界把发现问题与修改长期规则分开了，也限制了后台判断出错后的影响范围。

配套的 memory_review 支持按需刷新，以及驳回审计发现。如果底层记忆发生变化，之前的驳回会失效。这个设计有实际意义：一次判断只对当时的内容负责，不能因为曾经驳回过，就让之后变了样的条目一直绕过复查。

记忆的存储形式没有随之变复杂：它仍然限定在项目范围内，以人可读的 Markdown 保存，没有引入向量数据库，也没有隐藏的自动归并流水线。

我的判断

我认可它对修改权限的克制。项目记忆会影响后续 AI 编程行为，后台把「疑似矛盾」直接处理成「删除旧规则」，中间跨过了一个需要上下文判断的步骤。保留审查入口，通常更方便追责和纠错。

相比只往 MEMORY.md 追加内容，这套设计补上了退役理由、替代关系和复查入口；相比自动归并，它把最终决策留给主会话，代价则是仍然需要投入审查精力。主会话也不等于人工确认，原文没有说明是否要求用户逐项批准。

这是一份功能发布说明，没有提供审计准确率、误报率、维护耗时或对照实验。因此，「更容易追踪记忆变更」有明确的设计依据，「能显著提升 AI 编程效果」则还缺证据。Markdown 方便阅读，也不代表审计一定能理解复杂的项目约定。

能拿来做什么

• 如果你在 OpenCode 中使用项目记忆，修改前端构建约定或 Node 运行规则时，可以关注替换与归档能力，给旧规则留下退役理由和替代去向。
• 检查审计发现时，先区分重复、补充条件和真正冲突，再决定是否更新记忆，避免把适用范围不同的约定误删。
• 项目约定调整后，可以通过 memory_review 按需刷新；底层记忆变化会使旧驳回失效，此时应根据新内容重新判断。
• 如果准备采用这个插件，先用自己项目中的已知冲突检查审计结果。原文没有给出效果数据，是否省事需要结合实际记忆内容验证。