把个人 AI 工作台迁移到新电脑
这次换电脑，表面上看是硬件更新：旧台式机用了很多年，风扇和电源状态开始让人不放心，机械硬盘也有坏块记录。实际做下来，我发现真正迁移的不是一台电脑，而是一整套已经长在日常工作里的 AI 工作台。
这套工作台大概由几部分组成：Windows 桌面环境、WSL、Hermes、Codex、本地脚本、代理和网络规则、个人网站仓库，以及一套给 AI 和自己共同读取的长期记忆。硬件只是容器，麻烦的是这些工具之间的连接关系。
1. 为什么到了该迁移的时候
旧机器并不是突然坏掉。
它还能开机，也还能跑日常任务。但检查下来，几个信号叠在一起后，就不太适合继续当主力机了：
- 平台本身已经老了，CPU 和 Windows 11 官方支持之间存在兼容性压力；
- 机箱噪音变大，电源按钮偶尔需要多按几次，像是电源、前面板或风扇这类物理部件开始不稳；
- 系统日志里出现过异常断电记录；
- 2T 机械硬盘虽然在常规健康状态里显示正常，但事件日志里已经有坏块记录；
- 新机器要承担的不是简单浏览网页，而是长时间运行 AI 工具、WebUI、隧道、脚本和本地仓库。
所以最后的判断不是「旧电脑已经死了」，而是「继续把它当主力环境，风险和维护成本开始不划算」。
这里有一个很现实的取舍：我没有直接上更大的 SSD，而是先买了 1T。原因也简单，硬盘价格太高。于是存储方案也变得保守：新 SSD 尽量作为一个完整的 C: 使用，用文件夹组织工作区；旧机械硬盘只适合短期拷数据，不适合继续作为可信的长期数据盘。
2. 迁移的核心不是复制文件
以前换电脑，我可能会优先想：软件装回来、文件拷回来、浏览器登录回来。
这次不一样。因为 Hermes 和 Codex 这类工具用久以后，本地环境里会出现很多「隐形状态」：
- 某个 WebUI 默认应该跑在哪个端口；
- 哪些配置文件决定模型和工具链；
- 哪个脚本负责修复隧道；
- 哪些路径只在 WSL 里存在；
- 哪些历史对话记录了上一次排障结论；
- 哪些本地记忆应该被未来的 AI 自动检索。
这些东西不是单纯复制 Documents 就能恢复的。真正要迁移的是一张关系网。
我后来给自己的标准变成了：每迁移一个工具，都要回答三个问题：
- 它的入口在哪里？
- 它坏掉时怎么验证是哪一层坏了？
- 修复动作能不能沉淀成脚本或笔记，而不是下次重新猜？
3. Hermes：从「能打开」到「可恢复」
Hermes 是这次迁移里最典型的一块。
本地有一个 Hermes WebUI，另一个 Hermes WebUI 跑在 VPS 上，通过本机 localhost 端口访问。最开始的问题看起来很简单：页面打不开。可是排查下来，不能只问「端口有没有监听」。
有一次端口是开的，但页面仍然不能正常返回正文。后来才确认，对于这种 WebUI，只看端口、HEAD 请求或 favicon 都不够，必须用真实的 GET / 去确认 HTML 是否完整返回。
这件事让我把 Hermes 的检查方式从「看起来活着」改成了「真的能提供内容」：
- 本地服务要查健康接口；
- 隧道要查真实页面正文；
- VPS 上的 systemd 状态不能单独作为结论；
- 如果服务是
active，但正文为空或超时，就要继续查环境变量、启动日志和转发路径。
后来还有一个更有意思的变化：原本通过 WSL 做隧道转发，后来发现它会出现半工作状态。最终更稳定的方案是把转发迁到 Windows OpenSSH，让 Windows 侧负责 localhost 入口，再用隐藏脚本和计划任务保持可恢复。
这一步的重点不是用了哪个命令，而是思路变了：不要把「临时能打开」当成修好，要把「下次坏了能自动或半自动恢复」当成修好。
4. Hermes 成本和噪音也要迁移
Hermes 另一个问题是配置膨胀。
一开始我以为慢、贵、不聪明，可能是模型或 API key 的问题。后来排查发现，更大的问题在 Hermes 自己的运行表面太大：MCP、模型目录、辅助模型自动探测、旧会话状态、过长上下文，都会让一次很小的请求背上很重的负担。
最后的处理方式很朴素：
- 关掉暂时不用的 MCP；
- 关闭模型目录探测；
- 把辅助任务固定到明确的 DeepSeek 模型；
- 缩短重试、轮次和记忆长度；
- 每次改完配置后，用新的会话和健康检查验证，而不是相信旧 UI 状态。
这件事给我的提醒是：AI 工具的迁移不只是「把 key 和 config 搬过去」。如果旧环境里已经积累了很多默认工具、失败路径和历史状态，新机器上照搬也可能只是把旧的浪费复制过去。
5. Codex：真正重要的是连续性
Codex 的迁移感受又不同。
Codex 不是一个单点服务，它更像一组正在进行的工作现场：个人网站、Hermes、FlClash、Upwork、问卷系统、会计系统、Windows 维护、文件处理……每个主题都散落在不同对话里。迁移它的时候，最麻烦的也不是文件本身，而是这些对话还能不能被新机器上的 Codex 正确识别为「某个项目里的工作」。
我当时遇到的症状有点微妙：.codex 目录和会话文件都在，新电脑上也能看到一些项目入口，但项目页里可能是空的，或者线程还像是挂在旧电脑的路径下面。也就是说，内容没有丢，但 Codex Desktop 的项目索引、线程工作目录和旧 Windows 用户路径没有完全对上。
这一步不能粗暴重置。真正安全的做法是先把它当作数据修复，而不是当作软件设置：
- 先确认
sessions/**/*.jsonl里的对话内容还存在； - 再检查全局项目状态和线程索引里是否还残留旧用户目录；
- 对
state_5.sqlite这类索引库先备份，再只替换旧路径； - 区分「历史消息里出现旧路径」和「控制项目归属的元数据里出现旧路径」；
- 修完以后用 Codex 的线程读取能力和项目列表重新验证，而不是只看文件在不在。
当时还踩到一个典型坑：直接全局搜索旧用户名会搜出大量历史工具调用和聊天正文，那些只是历史记录，不一定应该被改。真正该动的是 session_meta、turn_context、全局状态文件和线程索引里的工作目录。后来我把这套经验整理成了一个专门的 codex-windows-migration-repair skill：默认 dry-run，真正写入前备份，修复后要求重启 Codex Desktop 让 UI 重新加载。
这个过程折腾得久，是因为它处在一个尴尬位置：数据看起来在，界面却不一定认；项目看起来在，线程却可能还指向旧机器。最后我得到的结论是，Codex 迁移不是「复制 .codex 文件夹」这么简单，而是要同时迁移三层东西：会话记录、项目/线程索引、以及旧路径到新路径的映射关系。
我一开始以为问题是「怎么把对话整理到项目里」。后来发现更准确的问题是：我不想每次开新窗口都重新解释一遍，也不想在几十个旧对话里猜应该接着哪个聊。
最后采用的方式不是强行移动历史对话，而是做了三件更稳的事：
- 给松散对话加可逆的标题前缀；
- 建一个本地 Markdown 记忆库，记录主题、路径、结论和继续路线；
- 让未来的 AI 在回答相关问题前，先检索这个记忆库。
这比「把所有历史都塞进一个超大上下文」更现实。长期记忆不应该是无限长的聊天记录，而应该是可检索的路标。
6. 个人网站也成了迁移的一部分
这次迁移还顺手重新确认了个人网站的分工：
zhuzg.com是轻量主页；notes.zhuzg.com是结构化的项目、研究和工具笔记；logic.zhuzg.com更适合放对话、思考和时间线记录。
这篇文章最后放在 notes，而不是主站或纯日志里，是因为它不是一篇「我买了新电脑」的生活记录。它更像一篇工作台复盘：我如何把工具从「能用」整理到「能恢复、能解释、能继续」。
这也是个人网站对我真正有用的地方。它不是只展示结果，而是记录一套方法是怎么形成的。
7. 这次迁移后留下的原则
复盘下来，我觉得以后再换机器、迁移工具或重建环境，可以直接按这几条来：
-
先判断旧机器是否还值得维护
不只看配置，也看异常断电、硬盘坏块、噪音、供电和系统支持周期。 -
把关键服务拆成入口、配置、验证、恢复四层
能打开只是第一步，知道怎么证明它真的健康更重要。 -
不要只迁移配置，也要迁移排障方法
上一次为什么坏、怎么确认、怎么修好，应该写成笔记或脚本。 -
本地 AI 工具要控制运行表面
不用的 MCP、模型探测、辅助 fallback 和长上下文，都会变成成本和噪音。 -
长期记忆要做成索引，而不是依赖某个巨大的聊天窗口
对话会压缩、窗口会分散，但主题索引、路径和结论可以长期保留。 -
新电脑不是终点，而是一次整理机会
真正值得迁移的不是所有旧东西，而是那些已经证明有用、并且能被解释清楚的工作流。
结语
以前我理解的「装机」更偏硬件：CPU、显卡、硬盘、电源、散热。
这次更像是在重建一个个人计算环境。新机器当然更快，但更重要的是，我借这个机会把很多原本靠记忆维持的东西，变成了可以被检查、被恢复、被 AI 重新读取的结构。
如果说这次迁移有什么真正值得记录的地方，大概就是这句：
当 AI 工具开始参与日常工作后，换电脑不再只是迁移文件，而是在迁移一套人与工具共同形成的工作记忆。