艾琳·布罗克维奇盯上了数据中心：AI基建热潮背后的不透明困局

艾琳·布罗克维奇（Erin Brockovich）这个名字，大多数人是通过朱莉娅·罗伯茨主演的同名电影认识的——当年她硬刚太平洋煤气电力公司（PG&E）污染水源的案子，成了美国环保史上的标志性事件。而现在，这位环保活动家把目光投向了一个正在全美疯狂扩张的领域：数据中心。

她最近上线了一个地图网站，专门标注全美各地正在建设或已建成的数据中心位置。这个地图被描述为”进行中的工作”，里面的数据点主要来自周边社区居民的主动上报。更夸张的是，布罗克维奇在五月初公开征集数据中心相关问题的线索，结果第一个月就收到了接近4000份提交。

“提交内容里出现频率最高的担忧——比噪音、比用水量、比电费上涨都要高的——其实就一个词：透明度。”布罗克维奇在 Substack 上这样写道。

先斩后奏的建设项目

布罗克维奇说得很清楚：她不是在笼统地反对数据中心，也不是反对AI。她反对的是她地图上记录下来的那种模式——项目在许可已经拿到之后才对外公布，开发商不接当地居民的电话，而地方官员在邻居们还完全不知道有这回事的时候，就已经签了保密协议（NDA）。

这套玩法在国内可能也不陌生。一个动辄消耗相当于几万个家庭的用电量和用水量的项目，决策过程却对受影响的社区完全不透明，等到大家知道的时候，许可已经批了，反对的窗口期基本过去了。

AI热潮下的基础设施焦虑

这件事的背景其实是：全美（乃至全球）正在经历一轮前所未有的数据中心建设热潮。AI大模型的训练和推理需要海量算力，算力背后就是服务器、冷却系统和——最要命的——电力。微软、谷歌、亚马逊、Meta，还有刚入局的SoftBank，都在疯狂找地方建数据中心。

但问题是，这些项目对当地社区的影响是实实在在的：用电用水规模巨大，有的项目甚至要配套新建天然气发电厂；冷却系统的噪音污染让周边居民苦不堪言；而数据中心的税收贡献是否足以弥补这些外部成本，各地争议很大。

更核心的矛盾在于：这些项目往往打着”经济发展”和”AI未来”的旗号，走快速审批通道，而当地居民的知情权和参与权在这个过程中被系统性地弱化了。布罗克维奇的地图项目，本质上是试图用信息公开来对抗这种不透明的决策模式。

---

• 布罗克维奇数据中心地图：brockovichdatacenter.com
• 她同时在 Substack 持续更新相关调查进展
• 热点地区：弗吉尼亚州”数据中心走廊”、得克萨斯州、爱荷华州等

互联网正在为机器重构，人类流量迟早被反超

过去几十年，云计算基础设施都是围绕「人类行为」设计的：人搜索、点击、滚动、播放，节奏稳定且可预测。但AI代理的行为完全不同——它们能在几秒钟内同时启动多个子代理，查询数百个数据库、搜索文档、调用API，然后像出现时一样迅速消失。

在这种认知下，亚马逊正在重新设计其核心云基础设施的一块关键拼图。

AWS悄悄上线了一件大事

本周四，AWS发布了新一代OpenSearch Serverless——这是一个完全托管的搜索和向量数据库，本质是一个大规模存储和检索信息的系统——而它的设计目标非常明确：专门为AI代理工作负载打造。

AWS表示，这个新系统能在代理触发任务时瞬间扩展，在代理闲置时缩回到零。这套逻辑听起来简单，但对原本为人类设计的架构来说，是一次根本性重构。

「代理正从实验阶段走向生产环境，它们产生的流量模式是此前的基础设施根本没有为之设计过的。」——Tia White，Amazon OpenSearch Service 总经理

人类的互联网，机器的用法

这个发布背后，是整个科技行业逐渐意识到一个问题：为人类驱动的互联网而设计的基础设施，在越来越多代理存在的世界里，其实并不好用。

目前AI代理在互联网活动中的占比还相对较小，但机器生成的流量已经相当可观，而且还在持续增长。Cloudflare的数据显示，过去六个月里，机器人流量占整体HTTP流量的31%。其中，AI爬虫、搜索引擎和助手约占所有机器人请求的四分之一。

Cloudflare高级产品经理Lai Yi Ohlsen对TechCrunch说了一句很直接的话：

「非人类流量将在2027年上半年某个时间点超过人类流量。」

---

谷歌也押注了代理

上周的谷歌I/O开发者大会上，谷歌宣布用户将能够把购物研究、行程预订、网页浏览、应用交互等任务委托给AI系统。但这件事的影响远不止消费级AI助手。

企业正在越来越多地内部部署代理，同时也让代理面向自己的客户运行，在幕后创造出全新类型的机器生成流量。

结果是，云服务商和基础设施公司一直在思考一个问题：如何把为人类设计的系统，改造为能够适应代理持续自主检索信息、调用工具、生成机器对机器流量的世界。

这正是AWS新版OpenSearch Serverless想要解决的问题。

技术关键：把计算和存储拆开

这一代产品最核心的技术变化，是把计算层与存储层解耦。计算资源可以在几秒钟内扩展，以容纳代理流量的突发高峰，也可以缩回到零，这样客户在代理闲置时就不用付钱。

White用一个比喻来解释之前的困境：就像你一直为一个停车位付钱，哪怕你根本没在用它。而升级后的Serverless版本更像是按计时器付费的停车位。

「之前，哪怕是我们上一代的Serverless版本，你也至少得让一个实例在运行，因为存储和计算是耦合在一起的。你没法按照你需要的速率自动启动（计算），所以你总是要为你的工作负载预留闲置的计算资源，不管你用没用。」White说。

---

整个云行业都在跟进

这种转变正在整个云计算行业同步发生。Databricks和Snowflake正在把自己重新定位为企业数据的AI记忆和检索系统。微软已经推出了针对Azure的更新，专门用来处理AI代理的流量突发，并在代理之间共享记忆。Cloudflare在类似的逻辑下，上个月也推出了旨在为代理提供持久化环境和即时扩展能力的基础设施。

公司部署的AI代理越多，围绕机器生成的工作负载重新设计基础设施的压力就越大，这反过来又可能让代理在更大规模上的部署变得更便宜、更容易。

发布时，OpenSearch Serverless将原生集成Vercel和Kiro等AI开发平台，这样开发者就可以为代理部署生产就绪的搜索和向量后端，而无需管理基础设施。

这对开发者来说是个好消息——至少从理论上讲，代理驱动的应用的运维成本应该会降下来。但更大尺度上看，这件事的真正意义是：互联网的基础设施，正在从「为人类设计」转向「为机器设计」。人类仍然是使用者，但底层管道的优先级已经变了。

程序员宁愿辞职也不愿不用AI写代码，这事儿迟早要翻车

2026年，研究人员发现了一个有趣的现象：你没法把AI编程工具从程序员手里抢走。哪怕只是参与一个实验，大多数开发者也不愿意在没有AI辅助的情况下写代码。

这听起来像是AI提效的胜利宣言，但另一群研究者却发出了警告：AI确实让代码产出更快了，但产出的代码未必更好。而这，可能会在将来给这群开发者带来麻烦。

「大多数开发者即使只是为了参与一项研究，也不愿意在没有AI的情况下工作。」——METR 研究团队

一次没能完成的实验

事情要从METR说起。这是一家受人尊敬的AI研究实验室，2026年2月，他们想做一件事：更新此前一项关于AI编程效率的里程碑研究。

这项2025年发表的研究测量了开源开发者手工完成任务和使用AI完成任务的耗时差异。结果让很多人意外：开发者报告说AI让他们更高效了，但实测数据显示AI实际上拖慢了速度。代码生成确实更快，但开发者花在查找和修复错误、引导AI、等待AI完成任务上的时间，把节省的部分全吃掉了。

所以当METR想重复这个实验、测量AI进步带来的效率提升时，他们碰壁了。开发者不愿意参与，理由是——「我不想在没有AI的情况下工作」，哪怕只是为了实验。

最终METR在2026年5月改做了一项调查问卷，让技术人员自己报告AI带来的效率提升。不意外地，受访者普遍认为AI让自己的产出价值翻了一倍。

---

「Tokenmaxxing」的幻灭

2026年迄今最火的趋势之一，是把一个人消耗的token数量当作AI生产力 proxy（代理指标）的「Tokenmaxxing」运动。用得多就等于产出多，这个逻辑听起来很诱人，但它可能已经走到头了。

亚马逊内部有一个叫Kirorank的token追踪排行榜。《金融时报》本周报道，这个排行榜被员工「玩坏」了——大家过度调用AI代理，推高了成本，亚马逊最终关停了它。这件事本身就很说明问题：AI使用量高，不等于生产力高。

Uber更夸张。《The Information》报道，Uber在2026年前4个月就把全年的AI预算烧光了。CTO Andrew Macdonald最近在一个播客里说，这种支出并没有带来项目或生产力的可衡量提升。

「现在代码写得快了两倍？希望你同时也把维护成本减半了。否则你就是在用暂时的速度提升，换取永久的债务。」——程序员 James Shore

维护成本这个坑

AI生成的代码并不一定减少后续维护需求，甚至可能增加。程序员兼作家James Shore在Hacker News上爆火的一篇博客里把这件事说得很直白。

有不少数据支撑这个观点。AI可靠性工程代理创业公司Entelligence AI的创始人Aiswarya Sankar发推称，企业把44%的token花在修复AI自己引入的bug上。代码审查工具公司CodeRabbit分析开源拉取请求后发现，AI产生的代码比人工代码多出1.7倍的问题。

当然，这些数据来自正在售卖AI代码审查工具的公司，多少有点自营自夸的嫌疑。但独立研究也发现了类似问题。新加坡管理大学的研究人员在2026年4月发表报告，警告「AI生成的代码可能给真实软件项目引入长期维护成本」。

---

那到底该怎么办

那些想向你推销AI编程代理的人会说，开发者大可以用AI编程代理来做修复代码的苦活，速度跟得上AI吐出代码的速度。Cognition（Devin的开发商）的创始人兼CEO Scott Wu就是这个观点的代言人。

但就连他也承认，Devin虽然可以独立工作，但目前它的技能水平介于初级和中级程序员之间，取决于具体任务。这不是一个「交出去就不用管」的方案。

新加坡管理大学的研究人员提出了一个更「人类」的方案：程序员应该像熟悉自己最爱的编程语言一样，深入了解AI擅长什么、不擅长什么。他们需要为AI设计强大的质量保证体系，并且像对待初级开发人员一样，仔细审查AI的输出。

同时，研究者们认为（Scott Wu也同意），人类仍然应该负责大局性的工作：软件架构、安全设计，这些事现在还放心交给AI。

说到底，AI是个好工具，但它现在还没好到让你把脑子交给它。程序员拒绝在没有AI的情况下工作，这件事本身没问题；有问题的是，拒绝同时意味着放弃了对自己产出质量的把关权。