Fable 5 刷屏的时候，我第一反应是：我们做国内 B 端 AI 产品，又被合规要求锁在国产模型上，看个热闹就差不多了。后来我发现，这个反应太顺手，也太危险。
海外旗舰模型的发布稿，对我们这类产品经理来说，不只是新闻。它更像一份提前几个月出现的产品路线提示：哪些功能只是临时补模型短板，哪些能力会随着模型升级变薄，哪些资产反而值得继续加码。这篇文章不是聊 Fable 5 有多强，而是记录我读完发布稿后，怎么把自家产品的功能清单重新扫了一遍。

我做的是教育行业的 B 端 AI 产品。模型选型这件事，不是想接什么就接什么，合规要求摆在那里，基本锁死国产模型。所以 6 月 9 日 Anthropic 发布 Claude Fable 5，朋友圈连续刷屏的时候，我一开始的心态很简单：它再强，和我也没太大关系。但我后来把发布材料又看了几遍，越看越觉得不该这么想。

过去两年，大模型能力的传导路径已经很清楚了。海外旗舰先把某个能力打出来，国产模型和开源模型随后跟进。推理能力是这样，长上下文是这样，工具调用和 Agent 能力也是这样。中间有时间差，但方向基本没变过。

Slock AI 创始人 RC 在 42 章经播客里也提到过，国产或开源模型追上当前海外旗舰能力，大体只是时间问题。他给的估计是 3 到 6 个月。这对被国产模型锁住的产品团队意味着什么？

意味着今天看起来“用不了”的能力，很可能就是几个月后你产品里的基础设施。Fable 5 今天原生解决的问题，可能就是你现在某个功能正在努力补的坑。

别人看发布会，是看模型厂商秀肌肉。产品经理看发布稿，更应该问一句：如果这些能力半年后变成标配，我手里的功能清单会怎么变？

一、先换一种读法：它到底会吃掉什么

发布稿里通常会写很多能力点。以前我会按“参数强不强、榜单高不高、演示炸不炸”去看，这次我换了一个问法：

如果这些能力变成模型的出厂设置，我们今天做的哪些功能会失去意义？

按这个问题重读 Fable 5，最先冒出来的是三类东西。

第一类，是喂长材料的工序。

过去两年，很多 AI 产品都围着“怎么把材料喂给模型”做了一大圈工程：切片、检索、拼接、摘要、压缩，再把结果塞回上下文。这个链路当然有价值，但里面很大一部分价值，来自模型上下文不够长。

Fable 5 给到百万 token 级别上下文后，过去需要切几十段才能塞进去的材料包，现在可以更接近“一次读完”。这不代表 RAG 明天就没价值，也不代表知识库产品要集体重写。但那些只为绕过上下文长度限制而存在的工序，价值会明显变薄。

第二类，是为模型搭的脚手架。

发布材料里有个很直观的例子：模型玩《宝可梦·火红》，不再依赖额外的地图、导航和游戏状态信息，只看原始画面也能往前推进。

这件事对做 Agent 产品的人很刺耳。我们过去做了很多编排层、状态层、辅助工具，本质上是在帮模型补视野、补记忆、补流程理解。模型短板越明显，脚手架就越厚；模型能力一旦补上来，脚手架的厚度就会被重新定价。

第三类，是通用评测能力。

这一点最容易误读。Fable 5 提到模型可以自我更新技能，甚至开发评测框架和评估体系。乍一看，会让人觉得“评测也要被模型做掉了”。

但我觉得这里要分开看。

模型确实会越来越擅长“怎么测”。它能生成测试集，能写评测脚本，能搭一套通用评估流程。可“测什么算好”，仍然要回到具体业务里。教育场景里，答案是否合规、讲解是否适合学生阶段、反馈是否会误导老师，这些标准不是模型厂商在发布稿里能替你定义的。

Kuse 的 CTO 宇豪在播客里把提前投入评测框架，视为他们很重要的决策之一。他的提醒也很直接：Agent 已经足够强了，但 evaluation 依然需要做。

所以被削弱的不是评测本身，而是通用评测方法论的稀缺性。真正值钱的，是沉在业务里的评测标准。

读到这里，我对 Fable 5 的理解变了。它不是在告诉我“某个模型更强了”，而是在提醒我：凡是只为补模型短板而存在的功能，都要重新算账。

二、动作快的人，早就在按这个逻辑做选择

这个判断并不是 Fable 5 发布后才成立。更有意思的是，很多一线团队在它发布前，已经在按类似逻辑做取舍。

42 章经有一期播客，请的是 Slock AI 创始人 RC。他们公司很小，7 个人加 40 个 Agent，在自己的产品里高频使用多 Agent 协作。

节目里聊到一个问题：群里发一个任务，Agent 们会默认“这活是我的”，于是一起抢答。

这个问题当然可以做得很重。比如给每个 Agent 做严格消息隔离，谁被 @，谁才看得到任务。但他们没有这么做，而是先做了一层很薄的任务认领机制：Agent 要先 claim，claim 到了别人就不能再 claim。

这个处理方式很值得玩味。

它不是没解决问题，而是只解决到“够用”。更重的那层，他们有意先不做。RC 的理由大概是：模型能力还在快速变化，很多现在看起来需要产品层处理的事，之后可能会被模型厂商解决。

我听到这里的时候，第一反应是：这就是“可拆卸补丁”。

抢答问题要解决，因为用户今天就会遇到；但解法不能做成很厚的基础设施，否则模型一更新，旧系统反而变成包袱。更妙的是，他们让所有 Agent 能看到完整消息，虽然有冗余和 token 浪费，却留下了群体学习的机会。一个 Agent 犯过的错，其他 Agent 也能看到和吸收。

也就是说，他们不只是在省工程量，还在避免把未来可能有价值的数据和协作习惯隔离掉。Kuse 的案例更像反面提醒。

宇豪复盘过一个坑：他们早期产品形态和当时的模型能力绑得太重。每次模型有明显突破，产品就要大改。还有一次，他们做设计 Agent 时，觉得当时模型能力不够，工程补偿成本太高，于是放弃了整个场景。后来模型能力补上来，Lovable 跑了出来。

这个教训对我触动挺大。因为它不是简单地说“不要补短板”，而是说：可以放弃重补丁，但不要轻易放弃场景。

补丁会过期，场景不会。你可以用很薄的方式先守住场景，等模型能力补上来；但如果把场景本身放掉，后面模型真的来了，红利也就不在你这里了。

再往旁边看，Sheet0 创始人文锋也提过，他的创业视角已经从“预判未来 5 到 10 年”，变成更多看未来 3 到 6 个月。

这些说法放在一起，我得到的结论是：AI 产品决策的规划周期正在被压短。过去我们喜欢问三年后的差异化在哪里，现在更现实的问题可能是，未来 3 到 6 个月，哪些能力会变成标配，哪些投入还能留下来。

三、我后来用三个问题扫功能清单

为了不让这个判断停在感受层，我给自己设了一个很简单的测试：

这个功能是在补模型短板，还是在建设模型外面的资产？

拆到操作层，我用了三个问题。

第一，这个功能存在的主要理由，是不是“当前模型还不够强”？

如果答案是是，它就很危险。比如切片检索、格式修复、复杂提示词模板、多 Agent 抢答协调，很多都属于这一类。它们今天有用，但价值和模型短板强绑定。

第二，模型变强后，这个功能是增值还是贬值？

私有数据接入、权限体系、行业评测标准、业务流程沉淀，模型越强，这些东西反而越有价值。因为它们不是在替模型补课，而是在给模型提供杠杆。

第三，模型厂商最近的发布稿里，有没有反复讲这个方向？

这不是说发布稿写了，第三方功能就马上没活路。它更像一个提醒：厂商反复强调的能力，大概率会成为未来一段时间的主航道。主航道上的第三方功能，要么跑得足够快，要么就得想清楚自己能沉淀什么。

这里有个常见反例：Cursor 和 Perplexity 一开始也像是在补模型短板，为什么它们活得很好？

我的理解是，它们留下来的不是某一代补丁，而是用户、入口、工作流位置和数据。Cursor 的很多脚手架会被新模型一轮轮改写，但用户已经在它那里写代码，工作流已经发生了迁移，这些东西不是模型厂商简单发一次版本就能带走的。

所以更准确的说法不是“补短板的功能不要做”，而是：你要按补丁失效后还能留下什么，来给这件事定价。

Slock 的任务认领机制就是一个好例子。claim 机制本身随时可以拆，但围绕它产生的协作方式、任务数据、团队习惯可能留下来。Kuse 提到的销售 Agent 也类似：真正可怕的不是 Agent 会写一个 CRM，而是掌握企业客户记忆的 Agent 会写 CRM。数据和记忆，才是模型换代后仍然躺在你手里的资产。

四、我把自家产品清单扫了一遍

道理讲完，还是得回到自己的产品。

这周我把手头产品的功能清单拉出来，按上面三个问题逐条过了一遍。产品细节不方便展开，但结论可以说：清单大致分成了三堆。

第一堆，是容易被模型能力吞掉的功能。

比如知识库问答里的部分切片检索工序、提示词模板调优层、输出格式修复、多 Agent 协调里的胶水逻辑。它们今天当然要用，因为系统要跑起来，用户也不等人。但它们更像临时施工架，而不是未来的主体建筑。

这类功能后续我会尽量控制投入：能薄就薄，能配置化就配置化，尽量别把团队最好的工程时间砸进去。

第二堆，是值得继续加码的资产。

比如多租户权限体系。模型再强，也不能替我们决定“谁能看什么、谁对什么结果负责”。宇豪在播客里提到，Agent 时代的权限还是无人区，谁能做好，谁就有区分度。这句话我很认同。

再比如行业私有知识库、审核规则库、人工复核和签字链路。这些东西看起来不性感，但它们是业务真正落地时绕不开的部分。模型能力越强，反而越需要它们来约束、放大和兜底。

第三堆，是一半危险、一半有价值的功能。

比如 Agent 编排界面。重编排能力本身，会被模型的长任务自主性慢慢削弱；但业务流程的定义权、审批链路、角色分工，这些仍然是资产。

这类功能不是简单砍掉，而是要换投入方向。少花精力在“帮模型一步步走流程”，多花精力在“把业务过程定义清楚，并让模型接得上”。

扫完之后，我没有更焦虑，反而清楚了一些。

之前看功能清单，很多模块都像是“我们需要做的能力”。按这套问题过一遍后，它们开始显出不同的性质：有些是补丁，有些是资产，还有些要从补丁慢慢转向资产。

这个方法的门槛并不高。它不需要真的调用 Fable 5，我也调不了。它只需要两样东西：一份模型发布稿，一张自己的功能清单。

五、下一次模型发布前，可以先做一次小审计

回到开头。我的产品用不了 Fable 5，大概率很多国内 B 端产品也用不了，或者短期内用不起。

但这不妨碍我们读它。

因为它真正值得读的地方，不是“我明天能不能接入”，而是“它透露了哪些能力会变成基础配置”。海外旗舰每发布一次，这张提示图就更新一次；国产模型每跟进一次，提示就兑现一批。

产品经理能决定的不是模型进化速度，而是倒计时走完时，自己手里剩下什么。

如果剩下的是一堆只为旧模型短板服务的补丁，那会很难受；如果剩下的是数据、流程、权限、评测标准、用户习惯和场景入口，模型越强，反而越能把这些东西放大。

那期播客结尾，主持人问 RC：如果模型继续变强，做产品还有意义吗？

他的回答大意是，只要人还在，人就有需求；需求本身就是 idea，至于怎么实现，可以交给 AI。

我挺喜欢这个回答。实现层会被模型一轮轮改写，但问题从哪里来、场景怎么定义、责任怎么落下去，这些并不会自动消失。

所以下一次发布会刷屏之前，建议你也把产品功能清单拉出来扫一遍：

这个功能是在补模型短板，还是在建设模型外面的资产？

这个问题不一定让人舒服，但比很多行业报告更诚实。