Claude Code 从 Windows 迁到 Mac，表面上像是“把配置复制过去”。
真正做起来才发现，长期 AI 工具最怕的不是少装一个插件，而是路径、记忆、运行状态和全局规则混在一起。能迁移的应该迁移，不能迁移的硬搬过去，只会制造更隐蔽的问题。
为什么折腾
我希望 Claude Code 在 Mac 上也能延续之前的工作方式：有全局规则、有项目记忆、有 hooks、有插件，也能继续参与 Obsidian 和网站项目的长期整理。
这个目标听起来简单，但它不是一次性安装。它更像是在迁移一个已经形成习惯的工作台。
如果只迁移可执行工具，AI 会变成一台新机器上的“陌生助手”；如果把所有状态原样复制过去，又可能把 Windows 路径、旧端口、临时数据库和运行缓存一起带过去。
我的公开版原则
公开版我不会贴具体路径、钥匙、端口和本机配置，只保留迁移原则：
- 全局规则可以迁移，但要改成本机可用的路径。
- hooks 可以迁移，但要确认解释器和运行环境是否一致。
- 项目记忆可以迁移，但运行中的数据库状态不能盲目复制。
- 临时文件、supervisor 状态和缓存不属于长期资产。
- 旧机器上的硬编码路径必须全部清理。
这件事的核心不是“搬得越全越好”，而是分清楚什么是资产，什么只是当时那台机器的运行痕迹。
实际怎么做
第一步是盘点可迁移资产。
我把全局规则、settings、hooks、插件和记忆数据分开看。规则和插件属于长期工作方式，可以保留；临时进程、端口状态、缓存和 worker 运行文件只适合重建。
第二步是处理路径差异。
Windows 和 macOS 的路径格式完全不同。最容易出错的地方，是配置里夹着旧路径但表面上不报错。AI 工具一旦读到旧路径，可能不是立刻失败，而是在某个具体任务里突然找不到文件。
第三步是处理长期记忆。
长期记忆系统很诱人，但也最脆弱。它可能依赖 SQLite、向量库、后台 worker、端口和特定目录。迁移时不能只问“文件在不在”，还要问“这个服务能不能重新索引、能不能正常查询、能不能追加新记忆”。
第四步是把旧环境退役。
当 Mac 成为主工作台以后，Windows 侧的同类记忆系统就不应该继续维护。两套长期记忆同时写入，后面一定会分叉。
哪里卡住
第一个坑是硬编码路径。
很多配置一开始只是为了跑起来，路径写死也无所谓。迁移时才发现，它们变成了隐形依赖。只要其中一个没改，后面的错误就会很难排查。
第二个坑是“运行状态”和“资产”混在一起。
有些文件看起来像配置，其实只是某次运行生成的状态。把它搬过去不但没用，还可能让新环境误以为旧服务仍然存在。
第三个坑是记忆系统比想象中敏感。
普通配置错了可以重试，长期记忆错了可能会丢历史、索引失效，或者留下无法信任的半迁移状态。这里最重要的是先备份，再验证，再决定是否重建。
最后怎么取舍
最后我更倾向于把 Mac 作为唯一主工作台。
Windows 侧保留历史，不再维护同一套长期记忆。Mac 侧重新确认规则、hooks、插件和项目入口，把能长期复用的部分留下，把旧机器运行痕迹清掉。
这次迁移给我的最大提醒是：AI 工具越像“长期搭档”，越需要像正式项目一样管理它的配置和记忆。
不要等它坏了才发现，真正难搬的不是软件本身，而是你过去几个月和它一起形成的工作方式。