• 来源：source/_posts/product-updates-rss-file-diff-mental-model.md
  • 日期：2026-04-14
  • 分类：软技能与思考

摘要

作者从三条看似独立的技术线——Web 版本更新弹窗、RSS 订阅推送、App 应用更新与文件 diff——中提炼出一套统一的实现模型。核心主张：它们本质都在回答同一组问题，可以复用同一套五层结构，只是每层的选项不同。

五层模型

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

场景对照表（博文原表）

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

关键洞察

  • 先定粒度，再选机制：差异粒度决定状态描述层要存什么、差异判断层怎么比，从而倒推更新发现层用什么机制。粒度搞错，容易出现技术选型过重或过轻（”用了 WebSocket 其实只需要每小时轮询一次”）。
  • 更新发现层和状态描述层相对固定，可做选择题；动作执行层和用户交互层需要按需调整。
  • App 更新是最复杂的场景，横跨全部五层，且每一层都不能出错。
  • 落地四问（顺序提问法）：① 只需知道”有没有变化”→ 版本号 + 轮询；② 需知道”具体哪里变了”→ 升级到条目级或文件级；③ 需”自动应用变化”→ 动作执行层复杂度显著上升；④ 失败后要回滚→ diff 粒度和执行层需专门设计。

整合到 AI Coding 的设想

作者提出三种沉淀形式（尚未实践）：

  • Checklist：每层一组选项，需求评审时逐层对照
  • Prompt template：描述需求时自然带出五层结构，用于 AI 辅助需求拆解
  • Skill / Rule：作为类似需求的默认起点，同时作为 Harness 的一部分

相关