AI 一天就能做出来的小游戏，为什么清一色都是单机？

最近刷技术社区和朋友圈，应该都有同款体验：用 AI Agent 做独立小游戏的内容快刷屏了。

一句话生成贪吃蛇，一下午做出来个肉鸽卡牌，像素美术有 AI 包圆，音效有 AI 生成，连游戏策划案都能让 AI 先写一版。工具从 Claude Code 到 Codex 到各种国产 coding agent，「人人做游戏」的叙事第一次有了实感。

但看得多了，我发现一个所有人都在默默绕开的角色：联机。

这些 AI 生成的小游戏，清一色单机。双人贪吃蛇、对战卡牌、合作解谜——理论上「双人版」比单人版只多一个「把对方操作显示出来」的工作量，但几乎没有 AI 做出来的游戏带联机。

这是巧合吗？我在一家做 IM 云服务的公司工作，我们的游戏房间功能和配套的 agent skill 刚上线，这个问题我认真想过，答案比「联机很难」有意思得多——它其实是「AI 生成代码」这个模式的属性和「联机基础设施」的属性，正面撞上了。

第一层解释：不是 AI 写不出联机的逻辑

先排除一个想当然的答案：「联机代码太难，AI 不会写」。

不对。一个双人贪吃蛇的联机逻辑——两边各自运行游戏循环，把各自的按键操作发给对方，双方按同样的规则应用操作——这个「逻辑本身」的复杂度，并不比单机版高多少。以帧同步为例：通道只转发每个玩家的操作指令（一帧一百多字节以内），各客户端收到同一帧的所有操作后，本地模拟出一致的世界。玩法代码完全在本地运行，自包含、可刷新验证。

而「自包含、可本地验证的逻辑代码」，恰恰是当前 coding agent 最强的领域。

所以问题不在「写不出来」。真正的原因在下一层。

第二层：联机的成本不在代码里，在代码外面

联机对战真正贵的，是一层 AI 没法替你承担的东西——基础设施。

玩家 A 和玩家 B 的操作要实时互见，中间需要：一条长连接通道（UDP 优先、WebSocket 兜底，因为企业网会拦 UDP）、就近的游戏节点（跨地域延迟要有人管）、房间的生命周期系统（创建、加入、席位、断线保留、销毁）、鉴权体系（怎么证明「这个玩家属于这一局」而不被伪造）、以及这套系统上线之后的监控、扩容和故障响应。

把这几项拆开看工作量：每一项的「代码」部分，AI 都能写；但合起来，它是一个有持续生命周期的基础设施组件——上线只是开始，之后的扩容、值班、故障复盘，是一个长期义务。

这就是错配的根源：

AI 生成模式的强项是一次性的、自包含的、本地可验证的逻辑生成；而联机对它提出了长生命周期的运维承诺——这个承诺没法被「生成」出来。

单机游戏写完刷新即玩，验证闭环在秒级；联机游戏写完，你面对的是「这套服务端敢不敢上线」的问题。AI 能帮你把服务端代码写出来，但「敢上线」需要的监控、压测、值班，是另一个维度的成本。

所以联机缺席不是 AI 能力的问题，是分工问题：把需要长期运维的东西交给了「只擅长一次性生成」的一方。

第三层：把墙变薄的正确姿势——分工重排

答案也就顺出来了：需要长期运维的那一层，交给已经在运维它的人；AI 专心做它擅长的玩法逻辑。

具体到联机对战，这个分工在技术上由「帧同步通道」实现得非常干净：通道只转发玩家的操作指令（不转发游戏状态），各客户端本地做确定性模拟。于是：

玩法逻辑：完全在客户端本地，自包含——归 AI，单机版怎么写联机版还怎么写；
联机通道：UDP/WebSocket 双通道、就近节点、断线恢复、房间生命周期——归平台；
中间的连接：薄到什么程度？服务端侧是「建房 + 给玩家签发加入票据 + 关闭房间」三个调用；客户端侧是「凭票据进房、每帧发操作、收所有人的操作」四行核心代码。

我们团队做的深应智联（IM 云服务）最近上线的游戏房间，就是这个形态——而且我们把它做成了 agent skill：对 agent 说一句「给我的双人游戏加联机对战」，agent 会确认需求、发起授权（你在浏览器里点一次允许，密钥全程不进对话）、生成服务端和客户端的接入代码，最后带着你双开窗口打一局验收。「能两个人玩」写进了完成定义里。

原理拆开看，「为什么这个 skill 能让 AI 做出能跑的联机游戏」有三个支柱：对战通道在平台侧解决（agent 只生成薄胶水，不碰需要运维的东西）；防幻觉规则内置（只用 skill 里出现过的接口、完整参数现场查官方文档、SDK 版本钉死——AI 生成联机代码的翻车大头是幻觉出不存在的接口）；授权流打通最后一公里（凭证问题从「复制粘贴给 AI」变成浏览器里的一次点击，且是可随时吊销的独立密钥）。

第四层：比游戏更值得聊的——skill 这个形态

写这篇真正想讨论的，其实超出了游戏。

这次做 skill 的过程让我意识到一个正在成形的模式：云服务的接入知识，正在从「文档」变成「agent 可执行的工作流」。

过去的接入是：开发者读文档 → 理解鉴权 → 抄示例 → 调试。每一步都可能出错，每一步的成本由开发者承担。skill 的形态是：厂商把「怎么正确接入自己」打包成 agent 的操作手册——需求怎么确认、凭证怎么安全获取、代码按什么结构写、验收标准是什么——agent 拿着手册执行，人只在关键节点（授权、验收）出手。

这个模式如果能成立，受益的不只是游戏：客服系统、支付对接、消息推送……每个「文档写得再好也要啃半天」的接入场景，都可能长出自己的 skill。

当然，现在下结论太早。skill 依赖厂商的自觉（手册写得好不好、会不会过时），也依赖用户对「让 agent 碰凭证」的接受度——这两个都是真问题，我们也在用真实用户的使用反馈修自己的答案。

最后

交代背景：深应智联是我们做的 IM 云服务，游戏房间和这个 agent skill 是最近的更新，skill 正在陆续上架各 agent 平台（部分还在审核）。想亲手试的：评论区留言（扣个「联机」），skill 包发你——装进 Claude Code / Codex 的 skills 目录，对你的 agent 说「给我的游戏加联机对战」，剩下的照着文章走。配套文档在官网公开。

问题留给评论区：

你用 AI 做过小游戏吗？卡在哪一步了？
「玩法归 AI、基础设施归平台」这个分工你认吗？还是觉得 AI 迟早能把基础设施也接管了？
如果每个云服务都出一个 skill，你希望第一批覆盖哪些服务？

我先站队第 2 题：AI 会接管越来越多的「写」，但「敢上线」的责任——监控、值班、故障复盘——在我可预见的视野里，都得有人类签字。这不是能力问题，是信任结构问题。