谷歌架构师两年实验：从代码生成到消息注入

为什么有人总在行业爆发前两年就开始动手？谷歌云开发者布道师Richard Seroter的两次实验，恰好踩中了AI工程化的两个关键拐点。

2024年的"疯狂"：把提示词写进源代码仓库

两年前，Seroter做了一件当时看起来很不靠谱的事。他设计了一套流水线：把提示词存进版本控制，让大语言模型在构建阶段直接生成完整应用。

架构极简到近乎挑衅。一个prompts.json文件，通过Spring AI调用Gemini 1.5 Flash，输出Node.js或Python代码连带Dockerfile，最终部署到Cloud Run。没有人工编码，没有逐行审查，AI包办从index.js到package.json的一切。

Seroter自己给这套系统贴的标签是"bonkers"——疯狂。他在GitHub仓库里明确警告：别用于生产环境。输出不可预测、未经测试、完全不受监管。

但实验验证了一个被后来人反复引用的核心命题：只要描述足够精确，大模型就能把意图转化为可执行产物。这个2024年的概念验证，如今被包装成"智能体软件工程"到处贩卖。重读那篇旧博文时，你会产生一种奇怪的考古感——像翻到某个如今支撑半个互联网的框架的最初提交记录。

代码仓库至今公开可查。Seroter特意设计成可脱离谷歌云服务运行，模型也可替换。这种开放性本身也是一种态度：验证想法比绑定生态更重要。

2026年的转向：把AI推理塞进消息总线

上周，Seroter发布了新实验。这次的问题更尖锐：能不能直接从消息中间件里调用大模型？

谷歌云新推出的AI Inference SMT（单消息转换）功能，让这件事变得过于简单。Pub/Sub主题→AI推理层→订阅端，三步完成消息富化或改写。不需要自定义订阅服务，不需要Cloud Run实例，不需要任何样板代码。纯配置驱动。

这个设计把智能推到了数据流动的最前线。消息在管道中穿行时就被实时处理，延迟以毫秒计，而非传统架构里的秒级轮询。

Seroter的演示场景很具体：金融交易风控。消息进来，Gemini判断风险等级，输出结构化JSON，下游系统直接消费。整个决策链路嵌入在基础设施层，应用代码零感知。

他坦承这同样"有点吓人"。模型幻觉可能导致错误分类，延迟抖动可能影响实时性，成本模型完全不同于传统计算。但实验的价值从来不在于给出答案，而在于把问题摊开到台面上。

两条时间线的交汇点

把两个实验并置，一条清晰的演进脉络浮现出来。

2024年的关注点在生产端：AI生成软件制品。2026年的关注点在运行时：AI注入数据流。前者改变的是代码怎么来，后者改变的是决策在哪做。

这个位移本身揭示了行业焦虑的转移。当代码生成逐渐 commoditized（商品化），竞争焦点自然下沉到更底层的集成点。谁能把智能嵌入现有基础设施而不颠覆架构，谁就能撬动存量系统的迁移意愿。

Pub/Sub作为谷歌云的事件总线，月处理消息量以万亿计。在这个位置插入AI推理，意味着无数现有应用无需重构即可获得智能能力。这是典型的平台思维：不做颠覆者，做赋能者。

但技术债不会消失，只会转移。Seroter在两次实验中都强调了同样的警示：非确定性输出、缺乏可观测性、治理框架缺位。这些问题在2024年是学术性的，在2026年即将成为运维人员的日常噩梦。

为什么现在值得关注

谷歌云Next '26的正式议程还在消化中，但真正的信号往往藏在个人博客的"如果...会怎样"里。

Seroter的身份特殊：既是官方布道师，又是持续动手的技术人员。他的实验选题通常领先产品路线图12-18个月。2024年的代码生成实验，如今已有多个商业化变体；2026年的消息注入实验，很可能正在影响下一代Eventarc或Workflows的产品定义。

对于正在设计AI集成策略的工程师，这两个实验提供了互补的参考系。代码生成适合探索期，快速验证概念；消息注入适合规模化，将智能能力编织进现有数据 fabric（架构）。选择哪条路径，取决于你的组织更缺速度还是更缺稳定性。

一个有趣的细节：Seroter两次都选择了Gemini Flash而非Pro版本。轻量、快速、低成本，这个选型本身就在暗示——他押注的是高频、低延迟的AI调用场景，而非单次复杂推理。这与边缘计算、实时决策的行业趋势高度吻合。

冷幽默的是，当我们终于准备好讨论这些想法时，Seroter大概已经在折腾2028年的实验了。而那个实验的答案，此刻正躺在某个未公开的代码仓库里，等待被未来的考古学家发现。