AI 桌宠：从一张图片到有性格的桌面伙伴
本文结论
想做的是：用户上传自己的图片，经过 AI 转化，得到一个可以放在 macOS 或 Windows 桌面上、能互动和聊天、记住偏好的小伙伴。
第一版选择 Electron + 2D 角色图片 + 本地情绪状态机 + 可配置的 AI 图片编辑与对话服务。先验证「这是我的宠物，它认识我、会回应我」的体验，再升级多表情资产与骨骼动画。
本文配套的 Softspot Demo 位于仓库
demos/desktop-pet/。文末区分已验证功能、接口模拟测试和待验收事项。
1. 产品到底要提供什么
桌宠的核心价值不是把聊天框换成一只猫，而是把用户已经喜欢的形象变成一个持续陪伴、行为一致的角色。
可以从三种场景切入：
| 用户场景 | 用户希望得到什么 | 最先要做好的体验 |
|---|---|---|
| 上传自家猫狗的照片 | 工作时也能看到熟悉的小家伙 | 花纹、轮廓和配饰能认出来；桌面上不挡操作 |
| 上传自己的画或原创角色 | 让创造的角色有自己的性格 | 形象保留、性格设定、动作与话语一致 |
| 工作时想要轻度陪伴 | 被回应、被记住，又不会不断被打断 | 轻互动、低频反馈、可睡眠、可隐藏 |
首个闭环是：上传 → 看到角色 → 摸一下有回应 → 聊两句 → 留在桌面 → 下次打开仍记得。
这里的「有感情」是产品体验：持续状态、合适的表达、关系记忆与行为反馈。它不是模型真的拥有情绪或意识。
1.1 第一版的取舍
做单只宠物、文字聊天、三项养成数值、五种情绪、显式偏好记忆和桌面陪伴。用户可以随时隐藏或让它睡眠。
暂不做屏幕读取、麦克风常开、自动操作电脑、多人社交、宠物商城或复杂任务代理。它们会引入独立的交互与权限问题，也不帮助验证「一张自己的图能不能让人产生陪伴感」。
2. 相关产品调研
调研日期为 2026 年 9 月 19 日。以下产品信息来自官网、开发者文档与公开源码，没有安装并实测这些竞品的双端客户端。页面声明不能直接当作质量或稳定性证明。
| 产品／项目 | 公开资料体现的能力 | 与本需求的关系 | 跟进价值与边界 |
|---|---|---|---|
| VPet | 投喂、摸头、丰富状态动画、创意工坊、插件；核心为 WPF | 养成与动作反馈很贴近桌宠场景 | 适合学习状态和动画组织；直接复用无法满足原生 Mac 客户端要求。代码与动画素材授权须分别查看 |
| PetPal Studio | 上传照片，生成动画包，导入 Mac／Windows 客户端 | 最接近「自己的照片变桌宠」 | 值得学习照片到资产包的产品闭环；公开教程列出一次性 US$10，付款后解锁预览，实际质量未实测 |
| PetPal Desktop | Tauri + Rust + JavaScript，透明窗口、托盘、资产包导入 | 证明照片资产和桌面播放器可以解耦 | 开发者页面明确说明仍是早期版本，未完成所有系统和架构的重新测试，Mac 公证未确认 |
| Desktop AI Companion | Windows 桌面覆盖、聊天、记忆、语音、Live2D／VRM 导入 | 接近「有性格、能对话的角色」 | 可参考角色设定与记忆体验；导入模型和上传普通图片的门槛不同，公开页面提供的是 Windows 版本 |
机会在两条能力的交汇处：照片生成产品降低形象制作门槛，AI 角色产品提供持续对话和关系感。本项目要把这两条路径合在一起，同时让第一次使用足够简单。
但不宜宣称市场上没有同类产品。尤其 PetPal 已公开提供相似的照片到桌宠路径，真正需要验证的是：形象一致性、情绪可信度、使用负担与长期留存。
3. 一张图片怎样变成能互动的角色
需要把「形象生成」与「运行时动作」分开：AI 可以离线生成资产，点击反馈则应立即由本地程序响应。
| 路线 | 优点 | 主要难点 | 本项目判断 |
|---|---|---|---|
| 原图／去底图 + 程序动画 | 快、便宜、图像身份不易漂移，任意主体均可尝试 | 整张图缩放和转动，肢体、眼睛不能独立动 | 作为即时预览与失败回退 |
| AI 图片编辑 + 少量情绪差分图 | 风格统一；开心、困倦等状态更直观；适配范围较广 | 多图的花纹、服饰和比例可能不一致，需要筛选与对齐 | 首选迭代路线；Demo 先实现单张 AI 编辑 |
| 自动生成 Sprite Sheet | 部署简单，播放器只需切帧 | 格子数量、基线、角色大小和动作连贯性不一定稳定 | 后续在自动校验后引入，不假设一次生成就可切片上线 |
| Live2D／Spine／2D 骨骼 | 连续动作、局部变形、表情控制更自然 | 需要拆图、补遮挡、网格与参数，任意上传图很难直接通用 | 适合经过美术加工的精品角色或受约束模板 |
| 图生视频后抽帧 | 容易获得较丰富的连续动作 | 循环首尾、透明背景、闪烁、身份漂移和动作切换要处理 | 适合预生成待机动画，不适合每次互动临时生成 |
| 单图转 3D／VRM | 可转向、换动作，空间表现更强 | 几何质量、骨骼绑定、毛发和动作重定向都增加复杂度 | 暂不作为第一版核心路线 |
Live2D 官方教程 的工作流包含 PSD 素材、网格、表情和变形器；自动变形器文档 还明确将非人类动物列为不适合的模型。它说明「已有 Live2D 模型可以驱动」不等于「任意宠物照片都能一键变成 Live2D」。
3.1 推荐的资产流水线
Demo 实现到单张角色 PNG，并由本地动画驱动。上图中的情绪差分、统一基线与资产包质检属于下一步，没有包装成已经完成的能力。
输入建议：单一主体、轮廓清晰、耳朵和尾巴尽量完整。照片、绘画都允许导入，但复杂遮挡或多主体图的结果需要用户选择和检查。
3.2 图片模型怎么选
Demo 使用 兼容 OpenAI Images Edits 的适配器，默认模型 ID 为 gpt-image-1.5，可在设置中改为账号实际可用的模型。
选择它作为接入起点，是因为公开文档覆盖参考图编辑、透明背景、PNG 输出和 Base64 结果；这使角色资产管线容易实现与校验。OpenAI 图片生成指南 与 Azure 图片模型说明 可用于核对接口和参数支持。
这不是经过模型效果对打后得出的画质冠军结论。不同模型、部署区域和账号权限会影响可用性，最新模型名也不一定支持同一组参数。国内产品上线可比较 Seedream 等参考图编辑服务，但应新增对应协议适配器，不能只替换 URL 就视为兼容。
正式选定服务商前，建议用同一组 20 张参考图测试：猫、狗、兔子、手绘角色、白色主体、复杂背景、饰品以及遮挡样例。记录每次请求的模型版本、参数、结果、耗时与真实计费。
验收重点为可辨识花纹、无多肢、透明边缘、完整轮廓，以及不同表情仍像同一个角色。供应商宣传图无法代替这组测试。
4. 为什么选 Electron
| 方案 | 适用点 | 对本项目的代价 |
|---|---|---|
| Electron | Mac／Windows 共用 Chromium 和 JavaScript；透明窗口、置顶、托盘、拖动与穿透有明确 API | 包体和基线内存较大，必须控制常驻窗口数量与动画 |
| Tauri 2 | 包体通常更小，Rust 后端适合严格控制本地能力 | 系统 WebView 存在差异；Mac 透明窗口涉及 macOSPrivateApi 配置，需评估分发方式与系统兼容 |
| Qt／PySide | 原生窗口能力成熟，可结合 Python 图像处理 | UI 和 Python 依赖打包增加维护面；当前仓库以 JavaScript 为主 |
| Unity／Godot | 复杂 2D／3D 动画、物理和角色行为更方便 | 对轻量常驻桌宠偏重，透明与桌面交互仍需处理平台差异 |
| Swift + Windows 原生技术 | 可深度适配各自系统 | 两套桌面实现，首轮验证成本最高 |
Electron 官方的 窗口交互文档 明确介绍拖动区域与鼠标穿透，并支持在 Mac／Windows 穿透时转发鼠标移动事件。Tauri 配置文档 列出了 Mac 透明背景相关开关。
本阶段优先级是：双端桌面行为可实现 > 快速验证完整闭环 > 渲染一致性 > 安装包最小化。因此选 Electron。这个结论针对当前技术栈和 Demo 阶段，并不意味着 Tauri 不适合桌宠。
如果后续主要问题变成常驻内存与分发大小，可以保留情绪逻辑和资产格式，再重新评估 Tauri。不要仅凭框架宣传的基础包体做迁移决定。
5. 怎样产生持续的情绪感
将系统拆成四层，而不是每次让 LLM 随机决定所有动作：
| 层 | 保存什么 | 谁决定 |
|---|---|---|
| 性格 | 名字、温柔／活泼／傲娇 | 用户设定；云端聊天使用 |
| 状态 | 精力、饱腹、亲密、是否睡眠 | 本地确定性规则 |
| 表达 | 安心、开心、好奇、困倦、低落 | 互动事件或经过校验的模型输出 |
| 记忆 | 用户显式填写的偏好、最近对话 | 本地存储，下次聊天重新提供 |
例如点击「一起玩」：精力减少 8，饱腹减少 5，亲密增加 5，切换为好奇状态并摇摆。点击「摸摸」：亲密增加 3，切换开心状态。睡眠优先级高于其他表达，睡着后不会因为一次摸摸立刻开始蹦跳。
运行时动画不调用大模型。这样拖动、摸头和投喂不会等待网络，云端费用也集中在图片创建和主动聊天。
Demo 的记忆边界
最多保存 8 条用户明确填写的偏好，聊天时直接注入，不做自动抽取、向量数据库或复杂 RAG。最近 24 条消息持久化，最多取最近 16 条发给模型。
这种小规模记忆已足够验证「它下次还记得我」。规模变大后再引入检索，可参考 Agent 长期记忆笔记。
本地无密钥模式使用固定规则话术，不能理解任意上下文；性格选项主要作用于云端对话提示词。它的作用是演示状态和动作闭环，界面明确标记「本地互动」。
6. Softspot Demo 的实现
6.1 代码与运行方式
文档放在 content/，程序放在独立的 demos/desktop-pet/，避免将桌面应用源码作为 Quartz 文章或静态附件发布。它拥有独立依赖与锁文件，不改博客构建流程。
从博客仓库根目录执行：
npm --prefix demos/desktop-pet ci
npm --prefix demos/desktop-pet start在「换个模样」导入图片，在「连接 AI」中配置服务，再点击「AI 转化为绒毛伙伴」。没有密钥也能先使用内置角色或上传图。点击「放到桌面」后，桌宠进入透明置顶窗口。
6.2 双窗口结构
主进程管理唯一状态、API 请求与文件持久化。两个窗口只处理展示和交互。密钥留在主进程内存，渲染进程启用隔离与沙箱，不开放通用文件系统接口。
正常情况下只存在两个窗口，关闭小窝会隐藏它，菜单栏／托盘可重新打开；退出菜单用于彻底结束进程。桌宠可手动拖动，透明空白区域可穿透，托盘可开启整个窗口完全穿透。
当前穿透以 UI 元素矩形为粒度：图片内部的透明洞仍可能拦截点击。多显示器移除时会将窗口限制回可用工作区域；跨不同缩放比例屏幕拖动仍需双端实机专项验证。
6.3 已实现能力
| 能力 | Demo 实现 | 限制 |
|---|---|---|
| 图片导入 | PNG／JPG／WebP，限制大小和像素，最长边缩小至 1024 | 尚无裁剪编辑器 |
| 本地去底 | 从图像边缘移除近似纯色区域 | 非 AI 分割；白色主体可能误删，可关闭 |
| AI 转化 | 真实 Images Edits 调用、透明 PNG 参数、结果落盘 | 需要用户账号与模型权限；真实质量未验收 |
| 动画 | 呼吸、开心弹跳、好奇摇摆、睡眠、低落 | 上传图使用整图变换，尚无独立眨眼、嘴型或肢体骨骼 |
| 内置角色 | 本地 Canvas 小猫，情绪改变时切换眼睛形态 | 内置角色是程序绘制，不是照片生成效果样例 |
| 聊天 | 云端 JSON 回应及情绪、无密钥本地模式 | 兼容服务需支持约定；云端失败明确回退 |
| 情绪状态 | 精力、饱腹、亲密及睡眠优先级 | 是 Demo 规则，尚未经过长期数值平衡 |
| 记忆 | 可添加、删除偏好，保存近期消息 | 不自动抽取长期记忆 |
| 桌面 | 透明置顶、拖动、托盘、隐藏、穿透开关 | 尚未在 Windows 实机及全部 Mac 架构上验证 |
6.4 错误与数据处理
聊天 30 秒超时，接口失败或 JSON 不合法时使用本地回应并显示回退标识。图片 150 秒超时，失败保留旧形象；超时不代表服务商取消任务，不自动重试以避免重复费用。
图片和状态保存在 Electron userData 目录。原始上传文件不会被修改；保存的 source.png 是本机缩放和可选去底后的导入版本。API 密钥不写入状态文件。
删除某条记忆后，后续请求不再注入该条显式记忆；如果聊天历史仍包含同样内容，需要同时清空历史。开启云端聊天意味着相关历史与记忆会发送给所选服务，不宣称云端模式完全离线。
7. 成本、性能和验收
7.1 成本按创建和陪伴分别计算
每只宠物创建成本
= 参考图编辑次数 × 实际单次费用
+ 情绪差分图次数 × 实际单次费用
+ 失败重试费用
每日聊天成本
= 各轮输入 Token 费用之和
+ 各轮输出 Token 费用之和不写死一个「每只几分钱」的数字：模型、尺寸、质量、输入图和重试都影响费用。当前 Demo 每次生成只请求一个图片结果，所有动作在本地运行，没有持续逐帧调用 AI。
商业化可尝试「一次性角色创建 + 聊天自带密钥」，等真实数据证明长期陪伴价值后再考虑订阅。创建付费前最好给用户足够的形象预览与失败补救，不把生成漂移留给用户承担。
7.2 建议的后续验收门槛
以下是目标，不是已测指标：
- 摸摸、投喂等本地操作到画面反馈，P95 小于 100 ms。
- 静置 30 分钟后 CPU、内存与耗电稳定，没有持续增长；分别测只有桌宠和同时打开小窝两种情况。
- 图片测试集中，至少 90% 的结果能让用户辨识原角色；不合格结果可重新选择，不直接覆盖。
- 8 小时陪伴过程中，不抢输入焦点，睡眠和隐藏后降低动画开销。
- Mac Apple Silicon、Mac Intel、Windows 11 x64 分别检查托盘、透明、置顶、穿透、缩放、多显示器、休眠恢复与重启恢复。
- 正式分发前补齐 Mac 签名／公证与 Windows 签名，验证干净机器的首次启动。
7.3 本次实际验证记录
在 macOS 15.7.3 / Apple Silicon 上执行 Electron 原生窗口 E2E。使用隔离数据目录，图片上传样例来自内置角色的 Canvas 输出，AI 服务使用本机模拟响应，因此不产生云端费用，也不能用来证明真实图片模型的生成效果。
已通过的检查包括：
- 启动原生窗口、内置角色渲染、摸摸／投喂／玩耍／睡眠／唤醒。
- PNG 上传、名字与性格修改、显式记忆添加。
- 图片编辑 Multipart 参数、图片失败保留旧资产。
- 聊天携带记忆、响应 JSON 校验、非法格式与 HTTP 错误回退。
- 桌宠置顶、截图透明像素、窗口间状态同步、隐藏。
- 更换 AI 服务地址时，阻止静默复用旧密钥。
- 重启恢复角色、消息和记忆；密钥不落盘；删除显式记忆。
- 渲染进程没有捕获到运行时异常。
复跑命令：
npm --prefix demos/desktop-pet run test:e2e报告为 demos/desktop-pet/test-results/smoke.json，截图为同目录的 studio.png 与 desktop-pet.png。
打包命令：
npm --prefix demos/desktop-pet run pack:mac
npm --prefix demos/desktop-pet run pack:winMac Apple Silicon .app 已完成打包后的实际启动、桌宠窗口与投喂验证；Windows x64 ZIP 已通过完整性校验。Windows 仅完成打包，未完成实机运行验收；Mac Intel 尚未构建和实测。 开发包未签名、公证。
真实图片模型生成、真实大模型对话、长时间性能与竞品双端体验尚未完成实测。下一轮最有价值的工作，是拿一组真实用户图片跑完生成质量验收，再补 Windows 实机验证。
8. 下一步如何推进
先找 5 位用户，各上传自己真正喜欢的一张图。观察第一次生成是否满意、是否愿意把桌宠留在桌面、第二天是否还打开，以及聊天和轻互动哪个更有价值。
如果「像我的宠物」比聊天更重要，就优先提升参考图一致性和动作质量；如果用户在意「它记得我」，就加强明确可管理的记忆与性格；如果用户频繁隐藏它，则先解决位置、遮挡和打扰频率。
技术上建议按以下顺序推进：
- 真实生成验收：统一参考图和成本记录，比较实际可用的图片编辑服务。
- 三种情绪差分：基于同一参考图生成安心、开心、睡眠，加入比例、基线、透明边缘检查。
- 跨平台稳定性：Windows 实机、多屏缩放、拖动与穿透、签名分发。
- 长期陪伴体验：限制通知频率、安静模式、适度记忆和可解释状态。
- 更细动作：达到留存目标后再投资分层、骨骼、Live2D 或视频抽帧流水线。
先证明用户愿意留下这只宠物，再增加动作和模型复杂度。