那是一个有点反常规的瞬间。
不是所有比赛作品都能让人停下来的。B站AI创造公开赛的展区里，大多数选手都在努力证明自己的AI“有用”：能写文案、能画图、能陪聊、能处理文档、能自动生成视频、能提高某种效率。可用这个电子宠物项目没有去抢这些赛道，它只做了一件事——把一只AI小动物放在屏幕角落里，它会发呆、会睡觉、会偷看你、会不理你，还会在你长时间靠近它的时候躲开。
没有任务系统，没有成长数值，没有对话知识库，甚至没有什么“实用功能”。
这个项目的全名叫“开发一个‘没用的AI’，电子宠物还能这样？？？”。名字里的问号很诚实，这确实是我最近几年看到的最典型的AI产品方向之一：它不是没想清楚，而是刻意把自己从“效率工具”和“功能型AI”的赛道里摘了出来。
我想认真聊一聊这个“没用的”项目为什么值得停下来看。
1. 从“有用”到“有用感”：一个被忽略的跳跃
我们在评估AI项目时，通常默认一个前提：AI必须有用。有用意味着它能解决问题、节省时间、提升效率、降低成本、替代重复劳动。这个标准本身没错，但它主导了我们绝大多数人的判断路径，也让我们默认忽略了一类产品——那些不解决任何具体问题，却让人不自觉想打开看几眼的AI。
这个电子宠物项目踩中的，恰恰是“有用感”而不是“有用”。
鼠标滑过它时，它会抬头看你一眼；你忙碌半天回到屏幕前，它已经自己歪着头睡着了；你戳它太多次，它会不耐烦地转个方向不理你。这套行为逻辑里面没有任何一个功能是“解决问题”的，但它在制造一种很真实的东西：陪伴感和被回应感。
从产品角度来说，这就是一个完整且自洽的情绪反馈系统。所谓的“无用”，只是不服务于效率目标，它服务的是一种更底层的心理需求——被另一个“存在”注意到。
我认为这才是AI产品设计里最值得讲清楚的分界线：效率型AI的验证标准是“任务完成率”，而情绪型AI的验证标准是“用户是否愿意自发打开第二次”。前者的核心是准确度，后者的核心是人格稳定性和行为可信度。
当绝大多数开发者还在追求把AI做得更聪明、更全能时，这个项目的判断是反过来的：它让AI“更像一个生物”，而不是“更像一个工具”。
2. 技术拆解：这个“没用”的项目，底层其实非常硬
先要给这个项目正个名：它叫“没用的AI”，不代表它容易做。
从我在网上看到的演示片段和比赛信息来看，这已经不是简单的“定时输出随机行为”那种哄小孩的电子玩具了。它看起来具备几个典型的Agent特征：独立的行为序列控制、基于外界输入的状态切换、稳定的角色人格记忆，以及一套防御性的交互边界。
如果你认真想做这样一个“没用的AI”，背后至少要打通四个技术层。
2.1 第一层：行为状态机是地基
“活着感”的核心，不是自由对话，而是行为状态切换的自然度。发呆、睡觉、躲避、好奇、偷看、焦虑、开心，这些是离散状态，模型之间按概率、输入和时间随机迁移。最简单的实现是用一个有限状态机（FSM），把状态定义清楚，把迁移条件定义清楚：
# 状态定义示例（结构示意，非完整源码） class PetState(Enum): IDLE = "idle" SLEEPING = "sleeping" HIDING = "hiding" CURIOUS = "curious" ANGRY = "angry" # 状态迁移条件 transition_rules = { PetState.IDLE: [ (PetState.SLEEPING, 0.2, "no_interaction_3min"), (PetState.CURIOUS, 0.6, "mouse_moved"), (PetState.HIDING, 0.1, "clicked_fast_multiple_times"), ], PetState.SLEEPING: [ (PetState.IDLE, 0.7, "mouse_moved_or_noise"), ], }这个状态机决定了用户感知到的“性格”。状态太少容易无聊，状态太多容易乱。我在自己做类似原型时，通常建议从5到7个状态开始跑，跑顺手再往上加。
2.2 第二层：人格一致性比智能感更重要
很多同类宠物项目翻车的点不是不够聪明，而是“不稳定”——今天跟你很亲，明天就像失忆一样冷冰冰。用LLM做自由对话很容易让AI产生人格漂移，今天温柔，明天尖锐，后天就忘了你是谁。
要维持“同一只宠物”的认知，需要考虑三件套：
- 固定提示词框架：使用System Prompt把这些信息固化：宠物背景、性格标签、说话习惯、行为边界。
- 记忆文件持久化：用户每次交互后，把关键反馈写入本地JSON或数据库。比如“主人今天摸了我五下”“我不喜欢被一直戳”这类长期记录。
- 短期上下文窗口：不要真的把全部历史塞给大模型，那样既慢又贵。维护最近20轮左右的交互摘要即可。
{ "pet_name": "泡芙", "age": 3, "personality": ["傲娇", "好奇", "有时候黏人"], "memory": ["用户喜欢用鼠标快速划过屏幕", "被连续点击超过10次后进入生气状态"], "behavior_template": "先观察，再回应，不主动讨好" }这套结构是让“没用的AI”产生“活着的错觉”的关键——不是能力在打动人，而是一致性在打动人。
2.3 第三层：防御机制是“灵魂”
最让我觉得这个项目在认真做产品的地方，是它给宠物设计了“防御机制”。
现在的AI聊天产品都很“讨好”：有问必答，有求必应，语气温柔，百折不挠。但这个电子宠物不一样——它被戳烦了会躲开，不开心会不理人，用户想“强制互动”时它反而会撤退。
这个设计在技术上其实不难实现：加入频繁点击检测、加入冷却时间、加入状态计数。但它在产品层面非常少见，因为大部分AI产品形态都把“响应速度”和“响应意愿”当作核心指标。
正是这一层“不配合”，让这个宠物更像一个独立存在。用户确实会被拒绝，但正是这个拒绝让整个交互产生了真实感——这在情感陪伴类AI里，其实是一个非常有价值的边界探索。
2.4 第四层：生成式AI不是必须
如果今天想快速复刻一个，我可以直接说结论：不一定非要接大模型。
如果你的目标只是做一个能“活”在桌面角落的电子宠物，用纯规则+状态机+动画资源就完全够了。大模型的价值在于自由对话和跨情境回应的弹性，但代价是延迟、成本和人格漂移风险。
真正适合接大模型的位置有三个：
- 用户主动发起对话时（不是宠物主动说话）
- 宠物要生成“新鲜行为”时，比如听见用户说“我好累”后，生成一个拥抱动作
- 长期记忆摘要更新时，用大模型把碎片事件提炼成宠物记忆
其余大部分时间，让宠物保持安静、偶尔动一动、偶尔发呆，比频繁输出更接近“活着”。
3. 为什么我会推荐每个AI开发者做一次这个“无用”项目
严格来说，这个项目看起来没有任何商业价值。它既不能提高工作效率，也不能做成标准SaaS，更看不出付费点，但它提供了一个难得的训练场：在没有KPI和效率指标约束的情况下，重新思考AI产品的互动方式。
我之所以推荐每个AI开发者做一次类似项目，原因有三。
3.1 它逼你从“功能视角”切换到“体验视角”
做功能型AI，核心流程是：需求分析 → 输入输出设计 → 模型能力匹配 → 效果评估。这套流程下，你基本不需要思考“用户会不会因为AI的存在而开心”。
但这个电子宠物项目完全不一样。你必须问自己：
- 用户什么条件下会觉得“被回应了”？
- 什么样的行为序列会让用户觉得“它在跟我互动”？
- 什么样的拒绝会让用户觉得有个性，什么样的拒绝会让人想删除它？
这些问题的答案不在大模型的权重里，而在你对人和环境互动的观察里。做一个“没用的AI”会强迫你接受一个事实：体验感是设计出来的，不是模型生成出来的。
3.2 它训练你做“轻量级工程决策”
在真正的AI应用开发里，很多问题不是“模型不够聪明”，而是“工程结构不够轻”。这个电子宠物项目就是一个很好的减速带：你要考虑本地运行的延迟、状态迁移的时机、与用户输入之间的碰撞冲突、动画和文本的同步、长期记忆的读写频率。
这些问题逼你用最小的方式做工程判断，而不是盲目堆接口。
3.3 它让你重新理解“AI Agent”的本质
现在Agent很火，很多人把Agent等同于“能调用工具、能规划任务、能自主执行的大模型”。但这个电子宠物提醒了我们一件事：Agent在最早期的定义里，就包含“能够感知环境并自主行动的行动者”。
这个宠物能感知鼠标、感知时间、感知用户点击频率，然后自己决定下一步行动。这就是一个完整且自洽的Agent，只是它不干正事而已。它的核心能力不是工具调用，而是意图感知和状态切换，这两种能力是所有Agent系统真正复杂的地方。
从这个角度看，“没用的AI”反而是对Agent能力边界的一次很有意思的解构：我们习惯用“做任务”来衡量Agent，但Agent完全可以用来“不做任务、只做陪伴”。
4. 如果你想复刻：从最小可用版到进阶版的全路径
这个项目听起来门槛不高，但要做得有“活体感”，比想象中要花更多功夫。下面是我最建议的复刻路径。
4.1 先只做局部，不要做全能
第一版别接大模型、别做语音、别做复杂动画。就用纯前端，做一个只有“状态机+鼠标感应”的桌面/网页宠物。
技术栈可以很轻：
- 前端：HTML + CSS + JavaScript，或者用Vue/React也行
- 状态机：手写一个简单FSM，不引第三方库
- 动画：用CSS transition或者Lottie动画，不用做骨骼动画
- 感应事件：mousemove、click、窗口失焦/聚焦、空闲计时
这个版本的目标只有两个：状态切换自然、用户愿意多停留两分钟。把这两件事打磨到位，再去扩展AI对话。
4.2 再接入LLM：只做单点对话
在状态机跑顺之后，再考虑接入LLM能力的点，最合适的是“主动对话”和“回应长文本输入”。提供一个输入框，用户说的话会被LLM理解、转化成一段简短回复，并可能触发宠物状态改变。
# 伪代码示意：把LLM输出映射到行为状态 response = llm.respond(user_input, pet_memory) if response.emotion == "happy": pet_state = PetState.CURIOUS elif response.emotion == "sad": pet_state = PetState.HIDING elif response.emotion == "angry": pet_state = PetState.ANGRY这里的关键不是让LLM自由发挥，而是让它输出结构化的情绪标签，再由状态机决定具体行为。LLM负责“说什么”，状态机负责“怎么做”。
4.3 进阶版：记忆文件与可扩展人格
到了这一层，你可以开始给宠物建立持久记忆。建议直接用SQLite或者JSON文件，不要上重型数据库。记录三类信息：
- 用户交互频率：每天大概互动几次，集中在什么时间
- 情绪反馈：用户什么时候开心、什么时候烦躁，宠物如何应对
- 长期记忆：宠物自己的“经历”，比如“上周日主人没有理我，但我自己玩得很开心”
这部分做好了，宠物会和用户产生一种“只有我们懂”的默契，这是陪伴类产品高粘性的重要来源。
4.4 不建议做的事：彻底自由放养
最后给几件不建议做的事：
- 不建议让宠物完全自由生成行为，没有状态机约束，行为会失控
- 不建议一开始就做大模型自由聊天，你会被延迟和语气漂移折磨死
- 不建议追求多模态，视觉、语音、文字全上，项目复杂度会崩溃
记住一条原则：先做行为稳定性，再做智能感。
5. 这个项目给AI开发者和团队带来的真正启示
很多做AI产品的人看到这种“没用的AI”，第一反应是“这不就是玩具吗”。但做过了你就知道，它真正要解决的问题，和商业级AI应用一模一样：输入噪音、状态控制、人格一致性、异步行为调度、用户容忍边界。
区别只是，商业AI项目用技术去完成一个明确的任务，这个电子宠物用技术去完成一出“像活着的错觉”。而后者，对数据流和控制流的要求其实一点都不低。
把这个角度展开来说，我觉得这个方向给开发者们留下的三点启示是能长期复用的。
5.1 AI应用不只是工具，也可以是“存在”
工具型AI解决“我做不完”的问题，陪伴型AI解决“我感到孤独”的问题。第二种问题的市场规模没有被验证，但需求是真实存在的。很多人下班后不想说话，但愿意对着屏幕里的小动物自言自语，这类产品其实填补的是一种“安全陪伴”。
如果你正在做情感陪伴类AI，请把“稳定的人格一致性”放到比“更强的模型能力”更优先的位置。用户记住一个AI，不是因为它更聪明，而是因为它一直“是那个它”。
5.2 反效率设计，反而更容易产生差异化
市面上绝大多数AI产品都在追求更快、更强、更全能。但那个电子宠物的反效率设计，反而在大量同质化产品中形成了强烈的差异化——它知道自己什么时候该不理你。
在AI产品同质化严重的今天，“克制使用AI能力”反而是一种取舍智慧。不是所有能力都要用上，在适合的场景里做减法，往往比做加法更能建立产品记忆点。
5.3 行为细节比想象中更具黏性
我在看这个电子宠物的演示时，印象最深的反而是一些很小的细节：它在发呆时耳朵会动一下；你鼠标经过时它先抬头再决定要不要理你；它睡觉时的呼吸起伏没有停在同一个频率。
这些细节没有用到任何一个最新大模型技术，但它们构成了这个“AI存在”的骨架。这就是我一直想说的：在AI应用层做到让人“愿意留下来”，靠的不是模型智商，而是行为细节的颗粒度。这是可以用工程手段精确设计的，而不只是依赖模型能力。
赛后的一些真实想法
那天我在展区多站了一会儿，看着屏幕里的电子宠物睡觉、醒来、又假装没看到我。有个路过的观众说了一句话，大意是：这东西没用，但有点可爱。
我觉得这句话恰好点到这个项目的本质了。它确实不能帮你写周报、不能帮你写代码、不能帮你生成图片，也没法完成生产环境里任何一个具体任务。但它提供了另一类价值：让人在一个充满“效率至上”声音的环境里，重新体验一次“纯粹因为有另一个存在，而打开屏幕”的感觉。
这种价值很难量化，所以很容易被轻视。但如果你真的做一个这样的项目出一版，亲手跑起来，看着它在桌面上发呆、睡觉、偶尔看你一眼，你会明白一个道理：AI产品的边界远不只在“能用”这一层，“让人愿意陪伴”本身就是一种极难复制的能力。
如果你最近正好在开发AI应用，或者正在找AI方向，我建议你花一两个月做这样一个“没用的AI”。你会被迫完善状态机、记忆管理、交互边界和人格一致性，这些能力迁移到任何AI产品上都会直接产生竞争力。而且很重要的是，做完之后你会对“AI替人做事”和“AI与人相处”这两条路，有完全不同的体感。
技术是为目的服务的。而这次，“目的”是让一个虚拟存在看起来像是真的在陪你——这个挑战，远比让AI答对一道题要复杂得多。
