• 截至 2026年3月4日，这件事还是“传闻”，苹果还没官宣。

  • 现在最该做的，不是重写项目，而是先把 AI 代码“拆干净”。

  • 只要你的 AI 能力是可替换模块，未来不管叫 Core ML 还是 Core AI，迁移成本都会低很多。

这件事到底是什么状态？

最近一些媒体提到：苹果可能会在 WWDC 2026 推出“Core AI”，并在 iOS 27 相关系统里加强 AI 框架能力。

这里要注意两点：

  1. 目前没有苹果官方最终确认。

  2. 就算有新框架，旧框架也通常不会“一夜消失”，大概率会有过渡期。

所以，别被“替换”两个字吓到。对开发者来说，更重要的是提前把工程结构准备好。

用一句话理解迁移策略

把 AI 功能当成“插拔件”，不要当“焊死在业务里的代码”。

通俗点说：

  • 业务层只关心“输入什么、输出什么、失败怎么办”。

  • 底层是 Core ML、Core AI，还是云端模型，都可以换。

这样做的好处是：框架变了，你改底层；业务页面基本不动。

现在就能做的 5 件事（不等 WWDC）

1. 先做一层统一接口

不要让页面直接调模型。先抽一层，比如 AIService：

  • predict()

  • generate()

  • classify()

  • fallback()

以后换框架，大概率只改这层实现。

2. 把模型管理正规化

至少做到：

  • 模型有版本号

  • 有发布/灰度/回滚流程

  • 能知道线上到底在跑哪个模型

没有版本管理，迁移时最容易“修好A、搞坏B”。

3. 默认“端侧优先 + 云端兜底”

端侧推理会遇到机型差异、内存压力、温控降频。

实操建议：

  • 优先本地跑（快、隐私好）

  • 失败或超时就自动切云端

  • 全程记录切换原因

别把这件事写成零散 if-else，要写进架构。

4. 先把监控打通

至少记录这几项：

  • 模型版本

  • 推理耗时（P50/P95）

  • 失败率

  • 回退率（本地切云端的比例）

没有这些数据，未来迁移后你很难判断“是框架问题，还是模型问题”。

5. 做两套回归测试

  • 效果回归：同一批输入，输出质量是否明显变差

  • 性能回归：加载时长、推理耗时、内存峰值是否超线

迁移真正难的不是“能编译”，而是“体验别变差”。

WWDC 后第一周，建议这样推进

第1-2天：只做信息确认

  • 看官方文档

  • 看官方 sample

  • 列出“必须迁移”和“可以暂缓”的清单

第3-4天：做最小可行 Demo

选你项目里最关键的一条链路（例如图片分类或文本摘要），做一个最小 POC，先验证可行性。

第5-7天：小步替换，随时可回滚

  • 每次改一小块

  • 每次上线前跑回归

  • 保留旧实现开关（feature flag）

这样就算新框架有坑，也不会全线受影响。

小团队最常见的 3 个问题

Q1：要不要现在就重写？

不要。先抽象接口和清理结构，比重写更值。

Q2：如果最后没有 Core AI 怎么办？

也不亏。你做的模块化、监控、回归，本来就是长期收益。

Q3：我现在只有 Core ML 代码，来得及吗？

来得及。先做“统一入口 + 回退策略 + 指标埋点”三件事，已经能把风险降一大截。

最后一句

别把“不确定”当坏消息。

在苹果正式公布前这段时间，正是你整理架构、降低未来迁移成本的窗口期。

等变化真的来时，你要做的应该是“换引擎”，而不是“推倒重来”。