今天做笔记漫读，看了下我之前写的一篇文章Web端版本更新弹窗实现，看到消息推送相关内容，我就想到最近在看的 RSS 推送和订阅的实现，也是做轮询，然后差异对比，更新，看起来技术方案上是有交叉的。再联想到最近在做的 app 应用更新方案和涉及到的文件 diff，好像都有着类似的逻辑。那么能不能抽成一个模型呢？后续实现类似的需求都共用这套实现模型，微调即可快速复用。下面是我的一些想法，后续可以按需做成规则、skill 或者成为 harness 的一部分。

模型概述

上面提到的几个需求场景，本质都在回答三件事：

  • 如何发现更新
  • 如何判断差异
  • 差异出现后如何处理

进一步展开，还可以变成五层：

  • 更新发现层：轮询、长轮询、WebSocket、SSE、Push
  • 状态描述层：版本号、feed、manifest、文件 hash
  • 差异判断层：版本级 diff、条目级 diff、文件级 diff、内容级 diff
  • 动作执行层：弹窗、发消息、下载、安装、回滚
  • 用户交互层：是否提示、何时提示、能否稍后、是否自动执行

上面的几层里面，更新发现层的方案是可以固定的，无论是产品更新、订阅更新还是 diff，都需要去发现更新，发现更新无非就分为两种情况：服务器是否有更新、本地是否有更新，要知道是否服务器更新可以客户端定时轮询或者是服务端推送消息，要知道本地是否有更新，可能就是文件或者内容监听。方案就那么几种，可以做选择题。

状态描述层也相对比较固定，比如网页更新可能是简单的版本号对比，应用更新可能就是 manifest + hash，然后 RSS 就是订阅源信息，本质上也是做选择题。

差异判断层的方案同样可以做选择题，后面的两层可能就需要按需调整，所以我觉得这套模型用于解决这些类似场景的需求是可行的。

下面是是一些使用这个模型的一些落地问题分析。

更新方案如何选择

要回答这个问题，应该先理清楚：要检测的是版本差异、文件差异，还是内容差异？

这些差异粒度，决定了状态描述层要存什么、差异判断层要怎么比，进而才能倒推更新发现层用什么机制合适。把这个顺序搞反了，很容易出现技术选型过重或过轻的问题——用了 WebSocket 但其实只需要每小时轮询一次，或者只比了版本号但其实需要精确到哪几个文件变了。

每种需求的落地点的差异

这套模型在不同场景里落地的方式不同，但本质结构是一样的：

场景 差异粒度 状态描述 更新发现 执行动作
Web 版本更新 版本级 版本号字符串 定时轮询 弹窗提示刷新
RSS 订阅 条目级 feed + entry id/时间戳 定时轮询 / Push 新增条目推送
App 更新 文件 / 块级 manifest + hash 启动检测 / 推送 下载 + 安装 + 回滚
git diff 内容级 commit hash / 行级内容 本地触发 展示差异本身

横着看是同一套结构，竖着看是四种粒度选择。Web 版本更新最轻，只需要知道”有没有变”就够了；git diff 最重，重点在于精确表达”哪里变了”。两者都能纳入同一个模型，只是在每一层上的选项不同。

App 更新是其中最复杂的一个，因为它横跨了所有五层，而且每一层都不能出错——发现慢了用户体验差，状态描述不准会触发不必要的更新，diff 粒度不够则无法做增量更新，执行层没有回滚机制就容易翻车，用户交互层没设计好则很容易引发投诉。

怎么用这套模型

当拿到一个类似需求时，可以按顺序问这四个问题：

  • 只需要知道”有没有变化”：版本号 + 轮询就够了，不需要搞 WebSocket，也不需要内容级 diff。

  • 需要知道”具体哪里变了”：从版本级 diff 升级到条目级或文件级，状态描述层也需要升级。

  • 需要”自动应用变化”：动作执行层的复杂度会显著上升，下载、校验、安装、回滚都需要考虑。

  • 失败后要回滚：diff 粒度和执行层都需要专门设计，不是加一个 try-catch 就能解决的。

这四个问题基本能覆盖大多数场景，答完之后需求自然会落进模型里某一个区域，选型应该就清楚了。

如何把这套模型整合到 AI Coding 中

  • Checklist：每层一组选项，需求评审时对着过一遍
  • Prompt template：作为 AI 辅助需求拆解的输入框架，描述需求时自然带出五层结构
  • Skill / Rule：沉淀进开发工作流，作为类似需求的默认起点，同时也是 harness 的一部分

这还只是我的一些想法，还没有进行实践，先记录一下。