Cloudflare的AI狂热：从基础设施公司到功能堆砌

Cloudflare的AI狂热曾几何时，Cloudflare像蝙蝠侠隐藏身份一样默默改善互联网：保护并打击坏人，为了哥谭这座全球城市……呃，我是说互联网。

十年前，当我第一次在网站上安装Cloudflare时，它为我节省了大量带宽和费用，而且每月还会发送网站性能报告……那时我就知道Cloudflare（CF）太棒了。因为Cloudflare在几件事上做得很好：它位于你的网站前面，抵御攻击，缓存静态内容，处理DNS，仅此而已。

没有废话。良好的基础设施。快速、可靠，以最好的方式保持无聊。而新东西就没那么好了。更重要的是，这是我在个人博客上的个人观点，你可以不同意，没关系！从根本上说，我在一家小型AI初创公司工作，依赖CF，我是他们既不完全满意也不完全不满意的客户。

CF是一家大企业，一台赚钱机器。如今，他们比以往任何时候都庞大，仍然处理着大量日常网络流量（大约三分之一的请求）。对股东等人来说，他们出售的安全和缓存层做得不错，能支付账单（在我写这篇文章时，股价处于历史高位）。

无论股价表现如何，过去几年CF已变得有些令人尴尬和排外（但不像其他公司那么糟，咳咳△）。

如今，它感觉不再像是一家由优秀工程师经营的公司，而是由产品经理和vibecoders主导，患上了我所说的“AI精神病”：梦想它 -> 感受它 -> 发布它。与现实脱节。首先，宕机次数比以往任何时候都多，还记得React useEffect那次事故[0]吗？

这种事发生在一家运营着约三分之一网络流量的基础设施公司身上，简直不可思议。宕机无处不在，但让我谈谈最大的抱怨：开发者体验（DX）。开发者体验感觉像是事后才想到的。但CF是一家基础设施公司，拥有出色的工程师，DX难道不应该是最重要的吗？

相反，CF决定成为一个面向所有人（孩子、狗和vibers）的云平台。我们是怎么走到这一步的？就是AI产品经理的心态：发布垃圾，发到X上，获得200个赞，然后重复。而不是专注于专业性、可靠性和简洁性……这就是一家基础设施公司如何被产品管理搞成它过去试图解决的问题。

做同一件事的方法太多，却没有一个出色。当一家基础设施公司被庞大的产品管理组织压垮时，你知道接下来会发生什么：首先，功能成倍增加。命名变成营销（Hyperdrive？听起来很酷吧？发布吧）。似乎重要的只是一些半成品的基础组件，就像表亲婚姻一样。

举个例子？好，我们来看看数据存储。他们有D1（无服务器SQLite）、带自有SQLite的Durable Objects、KV、R2、Queues，以及用于加速外部Postgres或MySQL的Hyperdrive。

仍然没有真正一流的、感觉原生的托管PostgreSQL。这里的关键词是“感觉原生”。Hyperdrive是一个智能连接池和缓存，用于位于其他地方的数据库。它很有用，但也承认了他们从未构建过大多数严肃应用仍然想要的数据库。

最终，你不得不把三四个存储产品粘在一起，并希望这些组合的文档不会过时六个月（懂的都懂）。好吧，也许你会想：“你根本不懂，老兄”。让我们看看计算端。哎呀。计算也是一团糟。有Workers。

还有Dynamic Workers，运行时生成的隔离环境，作为AI智能体和不受信任代码的轻量级容器替代品。然后是Sandboxes（基于容器）。然后是完整的Containers……以及围绕这一切的许多“代码模式”路径，以便智能体可以编写和运行代码。

每个都有不同的隔离、启动时间、定价和绑定。没有一个是“你运行代码的地方”。在它们之间选择意味着要阅读多个相互矛盾或滞后于实际产品的文档页面。好吧，也许你会说：“老兄，我们需要不同层次的计算来满足不同需求”。

好吧，那我肯定又错了。让我们看看最新最热门的炒作：AI智能体。智能体更嘈杂。有Agents SDK、Flue、Project Think、Cloudflare OS（他们刚刚开源了内部智能体工作区）。

而可观测性则是后来才加上去的（本节下文会详述）。

每一个新公告都增加另一个工具或框架，而不是完善已有的。经典产品经理操作：扩大表面积，最大化不连贯性，直到开发者体验感觉像是一个逃出沙盒的内部实验（懂吗？）。RAG也是同样的故事。AutoRAG改名为AI Search。

它只是R2、Vectorize、Workers AI上的一个托管管道。适合演示和黑客松。但在实际使用中，它在质量、过滤、混合搜索和实际可见性方面落后于真正的RAG平台，甚至不如一个像样的开源栈。

当它“适用于简单情况”时……你知道这对基础设施公司来说是个低标准。再给我加点樱桃好吗？文档让我抓狂。你不能只是“重新设计”UI就完事了。页面发布不完整。示例腐烂。

新产品没有精确的、带版本号的参考材料（甚至没有给智能体用的基本SKILL.md），而这些是真正基础设施所需要的。当公司自己发布AI生成的内容，后来需要免责声明和TODO清理时，信任就消失了。[1]每个工程师都知道文档是产品的一部分。

如果文档做不好，你怎么能获得采用和信任？把它当作次要营销……不行。

看看Workers AI，推理层，也延续了同样的模式：随着延迟改善和更大开放模型的加入，情况似乎有所好转，但深入观察，你会发现它在许多工作负载的速度和最新前沿模型方面仍落后于专业提供商。Cloudflare把自己定位为运行智能体的地方，但目录比去年的宜家还差。

性能迫使许多团队把繁重的推理任务送到别处，再次把Cloudflare当作管道。[2]这很大程度上源于更关心在X上与Vercel竞争，而不是在基础设施层之上构建稳固的一层。

边缘函数、框架、智能体运行时、“全栈”公告日复一日地发布，但让Cloudflare与众不同的核心网络、可靠性和简洁性却得不到持续关注。感觉AI精神病已经笼罩了整个高层，产品组织以功能速度和竞争性帖子来衡量，而不是让现有产品变得出色。

这股AI热潮让整个团队生产了大量重叠的工具目录，每个都足以写篇博客。但没有一个是基础设施客户真正需要的清晰、持久的答案。这就是产品经理在没人阻止时对基础设施公司做的事。他们优化公告节奏和表面积增长。

那个让Cloudflare重要的、连贯可信的基础设施层呢？

在所有这些噪音下，那个层越来越难找到。Workers Observability仍然不完整，而且很糟糕。Cloudflare多年来一直在宣布可观测性的进展。日志“正式可用”。仪表板中出现了统一可观测性部分。

自动追踪进入公开测试版。添加了查询生成器、指标视图、OpenTelemetry导出。营销说第一方可观测性终于与平台匹配。哈哈，开玩笑。现实感觉大不相同，因为核心部分仍然不完整、有缺陷，或者在你需要时缺失。

他们自己的文档列出了从未消失的硬性限制。追踪仍是公开测试版[3]（他们的文档网站上，追踪名称旁边的徽章上明确写着BETA，2026年8月）。由于运行时中的Spectre缓解措施，非I/O操作通常报告0毫秒。

追踪上下文不