苹果把已经能跑的 Siri 推倒重来，这事比新版本更值得聊
苹果把已经能跑的 Siri 推倒重来，这事比新版本本身更值得聊
事情是这样的。
WWDC26 主题演讲结束后那周，苹果开了一场只对媒体的小型技术分享会，主题就是 Siri 和 Apple Intelligence。新接手 Siri 项目还不到一年的迈克·罗克韦尔在会上说了一段话，我看完愣了一下。
他说，去年他们其实已经做出了第一个版本。就是在原来那套 Siri 的基础上小修小补，加了工具调用的能力，而且能正常跑。那个版本是活的，是能上线的。但他们看了看，觉得这玩意达不到心里想要的产品形态。手上还压着另一套方案，那套要做大规模的底层重构。最后他们的决定是，把已经能跑的那版扔了，完完整整从零再来一遍，彻底拆掉旧架构，依托新的大模型重新搭。
原文在这儿，IT 之家的报道，有兴趣可以去看 原话。
我盯着这段看了好一会儿。
好家伙。一个已经能跑、已经能交付的版本，说不要就不要了。
你要知道，在工程圈里，这几乎是头号禁忌。
二十多年前，Joel Spolsky 写过一篇文章，标题就叫《Things You Should Never Do》，副标题是「你这辈子都不该干的事，第一条」。文章开篇就一句重锤，他说软件公司能犯的最严重的战略错误，就是决定从头重写代码。原文还在，写于 2000 年，到现在每隔一阵就被人翻出来引用一次。
他举的例子是网景。当年 Netscape 决定把浏览器代码推倒重写，结果新版本难产了快三年，老用户跑了一大半，市场份额被 IE 一口吞掉，公司元气大伤。Joel 的核心论点特别戳人，他说那些看起来又脏又乱、你恨不得删掉重写的老代码，里面其实埋着无数你早就忘了的修复。每一个丑陋的 if 判断，每一个莫名其妙的 workaround，背后都是某个真实用户在某个真实场景下踩过的坑，是某个深夜被线上事故 ping 醒的工程师一行一行补回来的。你重写，等于把这几年攒下来的经验值一键清零。
这套论点我是真信的。坦率讲，我自己面对一坨祖传代码的时候，第一反应也是「这能不能重写啊」，但凡有点经验都知道，这个念头八成是错的。重写永远比你估的久，永远比你想的难，而且重写期间你还得分心维护老系统，等于一个团队干两份活。
所以苹果这个决定，第一眼看上去就是往 Joel 的枪口上撞。
但我越想越觉得，这事没那么简单。
得先分清楚，苹果扔掉的到底是什么。
罗克韦尔说的第一个版本，是「在旧 Siri 上加工具调用」。注意，是在旧的那套上加。旧 Siri 是个什么东西，用过的人心里都有数。它就是一套靠意图识别加规则匹配撑起来的系统，你说一句话，它先猜你想干啥，命中了某个预设意图就执行对应的动作，没命中就给你甩一句「我在网上找到了这些」。这套架构在 2011 年是先进的，放到大模型时代，它就是个历史包袱。
在这种架构上加工具调用，能跑，但你想想看，那是什么感觉。底层还是那套猜意图的老逻辑，你在外面套一层 LLM 让它能调几个新工具。就像给一辆烧油的老车塞了块电池，挂个混动的牌子，能开，但它永远不可能变成一台真正的电车。整个动力总成是反着的。
罗克韦尔这帮人看到的，大概就是这个。第一版不是不能用，是它的天花板太低了。你在它上面再怎么努力，做出来的也是个缝合怪。而他们想要的 Siri，是原生多模态的，是隐私从最底层架构就贯穿进去的，是 iPhone、iPad、Mac、Apple Watch、Vision Pro、CarPlay、AirPods 全平台共用同一套大脑的。这些东西，没一个是能靠在旧架构上打补丁打出来的。它们要求的是地基本身就长成这个样子。
随便挑一个展开你就懂了。原生多模态，意思是从你的语音、屏幕上的内容、摄像头看到的画面，统统当成同一种输入流喂给模型，而不是先把语音转成文字、再走一遍老的意图分类。这俩做法的差距，是从输入层就分叉的，不是加个模块能补的。再看隐私这块，苹果一直押的是端侧推理加私密云计算（Private Cloud Compute，把需要上云的那部分放进一个可验证、用完即焚的安全环境里，官方介绍见 Apple Security 博客）。隐私要从底层贯穿，指的是模型在哪跑、数据在哪算、什么东西绝对不许离开设备，这些得在架构设计的第一行就定死，而不是功能做完了再往上糊一层合规。你让一套 2011 年的意图识别框架去原生扛这两件事，它扛不动。地基的承重就那么多。
说到这儿，Joel 那条铁律和苹果这个决定，其实不矛盾。
Joel 真正反对的，是「代码看着丑所以我要重写」这种基于审美和洁癖的冲动重写。他反对的是你嫌弃旧代码的样子，而不是旧代码的能力。但如果旧架构的根本假设已经和你要做的事彻底拧了，那就不是丑不丑的问题了，是它压根支撑不了新目标。这种时候不重构，你才是在自欺欺人。
我自己平时的工作，是给大模型搭那层让它能真正干活的工程脚手架，agent 的工具链、调度、上下文管理这些。这行干久了有个体感，很多系统的痛苦不是出在某个具体函数写得烂，而是出在最初那个架构假设，在当时是对的，在今天是错的。你在错的地基上修得再精致，也是在给一栋歪楼刷漆。
苹果赌的，就是这个判断。
那问题来了，到底什么时候该忍，什么时候该掀桌子？
这个我也没有标准答案，行业里也没有。但我观察下来，有几个信号还挺值得参考。
第一个信号是，你想做的事，是不是和旧系统的核心假设直接冲突。Siri 这个 case 就是典型。旧 Siri 假设「用户的话能被归类到有限的意图里」，新 Siri 要的是「开放的、多轮的、跨模态的理解」。这俩假设是对着干的。当核心假设冲突时，增量改良会让你陷入一种很拧巴的状态，每加一个新功能，都要先和旧假设搏斗一轮，开发速度越来越慢，代码越来越像一团浆糊。这时候重构反而可能是更快的路。
第二个信号是成本结构。Martin Fowler 有个很有名的模式叫绞杀榕（Strangler Fig，他写过一篇介绍），灵感来自热带雨林里那种植物，它会慢慢缠住宿主树，一点一点替换，最后老树枯死，新的藤蔓已经长成了完整的形状。这套思路的精髓是，重构不一定要停下来推倒，可以让新旧并存，一个模块一个模块地迁移，旧的逐渐失去存在的意义。大多数情况下，绞杀榕比直接掀桌子安全得多。但绞杀榕有个前提，新旧系统得能共存、能互相调用。如果旧架构封闭到连个干净的接口都伸不出来，绞杀策略就跑不动，你只能选择真正的从零。
第三个信号，也是最容易被忽略的，是你有没有那个本钱。苹果有什么？它有现成的、不会因为重写 Siri 就停摆的现金流，有一支能扛住三年长跑的团队，更关键的是，它有一个还能用的旧 Siri 在线上顶着，给重构争取时间。这就是为什么当年网景死了而苹果敢这么干。网景是在生死线上重写，重写期间它没有别的牌可打。苹果是在安全垫上重写，旧的还在跑，新的慢慢磨。同样是推倒重来，一个是赌命，一个是换引擎，性质完全不一样。
所以你看，重不重写这个问题，从来就不是一个纯技术问题。它是技术判断、成本结构、还有你兜里有多少余粮，三件事拧在一起的结果。
聊到这儿，我反而对苹果这次的延期，多了一点理解。
过去一年多，外界没少嘲笑苹果的 AI。隔壁家模型一周一个大新闻，苹果这边 Siri 还在那儿磕磕巴巴，Apple Intelligence 一再跳票，发布会上画的饼一个个延期。说真的，这种被同行甩在身后的焦虑，我太懂了。在 AI 这个节奏快到离谱的赛道里，慢一步就像被全世界抛下。
但罗克韦尔这段话让我意识到，苹果那段时间不是没干活，它是在做一件最不讨好的事。一个已经能交付、能拿出去发布会上演示、能堵住所有人嘴的版本，他们选择了不发，回去重做。这个决定要顶着巨大的外部压力，每一天的沉默都在被解读成落后。厉害了，能忍住不把那个半成品推出去，这份定力，比飙参数难多了。
我不是说苹果一定对。新 Siri 到底行不行，还得等真正到了用户手里才知道，发布会上的 demo 谁都会做。但至少在「要不要为了短期止血而交付一个自己都不满意的东西」这个选择上，他们没有走那条最容易的路。
这事让我想起做工程时一个特别拧巴的瞬间。你手上有个能跑的方案，丑，但能交差，deadline 在眼前晃。你心里清楚有个更好的做法，但那条路要推翻重来，要多花好几倍的时间，还不一定成。绝大多数时候，迫于现实，我们都选了那个能交差的丑版本。然后那个丑版本就在系统里活了下来，活成了下一个人眼里的祖传代码，下一个深夜被它 ping 醒的人，可能就是几个月后的我们自己。
苹果这次，是少有的选了另一条路的样本。它有资本这么选，这是事实，但它确实选了。
万能青年旅店有句词，是谁来自山川湖海，却囿于昼夜厨房与爱。
写代码的人大概都有过类似的困境，心里装着山川湖海般的架构蓝图，手上囿于一个个 deadline、一坨坨改不动的旧代码、一次次「先这样能用就行」的妥协。我们大多数时候，都活在那个能用就行的版本里。
苹果这回，难得地朝山川湖海那个方向，走了一步。
至于这步走得对不对，等 iOS 27 真正铺开，Siri 到了我们每个人手机上的那天，自然有答案。我挺好奇的。
新版到底是脱胎换骨，还是又一个发布会上跑得飞快、到手里就卡壳的 demo，我们留着到时候一起验。