基于 ai-devtool-update-strategies 调研产出的详版设计方案（2026-08-22，含调研结果+更新策略设计+App列表AI排序）。
2026-08-22 · 赵卫国 背景：PC Settings App 升级为天喜（AI Assistant 产品），AI Assistant 模块已启动开发，本方案覆盖当前两个重点功能方向。 本文档包含三部分：一、调研评估结果（Claude Code / Antigravity / OpenClaw / OpenCode 四家更新策略对比）；二、版本更新策略设计方案；三、App 列表 AI 排序设计方案。
第一部分：调研评估结果
1. 调研对象与方法
| 产品 | 形态 | 调研方式 |
|---|---|---|
| Claude Code（Anthropic） | 终端 CLI（native 二进制） | 本机实测（v2.1.239）+ 官方文档 |
| Antigravity（Google） | VS Code fork 桌面 IDE | 官方 releases 页 + 设置项机制 |
| OpenClaw | CLI + Gateway 服务 + macOS 桌面 app | 本地仓库源码精读（docs/install、src/infra） |
| OpenCode | 终端 CLI（参考） | 本机实测（v1.18.21） |
2. 对比总表（11 维）
| 维度 | Claude Code | Antigravity | OpenClaw | OpenCode（参考） |
|---|---|---|---|---|
| 产品形态 | 终端 CLI（native 二进制） | VS Code fork 桌面 IDE | CLI + Gateway 服务 + macOS 桌面 app | 终端 CLI |
| 分发形态 | native 安装脚本（推荐）/ npm / Homebrew / WinGet | dmg / exe / tar.gz 安装包 | npm / git 源码 / install.sh / Docker / Sparkle appcast | curl 脚本 / npm / brew / scoop / choco |
| 更新触发 | native 装：后台自动更新；claude update 手动；brew/winget 装默认不自动 | 默认自动更新到最新；设置 Update Mode 可改 manual/none | openclaw update 一站式手动；auto-updater 默认关闭，开启后按时策略执行 | opencode upgrade [ver] 手动；autoupdate 配置可开/关 |
| 更新通道 | claude install stable|latest|<具体版本> | 单通道 latest；releases 页提供全部历史版本手动下载 | stable / beta / dev 三通道（npm dist-tag: latest/beta/dev；git 装=dev），可 --tag 指定 | 指定任意版本号升级 |
| 灰度/节奏 | 未公开灰度机制；后台静默应用 | 未公开；随 latest 直推 | 有明确灰度：stable 延迟 6h + 12h 确定性 jitter 分散应用；beta 每小时检查即装 | 无 |
| 更新粒度/重启 | 二进制整体替换；下次启动生效 | 整包更新，重启生效 | 包级原子替换；Gateway 服务协调重启（—no-restart 可选） | 二进制替换 |
| 原子性保障 | 多版本目录并存（~/.local/share/claude/versions） | — | 临时 prefix 安装→校验 dist 清单→切换；失败 --omit=optional 重试 | — |
| 回滚 | 指定版本重装 | releases 页下载旧版重装 | npm i -g openclaw@<ver> 钉版本 / git 钉 commit；doctor + restart 收尾 | 指定版本重装 |
| 可管控性（企业侧） | ~/.claude.json autoUpdates:false；DISABLE_AUTOUPDATER 环境变量 | update.mode=manual/none | OPENCLAW_NO_AUTO_UPDATE=1 环境变量硬禁；update.auto.enabled；checkOnStart 可关 | autoupdate: false 配置 |
| 升级质量保障 | claude doctor 检查 | — | openclaw doctor（配置迁移+健康检查）+ 完整 e2e 升级测试集（通道切换/迁移/upgrade-survivor/坏插件） | — |
| 版本号风格 | semver 2.1.x | semver 2.x（双产品线：Antigravity 2.0 / Antigravity IDE） | CalVer 2026.x.y（+ -beta.n） | semver 0.x/1.x |
3. 各家要点展开
3.1 Claude Code（Anthropic）
- 安装方式决定更新行为：官方推荐 native 安装（
curl -fsSL https://claude.ai/install.sh | bash），后台自动更新；npm/WinGet/Homebrew 装的默认不自动更新（交给各自包管理器） - 手动：
claude update|upgrade（检查并安装）；claude install [stable|latest|<ver>]装 native 指定通道/版本 - 多版本保留：
~/.local/share/claude/versions/下并存多个版本（本机实测 2.1.173、2.1.81 与在用的 2.1.239 并存）——更新失败可退 - 管控：
~/.claude.json的autoUpdates: false、autoUpdatesProtectedForNative、DISABLE_AUTOUPDATER环境变量 - 启发：安装方式即更新策略，同一产品按分发渠道区分更新行为；版本保留目录是廉价回滚方案
3.2 Antigravity（Google）
- VS Code fork，继承 VS Code 更新机制：设置里
Update: Mode= default（启动时检查自动更）/ manual（手动检查）/ none（永不检查）——默认自动，但一键可关 - 官网 releases 页公开全部历史版本下载，官方明示「想留在旧版，把 Update Mode 设为 manual 或 none」——回滚 = 手动下载旧版重装
- 多平台多架构包齐全（dmg 双架构 / exe 双架构 / tar.gz 双架构）；两条产品线并行（Antigravity 2.0 与 Antigravity IDE 各自版本序列）
- 启发：桌面应用的用户预期就是「默认自动 + 设置一键可关 + 旧版随时可下载」，简单直接
3.3 OpenClaw（最成熟，重点参考）
- 一站式更新命令：
openclaw update自动识别安装类型（npm/git）→ 拉最新 → 跑openclaw doctor（配置迁移+体检）→ 重启 Gateway；支持--channel beta/dev、--tag、--dry-run预览、--json、openclaw update status --json查状态 - 三通道：stable（npm latest）/ beta / dev（git main）；beta 通道缺失或落后于 stable 时自动回退；当前版本是 beta 时自动留在 beta 通道（通道粘性）
- 安装形态可切换且保留状态：
--channel dev= npm 装切到 git 源码装；--channel stable切回；~/.openclaw的配置/凭据/工作区不受影响 - 自动更新默认关闭，开启后分通道策略：
- stable：延迟 6h + 12h 确定性 jitter → 错峰灰度，避免全网同时踩新版问题
- beta：每小时检查、立即应用
- dev：不自动更，手动
- 原子替换：全局 npm 更新先装到临时 prefix → 校验打包产物清单 → 整体切换，避免新旧文件叠加；失败以
--omit=optional重试一次 - 硬开关：
OPENCLAW_NO_AUTO_UPDATE=1环境变量可无视配置强禁自动更新（事故止血用） - 回滚：
npm i -g openclaw@<版本>钉版本或 git 钉 commit，然后 doctor + gateway restart - macOS 桌面端走 Sparkle appcast.xml（app 内更新 + 发布说明）
- 版本号 CalVer（2026.5.12-beta.1），升级有完整 e2e 测试（通道切换/配置迁移/upgrade-survivor/坏插件恢复/重启鉴权）
3.4 OpenCode（参考）
opencode upgrade [version]手动升级，--method自动/指定安装方式（curl/npm/pnpm/bun/brew/choco/scoop）——升级路径感知安装方式- 配置
"autoupdate": false可关闭自动更新（本机即关闭） - 形态最简：单二进制 + 手动升级 + 一个配置开关
4. 调研结论
三条最值得天喜借鉴的：
- OpenClaw 的错峰灰度（延迟 + jitter）——避免全量用户同时踩新版问题，是大规模装机量下的必备能力
- OpenClaw 的原子替换（临时目录安装 → 校验 → 切换）——更新不弄坏环境是底线
- Claude Code 的多版本保留 +「安装方式即更新策略」——廉价回滚 + 按分发渠道适配更新路径
行业共识：默认自动更新 + 用户可关 + 旧版可回退，三者缺一不可。
第二部分：天喜版本更新策略设计方案
5. 设计目标
| 目标 | 说明 |
|---|---|
| 用户无感保鲜 | 用户不主动操作也能用上最新稳定版，更新不打断使用 |
| 快速迭代能力 | AI 产品周级甚至更高频迭代，发布链路必须轻 |
| 可灰度可回滚 | 新版本出问题能控制爆炸半径、能止血 |
| 可管控 | 个人用户可关自动更新；企业/IT 场景可锁版本 |
| 更新不弄坏环境 | 原子安装、失败可退、更新后自愈 |
非目标：不追求”实时推送最新能力”——能力更新走云端（见 §6 版本解耦），客户端更新保持低频稳定。
6. 总体设计
6.1 客户端版本与能力版本解耦（核心决策）
AI 产品的”迭代快”主要体现在模型、提示词、技能、知识库，不在客户端壳。两类资产分开管理：
| 资产 | 载体 | 更新方式 | 频率 |
|---|---|---|---|
| 客户端壳（UI/框架/系统交互层） | 安装包 | 客户端自动更新（本方案主体） | 低频（双周~月） |
| 能力资产（prompt/技能/功能配置/模型路由） | 云端配置包 | 启动拉取 + 定期热更，本地兜底缓存 | 高频（天~周） |
- 能力包带版本号与签名，客户端按
兼容版本区间拉取，避免新能力依赖新壳时报错 - 能力包更新无需重启客户端（或仅重载会话）
- 断网/云端异常：回落到本地缓存的最后一份能力包 + 安装包内置基线
6.2 双通道
| 通道 | 人群 | 节奏 |
|---|---|---|
stable | 全量用户 | 双周~月，走完灰度链路 |
beta | 内部员工 + 尝鲜用户（设置页自助加入） | 周级，快速试错 |
- 版本号采用 CalVer：
2026.x.y（y 递增；紧急修复.hotfix后缀） - beta 反馈入口内置（一键带版本号和日志上报）
- beta 用户占比建议控制在 5% 以内，既是试验田也是口碑源
7. 更新触发与灰度
7.1 默认行为：静默自动更新
后台检查（每日 + 启动时，错峰随机时间）
→ 发现新版 → 后台静默下载（差分包优先，限速）
→ 校验（签名 + 完整性）
→ 就绪 → 下次应用退出/重启时应用（不打断使用中会话）
→ 更新完成首次启动：轻量 toast「已更新到 2026.9.1」+ 可点开 changelog
- 绝不在用户使用中弹窗强制更新；仅安全级紧急修复例外（见 §7.4）
- 下载限速：工作时段（9:00–19:00）低优先级，避免抢占带宽
7.2 错峰灰度发布
对 stable 更新采用「延迟 + 分桶」两级错峰（借鉴 OpenClaw 的 delay+jitter）：
- 服务端放量：按用户 ID 哈希分桶放量：内部 → beta → 5% → 20% → 50% → 100%，每档观察 ≥24h
- 客户端抖动：收到更新指令后，在 0–12h 内随机延迟应用，避免同一时刻全网更新
放量晋级条件（同时满足）：
| 指标 | 阈值（建议） |
|---|---|
| 更新成功率 | ≥ 99% |
| 更新后 24h 崩溃率 | 不高于上一版本 +0.1pp |
| 核心功能可用率（助手问答/设置操作） | ≥ 99.5% |
| 用户负反馈（更新相关） | 无明显异常上升 |
任一指标恶化 → 自动暂停放量并告警。
7.3 回滚与止血
- 服务端一键停发 + 回退：放量过程中可停止新版本下发；已更新用户通过 §9 客户端回滚兜底
- 紧急止血开关：云端配置可下发「冻结自动更新」指令（事故时全网暂停，无需发版）
7.4 紧急安全修复通道
- 独立的
critical标记：跳过常规延迟，仍走分桶放量（10%→100%，每档 ≥4h） - 允许在应用空闲时主动应用（无需等重启），但仍不中断进行中的会话
8. 更新流程工程细节
8.1 下载
- 差分包（基于上一稳定版的 bsdiff/zstd patch）为主，全量包兜底
- 断点续传；下载失败自动重试（指数退避，最多 3 次/天，避免打满重试）
- 包体签名验证（代码签名证书）+ SHA256 校验，防篡改防劫持
8.2 安装（原子化，借鉴 OpenClaw）
下载完成 → 解压到临时目录（%LOCALAPPDATA%/Tianxi/staging/<version>）
→ 校验目录清单（文件数/关键文件存在性/签名）
→ 校验通过 → 标记为"待切换"
→ 应用重启时：旧版本目录改名备份 → 新版本目录切换为当前 → 启动新版
→ 新版启动成功并上报 → 清理备份（保留一个版本周期）
- 任何一步失败：丢弃 staging，保持现状，上报失败原因，不影响用户使用
- 磁盘空间预检（目标盘剩余 < 2× 包体时提示，不强行安装）
8.3 A/B 双槽（Windows 侧落地形态二选一）
| 方案 | 说明 | 适用 |
|---|---|---|
| A：双目录 + 启动器 | 小启动器（launcher.exe）读取 current 指针，指向 slot A/B；更新写另一个 slot，切换指针 | 自研更新器，控制力最强（推荐） |
| B：MSIX | 系统级打包，自带版本并存与原子切换 | 若走商店/企业分发渠道 |
建议 A：PC 厂商自有渠道分发，自研启动器 + 双槽，回滚和静默更新都可控。
8.4 更新后自检（doctor，借鉴 OpenClaw）
新版本首次启动自动执行：
- 关键组件加载检查（主框架/模型网关连接/助手服务）
- 配置迁移（旧版配置按迁移脚本升级，迁移前备份）
- 用户数据完整性抽查（历史记录/偏好）
- 失败 → 自动回滚（§9）并上报；成功 → 上报健康心跳
9. 回滚机制
| 层级 | 机制 |
|---|---|
| 自动回滚 | 新版本连续启动失败 2 次 / doctor 关键项失败 → launcher 自动切回上一版本槽，上报 |
| 手动回滚 | 设置页「关于天喜 → 回退到上一版本」（保留期内可见） |
| 云端回退 | 服务端停止下发新版 + 对已更新用户下发「建议回退」指令（用户确认后执行） |
| 兜底 | 官网提供历史版本全量安装包下载（学 Antigravity：所有历史版本公开可下载） |
版本保留策略：本地保留上一版本槽（约 +1× 安装体积），超过两个版本周期的旧槽清理。
10. 用户与企业管控
10.1 个人用户（设置页）
| 设置项 | 选项 | 默认 |
|---|---|---|
| 自动更新 | 开 / 关 | 开 |
| 更新时机 | 应用退出时 / 每日凌晨 / 手动 | 应用退出时 |
| 更新通道 | 稳定版 / 抢先版（beta） | 稳定版 |
| 跳过此版本 | 更新提示时可选 | — |
关闭自动更新后：仅在「关于」页提示有新版本，不下载不安装。
10.2 企业/IT 管控
- 策略文件 / 注册表项锁定：
UpdateMode=disabled|manual、PinnedVersion=2026.x.y、Channel=stable - 优先级：企业策略 > 用户设置（策略存在时设置页对应项置灰并说明）
- 支持企业批量部署场景：离线全量包 + 静默安装参数（
/quiet /norestart）
11. 监控与度量
版本分布大盘：各版本用户数/占比、更新成功率、失败原因 TOP N、回滚率、平均更新到位时长（发布→50%/90% 用户到位）。
关键看板指标：
- 更新成功率（下载/校验/切换三段分开统计，定位瓶颈）
- 更新后 24h 崩溃率（按版本对比）
- 自动回滚触发次数
- 灰度各档位晋级耗时
上报复用现有天喜数据通道，注意：更新状态数据属于必要运维数据，在隐私声明中说明。
12. 测试与质量门禁
升级 e2e 测试矩阵（借鉴 OpenClaw 的 upgrade-survivor 体系）：
| 场景 | 验证点 |
|---|---|
| 正常升级 | 数据无损、配置迁移正确、登录态保持 |
| 升级中断（断电/强杀） | 重启后自动恢复，不停在坏状态 |
| 下载坏包/校验失败 | 静默丢弃，不影响现网 |
| 新版本启动失败 | 自动回滚成功并上报 |
| 跨多版本升级（2026.1 → 2026.9） | 迁移脚本链式执行正确 |
| 磁盘空间不足 | 预检拦截，给出明确提示 |
| 回滚后再升级 | 双槽状态一致，无残留 |
每次发布前：升级矩阵全过 + 灰度指标看板就绪 + 止血开关演练。
13. 里程碑建议
| 阶段 | 内容 | 目标 |
|---|---|---|
| P1（随首版） | 双槽 + 静默自动更新 + 手动检查更新 + 设置页开关 | 基础保鲜能力 |
| P2 | 差分包 + 灰度放量 + 指标看板 + 自动回滚 | 规模化发布能力 |
| P3 | 企业策略管控 + 紧急止血通道 + 能力包热更体系 | 企业场景与高频迭代 |
第三部分：App 列表 AI 排序设计方案
14. 背景与目标
天喜 Settings 模块的 App 列表是高频入口。当前为静态列表，目标是做成 AI 排序：把用户此刻最可能想用的 app 排在前面，并为后续「天喜助手唤起 app 并代操作」（跳转升级为 AI 唤起）积累数据基础。
目标：
- 常用即所见：高频/近期使用的 app 自动靠前
- 场景贴合：不同时段呈现不同排序倾向
- 可干预：用户置顶/隐藏优先于算法
- 可演进：从规则打分平滑升级到个性化模型
15. 排序信号与评分
v1 采用规则打分（不引入模型），可解释、可调参、出问题能查：
分数 = 使用频率分 × 时间衰减系数 × 时段场景系数
| 信号 | 说明 | 备注 |
|---|---|---|
| 使用频率 | 近 30 天启动次数（对数平滑） | 主信号 |
| 时间衰减 | 最近一次使用距今越近权重越高（半衰期约 7 天） | 兼顾”最近在用” |
| 时段场景 | 工作时段偏办公类、晚间偏娱乐类（按 app 分类先验） | 系数 0.8~1.2 |
| 显式操作 | 置顶/常用/隐藏 | 最高优先级，直接压过算法分 |
冷启动（新用户无数据）：预装常用 app + 同机型用户群组热度兜底，使用一周后切换个人数据。
16. 展示集：列表里放哪些 app
- 准入：用户安装过的 + 用户实际用过的；不把系统全量 app 堆进列表
- 功能注册制：希望被天喜深度集成的 app（能被助手唤起/代操作）走功能注册（feature manifest）接入；注册过的 app 在列表中带 AI 标识，点击进入时天喜助手可代操作——与「app 跳转升级为 AI 唤起」的规划打通
- 排序信号同时反哺天喜助手主动建议（如”你最近常用 XX，设为快捷入口？“）
17. 分阶段演进
| 阶段 | 方案 | 依赖 |
|---|---|---|
| v1 | 规则打分（频率×衰减×场景）+ 显式操作优先 | 本地使用统计 |
| v2 | 个性化重排（轻量排序模型或 bandit 探索） | 使用数据积累 + 端侧/云端轻量推理 |
| v3 | 与助手联动：排序 + 主动建议 + AI 唤起一体化 | 功能注册生态成型 |
18. 合规与隐私（硬约束）
- 使用频率等行为数据仅本地计算，不上报云端
- 隐私声明中明确说明统计口径与用途
- 群组热度等聚合数据使用脱敏统计，不涉及个体行为
19. 与更新策略的关系
- 排序算法参数/场景系数表属于能力资产，走第六部分的云端热更通道，无需客户端发版即可调优
- 排序相关的 A/B 实验复用能力包的灰度机制
附：与调研对象的对照（更新策略部分）
- 学 OpenClaw：错峰灰度、原子替换、更新后 doctor、升级 e2e、止血环境变量
- 学 Claude Code：多版本槽保留、「安装方式即更新策略」（天喜对应：预装/官网下载/商店分渠道适配更新路径）
- 学 Antigravity：默认自动 + 设置一键关 + 历史版本全量可下载
- 学 OpenCode：升级命令感知安装方式（天喜的「检查更新」按当前安装渠道选择更新路径）