我的与 Fable 的冒险

最近，Fable 这个新型超级 AI 模型引起了很多讨论。论坛上热烈讨论其对网络安全的影响，立法者们正在商讨其政治影响，而金融分析师们则对其运营成本感到束手无策。

为了更好地理解这个问题，Fable 的价格是非常昂贵的。使用其 API 的费用大约是使用 Opus 4.8 的 10 倍，甚至是使用 Sonnet 5 的 50 倍，相比之前的 GPT 模型（在 Sol 推出之前），也贵了 15 倍。

尽管有“天才税”，我还是决定尝试一下，抛开偏见。我的目标和任何技术总监一样：用更少的资源，做更多的事情，并且更快。想看看成本是否能通过回报来证明其合理性。

所以我的团队和我直接将 Fable 连接到我们的工作流程和日常分析中。在接下来的 48 小时里，我们学到了一个关于技术天才和商业荒谬的精彩教训。

主动的天才和 GitLab 的漏洞

在扫描我们的基础设施后几分钟，Fable 就发现了问题。我们的 GitLab 环境中有一些开源库存在漏洞。

对于非技术人员来说，GitLab 是一个开发协作和版本控制的平台，全球有超过 100,000 家组织使用它来存储代码和自动化部署。它是软件运营的核心。

Fable 不仅仅发现了问题，还主动寻找这些库的源代码，分析了补丁，并提供了完整的修复过程。令人难以置信的是，GitLab 多年来一直存在这些问题，却几乎没有人注意到，而 Fable 只用了几分钟就找到了。

无法触及的数据库

不久后，我们将 Fable 应用于一个历史性的问题：一个非常古老的 MySQL 数据库的技术债务。多年来，我们一直不敢碰它，理由是更新它可能会因为与旧系统的兼容性问题而破坏运营。

当我们要求 Fable 分析为什么不能迁移这个数据库时，模型直接忽略了我们的悲观假设。它决定可以做到这一点。在几小时内，Fable 创建了一个主脚本来完全更新 MySQL 引擎，并编程了整个中间过程（中间件），以确保向后兼容性。它解决了我们早已放弃的问题。

与现实的冲突（和账单）

从纯粹的工程角度来看，Fable 是神奇的。但从业务角度来看，故事就完全不同了。Fable 的主动性对我们的实际运营产生了什么影响？完全没有。

我承认我们没有实施 GitLab 的补丁。为什么？因为在分析了漏洞后，我们意识到在我们的特定情况下，这个缺陷不会对我们的数据、客户数据或内部项目构成风险。我们可以很好地继续下去。

另一方面，Fable 修复的 MySQL 数据库是一个即将被淘汰的遗留系统。修复它不会为这个季度的目标带来任何价值，因为整个系统很快就会被淘汰。

然后，账单来了：Fable 的前 48 小时自主使用为我们带来了 845 美元的 API 账单。我们花费了几乎 1000 美元，让一台超级计算机漂亮地解决了两个在运营上不存在的问题。

一只燕子并不代表春天

到目前为止，Fable 还没有找到其他能够证明其日常费用的运营问题。事实上，我们当前的主力，Sonnet 5，以远低于 Fable 的成本，发现了 95% 相同的问题。

我并不怀疑 Fable 的力量。我相信在网络安全攻击或生物技术实验室等领域，Fable 每一分钱都能被充分利用。但我没有证据证明对于大多数传统企业来说，Fable 在今天是值得的。

当然，这些只是轶事。我的团队和我不会放弃 Fable，但会将其放在“紧急情况下破玻璃”的架子上。它只会被用于不可能完成的项目。

真正的指挥家

如今，我们的策略更加务实。我们使用 Sonnet 5 进行繁重的工作，并将复杂的负载迁移到 GPT Sol（OpenAI 的新旗舰模型，专注于连续推理和高可靠性代理）。

但我们对未来的真正赌注是本地 AI。我们密切关注着强大的中国模型 Kimi K3。我们的目标是将其部署在我们的服务器上（on-premise）。Kimi K3 目前的挑战是需要大量的 GPU 和 VRAM 来运行，但我们希望通过在接下来的几个月内进行良好的蒸馏和量化，Kimi 能够成为我们内部 AI 代理的伟大指挥家，免费且私密。

在 2026 年，智能并不稀缺；稀缺的是判断何时需要购买一辆法拉利去街角，何时更好地步行的常识。

我很乐意阅读你们的经历。你们是否在支付 Fable 的“天才税”，还是更喜欢优化？欢迎分享。