用 Claude Code 搭配 DeepSeek MiMo 2.5Pro 重构 OC/Swift 混编项目，我差点被整崩溃

最近手头有个老项目，业务逻辑大部分已经用 Swift 重写了，只剩下少量的 Objective-C 代码和几个 OC 第三方 SDK 还赖着不走。想着干脆一不做二不休，把业务层彻底迁移到 Swift，顺便做个模块化重构，让代码结构更清爽一点。

正好 Claude Code 火得一塌糊涂，DeepSeek 的 MiMo 2.5Pro 也是号称地表最强，我就寻思着让这两个“神仙”联手，把剩下这点陈年旧账清一清。第一个模块拢共就 20 来个类，代码量撑死几千行，原以为也就是喝杯咖啡的功夫就能搞定，结果差点被现实教做人。

Xcode Bridging Header 配置示意图

桥接头文件配置

起初的设想很美好：直接告诉 Claude Code，“把这个模块从 OC 迁移到 Swift”，然后它就能像变魔术一样把代码转换得漂漂亮亮。毕竟现在的 AI 写代码都挺神的，这点小任务应该不在话下。

然而，真正开干之后才发现，OC/Swift 混编的水比我想象的要深得多。AI 生成 Swift 代码倒是挺快，但一编译就全是红波浪线，报错信息五花八门，看得人头皮发麻。

OC Block 到 Swift 闭包转换示例

Block 与闭包转换对比

桥接头文件混乱：混编项目中，Bridging-Header.h 是重中之重。很多 OC 的宏定义、第三方 SDK 的声明都需要在这里正确暴露。Claude Code 有时候会忽略某些依赖，导致 Swift 找不到对应的符号。
内存管理差异：OC 的引用计数和 Swift 的 ARC 虽然都是自动管理，但在混编场景下，一些代理属性的修饰（比如 weak/strong）很容易搞混。AI 在转换时偶尔会漏掉 weak，导致循环引用，内存飙升。
Block 和闭包的转换：OC 的 Block 和 Swift 的闭包虽然看起来像，但细节上差别不小。特别是涉及到 self 的捕获和上下文传递时，写法完全不同。AI 有时候会直接把 OC 的 Block 语法生搬硬套，虽然语法上可能通过，但运行时直接崩溃。
第三方 SDK 的 Swift 封装：有些老牌的 OC 第三方库根本没有 Swift 版本。虽然可以通过桥接直接用，但如果你想用 Swift 的风格去封装一层，或者用 Swift 的泛型、扩展去增强它，AI 往往会生成一些看起来很高级但根本调不通的代码。

最搞心态的是，每当你解决一个问题，编译器就会扔出三个新问题。改了一下午，那个模块依旧跑不起来。原本以为 AI 能把效率拉满，结果大部分时间都在跟 Xcode 报错做斗争，还得自己手动去猜 AI 的意图，反向调试它生成的代码。

虽然这次尝试有点“翻车”，但也不能全盘否定 AI 的作用。回顾一下，如果是纯手写重构，可能需要两三天，AI 至少帮我把骨架搭好了，语法转换也完成了 80%。剩下的 20% 才是最难啃的骨头。

如果想用 AI 辅助混编重构，建议采取以下策略：

小步快跑，不要贪多：不要试图一次性把整个模块丢给 AI。最好是逐个文件、逐个类地进行迁移，确保每一个类编译通过，再进行下一步。
手动控制桥接头文件：不要让 AI 自动去改 Bridging-Header.h，自己手动维护这个文件，明确知道哪些 OC 接口暴露给了 Swift。
注重类型安全：AI 生成的 Swift 代码有时候会滥用 Any 或 AnyObject，这在 Swift 中是大忌。一定要手动检查，把类型定义得清晰明确，利用 Swift 的强类型系统提前发现问题。
善用测试用例：在迁移前，最好有 OC 的单元测试。迁移后，跑一遍测试，能快速发现逻辑上的偏差。

Claude Code + MiMo 2.5Pro 这一套组合拳，在处理纯代码逻辑时确实很强，但在遇到 OC/Swift 这种由于历史包袱导致的复杂上下文时，还是会有些力不从心。它可以帮你省掉敲键盘的力气，但省不掉思考架构和处理边界情况的脑力。

旧项目重构这事儿，急不来。AI 是个强有力的副驾驶，但方向盘还得自己握紧。下次再遇到这种硬骨头，我可能会更谨慎地拆解任务，不再指望一键生成完美代码了。