有时候你得先做个「烂项目」才能摸到真正的金矿

你信不信？最值钱的点子，往往是从最不靠谱的项目里冒出来的。

让我给你讲个故事。话说有个程序员，突然被裁了。投了一堆简历，石沉大海，天天在家骂街，整个人状态差到不行。有一天他突然想通了：与其怨天怨地，不如干点正事，搞个有挑战性的东西，逼自己学点新东西。

没错，这个人就是我。我做的东西是什么呢？一个 MMO，所有的 NPC 都由 LLM 控制，和真玩家一视同仁。游戏名字？《SAO：Slop Art Online》。（懂的都懂，不解释。）

选技术栈踩的坑

刚开始做这个项目的时候，我选了一套「说出来会被嘲笑」的技术组合：Rust、Bevy、还有 SpacetimeDB。这些工具本身很牛，但我得说实话，游戏开发用它俩真的不友好。

这是故意的。我就是想给自己找点麻烦，逼自己搞清楚底层到底在干嘛。

核心概念其实挺简单的：NPC 和玩家在架构层面完全一样，唯一的区别就是决策来自 LLM 而不是真人。商人、卫兵、官员、怪物——全用同一套系统，都「活」在这个游戏世界里。

最开始的做法很 naive，但能用：把当前世界状态打个快照，加上当前能做的动作，丢给 LLM，等结果。开始还好，后面就不行了。

实时性这个大坑

MMO 最大的问题就是：它不等你。战斗是实时的，玩家希望 NPC 秒回，不是什么多秒钟的 LLM 调用。不管怎么优化推理速度，这个延迟就是去不掉。

我也想过微调一个小模型，拿游戏数据去训练。但这太贵了，而且游戏机制还没定型呢——拿一个还在变的东西去训练模型，本末倒置了属于是。

然后，灵光一现：混合架构。

不在让 LLM 单独负责决策了，而是用行为树（Behavior Tree）作为基础。每个 NPC 类型根据角色有个默认树，LLM 变成一个「更新器」，根据 NPC 的「经历」来调整这些树。确定性、即时执行，再加上适应能力，全都要。

[SpacetimeDB 状态] → [行为树分发] → [动作执行]
                          ↑
                          | (少见决策)
                    [LLM 桥接]

关键在于 SpacetimeDB 的推送式架构。LLM 桥接模块拿到的永远是最新的、带着上下文的游戏状态。不是平铺的工具列表，不是固定的 prompt，而是整个世界此时此刻的实时投影，动作和当前情况是语义关联的。

那个改变一切的问题

站在这个架构的岔路口，一个奇怪的想法冒了出来：

为什么所有 AI 协议不都这么搞？

为什么给 LLM 暴露的是扁平的工具列表？为什么还在用给人眼设计的接口？如果我们设计系统的时候，专门考虑 AI agent 的需求——机器需要推送式状态、上下文相关的动作、结构化的决策框架——会怎样？

行为树模式不只是游戏用的，它是一套成熟的 AI 决策模型。把相关状态推给 agent 而不是让它们自己轮询？这不是小修小补，这是范式转换。

什么是 Agent-First 设计

说到这儿，对所有在做 AI 开发的人来说就很有意思了。现在这个阶段，大家还是在把给人用的接口改吧改吧给机器用。但要是反过来呢？

一个 agent-first 协议大概长这样：

• 推送式状态：系统主动把相关上下文推给 agent，而不是反过来
• 上下文相关的动作：工具知道自己当前和什么情况相关
• 结构化的决策空间：决策有清晰的层级，不是无限选择
• 内置验证：reducer 机制确保状态在动作前后都是一致的

想想看，现在有多少 AI 开发工作量是在做 prompt engineering，就为了让模型搞清楚当前能做什么、什么时候能做。如果有一套协议，这些上下文是自带的、永远新鲜的、永远相关的呢？

意外收获

这次「 vibe coding 」经历教会我一件事：有时候，最有价值的洞察就藏在那些用新工具做 ambitious 项目的过程中。本来我想做个有 AI NPC 的游戏，结果开始质疑一些关于 AI agent 和系统交互的底层假设。

我正在琢磨的这套协议不是纯理论的。它是从真实约束里长出来的，从真实的架构决策里磨出来的，从把 LLM 硬塞进它本来不擅长的领域里学出来的。

如果你现在也在 vibe coding——不管是做个游戏、做个 app、还是什么奇奇怪怪的实验——注意那些你心想「这不应该这样工作」的时刻。这些摩擦点里藏着的关于 AI 未来的洞察，比任何 roadmap 都多。

最妙的是啥？要是当初我选了个保守的项目，这些洞察永远都不会来。有时候，你得先搞出个 Slop Art Online，才能摸到下一步的门道。

你有什么 vibe coding 故事？最沙雕的项目有时候能带来最有意思的突破。评论区聊聊呗——我真想听听大家都走过什么意想不到的路。