那天讨论一个刚推出不久的桌面应用。用户先问了一个看似简单的问题：如果桌面版只是把网页能力换了一个入口，后面的操作到底应该走桌面版，还是继续走网页版？紧接着，他又把问题往后推了一步：桌面版一定还会升级，万一后续出现了现在没有的能力，我们怎么及时补上？
我一开始容易把这理解成“等它更新后再适配”。但这句话其实把最重要的工作推迟了。真正要解决的不是某一次升级，而是怎样让升级变成一个能被发现、被比较、被验证的事件。否则每次版本变化，都要重新凭记忆摸索一遍；只有用户遇到问题、再次提问，缺口才会暴露出来。
新入口的价值不只在于多了一个入口，而在于它会持续改变我们原来依赖的能力边界。
表面上是升级，实际上是基线变了
桌面版和网页版看起来可能只是入口不同：很多操作仍然发生在网页里，页面、任务和交互也有相似之处。但入口一旦换了，能不能调用某项能力、能力从哪里来、多个网页是否可以并行处理，都会变成新的问题。
当时还谈到任务空间与普通网页入口的差别。普通入口可能只需要关注当前页面；任务空间则可能同时打开多个网页、承载多个任务。它们都叫“网页操作”，但不能因此默认它们拥有相同的上下文、并发方式和状态隔离。
这就是升级哨兵的第一个作用：先把当前版本的事实留下来。版本号是一部分，实际入口、已经确认的能力、能力之间的依赖关系也应该成为基线。没有基线，就没有“变化”这个概念，只有一次次重新观察。
如果不处理，后果并不只是少了一个新按钮。旧流程可能继续调用原来的入口，却不知道桌面版已经改了行为；新能力可能已经存在，却没有被共用流程接入；更隐蔽的情况是，某个能力还能运行，但它的返回结果或适用范围已经变化。等到任务失败时，问题会看起来像偶发故障，实际上是版本变化没有被记录。
我为什么不等用户再次发现问题
用户后来问：既然能发现这么多问题，为什么之前没有发现，非要等提问时才暴露？这句话把重点从“修一个问题”移到了“为什么没有提前发现”。
最容易误判的是，把一次成功运行当成了长期稳定。刚推出的桌面应用，今天能打开、能执行，并不代表下一个版本仍然保持相同的结构。更不能因为网页版已有某种能力，就默认桌面入口已经具备同样的能力。
错误捷径是：升级后重新人工摸索全部功能。它看上去最保险，因为每个地方都重新看一遍；实际上成本高，而且结果依赖当时的人是否记得以前看过什么。另一个错误捷径是只等故障出现再修补。这样会把测试成本转嫁给真实任务，也让“发现问题”永远发生在用户已经受到影响之后。
我选择先建立版本快照，是因为它把“我觉得没变”改成了“我能指出哪里没变、哪里变了”。
快照不需要记录所有内部细节。它只需要覆盖会影响使用的结构：当前版本、主要入口、已经确认的能力、关键连接方式，以及与任务空间相关的边界。重要的是可比较，而不是堆满资料。留下太多无法解释的字段，反而会让每次升级都变成整理档案。
把变化拆成 3 种，而不是重新摸索一遍
有了基线后，每次升级只看差异。我会把差异分成 3 类：新增、删除和行为变化。
新增是现在没有、升级后出现的能力。它不能只登记成“发现了新功能”，还要回答它能服务哪个旧任务，是否需要加入共用能力层。删除则更容易被忽略。某项能力不再存在时，旧流程不能继续假设它可用，而应该给出替代路径或明确失败。
行为变化最危险，因为表面上看起来一切还在。一个入口仍然能打开，不代表参数、返回结构、页面上下文或多个任务之间的隔离方式没有变化。这里需要做小范围探针，确认变化是否影响已有调用，再决定是更新说明、调整适配，还是暂时保留旧路径。
这 3 类差异的好处是让“升级”变成了有限的问题。我们不再问“这个新版本有什么”，而是问“相对于上一个可用版本，新增了什么、删除了什么、改变了什么”。问题范围缩小，验证也更容易开始。
先用无副作用探针确认，再接入共用流程
版本探测不等于立刻使用新能力。探测阶段应该尽量只读、低成本、无副作用。比如确认版本标识是否变化，读取入口结构是否仍在，检查能力清单中的项目是否可见。探针的目标是发现事实，不是顺手执行真实任务。
我会把确认过程分成两层。第一层只回答“变化是否存在”；第二层才回答“变化是否值得接入”。如果第一层发现版本变了，就比较快照，生成新增、删除、行为变化的差异。只有在差异与工作相关时，才进入第二层，针对具体能力做小范围验证。
这里需要保守一点。一个能力在界面上出现，不等于它已经适合自动化；一个网页能打开，也不等于它支持多个任务空间并行。桌面入口和网页版可能共享一部分页面能力，但上下文容器、任务数量和状态管理仍要分别确认。
确认过的新能力，才接入共用能力层。这样做的理由是避免每个旧流程都自己判断版本。如果每个调用方都保存一套升级逻辑，后面会出现多个版本判断，彼此还可能互相矛盾。把差异集中处理，旧任务只关心“我要完成什么”，共用层负责“当前入口应该怎么做”。
用旧任务做回归，防止只追新不守旧
升级哨兵最后不能停在差异报告。新能力接入后，还要用已有任务做回归。回归不是把所有历史操作完整重跑，而是挑能代表旧边界的几类任务：单页面操作、多个页面或任务空间的切换、依赖旧能力的流程，以及遇到能力缺失时的失败提示。
这样可以同时检查 2 件事。第一，新能力有没有真的被旧流程使用，而不是只躺在能力清单里。第二，升级有没有破坏原来可以完成的任务。只验证新功能，容易得到“新增成功”的错觉，却漏掉旧入口被改坏、上下文串线或错误提示失真的问题。
回归还应该留下结果和版本对应关系。某次检查是在什么基线、什么差异下完成的，至少要能被后来的人读懂。否则下一次升级时，大家只知道“以前测过”，却不知道当时测的是什么。一个流程成熟的标志，不是它能跑通一次，而是下次可以沿着上一次的判断继续走。
升级哨兵真正守护的不是某个版本，而是旧任务的可预期性。
把一次修复变成持续的方法
这件事让我重新意识到，软件升级的麻烦通常不在版本号本身，而在于我们没有把变化变成可观察的对象。只要每次都从零开始，人的记忆就会成为系统的一部分；记忆一旦断掉，遗漏就会重新出现。
可复用的方法可以压缩成一条流程：先保存版本快照和能力基线；升级后做低成本版本探测；只比较新增、删除、行为变化；对有影响的差异做无副作用确认；确认后的变化进入共用能力层；最后用代表性旧任务回归。每一环都不追求把所有事情做尽，而是为了减少下一次判断的盲区。
这套方法也适合网页入口、桌面壳、任务空间等边界不断变化的系统。只要入口还在迭代，就应该把“它现在能做什么”记录成可以比较的状态。能力清单不是说明书，快照也不是档案馆；它们的价值在于下一次升级时，能快速指出应该重新确认哪里。
最重要的规则是，发现变化以后直接补进流程，而不是把它留成一条待办。用户当时提出“后面没有的东西也要增补”，本质上是在要求系统具备持续生长的接口。升级哨兵就是这个接口的前半段：先发现，再判断，再让共用流程获得新能力。
下次我会怎么做
下次遇到刚推出、还会持续升级的新入口，我会在第一次可用之后就建立基线，不等到发生故障才开始记录。基线只保留会影响任务的事实，避免把无法解释的内部细节变成维护负担。
我会先问 3 个问题：版本发生了什么变化，能力清单发生了什么变化，旧任务还能不能按原来的方式完成。发现差异后，先做只读探针，再决定是否接入；看到新按钮时，不直接把它当成稳定能力；看到旧流程仍能跑时，也不把它当成没有变化。
最后，我会给每次升级留下一个小而完整的闭环：差异是什么，确认了什么，改动进入了哪里，哪些旧任务通过了回归。这样以后再遇到升级，就不必靠提问把问题逼出来，也不必把整个入口重新人工摸索一遍。
真正值得保留下来的，不是某个桌面应用今天有哪些能力，而是一种面对变化的工作习惯：让变化先被看见，让判断有据可查，让修复能够回到共同流程里。