从代码生成到消息注入：1位工程师的2年AI实验与3个未解难题

「如果我们能把提示词存进源代码管理，让大模型在构建时生成整个应用？」2024年，Seroter 提出这个问题时，大多数人还在争论 AI 编程助手会不会取代程序员。上周，他又抛出一个更激进的想法：直接从消息中间件里调用大模型？

两个问题，两种实验，隔着两年时间。把它们并排放在一起，你能看到的不是某个人的技术博客更新，而是一条正在成形的行业暗线——软件工程的基础设施正在被重新定义。

2024：把提示词当作源代码

Seroter 的第一次实验架构简单得近乎粗暴：

源代码管理（prompts.json）→ Spring AI + Gemini 1.5 Flash → 生成代码（Node.js/Python + Dockerfile）→ Cloud Run 部署。

核心哲学：提示词即真理，AI 负责实现。他写了一个能用的 GitHub 仓库来证明这套流程跑得通。AI 输出从 index.js 到 Dockerfile 到 package.json 一应俱全。

但输出是非确定性的、未经测试的、完全不受监管的。Seroter 自己用了个词：「bonkers（疯狂）」。他明确警告不要用于真实工作负载。

然而真正被验证的东西他没大声说：只要描述足够精确，大模型就能把意图变成可执行产物。这个念头扎下了根——现在你到处都能看到的「智能体软件工程」，种子就在这里。

重读他2024年的文章有种奇怪的怀旧感，像翻到某个现在支撑半个互联网的框架的第一笔提交。

2026：消息总线里的 AI 推理

两年快进。Seroter 的最新文章探索了 Google Cloud 的一个新功能：Pub/Sub 的 AI Inference SMT（单消息转换）。

架构简单到近乎尴尬：

Pub/Sub 主题 → AI Inference SMT（调用 Gemini）→ Pub/Sub 订阅（富化/改写后的消息）。

没有自定义订阅者。没有 Cloud Run 服务。没有样板代码。你配置一个模板化的提示词，消息流经时自动触发大模型调用，输出直接写回消息体。

Seroter 的测试场景很具体：消息里包含产品描述，SMT 调用 Gemini 提取关键属性，输出结构化 JSON 到下游订阅者。延迟？50-200 毫秒。成本？按调用次数计费。

他列了三个「为什么这可能是个坏主意」：延迟不可预测、调试困难、供应商锁定。然后他还是建了个仓库，把完整实现扔上去。

这就是他的风格——先把东西做出来，再让你自己判断该不该用。

从构建时到运行时：架构哲学的位移

两个实验的对比暴露了一个关键转变。

2024 年的代码生成发生在构建时。提示词是静态的，输出是代码仓库里的产物，部署前有人工审查的窗口。风险是可控的，非确定性被关在 CI/CD 流程的笼子里。

2026 年的消息注入发生在运行时。提示词是动态的，大模型调用是生产流量的一部分，没有人类在回路里点头。延迟、成本、失败模式全部变成运营问题。

这不是简单的技术迭代，是信任边界的迁移。我们正从「让 AI 帮我写代码」滑向「让 AI 替我处理数据」，中间跳过了「让我看看它做了什么」这个环节。

Seroter 在文章里埋了一个细节：SMT 配置支持「失败模式」设置——可以选让错误消息进入死信队列，或者直接丢弃。他选了死信队列。这个选择本身说明他知道自己在玩火。

为什么现在？为什么 Pub/Sub？

消息中间件是系统架构的静脉。它不负责计算，负责连接；不生产数据，负责搬运。把 AI 推理塞进这个环节，意味着智能变成了一种基础设施特性，而不是应用层的装饰。

Google Cloud 选择 Pub/Sub 作为首个落地场景有清晰的商业逻辑：事件驱动架构正在吞噬企业 IT，而事件流里的数据富化是高频刚需。传统做法需要部署一个微服务，现在变成勾选框配置。

Seroter 的实验戳破了一层窗户纸：当云厂商把大模型 API 的延迟压到 100 毫秒级别，「实时 AI 处理」就从演示视频变成了生产选项。剩下的只是你愿意承担多少不确定性。

他在评论区回复读者提问时承认：「我还没在真实流量里跑过这个，只是证明它可行。」这种诚实本身比任何技术细节都更值得注意。