- 01定义确定参与者、作用域、持久结论与禁止保存内容。
- 02验证用真实且脱敏的轨迹测试写入、修订、召回与删除。
- 03发布把质量、延迟、失败和回滚加入发布门槛。
- 01客服上下文
- 02编码项目知识
- 03偏好与日程
- 04长期关系连续性
一个好用例必须说明谁拥有记忆、何时写入、怎样修订，以及错误召回会造成什么后果。
客服要记住已经解决的事。
保留客户偏好、历史结论与有效解决方案，但把工单原文和知识库放在来源层。错误记忆必须能追到证据并被修订。
- 按客户与账户划分作用域。
- 区分已验证结论与模型推断。
- 删除与合规请求覆盖相关记录。
编码助手要记住为什么。
长期项目需要架构决策、约定、过去修复和未解决约束，而不是把整个 Git 历史塞回提示词。
- 项目命名空间避免跨仓库污染。
- 来源链接保留决策依据。
- 过时约定通过替代历史关闭。
个人产品要尊重变化。
偏好、位置、计划与关系会变化。双时间记录让当前回答使用有效事实，同时允许历史问题检查之前状态。
- 不要从弱证据推断敏感属性。
- 为用户提供可见、可改、可删的记忆控制。
- 用最小必要上下文降低陈旧事实影响。
这个产品范围包含什么
- 针对多种产品形态的作用域与写入模式。
- 记忆、文档、时间状态和检索跟踪。
- 从测试轨迹到发布门槛的评估方法。
明确边界
- FishMem 不替应用决定内容政策或用户同意。
- 高风险领域需要额外人工与法规控制。
- 公开用例不是客户案例，也不是效果保证。