workbudy 国内版被自动升级到国际版，就因为版本号比国内版高

这条信息很关键——"提示更新"说明走的可能不只是启动强制更新那条路。我查一下还有没有别的更新入口，同时看看现在的实际状态。
全貌出来了。关键在这里——除了启动强制更新，还有一条每小时跑一次的周期检查，完全没有开关：
环境变量已写入。现在把它固化进脚本。
你那句"会提示更新"是决定性的——它让我找到了真正的原因，也说明我上一轮的方案不完整。

更新检查一共有四条链路，其中两条根本没有开关

从 app.asar 里 DesktopUpdateService 的初始化代码读出来是这样的：

runStartupForceAutoUpdate(c, configStore, productSource) // ① 受 startupForceAutoUpdate 控制
runEarlyForceUpgradeCheck(c) // ② 早期强制升级检查
setTimeout(() => c.checkForUpdates(), 30000) // ③ 启动 30 秒后 —— 无门控
setInterval(() => { // ④ 每 1 小时 —— 无门控
  c.checkForUpdates(); c.checkForceUpgrade();
}, 3600000)

我上一轮只关了 ①。③ 和 ④ 没有任何开关，启动半分钟后就查一次，之后每小时查一次——这就是你看到的"提示更新"。只关 ① 挡不住它。

真正的解法：把更新源钉死在国内地址

更新地址的拼装逻辑是：

`${process.env.WORKBUDDY_UPDATE_URL || resolveUpdateBaseUrl(product.endpoint) || 'https://copilot.tencent.com'}/v2/update?platform=...`

环境变量优先级最高，我已经帮你设好了：

WORKBUDDY_UPDATE_URL = https://www.workbuddy.cn

效果：四条链路全部改走国内源，而这个接口返回的是 5.8.3 —— 正好等于国内版的当前版本，所以不会提示更新；同时它永远够不到 download.codebuddy.ai 上的国际版包，再怎么点更新也升不到国际版。以后国内版真出新版本，还能正常升。

（如果你想要彻底冻结、连国内更新也不要，把它设成 http://127.0.0.1:9 这种不通的地址即可。想恢复默认，删掉这个环境变量就行。）

还有个更根本的原因：安装时文件被锁

你说"之前互不干涉"，那是因为以前两版装在不同目录。现在它们被装进了同一个目录，而安装国内版时国际版进程还在跑：

国际版锁着 resources/app.asar.unpacked/** → 国内版安装器覆盖不了这些文件 → 国内版的 WorkBuddy.exe 启动后加载到的仍是国际版的 product.json（isOversea=true、endpoint=workbuddy.ai）→ 它以为自己是国际版，跑去 workbuddy.ai 查更新 → 看到 5.8.4 → 提示更新 → 装回国际版。

所以"装 CN 前必须先彻底退出国际版"不是建议，是必要条件。

脚本已升级到 6 步

1. 杀掉所有 WorkBuddy 进程
2. 卸载国际版
3. 卸载国内版（清掉被污染的安装）
4. 钉死更新源 → workbuddy.cn
5. 关闭启动强制更新
6. 启动国内版安装包，然后自动校验装成的到底是哪个版本

第 6 步是新增的自动校验：装完会读 resources/app.asar.unpacked/cli/product.json 打印 isOversea。如果打出来还是 true，说明文件没被替换掉（安装时应用没退干净），脚本会直接警告你重来。另外卸载程序位置也修正了——国际版现在装在 Programs\WorkBuddyAI，脚本三个目录都会找。

你现在的情况

当前是国际版，装在 Programs\WorkBuddyAI（isOversea=true / 5.8.4），9 个进程在跑。两处 app-config.json 的 startupForceAutoUpdate:false 都还在。

环境变量对已经启动的进程不生效，重启一次 WorkBuddy 后才开始起作用。之后即使再装国内版，也不会被"更新"带走了。