Cloudflare的AI狂热:基础设施巨头如何沦为产品经理的试验场?
在互联网的浩瀚星空中,Cloudflare曾是一颗隐秘的恒星。它不张扬,却默默守护着全球三分之一的网络流量,像蝙蝠侠的身份一般隐藏在暗处,为城市(互联网)抵御邪恶势力。十年前,当一位开发者第一次将Cloudflare部署到网站上时,它带来的不仅是DDoS防护和CDN加速,更是一份月度报告 - - 一份简洁的数据报告,告诉你网站的性能表现。那一刻,Cloudflare的伟大之处不言而喻:它专注、高效、可靠,像一台精密的机器,只做最擅长的事 - - 网络基础设施。然而,时过境迁。曾经以工程师文化闻名的Cloudflare,如今却被贴上了「AI狂热」的标签。
它不再满足于做幕后英雄,而是试图成为一个包罗万象的云平台,从数据库到AI代理,从存储到计算,每一项产品都像是一场「概念验证」的实验。曾经的「无聊但优雅」的基础设施公司,如今却陷入了产品经理们的「梦想 - 振动 - 发布」循环中,丧失了对现实的判断力。本文将深入探讨Cloudflare如何从一家专注可靠性的基础设施公司,沦为AI概念泛滥的技术平台,以及这种转变背后的组织文化变迁。我们将分析其产品策略的失误、开发者体验的崩溃、可观测性的缺失,并探讨这种「AI狂热」背后的真正驱动力。---### **从「无名英雄」到「概念工厂」:Cloudflare的蜕变**Cloudflare的崛起是互联网基础设施历史上的一段传奇。2009年成立之初,它的使命很简单:为网站提供安全防护和性能优化,同时保持低调。
这种「隐形英雄」的定位让它在竞争激烈的CDN市场中脱颖而出。它不需要用户记住它的名字,只需要用户感受到它的存在 - - 当网站被DDoS攻击时,Cloudflare挺身而出;当用户访问页面时,Cloudflare让加载速度更快。然而,随着公司规模的扩大和股价的飙升,Cloudflare开始寻找新的增长点。它不再满足于做幕后的守护者,而是试图成为一个「全栈」的云平台。这种转变的背后,是产品经理们对「功能多样性」的痴迷,以及对「AI概念」的盲目追捧。曾几何时,Cloudflare的产品线清晰明了:- **DNS**:全球分布式的域名解析服务。
- **CDN**:静态资源的缓存和加速。- **DDoS防护**:抵御网络攻击的盾牌。- **Workers**:轻量级的边缘计算服务。这些产品都是为特定场景设计的,每一项都经过严格的工程验证,确保可靠性和性能。然而,随着AI热潮的兴起,Cloudflare开始疯狂扩张产品线,试图在每一个细分领域都占据一席之地。---### **产品过度扩张:从「一招鲜」到「样样稀松」**Cloudflare的产品策略如今让人联想到一家「概念工厂」。
它不再专注于核心竞争力,而是试图在每一个新兴领域都推出一个产品,哪怕这个产品只是半成品。这种「样样通、样样松」的策略,让开发者们陷入了选择困难症。#### **1. 存储层的混乱:从SQLite到R2的「亲戚」**Cloudflare的存储产品线如今已经变成了一场「亲戚聚会」。它有:- **D1**:Serverless SQLite数据库。- **Durable Objects**:带有SQLite的持久化对象。- **KV**:键值存储。
- **R2**:对象存储。- **Queues**:消息队列。- **Hyperdrive**:外部PostgreSQL/MySQL的连接池和缓存。乍一看,这些产品覆盖了从键值存储到关系型数据库的各种需求。但实际使用起来,开发者们却发现:- **没有原生的PostgreSQL**:虽然D1和Durable Objects都支持SQLite,但大多数严肃的应用仍然需要PostgreSQL。Cloudflare迟迟没有推出原生的PostgreSQL服务,而是通过Hyperdrive来「临时抱佛脚」。
- **产品之间的割裂**:要想构建一个完整的应用,开发者可能需要同时使用D1、KV和R2,但这些产品的API、文档和最佳实践完全不同,导致集成过程充满坑。- **文档的滞后**:Cloudflare的文档更新速度跟不上产品发布速度。许多新功能的文档要么缺失,要么过时,甚至有些功能在发布时就带着「TODO」标记。这种混乱的产品策略让Cloudflare失去了「基础设施公司」的核心优势 - - 可靠性和简洁性。曾经,开发者只需要了解Cloudflare的DNS、CDN和Workers,就能构建一个高性能的网站。现在,他们需要花费数周时间来研究如何将D1、KV和R2组合在一起,而最终的结果可能仍然不如直接使用AWS RDS或PlanetScale。
#### **2. 计算层的「分裂」:从Workers到「代码模式」的泛滥**Cloudflare的计算层同样陷入了混乱。它提供了多种运行代码的方式:- **Workers**:轻量级的边缘函数。- **Dynamic Workers**:为AI代理和不可信代码设计的运行时隔离。- **Sandboxes(容器)**:更重量级的容器化运行环境。- **完整的容器服务**:类似于AWS Fargate的容器服务。- **「代码模式」**:为AI代理提供的代码编写和执行环境。
每一种运行方式都有不同的隔离机制、启动时间、定价模型和绑定方式。开发者在选择时,需要阅读多个文档页面,甚至可能面对相互矛盾的信息。这种「分裂」的计算层让Cloudflare失去了「统一运行环境」的优势,使得开发者体验变得复杂而低效。更讽刺的是,Cloudflare曾经以「简单」和「一致」著称。现在,它却在试图通过「多样性」来吸引不同的用户群体,却最终让每一个人都感到困惑。#### **3. AI产品线的「噪音」:从RAG到AI代理的泛滥**Cloudflare的AI产品线更是让人眼花缭乱。
它推出了:- **Agents SDK**:AI代理的开发工具包。- **Flue**:AI代理的运行时环境。- **Project Think**:AI代理的工作空间。- **Cloudflare OS**:开源的内部AI代理工作空间。- **AI Search(前身为AutoRAG)**:托管的RAG(检索增强生成)管道。- **Workers AI**:边缘AI推理服务。
每一种产品都试图解决AI开发中的某个具体问题,但最终的结果却是「样样稀松」。例如:- **AI Search**:Cloudflare将其定位为「托管的RAG管道」,但实际使用时,它缺乏高质量的过滤、混合搜索和可观测性。对于简单的用例可能够用,但对于生产环境的应用来说,它远远落后于专业的RAG平台(如Pinecone或Weaviate)。- **Workers AI**:虽然Cloudflare在边缘AI推理方面取得了一些进展,但其模型目录仍然落后于专业的AI提供商(如Hugging Face或Together AI)。许多开发者发现,在Cloudflare上运行推理任务时,延迟和模型质量无法满足生产需求,最终不得不将关键的推理任务外包给其他平台。这种「泛滥」的AI产品线让Cloudflare看起来更像是一家「概念验证」公司,而不是一家能够提供可靠AI基础设施的公司。
开发者们不禁要问:Cloudflare到底想成为AI代理的运行平台,还是仅仅追赶AI热潮的「概念工厂」?---### **文档与可观测性的崩溃:信任危机的根源**任何一家基础设施公司的成功,都离不开两个关键要素:优秀的文档和可靠的可观测性。然而,Cloudflare在这两个方面的表现,让人怀疑它是否还在认真对待「基础设施」这个核心业务。#### **1. 文档的「设计」vs「实用」**Cloudflare的文档曾经以「简洁」和「实用」著称。但如今,它的文档更像是一场「设计师的梦魇」。Cloudflare频繁重新设计文档界面,试图让它看起来更「现代化」,但却忽略了最基础的需求:准确性和完整性。具体问题包括:- **文档更新滞后**:许多新功能在发布时就带着「TODO」标记,或者文档几个月后仍然不完整。
- **例子腐烂**:文档中的代码示例经常过时,或者无法正常运行。开发者们在尝试使用时,往往需要先「修复」示例代码。- **版本混乱**:Cloudflare的产品更新频繁,但文档却没有清晰的版本控制。开发者经常发现,某个功能在最新文档中已经被移除,但在旧版本中仍然存在。- **AI生成的文档**:Cloudflare甚至开始使用AI来生成文档,但这些文档经常包含错误、重复或不完整的信息。更讽刺的是,Cloudflare自己也意识到这些问题,并在某些文档中加入了「TODO」或「需要清理」的标记。
这种对文档的「设计优先」策略,让Cloudflare失去了开发者的信任。曾经,开发者可以依赖Cloudflare的文档来构建可靠的系统。现在,他们需要在使用前先「验证」文档的准确性,或者直接求助于社区。#### **2. 可观测性的「半成品」:从「一般可用」到「Beta forever」**Cloudflare在可观测性方面的投入同样让人失望。它曾多次宣称要推出「统一可观测性」平台,包括:- **日志**:已「一般可用」。- **统一可观测性仪表板**:在控制台中出现。
- **自动追踪**:进入开放Beta。- **查询构建器**:支持指标视图。- **OpenTelemetry导出**:支持第三方工具集成。然而,实际使用时,开发者们发现:- **追踪仍在Beta**:Cloudflare的文档明确标注「追踪」功能仍在Beta阶段(截至2026年8月),这意味着它仍然不够稳定,不适合生产环境。- **采样问题**:即使在付费账户中,Cloudflare仍然错误地应用了1%的采样率,导致关键的调试信息丢失。这一问题直到被社区曝光后才得以修复。
- **日志丢失**:社区中有大量报告称,日志在控制台中消失,但在Wrangler的实时日志中仍然可见。2026年3月的一场大规模事故中,大量日志在整个账户中消失,即使配置正确且配额充足。- **端到端可见性缺失**:Cloudflare的追踪无法与外部服务集成,导致跨服务的端到端可见性被故意破坏。这种「半成品」的可观测性让Cloudflare失去了开发者的信任。曾经,Cloudflare以「网络基础设施」的专业性著称。现在,它在「可观测性」这一基础设施的核心领域,却无法提供可靠的解决方案。
---### **组织文化的崩溃:从「工程师文化」到「产品经理天下」**Cloudflare的蜕变不仅仅是产品策略的失败,更是组织文化的崩溃。曾经,Cloudflare以「工程师文化」和「可靠性优先」著称。但如今,它却被贴上了「AI狂热」和「产品经理天下」的标签。#### **1. 产品经理的「梦想 - 振动 - 发布」循环**Cloudflare的产品发布节奏如今让人联想到一场「概念验证」的竞赛。每隔一段时间,Cloudflare就会在X(前Twitter)上发布一个新产品,配以华丽的截图和雄心勃勃的宣言。这些发布帖子通常包括:- 一个「振动」的标题(例如「Cloudflare OS:AI代理的未来」)。
- 华丽的截图和演示视频。- 一些「客户引用」(通常是合作伙伴或内部团队的吹捧)。- 一个6000字的博客文章,充满了「愿景」和「使命」的空话,却缺乏具体的技术细节。这种「梦想 - 振动 - 发布」的循环让Cloudflare的产品发布变成了一场「营销秀」,而不是真正的技术创新。开发者们不禁要问:Cloudflare到底是在构建可靠的基础设施,还是在追求「病毒式传播」的营销效果?#### **2. 领导层的「AI优先」:工程师的权威被削弱**Cloudflare的领导层变化同样反映了这种文化转变。曾经,Cloudflare的核心决策由工程师和网络专家主导,他们深知「可靠性」和「性能」的重要性。
但如今,Cloudflare的领导层更加关注「AI概念」和「产品发布节奏」,而忽视了核心基础设施的建设。具体表现包括:- **工程师权威的削弱**:曾经,Cloudflare有像Kenton Varda这样的顶级工程师,他们对系统的深度理解是公司的核心竞争力。但如今,这些工程师的声音在决策中被边缘化,取而代之的是产品经理和营销团队的主导。- **AI驱动的裁员**:2026年,Cloudflare进行了大规模裁员,裁减了约1100个岗位。官方将这次裁员归因于「AI驱动的代理化运营模式」。但实际结果是,大量经验丰富的工程师和网络专家离开公司,流向了OpenAI、Anthropic等AI实验室。
- **「T型人才」的缺失**:Cloudflare需要的是「T型人才」 - - 既有深度专业知识(例如网络、系统、运行时设计),又有广度理解(例如产品策略)。但如今,Cloudflare的组织结构更像是「产品经理」主导的「功能工厂」,缺乏真正的技术深度。这种「AI优先」的组织文化让Cloudflare失去了「基础设施公司」的核心优势。曾经,Cloudflare的工程师们以「可靠性」和「性能」为荣。现在,他们却在为「概念验证」和「营销效果」而努力。---### **Cloudflare的未来:是「回归本源」还是「继续堕落」?**Cloudflare的蜕变并非不可逆转。
它仍然拥有强大的网络基础设施,仍然是全球三分之一网络流量的守护者。但要想重新赢得开发者的信任,它需要做出根本性的改变。#### **1. 回归「基础设施」核心**Cloudflare需要重新专注于「基础设施」的核心业务:- **简化产品线**:停止推出「概念验证」式的产品,而是专注于构建「原生」的PostgreSQL、更好的文档和可观测性。- **提升可靠性**:加强对核心服务(如DNS、CDN、Workers)的投入,确保它们的稳定性和性能。- **优化开发者体验**:让开发者能够「一键」部署和调试,而不是让他们在多个产品之间「迷路」。#### **2. 重建「工程师文化」**Cloudflare需要重新重视「工程师文化」:- **提升工程师的权威**:让顶级工程师在决策中发挥更大的作用,而不是让产品经理主导一切。
- **招聘「T型人才」**:不仅需要营销和产品人才,更需要深度理解网络、系统和运行时的工程师。- **减少「AI狂热」**:AI是一个有用的工具,但不应该成为公司的核心战略。Cloudflare需要回到「基础设施」的本源。#### **3. 重建信任:文档和可观测性**Cloudflare需要重新赢得开发者的信任:- **修复文档**:让文档成为「实用」的工具,而不是「设计」的展示。确保文档的准确性、完整性和及时性。- **完善可观测性**:让「日志」、「追踪」和「指标」成为可靠的工具,而不是「半成品」。
- **开放透明**:在产品发布时,坦诚地讨论技术挑战和权衡,而不是用「愿景」和「使命」来掩盖问题。---### **结语:Cloudflare的「AI狂热」是一场悲剧**Cloudflare的蜕变是一场悲剧。它曾经是互联网的守护者,是基础设施公司的典范。但如今,它却沦为了一家「概念工厂」,试图在每一个新兴领域都推出一个产品,却最终让每一个人都感到困惑。这种「AI狂热」背后的真正驱动力,是产品经理们对「功能多样性」的痴迷,以及对「营销效果」的追求。它让Cloudflare失去了「可靠性」和「简洁性」的核心优势,让开发者们对它的信任荡然无存。
但Cloudflare仍然有机会重新振作。它仍然拥有强大的网络基础设施,仍然有机会回到「基础设施」的本源。但要想做到这一点,它需要:- 停止「概念验证」式的产品发布。- 重新重视「工程师文化」和「可靠性」。- 修复文档和可观测性,重建开发者的信任。否则,Cloudflare将继续在「AI狂热」的泥潭中越陷越深,最终沦为一家「平庸」的云平台。
而互联网,也将失去一位曾经的守护者。 。
