之前说发现了macOS上Raycast的省内存平替Tinycast，但因为无法完美导入配置而被迫放弃。
发完有读者留言，让我试试看用大模型来手工迁移呢？
的确是灯下黑了，还是习惯了传统软件应用的那套，一切局限于软件本身提供的功能，缺乏了让大模型发挥主观能动性的“压榨”习惯。
于是，告诉大模型我电脑里面用Raycast和Tinycast，我需要将quicklink和script的缩写和快捷键都迁移过去。它一通分析，没几分钟，竟然就完成了，完美！
如今，我已经用上Tinycast了，几乎没有任何体感上的区别。
本着打破砂锅问到底的精神，我问大模型，为什么Tinycast无法做出这个完美的迁移，大模型却可以？
大模型的解释有点意思：
.rayconfig是未公开格式，没有 schema 承诺。今天能解，下个版本可能就变——Tinycast 之前已经因为格式变动删掉过 v1 支持，作者对追加解析逻辑的保守是有前科依据的匹配错了比不匹配更糟：URL 重复、脚本同名、多份导出合并，都可能张冠李戴。看代码风格就知道作者的原则——“识别不了的修饰键就整条丢弃，也不导入一个可能误触发的弱组合”、“超时的值超出选项集就跳过，不做截断”。宁可少导也不错导，是有意的设计哲学
迁移工具是一次性使用的功能，为它维护一套会随上游格式漂移的模糊匹配引擎，投入产出比很低。而我这个方案能成立，恰恰因为我不是通用工具——我知道你的具体环境、能当场验证每一条匹配对不对、错了你能立刻发现。这种“个案精确性”是通用软件给不起的。
大模型还给了一个两种工作模式的对照：
| 数据来源 | 卡点 | 做法 | |
|---|---|---|---|
| Tinycast 导入器 | .rayconfig（同一份） |
Raycast 命令 ID 映射不到自家条目 | 白名单制，对不上就丢 |
| 我 | .rayconfig + Tinycast 本地配置 |
无 | 内容匹配（URL/路径）+ 直接写 Tinycast 的存储 |
从这个角度，也能理解平替的权衡，毕竟获得新用户更关键，Raycast重度用户又不用AI功能的，可能也并不多。
但没关系，感谢AI时代，可以完成很多软件作者不支持的精细化迁移，这种只需要做一次的活，的确是让大模型来做，更完美。