READ · UNDERSTAND · TRANSFER
阅读理解，按需巩固
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 记忆冲突中的对象、来源与双时间
先理解核心原理
先备概念：事实对象与属性、版本和来源、业务有效时间
两条记忆只有在同对象、同属性、同作用域和重叠有效时间内相反，才形成冲突。记录时间不能替代业务生效时间，相似度不能裁决事实。
先问它们是否真在说同一件事
“项目 A 用 Java”与“项目 B 用 Go”不冲突；“去年用 Java”与“今天迁到 Go”也不冲突。直接选最新或最相似，会把对象或时间维度抹掉。将对象、属性、作用域和有效区间结构化，先筛适用事实，再判断是否矛盾。
两种时间对应两种问题
观察时间是系统何时得知，业务有效时间是事实何时成立。今天导入去年的会议记录，不会自动成为今天的项目配置。双时间建模可回答“当时真实情况是什么”与“当时系统知道什么”，但并非所有偏好都需要完整历史系统；有补录、审计或历史问答时才值得承担复杂度。
冲突裁决要有可解释依据
优先考虑明确更正、领域权威来源、验证程度和适用时间，而不是统一让最新记录赢。用户能确认个人偏好，组织规则要来自可信配置，工具状态可能需要重新读取。若两条都可靠且同范围冲突，保留待确认状态，向用户展示具体分歧。拼成折中答案可能创造第三个无来源事实。
历史可查与当前可用不同
旧值可能对历史问答仍有意义，但撤销或删除改变的是当前读取权限。历史版本存在不代表允许展示；须按当前授权和保留策略检查。已依错误事实执行的动作也不会因改写记忆自动撤回，需要单独对账或补偿。反例是把新认知写回旧记录后，审计再也解释不了当时为何做出决定。
回到问题：怎样回答？
不能只按最新时间或向量相似度裁决。先检查事实是否描述同一对象、同一属性和同一有效时间，再考虑来源、明确修正与可信程度。保存观察时间和业务有效时间，区别“今天才知道的旧事实”和“今天生效的新事实”。无法消解的冲突应保持多个候选并澄清，不能拼出第三个没有来源的结论。
实现与取舍
冲突的定义
“用户以前用 Java”和“现在用 Go”并不冲突；“本项目使用 PostgreSQL”与“另一个项目使用 MySQL”作用域不同。先按实体、属性、项目和有效时间归一化。相似度只能帮助找到相关记录，不能判断真伪。模型抽取时也应保留条件与否定，避免制造虚假冲突。
两条时间线
observed_at 表示系统收到信息的时间，valid_from 和 valid_to 表示事实何时有效。迟到的历史记录不应覆盖当前状态。用户明确纠错优先于旧推断，但若涉及组织政策，需要区分个人陈述和权威制度来源。来源优先级是应用规则，不应由每次模型生成临时决定。
合并和并发写入
对同一主体属性建立版本号或条件更新，防止两个异步写入互相覆盖。保存冲突关系与 supersedes 引用，读取时按当前任务时间和作用域构造视图。重要字段可在冲突时暂停自动应用并要求确认，例如发票抬头或对外联系人，不能随机选一条“看起来更合理”的记录。
验证时间与来源规则
按乱序投递旧事实、新事实、纠错和撤销，检查最终有效视图一致。再测试历史查询，例如“上个月使用哪个数据库”，确保系统不会把当前值套到过去。说明保留历史与删除请求之间的处理边界：历史可追溯不代表已撤销内容可继续被模型读取。
工程推演
- 场景
- 面试假设：一条旧项目配置今天才导入，与上周确认的新配置相反。
- 设计决策
- 记录有效时间与来源，迟到旧记录不覆盖当前配置。
- 验证目标
- 当前查询用新配置，历史查询能按时间解释。
- 适用边界
- 权威来源优先规则需在业务层明确。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层最新导入的一定最新有效吗？
从冲突表面进入时间维度的区别。
参考解答
不一定。导入时间是系统记录时间，文档可能描述过去事实或未来计划。保存业务有效区间与来源版本；不知道时不要宣称当前有效。排序可用新导入作为复核线索，但不能让它推翻明确的当前修正。对重要事实重新查权威来源。
沿着这个回答继续深入
第 2 层今天确认“上月已经迁到 Go”，应改掉所有旧记录吗？
父问区分两种时间后，进一步面对追溯更正。
参考解答
更新目前对上月有效事实的认识，但保留必要的记录视角，不能伪装成系统上月就知道。将更正关联到被纠正事实，保存有效时间和得知时间。只需当前记忆的产品可以使旧值失效；需审计的系统要能解释当时基于什么输入执行。
沿着这个回答继续深入
第 3 层上月已按旧事实执行任务，更正记忆是否自动修复了结果？
追溯更正产生下游影响，揭示数据修正与业务副作用的区别。
参考解答
没有。记忆更正只改变后续依据，已发送邮件、生成报告或外部修改仍是发生过的事实。通过依赖记录找受影响产物，核对是否需要重新生成、更正通知或业务补偿；这些动作按当前授权执行，不能把历史状态重写成从未出错。
第 1 层同一用户不同项目的技术栈如何隔离？
相反描述可能来自不同对象，先隔离再裁决。
参考解答
按项目资源 ID 建作用域，并在检索前确定当前项目。个人熟练语言和项目生产技术栈分属不同属性，不能相互覆盖。问跨项目对比时分别读取已授权事实并标明项目；当前项目不明确时澄清，不能取向量最相似的一条当全局事实。
第 1 层撤销以后还能为了历史查询展示吗？
事实的历史成立与当前读取授权是两条独立轴。
参考解答
只有业务保留策略允许且当前身份仍获授权时才可展示历史。删除或撤销可能禁止再使用，即便历史查询指定旧日期也不能绕过。允许的审计读取应独立鉴权和记录，面向普通用户的记忆服务不要自动开放旧版本。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
补录过去配置
改变的条件：今天才收到上月的更改记录
延伸问题：回答上月项目配置，应信当时缓存还是补录记录？
推导与参考解答
先确认用户问“上月实际配置”还是“当时系统知道的配置”。前者按目前已核对的有效历史回答，后者按当时记录视角回答并说明后来更正。若没有完整历史来源就保留不确定性，不能用今天状态倒推上月。
保持不变的原理：记录时间与有效时间对应不同查询，不能互换。
两份工具结果相反
改变的条件：来源都可信，但读取时间不同
延伸问题：最新读到的权限能替代旧任务里的批准吗？
推导与参考解答
当前权限可决定能否继续访问，却不能证明旧批准覆盖新动作。分别检查权限现在有效、批准对象及版本仍匹配，以及外部对象是否变化。不能将多个事实混为一个“最新状态”；缺少任何关键条件都暂停对应动作。
保持不变的原理：各事实有自己的对象与有效范围，可信来源不会自动建立跨事实依赖。
易错点
- 相似度最高即真实
- 只存一条更新时间
- 合并时丢掉来源与条件
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 知道先按对象、属性、作用域和有效时间判断是否冲突。
- 中高级信号
- 能分别建模观察时间和有效时间，并记录明确纠错关系。
- 资深信号
- 用乱序事件测试并发、历史视图和撤销边界。
巩固练习 按需完成 · 建议 15 分钟
给三条乱序到达的数据库配置记录，推导当前值和上月值。
展开验收要求与检查点
- 观察时间不冒充生效时间
- 不把不同项目混合
- 无法裁决时保留冲突
重点检查
- 按作用域判断是否真冲突
- 区分观察时间与有效时间
- 并发更新和纠错可追溯