Phase 4 / Ep 18: 心智模型（双向同步冲突决断）

⏱ 预计阅读 3 分钟 更新于 2026/4/13

我们要跨入一个大坑：如果一件事，同时在你的 T-Block 系统和 Google Calendar 系统被改动了，听谁的？

这在工程学属于**分布式数据一致性（Eventual Consistency）**难题。普通水平的大模型面对复杂业务分支往往一到这就烧断神经，写出充满无数 if-else 的死循环。

1. 把战线拉回 findings.md 辩论区

代码写不好，不是因为技术差，而是因为业务流不清晰。我们要命令这位极客架构师必须停止手里的编码（键盘），再次回到白板前。

“我们来到了深水区。关于日历事件的同步冲突，请不要直接写判断逻辑。现在你需要对 T-Block 采用的冲突策略做彻底分析推演。目前摆在我们面前有三个流派：1. LWW (Last Write Wins 时间戳绝对后写入者赢)；2. Local Win (永远以 T-Block 手改优先)；3. Remote Win (永远以 Google 为真理)。

作为系统极简主义者，请分析给出最推荐的一项。并作为正式仲裁法典写入 docs/findings.md，并在其中给出一个代码处理流程草图（伪代码）。”

2. 来自赛博大脑的仲裁报告

Agent 在经历了深度的演算后，会将仲裁发还给你。 通常一个好的模型它会在这时否掉盲目的 LWW，因为它会指出：“很多时候移动端日历修改在断网重连后上传的时间戳有极高的误判率”。

由于 T-Block 是依托于 Google 体系的，它往往会得出这样一份精彩记录并在硬盘保存：

# [设计决断] 冲突策略仲裁定音
**结论决议：采用 Baseline Remote Wins 伴有 Local Revision Tag。**
一切主键及宏观变动（改日期、改时间）强制以 Google API 侧发来的数据为主骨干（真理源）。但本地产生的详细 Task Description 切分，被存入在专属扩展 JSON 字段中。合并时，只有基础时间信息会被 Google 强行覆盖。

3. 把决议铸为代码的脊梁

当人类说出了一句：“Approve（赞成）”之后。

这个决议立刻生效了。我们在下一轮开启代码编写要求时，Agent 再去写 syncLocalToRemote() 这个极其复杂的聚合函数时，就不会像个无头乱撞的苍蝇，它会极其忠实地围绕**“Remote Win”**作为一切的兜底 catch 与对象融合（Object Merge）的根逻辑。

这样写出来的代码体系，干净、防弹，且能被清晰追溯。