AIClaw 3.7.15 为 Windows 更新带来安装器方案

AIClaw v3.7.15 在 ZIP 便携包之外新增了 Windows x64 安装器（NSIS）、校验和验证与交互式更新流程。核心价值不在功能堆叠，而在于把下载、校验、启动安装器、完成升级四个阶段明确拆开，让用户清晰掌握每次更新的边界与责任。

AIClaw 3.7.15 更新文章预览

从 ZIP 解压到交互式安装器

过去用 ZIP 更新桌面应用，需要找到新下载包、关闭运行中的应用、解压并替换对应目录。对便携分发来说这没问题，但版本发布一频繁就变成重复劳动。AIClaw v3.7.15 保留 ZIP 的同时，新增了 Windows x64 交互式 NSIS 安装器，公开发布页同时附带安装器和校验和文件。

这一改动的重点是把更新从“手动文件管理”变为“可审计的下载-校验-启动”链路，减少用户直接接触文件的环节。

NSIS（Nullsoft Scriptable Install System） 是一套开源的 Windows 安装器制作框架，通过脚本描述安装步骤、组件、快捷方式和卸载逻辑，生成单一可执行安装包。electron-builder 把 NSIS 作为 Windows 目标之一，可输出交互式（有向导界面）或静默（无界面）安装器。选择 NSIS 而非 MSI 的原因通常是构建配置更简单、与 Electron 打包链路集成更直接，且能覆盖绝大多数个人用户场景。Microsoft Installer（MSI）在企业域环境下更便于组策略部署，但需要额外的工具链和更严格的组件注册。本文使用的“交互式”形态意味着安装路径、确认步骤都交由用户在向导中决定，应用不代填静默标志。

更新流程的四步决策路径

点击更新动作后，Windows 更新器在 apps/desktop/src/main/updater.ts 中执行固定序列：

检查 GitHub 最新 Release，确认存在更新版本。
找到对应版本的 Windows 安装器并下载到临时目录。
下载 SHA256SUMS.txt，将安装器摘要与命名条目比对。
请求 Windows 打开安装器，移交成功后退出 AIClaw，由用户完成安装确认。

应用不会传递静默安装标志。其“成功”意味着安装器已启动，而非安装已完成。如果用户在向导中取消，仍可重新打开旧版本应用。这里并没有跨应用与安装器的事务保证，也没有自动回滚机制。

校验失败时应用应保持运行

当校验和条目缺失或摘要不匹配时，安装器不会被打开。下载失败或操作系统启动错误同样会让 AIClaw 继续运行。失败路径会清理临时下载目录，并打开 releases 页面让用户自行查看可用下载。

更新器拒绝从开发模式安装。仅有 ZIP 的 release 会回退到之前的“下载并打开文件夹”行为。这一回退是为了兼容旧发布格式，而不是绕过已有安装器的校验和检查。对维护者来说，这个区别很重要：早于安装器支持的 release 仍然可用，而损坏的安装器下载会明确报告为失败。

校验和是完整性检查，存在信任边界

摘要比对只验证下载的可执行文件与 release 提供的摘要一致，并不独立证明发布者身份。可执行文件和校验和来自同一分发渠道。当前安装器没有 Authenticode 签名，Windows 可能显示未知发布者警告。该实现既没有禁用系统保护，也没有把校验和匹配等同于发布者签名。

这一点值得强调：校验和解决的是传输完整性，不是来源可信性。用户仍需自己对分发渠道建立信任。

SHA256SUMS.txt 是一种常见的发布产物清单格式，每行由“摘要 + 两个空格 + 文件名”组成，源自 GNU coreutils 的 sha256sum 工具。它最初用于在 POSIX 系统上批量校验归档文件，后来被许多开源项目沿用，配合 GPG 签名形成“校验 + 签名”两级防线。AIClaw 当前只做第一级：比对摘要。若清单本身被替换，比对仍会通过，因此真正的信任锚点是发布渠道（GitHub Release 页面）本身。

Authenticode 是 Windows 的代码签名机制，签名证书由受信任的 CA 签发。签名后的可执行文件在 SmartScreen 和 UAC 提示中会显示发布者名称，用户可据此判断来源。未签名安装器会触发“未知发布者”警告，但系统不会阻止运行。签名通常需要付费证书和构建时的密钥管理，因此个人项目常在早期阶段跳过。需要注意的是，Authenticode 与“是否校验和通过”是两个独立维度：前者回答“谁发布的”，后者回答“传输有没有损坏”。

先打包应用，再构建安装器

installer build script（scripts/package-win-installer.mjs）消费现有打包器产出的 Windows 应用目录，读取其中的应用版本，并把准备好的目录传给 electron-builder 的 NSIS 目标。配置使用稳定的应用 ID、辅助向导和带版本的安装文件名，禁用安装目录选择，并设置 deleteAppDataOnUninstall=false。主进程同时设置匹配的 Windows 应用用户模型 ID，并保留已有的用户数据应用名。

程序替换与用户数据保留是两回事。安装器替换应用文件；设置和聊天继续使用原有的 Electron 用户数据位置，全局应用数据和记忆保持原有主目录位置，安装器不会把它们移入程序文件夹。

对已有 ZIP 用户，第一次迁移是手动的：下载新的 setup 可执行文件，安装，使用新快捷方式。旧的解压目录不会被自动删除。旧 ZIP 应用的更新器不会因为 GitHub 上存在安装包就获得新行为。一旦运行新实现，后续提供安装器的更新就能使用这条下载-启动路径。便携 ZIP 仍然保留给偏好的用户。

Electron 用户数据目录默认位于 %APPDATA%\<appName>，用于存储 settings.json、聊天记录、缓存等；userData 路径由主进程 app.setPath 或打包配置中的产品名决定。全局应用数据则常定义在用户主目录下（如 ~/.aiclaw），用于跨安装共享的模型文件或全局记忆。安装器只负责替换 <Program Files>\AIClaw 下的程序文件，deleteAppDataOnUninstall=false 正是为了卸载时保留这些用户数据。Windows 应用用户模型 ID（AppUserModelID） 用于任务栏分组与通知归属，打包配置中的 appId 与主进程设置必须一致，否则同一应用会显示成两个图标或通知来源异常。package-win-installer.mjs 把打包产物目录当作输入，避免重复解压或重建，使应用版本号能在安装器命名中保持同步。

把宿主移交与 Windows 安装分开测试

updater regression tests（scripts/test-updater.ts）模拟 Electron 和网络响应，覆盖有效摘要与启动前退出顺序、错误或缺失校验和、操作系统启动失败、仅 ZIP 回退、无更新/开发模式/无效标签以及 Release API 失败等场景。这些测试验证更新器的决策，但不执行 Windows 安装器。

原生 smoke 脚本（scripts/smoke-win-installer.ps1）在 Windows runner 上单独完成安装测试：安装到含空格的临时路径，检查预期应用文件，修改程序文件为过期 fixture，再重新安装验证替换；同时在两个用户数据位置放置哨兵文件，在安装、重装和卸载后检查。脚本使用静默标志用于自动化测试，这些标志不会由应用的交互式更新路径传递。其替换检查仅在同一构建上重装并覆盖被修改的文件，不模拟所有跨版本迁移，也不验证每一个真实用户数据库。

公开发布的 v3.7.15 release workflow 已成功完成，包括 Windows 安装器任务。workflow 定义把发布依赖于该任务。release 说明也报告了本地检查和六个更新器回归测试通过。作者核对了带标签的测试和公开 workflow 结果，但并未重新运行测试套件或执行独立的 Windows 桌面验收测试。

Electron 主进程应用更新器运行在 Node 环境中，可以直接调用 shell.openPath 打开外部安装器，但打开动作与安装完成之间没有回调——退出码只表示“安装器进程是否成功启动”。这就解释了为什么“成功”在本文语境里被定义为移交完成而非升级完成。

回归测试以桩替换 Electron 模块和网络请求，断言状态机在每种输入组合下选择正确的分支；它不触碰真实 Windows API，因此运行速度快、可在 CI 的任意平台执行。Smoke 测试则相反，必须运行在 Windows runner 上，因为它依赖 MSI/NSIS 的替换语义、文件锁行为以及 %APPDATA% 等真实目录。两者互补：前者防止逻辑回归，后者捕捉环境相关的问题（如空格路径、杀毒软件拦截、安装目录被占用）。本文用静默标志驱动 smoke 脚本，正是为自动化测试绕过 GUI 交互，与应用更新路径的交互式传递是两条不可混淆的通道。

要点总结

AIClaw v3.7.15 在 ZIP 之外新增 Windows x64 NSIS 安装器，更新流程从手动文件管理变为下载-校验-启动安装器三步链路。
校验和验证可防止下载损坏，但不验证发布者身份，安装器未做 Authenticode 签名。
校验失败、下载失败或启动失败时应用保持运行，并清理临时目录、打开 releases 页面。
程序替换与用户数据保留分离，安装器不迁移用户设置、聊天记录和全局数据。
更新器回归测试与原生 Windows 安装 smoke 测试分离，前者验证决策，后者验证安装行为。