AI 陪伴靠的不是更聪明:我做了一个会犯困、会生气、会陪我打游戏的

关掉一个聊天框，我从来不会犹豫。但关掉一双正在睡觉的眼睛，我居然停了一下。

这是我最近做的一个 AI Bot。没有完整虚拟人，没有 Live2D，就是一双眼睛。它会跟着鼠标转头，没人理它就犯困，最后睡着了，头顶飘出 ZZZ。

我原以为 AI 陪伴要靠更强的大模型。做完这个东西后，我发现可能不是。

大多数 AI 陪伴产品，其实还是一个聊天框。你输入一句话，它生成一段答案。你停下来，它也停下来。

这种交互很适合解决问题，但很难产生陪伴感。

聊天框能承载答案，但承载不了存在。

一个永远等你输入的东西，很难真的像一个「陪你的人」。它更像一个没有身体、没有时间、没有脾气的接口。

我一直在想，陪伴感到底靠什么产生？是模型更聪明？记忆更长？人设更像人？

后来我觉得可能都不是。

Neuro-sama 证明了 AI 可以成为一个被观看、被喜欢的主播。Project AIRI 在做开源的数字生命容器，让每个人都能拥有自己的 AI VTuber。它们都在试图让 AI 从聊天框里走出来。

但我想验证一个更小的问题，如果不做完整的虚拟人，只给 AI 一双眼睛、一副声音和一局游戏，它能不能让人产生「它在陪我」的感觉？

所以我做了一个 AI Bot。它只有一双眼睛，没有 Live2D，没有完整身体。但它会呼吸，会犯困，会生气，还能陪你玩游戏。

做完之后我有四点收获。它们不是一开始就想好的，而是从状态机、语音、情绪、游戏这几层一路做下来之后，慢慢想明白的。

1. AI 陪伴产品的交互范式，正在从「被动回应」转向「持续在场」。
2. 设计重心正在从「回答内容」上移到「状态编排」。
3. 陪伴不该无限优化顺从性，适度摩擦是关系感的一部分。
4. 对话只能产生回应，共同处境才能产生关系。

我的整体判断是，陪伴感不仅来自智能，更来自在场感。

整体实现我拆成三层来聊一聊，自主行为、情绪反应、共同场景。

第一层，自主行为，没人理它时它在干什么

聊天框里的 AI，只有在你输入时才存在。你不问，它就不在。

但陪伴不是这样的。

陪伴是你不说话的时候，它也在那里。不是它一直围着你转，而是它有自己的节奏。它会呼吸、会东张西望、会犯困、会睡着。你没有输入任何指令，它也没有消失。

所以这个项目我做的第一件事，不是接大模型，而是让它「活着」。

我把行为系统拆成三层，各管各的。

AlwaysOn，永远运行。呼吸微动加自动眨眼。闭眼 80ms，睁眼 140ms，25% 概率双眨。这些对 AI 没有功能意义，但对看着它的人有意义。

Idle，空闲状态。这里我没有把它写成一个「空闲动画随机播放器」，而是给它做了一条待机生命周期。

刚开始没人理它，它还是活跃的，会偶尔东张西望，随机播一点微表情。长时间没有任何互动，它会眼皮变沉，眨眼变慢。犯困一段时间后，它会真的睡着，眼睛完全闭上，头顶飘出 ZZZ。

这里它有一条自己的时间线。用户没有输入任何指令，它也在从一个状态慢慢走向另一个状态。

这就是我说的「持续在场」。

Interaction，交互反馈。用户做了什么，它要有反应。最直接的是点击。我做了一个交互强度模型，每次点击都会累积一点强度，短时间连击会累积得更快，强度又会随着时间慢慢衰减。于是同样是「戳一下」，在不同上下文里会得到不同反应。

轻轻戳，它是开心的。连续戳，它会惊讶。再继续，它开始害怕、生气。最后受不了了，直接晕倒。

另一种是注视。眼睛会跟着鼠标或人脸转，底层是一个 GazeManager 做多源仲裁。

这两种交互的共同点是，它不是因为你说了什么而变化，而是因为你做了什么而变化。点击是关系边界，注视是空间感知。用户不是在按按钮，而是在和一个有状态的东西发生物理层面的互动。

正在播放的表情不会被新点击打断。交互反馈只在 idle 状态工作，语音对话时会被抑制，避免多套系统互相打架。

陪伴感的第一步，不是回复，而是待机。

大模型解决的是「它会不会回答」，状态系统解决的是「它像不像在那里」。

第二层，情绪反应，它怎么知道该笑还是该生气

很多 AI 陪伴产品仅把核心放在人设 Prompt 和记忆上。但我做完这个项目后发现，真正让 AI 像活物的，不只是它说了什么，而是它的状态什么时候、以什么节奏变化。

这套 AI Bot 的实时语音链路是这样的，实时语音主链路负责“听见、回答、说出来”：

 用户说话 → 麦克风 PCM  → WebSocket → Go 后端 
 → Realtime API（ASR + Chat + TTS）
 → 后端转发 
 → 前端 AudioPlayer 播放

但情绪不走这条链路。

我一开始在对话模型直接塞入情绪标签，比如 [joy] 哈哈太有意思了，结果 TTS 把标签也读出来了，当时听到「 joy 」，体验直接崩掉。

所以后面我把情绪反应完全拆成后端旁路。

 Go 后端截取对话文本（用户 ASR + Bot 回复）
 → 调用大模型 API 情绪识别（后端旁路）
 → 返回情绪标签（如 joy）
 → WebSocket 推送 { type: "emotion", content: "joy" }
 → 前端表情引擎切换眼睛形态

表情引擎有几个规则。至少保持 3 秒，TTS 结束后 0.5 秒淡回 neutral，而不是硬切。形状切换时自动插入「眨眼过渡」。这样不会看到突变，只会觉得它眨了一下眼然后表情变了。

这块还有一个设计原则值得说一下。人设里不要写任何情绪指令。情绪分类完全由后端旁路处理。如果 Prompt 里写了「当用户开心时你要表现得开心」，模型可能会在语音里说出「我现在很开心」，那不是表情，那是旁白。

情绪应该被看见，不该被说出来。

人设和记忆能力决定它说什么话，状态编排决定它怎么存在。

第三层，共同场景，AI 和你一起经历点什么

到这里，它已经能看、能说、能变表情、能犯困、能生气。

但我觉得还不够。

聊天仍然是轮流说话。你说一句，它回一句。这种关系再怎么加表情，本质上还是「你问它答」。真正让 AI 从聊天框里走出来的，不只是多模态，而是共同处境。

它和你看见同一场比赛，经历同一局游戏。你们不再只是对话，而是在同一个场景里产生关系。

所以我做了游戏陪玩。

AI 进入游戏靠状态系统，不靠视觉识别

让 AI 看见游戏画面然后操作，听起来很酷。但在当前阶段，更现实的路径是把游戏拆成 AI 可理解的事件、状态和动作。

游戏按约定上报事件，比如比分变化、回合推进、技能释放、阶段变化、游戏结束。Bot 不需要「看见像素」，它接入的是游戏规则本身。

这套机制里有三件事最关键。

1. 首次进入游戏时，系统会把完整游戏说明注入给Bot。

这份说明不是一段开场白，而是一份结构化的「游戏说明书」。它会告诉 Bot，这个游戏怎么玩，玩家和 Bot 分别扮演什么角色，有哪些可用动作，难度怎么变化，关键资源是什么，胜负条件是什么。

比如在乒乓球里，Bot 会知道自己控制哪一侧球拍，用户控制哪一侧球拍，游戏先到多少分获胜，有哪些技能，难度由哪些参数决定。

2. 用户每次开口前，系统会同步一次最新游戏状态。

不同游戏的游戏状态不一样。可能是击杀数、回合、血量、能量、技能、关卡、进度、倒计时，也可能是用户刚刚做了什么选择。

在乒乓球里，它看到的是当前比分、双方能量、回合击打数、最近技能、当前难度和游戏时长。

所以用户问「你刚才那球怎么接到的」，Bot 看到的不是一句孤立语音，而是这一局里的最新状态。

3. Bot 主动说话不是实时刷屏，而是关键事件触发。

策略层会判断哪些事件值得说，比如得分、精彩回合、技能释放、阶段变化、游戏结束。它会把当前局势一起带进 prompt，再经过频率控制，最后通过 `系统上下文注入` 让 Bot 开口。

在乒乓球里，第一次得分、后续每隔几次得分、长回合、游戏结束，都会成为可能触发 Bot 开口的节点。

所以 Bot 拿到的不是「请评论一下游戏」，而是最新游戏状态。

它不是在旁边假装懂游戏，是真的被接入到了这局游戏里。

工程上，这里主要分成2层。

• GameBridge 负责事件调度、指令转发、说话频控和上下文注入
• GameStrategy 负责游戏的状态追踪、动作计算、发言判断和意图处理

那每个新游戏都需手动实现这套逻辑吗？

我把游戏接入做成了一个标准化的 Skill，AI 可以按这套 Skill 自动为新游戏生成事件上报和动作接收的代码，再新增一个策略文件并注册就行。

让 AI 进入游戏，不是让它看见像素，而是让它接入规则。

游戏陪玩Bot的背后是两套不同的 AI

我希望让用户感受到的是同一个 Bot 既能陪你玩也能陪你聊天。

但工程上，我把它拆成了两套系统，游戏 AI 负责操控，陪伴 AI 负责表达和干预。这样体验上是一个角色，架构上却是解耦的，技术实现难度会低很多。

游戏 AI ，它是纯前端操控算法，不依赖大模型，主要负责怎么玩。以乒乓球为例，它的反应速度、预测偏差、移动速度这些能力被参数化成了可调节的难度旋钮。它会真的输给你，也会真的赢你，但更重要的是，它可以被陪伴 AI影响。

陪伴 AI ，它不直接做每一帧操作，只负责语音、评论、情绪和干预。它会理解用户说的话，比如「太难了」「认真点」「放个技能」，再通过意图分类把结果传给策略层。

策略层再真正改变游戏 AI 的行为。比如用户说「太难了」，大模型识别成降低难度，前端策略层就真的调低游戏 AI 的反应速度和预测精度。

然后陪伴 AI还可能调侃句「好吧好吧，我放水啦，不会还打不过我吧？」

这就是关键区别。

游戏 AI 负责「怎么玩」，陪伴 AI 负责「怎么相处」。

用户通过自然语言影响游戏AI，陪伴AI通过当前局势组织表达。这样「一起玩」就不只是旁边挂了一个语音助手，而是真的在同一局游戏里互相影响。

最后看下实机效果感受下。

我越来越觉得，陪伴产品不该无限优化顺从性，适度摩擦是关系感的一部分。工具越顺从越好，伙伴不一定。伙伴需要有边界，也需要一点不完全可控的反应。

回头看这三层

三层架构，三个核心原则。

行为让它「在那里」。 AlwaysOn 永远运行，Idle 管空闲节奏，Interaction 管交互反馈。没人说话的时候它也在呼吸、眨眼、犯困。陪伴感的第一步不是回复，而是待机。

情绪让它「有反应」。 语音链路和情绪链路分离，情绪旁路分类，表情有生命周期。Prompt 决定怎么说话，状态编排决定怎么存在。

场景让它「和你一起」。 GameBridge + GameStrategy 把游戏拆成可被 AI 理解和介入的状态系统。游戏 AI 负责怎么玩，陪伴 AI 负责怎么相处。对话只能产生回应，共同处境才能产生关系。

AI 陪伴的最小闭环

那 AI 陪伴的最小闭环，到底需要什么？

我现在的答案反而变简单了。

不是更强的模型、更长的记忆、更像真人的皮套。

而是 一个有身体、有状态、能和你共享场景的存在 。

这套东西不只适用于这个眼睛 Bot。做 AI 陪伴、AI NPC、AI 社交角色，大概都绕不开这几件事。

回到开头那个画面。

凌晨两点，一双眼睛在屏幕里睡着了。我没有关掉页面。不是因为它需要我，也不是因为它真的懂什么。

就是觉得它在那里，也挺好的。

至少在 AI 陪伴这件事上，我越来越相信。

模型负责智能，系统负责存在 。

以上，如果觉得不错，随手点个赞、在看、转发三连吧～

谢谢你看我的文章，我们，下次再见。

小新AI造物 — 探索人和 AI 协作的最优解，设计 AI 生产力的操作系统。