Cloudflare AI功能异常事件的技术根因分析

曾经，Cloudflare 就像蝙蝠侠的身份一样隐藏在幕后，让互联网变得更好：保护城市、打击坏人……好吧，我说的是互联网。

十年前我第一次在自己的网站上安装 Cloudflare 时——它帮我省了大量带宽、省了账单费用，同时还在每月发给我一份网站运行报告……那一刻我就知道 Cloudflare（简称 CF）太牛了。

因为 Cloudflare 当时做对了几件事：挡在网站前面、扛下攻击、缓存静态资源、管 DNS，仅此而已。

没有废话。基础设施扎实。速度快。稳定可靠。无聊得恰到好处。

新出的那些东西。可就不是那么回事了。

更重要的是，这是我在我个人博客上发表的的个人观点，你可以不同意，这完全没问题！

从本质上说，我在一家小型 AI 创业公司工作，依赖 CF，算是一个不算太开心但也不算太不开心的客户。

CF 是一家大企业，一台庞大的赚钱机器。如今它比以往任何时候都更大，仍然承载着大量日常网络流量（大约每 3 个请求中就有 1 个）。为股东们和诸如此类的人干得好，他们出售的安全和缓存层确实在做正确的事、付得起账单（写这篇文章时股价正处于历史新高）。

不管股票表现多好，过去几年 CF 还是把自己变成了一个有点尴尬和搞小圈子的公司（虽然没别人那么糟糕，咳咳 △）。

如今，它不再像一家由优秀工程师运营的公司了，现在都是 PM 和 vibecoder，我称之为 AI 精神病：梦想它 -> 感觉它 -> 发货它。失去了与现实的连接

首先，故障比以往任何时候都多，还记得那个 React useEffect 的烂摊子吗 [0]？在一个运营着大约三分之一互联网流量的基础设施公司发生这种事，简直疯狂。

故障无处不在，但来说说我最大的抱怨：DX。

开发者体验感觉像是被当作事后诸葛亮补上去的。

但 CF 是一家基础设施公司，有一群很酷的工程师，DX 不应该是一流的吗？

相反，CF 决定也要成为面向所有人的云平台——小孩、狗、还有 vibers。

我们是怎么走到这一步的？AI 产品经理的思维方式。

发货垃圾，在 X 上发帖子，得到 200 个赞，然后重复。

不去专注专业性、可靠性和简单性……

就这样，一家基础设施公司被产品管理成了它曾经解决的问题的同类。

做同一件事的方式太多，没有一个真正好用

当一家基础设施公司被完整的产品管理组织碾压时，你就知道接下来会发生什么：首先功能开始泛滥。命名变成营销（Hyperdrive？听起来很酷对吧？发货）。唯一似乎重要的就是一些半成品的原始组件，表嫂-老婆风格（cousin-wife style）。

例子？好 -> 让我们看看数据存储。

他们有 D1（无服务器 SQLite）、 Durable Objects 自带的 SQLite、KV、R2、Queues，还有 Hyperdrive 来加速外部 PostgreSQL 或 MySQL。

仍然没有真正的原生一流托管 PostgreSQL。关键词是它必须感觉原生。

Hyperdrive 是一个智能连接池和缓存，用于位于其他地方的数据库。

有用，但这等于承认他们从未构建大多数严肃应用仍然需要的数据库。

最后你得把三四个存储产品粘在一起，希望那个组合的文档不是落后六个月（IYKYK）。

好吧也许你会想："你根本不知道你在说什么哥们"。

让我们看看计算这一侧。

计算是一样的一团糟。

有 Workers。还有 Dynamic Workers，运行时生成的 isolate，作为 AI agent 和不可信代码的轻量级容器替代品销售。

然后是 Sandboxes（基于 Containers）。

然后是完整的 Containers……

还有围绕这一切的一大堆"代码模式"路径，让 agent 可以编写和运行代码。每一个都有不同的隔离、启动时间、定价和绑定。没有一个是简单的"你运行代码的地方"。在它们之间做选择意味着要阅读多个相互矛盾或落后于实际产品的文档页面。

好吧也许你会说："哥们，我们需要不同的计算层级用于不同的场景"。好吧——那肯定是我又错了。

让我们看看最新的炒作。AI Agents。

Agent 更加嘈杂。Agents SDK。Flue。Project Think。Cloudflare OS（他们刚刚开源了内部 agent 工作空间）。

然后可观测性是后来才补上的（见本节下方的更多内容）。

每一个新发布都添加了另一套工具或框架，而不是完善他们已有的那个。经典产品经理手法：增加更多表面积，最大化不连贯性，直到开发者体验感觉像一个逃出沙箱的内部实验（懂吗？）。

RAG 同样的故事。AutoRAG 更名为 AI Search。它只是 R2、Vectorize、Workers AI 上的托管管道。对演示和黑客马拉松来说还行。但在实际使用中，它在质量、过滤、混合搜索和实际可见性方面落后于正经的 RAG 平台，甚至落后于一个像样的开源技术栈。当它"对简单案例有效"时……你就知道这对于一家基础设施公司来说标准有多低了。

再给我加几颗樱桃好不好？

文档要了我的命。你不能只是"重新设计" UI 就说工作完成了。页面发布时不完整。示例腐烂。新产品上线时没有真正基础设施所需的那种精确的、带版本号的参考资料（甚至是 agent 的基本 SKILL.md 之类的东西）。

信任消失了 当公司自己在发货 AI 生成的内容，后来还需要免责声明和 TODO 清理 [1]。每个工程师都知道文档是产品的一部分。如果你连文档都做不好——怎么能获得采用和信任？把它当作次要的营销来对待……不太行。

瞥一眼 Workers AI，这个推理层，只是延续了这种模式：随着延迟改善和他们添加了更大的开源模型，事情似乎在往上走，但再深入看就会发现，在很多工作负载的速度上，它仍然落后于专业提供商，而且在拥有最新的前沿模型方面也是如此。

Cloudflare 标榜自己是运行 agent 的地方，但模型目录比去年宜家的还差。然后性能迫使很多团队把困难的推理任务发送到别处，把 Cloudflare 当作管道再使用一次 [2]。

很多这一切来自于更在意在 X 上与 Vercel 竞争，而不是在基础设施层之上构建一个坚实的层。Edge functions、框架、agent 运行时、"全栈"公告日复一日地涌来，但让 Cloudflare 与众不同的核心网络、可靠性和简单性得到的关注越来越少。AI 精神病似乎已经席卷了整个高层，产品组织被衡量的标准变成了功能速度和竞争帖子，而不是让现有东西做到极致。

这场 AI 狂热导致整个团队产生了一个庞大的、重叠的工具目录，每一个都足够好到能发一篇博客。没有一个是为基础设施客户真正需要的清晰、持久的答案。

这就是当没有人阻止他们时，产品经理对一家基础设施公司做的事。他们优化的是发布频率和表面积增长。那个让 Cloudflare 变得重要的连贯、可信的基础设施层？在那堆噪音下面越来越难找到了。

Workers 可观测性仍然不完整，而且很烂

Cloudflare 多年来一直在宣布可观测性的进展。日志变为"正式可用"。仪表板中出现了统一可观测性部分。自动追踪进入公开测试。查询构建器、指标视图、OpenTelemetry 导出被添加进来。营销说终于有了与平台匹配的第一方可观测性。吧

现实感觉完全不同，因为核心部分在你需要时仍然是残缺的、有 bug 的，或者干脆缺失的。

他们自己的文档列出了从未消失的硬性限制。追踪仍然是公开测试 [3]（2026 年 8 月他们的文档网站上，追踪名称旁边的徽章上 literally 写着 BETA）。非 I/O 操作经常因为运行时中的 Spectre 缓解措施而报告 0 毫秒。追踪上下文不会传播到外部服务，因此跨非 Cloudflare 内容的端到端可见性被人为破坏。Span 属性不完整；他们仍在计划添加更多。甚至付费账户也报告平台错误地应用了激进的 1% 采样，即使 head_sampling_rate 设置为 1 且使用量远低于配额——幸运的是这个问题已被修复 [4]。你怎么能带着 bug 发货日志，其他人会用可观测性吗？

社区帖子显示了日常的痛苦（别担心他们把社区经理炒了 facepalm 又一个糟糕的决定）：人们报告说日志从仪表板消失，而 wrangler tail 仍然实时显示它们。2026 年 3 月的一个大事故导致整个账户的大部分日志停止显示——即使配置正确、配额可用、没有代码更改，也只有零散的条目出现。

一位开发者说得很好："一键获取 workers 的日志和追踪是缺失的那块，workers 可观测性一直是薄弱环节。"他们不断发货相邻的功能，而"我想为 Workers 获得可靠日志记录"这一基本体验仍然不完整。

产品发布优于基础设施

记得这个场景吗？那是星期一。打开 HN 并大喊"爸爸醒醒新的 Cloudflare 产品发布了"。几小时内一个产品经理在 X 上发布公告。帖子针对参与度优化——干净的截图、大胆的声明、一个帖子串。然后是长的博文：一篇 6000 字的故事、有抱负的框架、仪表板截图、一些客户引言，几乎没有关于艰难权衡或为什么选择这个设计而非其他方案的真正技术讨论。谈论工程决策被认为是秘方吗？还是因为 ChatGPT 建议这样？

每隔一个星期一就有新的发布：一个 agent 工具。另一个沙箱变体。另一个托管 RAG 管道。另一个运行代码的方式。

帖子在一英里外就闻起来像市场营销，但你是基础设施公司。还有谁会读那些博客？营养师？

基础设施 nerd 们都去哪了？

更深层的问题在产品经理之上。看看当前的领导层，问题不可避免：曾经定义 Cloudflare 的基础设施人员在哪里？

他们仍有强大的工程师（嗨 Kenton Varda）。但重心已经转移。CF 被优化为发布频率、与 Vercel 的竞争定位、以及下一个 AI 故事。那些理解运行全球 anycast 网络的艰难约束、isolate 隔离的微妙之处、控制平面可靠性……的人，现在似乎权威少了。

你怎么知道的？2026 年的裁员使优先级清晰了。大约 1100 个职位被裁，包装成向"agentic"运营模式迈进的 AI 驱动（AI Slop）举措。旧人才持续流向 OpenAI、Anthropic 和其他 AI 实验室。

Cloudflare 需要的是更多 T 型基础设施人员。深入系统、网络、运行时设计和可靠性的人。而产品经理应该存在的目的是为这些人服务。

读到这里你可能不相信，但像我这样的很多人仍然热爱底层产品。云网络。这正是为什么当前的路径如此令人沮丧。我觉得这是死于一千个 AI 垃圾：AI 精神病。

Cloudflare 仍有时间扭转局面。雇用那些真正在意的人，而不是那些在 35 岁时为了发一条病毒推文而追逐 F.I.R.E.（拿着几十万年薪加 RSU）的人。

[0] https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/ [1] https://www.thestack.technology/cloudflare-matrix-blog-ai-assisted-vibe-coding/ [2] https://developers.cloudflare.com/ai/models/ [3] https://developers.cloudflare.com/workers/observability/traces/ [4] https://www.answeroverflow.com/m/1484012295314215104