前几天我在 Codex 里看到一个新东西。
桌宠。
我当时第一反应其实是，啊？
一个写代码的工具，旁边蹲着一个小东西，运行的时候动一下，等待的时候换个姿势，失败的时候再换个表情。
听起来就很不像什么严肃功能。
但我还是点进去试了一下。
试完以后，我有点改观。
它当然不是那种用了以后效率翻倍的功能，也不是能改变编程方式的大杀器。它更像一个很轻的小提示，把 Codex 这种 Agent 正在做的事，变成一个能被看见的状态。
这个点挺有意思的。
以前我们和 AI 打交道，更多是在聊天框里等一句回复。你问一句，它答一句，最多中间转个圈。
但 Codex 不太一样。
它会读文件，会改代码，会跑命令，会卡在权限确认那里等你点一下，也会一边处理一边告诉你它现在到了哪一步。
这时候，一个问题就冒出来了。
它现在到底在干什么？
如果界面里只有日志，你要么一直盯着看，要么切去干别的，过一会儿再回来瞄一眼。它是卡住了，还是在等我？它是还在跑，还是已经做完了？
很多时候没有那么直观。
所以桌宠这个东西，第一眼看是装饰，放到 Codex 这个场景里，又不只是装饰。
它像一个很轻的状态提示。
我这次没有直接用默认宠物，也没有去 Petdex 上装别人做好的。
我想试试，能不能用自己的参考图做一个。
我选的是以前养过的一只缅因猫。
银灰色，耳朵很大，耳尖有一撮毛，眼睛偏黄绿色，胸前有很厚的一圈白灰色长毛。它后来很早就离开了，所以这次拿它做 Codex 桌宠，对我来说也有一点纪念的意思。
这件事就突然不只是换个小图标了。
我先挑了几张照片。
不是随便丢一张正脸就完事。我找了正脸、侧脸、全身、坐着、趴着几种角度。因为桌宠最后不是一张头像，它要有好几种动作状态。只给一张照片，AI 很容易只记住「灰猫」，但记不住这只猫自己的轮廓和气质。
这一步我没有直接丢给 Codex。
我先把照片给 ChatGPT 看了一遍，让它帮我提特征。
银灰虎斑，黄绿色眼睛，耳尖毛，白灰色胸毛，长胡须，大尾巴，还有那种有点安静、有点认真，但不凶的表情。
这一步看着像多此一举，但后面确实省事。
你直接让 Codex 按照片生成一个桌宠，它也会做。但它到底抓到了什么，准备舍掉什么，你一开始是不知道的。等它一口气生成完，再发现方向偏了，就得整套重来。
我不太喜欢这种返工。
说真的，做这种小东西最麻烦的地方往往不是生成，而是你得在它还没跑远的时候，把方向掰回来。
接着我在本地单独建了一个项目文件夹。
没有放进我的网站项目，也没有混到别的开发目录里，就单独建了一个。
codex-pet-lab桌宠看起来不像正式代码项目，但生成过程中会冒出一堆文件，参考图、临时目录、base 图、spritesheet、pet.json、contact sheet。
这些东西如果散在别的项目里，后面排查的时候很烦。
然后就是安装 Hatch Pet。
这里我卡了一下。
教程一般会写得很顺，输入 $skill-installer hatch-pet，装完以后重载 skill，就可以开始生成。
但我第一次开着自动审查模式，安装命令一直卡在 automatic approval review timed out。
一开始我还以为是我哪里写错了。
后来才发现，这不是当前项目目录里的普通操作。它要联网下载 skill，还要写到本机的 .codex/skills 目录。自动审查没成功，也没有弹出一个很明确的提示。
我把权限切回默认，手动批准了一次。
装上了。
然后重启 Codex，Hatch Pet 就能用了。
这种小地方，官方说明里通常不会写得太细，但第一次照着做的人，真的很容易卡在这里。
装好以后，我没有马上让它生成。
我先开了计划模式。
让它只看参考照片，不创建文件，不生成图片，先把计划说出来。
我的提示词大概就是这个意思。
$hatch-petI want to create a custom Codex desktop pet based on my own reference materials.
The reference files are in
./references. These files are either created by me, owned by me, or I have the right to use them. Do not use any copyrighted character, brand mascot, anime, game, movie, logo, celebrity, or existing IP as inspiration.Before generating any images, pet package, spritesheet, or
pet.json, please first inspect the reference materials and give me a short creation plan.Please output only the key visual traits, style direction, animation states, visual constraints, and possible risks.
Do not generate images yet.
Do not create files yet.
Wait for my confirmation before producing the pet.
这段不只适合猫。
你想做狗，手绘角色，原创 mascot，或者自己设计的小东西，也可以把参考素材和描述换掉。
它给我的第一版计划还挺准。
它看到了银灰色缅因猫，深色虎斑，浅色口鼻和胸毛，很高的耳朵和耳尖毛，黄绿色眼睛，粉棕色鼻子，长胡须，大尾巴。
但也有两个地方我改了一下。
一个是它想在 failed 状态里加眼泪。
我不太想这样。
它毕竟是我以前养过的猫，我不希望失败状态太伤心。最后我让它改成耳朵稍微往后，有点懵，但不难过。
另一个是它把鼻梁上的浅色纹路理解成一条很明显的白线。
这也不太对。
我让它收一点，不要画得像卡通符号。
这就是先让它出计划的好处。
方向还没偏太远，改起来很轻。
确认以后，它先生成了一张 base sprite。
第一眼看过去，我觉得还可以。
它肯定不像照片级还原，也不可能完全还原。但耳朵、眼睛、胸毛和尾巴都在，已经不是一只随便生成的灰猫了。
后面它继续生成不同状态，待机，向左跑，向右跑，挥手，跳跃，失败，等待，奔跑，审视。
最后生成了 pet.json 和 spritesheet.webp。
pet.json 可以理解成这只宠物的配置文件，告诉 Codex 每个动作叫什么，每个动作有几帧，怎么播放。
spritesheet.webp 是真正的动画图集。
contact-sheet.png 更像检查用的总览图，可以一次看到所有状态。
到这里还没结束。
我把生成好的 silver-maine 文件夹放到这里。
C:\Users\admin\.codex\pets一开始我这里甚至没有 pets 文件夹。
后来才知道，没有也正常，手动新建就行。
放进去以后，回到 Codex 的外观设置里，就能在自定义宠物里看到它。我的这只叫 Silver Maine。
不需要重启，直接就能选。
但真跑起来以后，又遇到一个很小的问题。
第一次唤出宠物时，小猫的脸刚好被浮层上的下拉按钮挡住了。
这个问题不是生成失败。
它就是 GUI 里的控件和图片位置打架了。
于是我又让 Codex 把 spritesheet 里的猫整体稍微缩小一点，往左下挪一点，给右上角留出空隙。重新生成后，再覆盖本地宠物包。
这一步反而让我觉得最有意思。
如果是在 CLI 里，根本不会有这种问题。
命令行里只有文字、路径、日志。
但到了 GUI 里，一个小图标，一个浮层按钮，一个气泡提示，都会影响用户看到什么。
这也是我这次试桌宠时最明显的感受。
Codex 这类工具开始从命令行和聊天框往桌面端走以后，问题就不只是能力强不强了。
它还要处理很多前端层面的细节。
状态怎么露出来。
什么时候打扰用户。
它在工作时，用户能不能不用盯着日志，也知道它大概在忙。
它失败的时候，是冷冰冰地报错，还是给一个更轻的反馈。
桌宠当然不是唯一答案，也不一定适合所有人。
但它把一个原本抽象的 Agent 状态，变成了一个很具体的前端对象。
说到这个，我想起之前看过的一期 Peter Yang 采访 OpenAI Codex 团队的内容。
链接在这里。
https://creatoreconomy.so/p/how-openai-codex-team-builds-with-codex-alex-romain
里面有个点我印象很深。
Codex App 一开始并不是一个特别自然就会被做出来的东西。IDE extension 已经有用户，CLI 也有势头。那为什么还要做一个 App？
Codex 团队看到的是另一件事。
多 Agent 委派会变得越来越常见。
但让用户开着十几个终端去管理这些 Agent，不是一个好体验。
这个判断比「GUI 更友好」有意思多了。
GUI 的意义不是给不懂命令行的人降低门槛。
到了 Agent 这里，用户要管理的东西变了。
以前你敲一条命令，等一个结果。
现在你可能同时把几个任务交出去，一个在修 bug，一个在跑测试，一个在读文档，一个等你 review。
你要知道谁在动，谁卡住了，谁在等你点确认，谁已经可以收尾。
这时候界面不只是输入输出。
它开始承担状态管理。
Codex App 是一个更大的例子，桌宠是一个很小的例子。
它们解决的问题不一样，但方向有点像。
当 Agent 不再只是回答问题的模型，而是开始在后台替你做事，前端就要让这些正在发生的事，更容易被人感知到。
不一定要很夸张。
有时候只是一个小猫坐在屏幕角落里，你就知道它还在忙。
我最后也把这只宠物提交到了 Petdex。
Petdex 是一个社区分享站，里面可以浏览、安装别人做好的 Codex pet。我的这只叫 silver-maine，页面在这里。
https://petdex.crafter.run/zh/pets/silver-maine
这里还踩了另一个小坑。
我一开始发现 Petdex 里的预览动画不动，连我自己的 Codex 宠物也没有明显动画。
我第一反应是，坏了，是不是生成包哪里有问题。
后来查了一下才发现，我的 Windows 系统里 MinAnimate = 0，等于窗口动画效果被关掉了。很多网页、Electron 应用或者桌面应用，会跟着系统的减少动态效果走，动画就可能停住。
这个地方挺隐蔽。
不是每个人都会遇到，但如果你试的时候宠物不动，也不一定是 Hatch Pet 生成失败。
先看看系统动画、浏览器、省电模式这些设置，可能比重做一遍宠物更有用。
折腾完以后，我对 Codex 桌宠的看法变了。
它确实还是一个小玩具。
但不是没意义的小玩具。
以前我们讲专业工具，很容易默认它应该克制，冷静，信息密度高。
CLI 当然有它的优势，快，直接，可控，也很适合明确任务。
但 Agent 的工作方式有点不一样。
它不是你敲一行命令，它回一行结果。
它可能在后台跑几分钟，甚至更久。它会读上下文，改文件，请求权限，等待你确认，再继续往下做。
这个过程里，用户和工具之间的关系会变长。
关系一旦变长，界面就不能只靠日志和按钮。
你需要一种更轻的状态感知。
它在忙，还是在等。
它完成了，还是卡住了。
现在要不要切回去看一眼。
我不会说每个工具都应该有桌宠。
那也太闹了。
但我能理解为什么 Codex 会做这个功能，也能理解为什么 Petdex 这种分享站会冒出来。
当工具越来越像一个在桌面上帮你干活的代理，它就不再只是一个输入框。
它需要把自己的状态露出来，也需要让用户在不被打扰的情况下，知道它还在。
有时候，一个小猫坐在屏幕角落里，确实比一串冷冰冰的日志更容易被看见。