Fable 5 碎碎念

刚刚，我取消了当前最强模型 Fable 5 的订阅。

这绝非因为它的技术不够惊艳，是因为在经历数天高强度的真实测试后，我始终在直面一个深刻的认知错位：我们总期盼雇一位独当一面的“天才合伙人”，看似低成本，实则只能取代一部分重复劳动，很多时候更需要你极高的培养成本，仍难满意。

当你把 AI 从聊天、写周报的“娱乐区”真正拉入包含上下游的“生产区”时，这种落差便会以前所未有的焦虑呈现出来。

一、大模型失效的几个盲区

在几天的极限测试中，我将博客代码重构、视频自动化（Remotion）、音视频多模态处理（RSS/Podcast 文本提取）以及 TTS（语音合成）的工作流全盘交给了 Fable 5。结果证明，大模型在处理复杂工程时，容易陷入三个问题：

1. 还是会偷-懒局部最优陷阱 以博客构建（Hugo）为例，这不仅是改代码，而是体验设计。Fable 5 能漂亮地重写页面 A 的 CSS，却根本意识不到页面 B 的响应式结构也存在同类问题需要一并修改。**大模型的本质是基于上下文的概率预测引擎，其注意力机制极易收敛于局部任务，丧失对系统架构的全局监控。**它能改对一行代码，却无法感知整个项目的连锁反应。

2. 经常性选择不主动 处理长音频转录（Podcast ASR）时，只要我不给出极其死板的格式约束，它就会把几万个字符直接堆砌在屏幕上——没有段落，密密麻麻一整块。即使让它开始分段，又可能把表格拆成几个散落的段落。除非给出死命令，否则它只做最低成本的输出，完全没有主动优化信息展示的意识。

3. 产出带幻觉的方案 最典型的是在探索 Gemini 3.1 Flash TTS 的最佳工程实践时，Fable 5 迅速给出了一套看似高深、实则经不起推敲的“高级方案”。一旦投入实战，音频节奏断裂、响度不一、缓存逻辑冲突等问题便层出不穷。**面对未知与风险，AI 的第一反应不是承认不会并请求指引，而是利用庞大语料库拼凑出一个看似逻辑自洽的幻觉。**你着急要个结果，它更会用看似完美的设计把 Bug 埋得更深。最终你非但未被解放，反而疲于救火。

二、驾驭 AI 之道

反复遭遇这些问题后，我得出一条结论：模型越强，对使用者的架构能力、工程素养与需求拆解能力要求就越高。过去常说的“品味”，或许称作救火队长更贴切。

你必须在 AI 捅出篓子前预判风险，并随时介入修正。不能再幻想随手丢一个目标便袖手旁观；负责的环节越多，越需要一套防错的工程化与提示词。

谋定而后动 不要用语言描述视觉，那是一种低效的跨模态翻译。以设计网页为例，直接让大模型输出最终代码极其危险。更聪明的做法是：让 AI 先用基础 HTML 写出四个视觉方向截然不同的原型。有了具体的页面，然后才开始针性地深入迭代。

多智能体博弈 一个即便技艺高超的架构师，也很难精通若干项目中的所有模块。虽然 Fable 5 模型依然很强，但也必须采用不同模型交叉审阅的策略。千万不能因为强就让它既当运动员又当裁判。动工前，先让 Fable 5 输出一份详细的方案，再将这份方案交给另一个模型 Review。这是提前发现问题关键：算力换人力，决策权还在你的手中。

做提问的架构师 模型越强，以前庞大提示词越可以精简，但对边界与约束的划定要求反而更高。你不能指望抛出一个问题，AI 就能自动完成“痛点识别、方案设计、连带问题处理、完美交付”的闭环。

好的过程应该包含这几步： 第一步：与人和 AI 共同发散式头脑风暴（探索） 第二步：原型设计（验证） 第三步：多模型确认详细技术方案（减少风险） 第四步：分步交付，循环迭代

写在最后

好的模型固然不错，能够十倍百倍提升生产力。但于此同时，也有给使用者带来极大的挑战。随着任务和项目的越来越复杂，反而更需要驾驭它的人有着足够充分的经验。

本以为优秀的模型更能填补自身能力的空白，然而焦虑却更快浮现。他更快地让我照见了哪些在方案、技术上的盲区。

当然这种感知很重要，让你不得不去思考，如何寻觅到把 AI 化为超级生产力的钥匙：是重复劳作，还是是品味？是在 AI 模型中，还是模型之外？

取消订阅后，我照例去煮了碗面。自己准备食材，自己点的火。 煮了几十年，除了享受过程似乎并不需要啥捷径。