Codex真的能养宠物了！自定义宠物这个Skill揭示了ai怎么工作最有效率！

Codex 桌面宠物不只是彩蛋：我真的做出了一只会动的火焰大蒜，它背后其实是一套完整工作流

很多人第一次看到 Codex 桌面端的宠物，第一反应往往是：这也太可爱了，像给开发工具塞了一个电子挂件。

但我这次真的把一只会动的"火焰大蒜"做出来之后，感受反而完全变了。

它当然有趣，甚至有点离谱。可真正让我上头的，不是"桌面上多了一只小东西"，而是我发现这套宠物机制背后，根本不是一句提示词生成一张图那么简单，而是一条相当完整的小型资产生产流程：有主形象生成、有动作分解、有 QA 校验、有打包产物，还有明确的安装目录和清晰的运行契约。

换句话说，这不是"聊天时顺手出一张萌图"，而更像是在 Codex 桌面端里，亲手走完一条可交付、可安装、可复用的微型生产线。

我的pet.json

复制代码

{
  "id": "flame-garlic",
  "displayName": "Flame Garlic",
  "description": "A cute garlic pet with a small flame for a head, in Codex digital pet style.",
  "spritesheetPath": "spritesheet.webp"
}

本地 hatch-pet skill 与 codex-pet-contract 文档显示，自定义宠物的安装目录为 KaTeX parse error: Expected '}', got 'EOF' at end of input: {CODEX_HOME:-HOME/.codex}/pets//，核心文件为 pet.json 与 spritesheet.webp；生产流程中还会生成 qa/contact-sheet.png、qa/review.json、qa/videos/*.mp4、final/validation.json 等 QA 与校验产物。

一只"火焰大蒜"，为什么让我重新认识 Codex 桌面端

这次我做的 pet，是一只火焰大蒜。

光听名字就知道，这个东西天然带一点不正经：大蒜本来就有点反差，火焰再叠上去，视觉上会更像一个又怪又燃的小角色。它非常适合做宠物，因为你很容易脑补出它待机、挥手、跳跃、失败、等待、忙碌、审查这些状态。

但真正开始做之后，我很快发现，Codex 对"宠物"这件事的理解，比我预想得工程化得多。

它不是让我说一句"帮我画一只火焰大蒜"，然后系统自动补完剩下所有细节。相反，整套流程拆得很细：

先确定主形象，也就是这只 pet 的视觉基准。
再围绕固定动作行去生成不同状态的动作条。
然后检查动作是否符合规格，角色形象是否稳定。
最后把结果整理成应用能识别和安装的资产包。

从体验上看，这更像"做一个能被桌面应用消费的角色资源"，而不是"让 AI 临时给你画个可爱玩意儿"。

宠物的本质，其实是一套有规格的动画资产

如果只从结果看，Codex 桌面宠物像是一个彩蛋；但从机制看，它是一套很明确的精灵图动画资源。

根据本地 hatch-pet skill 的契约文档，这个宠物 atlas 有固定规格：

整张 spritesheet 的尺寸是 1536x1872
采用 8 列 x 9 行 的固定网格
每个单元格尺寸是 192x208
背景要求透明
未使用的格子必须保持透明

这意味着，宠物并不是"随便几张图拼起来"就能工作。应用侧其实已经预设了读取方式，会根据固定的行列去取不同状态的帧，再按对应时长播放。

更关键的是，这 9 行并不是抽象概念，而是明确对应 9 种状态：

idle
running-right
running-left
waving
jumping
failed
waiting
running
review

其中最有意思的一点是，running 并不等同于"字面意义上的跑步"，而更接近"正在忙任务"的工作中状态；review 则是偏审查、观察、思考的循环动作。也就是说，这套宠物不是单纯的动态贴纸，它和 Codex 本身的工作语义是对齐的。

这一下就把"好玩"变成了"产品设计挺完整"。

我做火焰大蒜时，走过的并不是一句话出图流程

这次最直观的感受，就是制作过程明显被拆成了多个阶段。

1. 先做主形象，而不是直接做整套动作

第一步不是把 9 行动画一次性全生成，而是先生成 base，也就是主形象参考图。

这个 base 很重要，因为后面所有动作条都要尽量锁定同一个角色身份：头部轮廓、脸、颜色、火焰形态、蒜瓣结构、整体比例、轮廓粗细，都不能一会儿像这个、一会儿像那个。

如果 base 没站稳，后面的宠物就会从"同一角色在做不同动作"，变成"9 个长得像亲戚但不是同一只的东西"。

对于火焰大蒜这种设定，这一步尤其关键。因为"火焰"很容易越画越飘，"大蒜"又很容易因为拟人化程度不同，导致有时候像蔬菜，有时候像吉祥物，有时候又像一个带火特效的蒜头图标。先把主形象钉住，后面才有一致性可谈。

2. 再做动作条，而且不是所有动作都一锅出

按 hatch-pet 的工作流，动作生成不是瞎铺开，而是有明显优先级的。

通常会先看 idle 和 running-right。原因很简单：

idle 最能暴露角色是否稳定，待机如果都不自然，其他动作更难成立
running-right 最能测试角色在运动状态下是否还能保持身份一致

这和传统图形资产制作很像，先做最关键的基准动作，确认角色没跑偏，再扩展到其他状态。

3. 部分动作可以镜像，但不是无脑翻转

这次我觉得特别像"产品级细节"的一点，是 running-left 不一定非要重新生成，但也绝不是可以默认镜像。

本地 skill 的说明写得很明确：只有当角色足够对称、翻转后不会破坏身份、不会让手持物或单侧特征出错时，running-left 才适合由 running-right 镜像得到。

这件事听起来小，但它很说明问题。

因为这代表流程里不只是"尽量省生成次数"，而是把"资产正确性"和"生产效率"一起考虑了。对于火焰大蒜这种角色，如果左右两边没有强烈不对称特征，那么镜像是很合理的；但只要某一侧有独特火焰形状、配件、文字或方向性强的动作，硬镜像就会穿帮。

这不是娱乐功能常见的粗放做法，反而很像正经资源生产里的优化分支。

4. 生成完成后，还要过 QA 和打包

如果只是"生成几张图然后显示出来"，那顶多叫半成品。

真正让我觉得这套东西完整的，是它后面还有一整段检查和包装流程。最终并不是只得到"看起来差不多"的图片，而是要产出一组明确文件，并且这些文件有各自职责。

关键产物到底有哪些，它们分别负责什么

这部分是我最想强调的，因为它直接决定了这东西到底是"聊天产物"还是"可交付资产"。

按照本地 hatch-pet skill 的说明以及宠物契约文档，一次正常的 pet 生产流程里，常见关键产物包括下面几类。

1. `pet.json`：宠物的清单和入口说明

最终安装目录里最核心的清单文件就是 pet.json。

它的作用不是存动画像素，而是告诉应用："这只宠物是谁，它叫什么，它的说明是什么，它的精灵图文件在哪里。"

一个典型 manifest 会包含这几个字段：

id
displayName
description
spritesheetPath

也就是说，pet.json 负责的是"身份"和"索引"。没有它，应用不知道该怎么把这份资源识别成一只可以加载的宠物。

2. `spritesheet.webp`：真正被应用消费的动画资产

如果说 pet.json 是入口，那么 spritesheet.webp 就是宠物本体。

应用最终读取的核心资产就是这张精灵图。9 行状态、每行多少帧、每帧在网格里的位置，本质上都被压进这张统一规格的 spritesheet 里。

这里也能看出它为什么更像"资产打包"而不是"即兴出图"：

你不能只给一张 PNG 头像
你不能只给几张零散 GIF
你必须给出符合固定网格和透明规则的整张图

这就是典型的可执行资源格式，而不是聊天记录里的图片附件。

3. `qa/contact-sheet.png`：第一眼看全局一致性的总览图

这份文件很适合拿来做人工审查。

因为 contact sheet 会把整个 atlas 的内容按格子铺开，你能很快看出：

某一行帧数对不对
某个动作有没有出格
角色是不是在不同状态下长得不像同一只
有没有白底、脏边、裁切、串格、背景没抠干净的问题

如果说自动校验是规则层，contact-sheet.png 就是视觉层的第一关。

4. `final/validation.json`：规格校验结果

这个文件更偏"结构正确性"的验证结果。

它会帮助确认 atlas 尺寸、网格、透明区域、单元格范围之类的约束是否满足。对于桌面应用来说，这类校验非常必要，因为视觉上"差不多"不代表程序侧一定能安全读取。

5. `qa/review.json`：更细的 QA 审查记录

除了规格层检查，流程里还有更细的 QA 结果，例如边缘像素、异常稀疏帧、尺寸离群、色键清理问题等。

这类文件的价值在于，它不是只问"能不能显示"，而是进一步问"是不是干净、稳定、适合放进产品里"。

6. `qa/videos/*.mp4`：把动作真正跑起来看

静态看 contact sheet 和动态看视频，是两种完全不同的审查体验。

有些问题在格子里不明显，一旦连播就会暴露，比如：

首尾循环突兀
某帧突然抖动
角色比例忽大忽小
动作节奏很怪

所以 QA 视频并不是锦上添花，它实际上是把"能拼出来"升级成"能看、能用、能接受"的关键一环。

为什么我会说，这更像一条微型生产线

把上面这些文件和步骤连起来看，你就会发现这件事已经不是单点生成，而是一条很清晰的流水线：

准备 pet 请求和 job 清单
生成主形象
生成动作条
必要时做镜像分支
提取帧并拼 atlas
做校验和 QA
输出安装包

本地 skill 里甚至把 run 目录、prompts、decoded、frames、final、qa 这些阶段性目录都分好了。这种组织方式有个特别明显的好处：你可以追溯每一步是怎么来的，哪一步出了问题，该修哪一段，而不是面对一堆"最后终于出来了"的黑盒结果。

这就是为什么我会把它定义为"可交付、可安装、可复用的小型资产生产流程"。

它有输入，有中间件，有规则，有检查，有最终包，还有明确安装位置。严格一点说，这比很多"AI 帮你生成一个东西"的功能都更接近真实生产。

真实体验里最有意思的，不是顺滑，而是有摩擦感

我反而觉得，正是那些不那么丝滑的地方，让这套流程显得更真实。

比如这次过程中，我就碰到了典型的 429 和权限问题。

429 这种情况，本质上是生成链路里的速率或额度压力提醒。它会把你从"我以为一句话就该秒出结果"的幻觉里拉回来，让你意识到：你现在驱动的不是一个随手贴纸功能，而是一条实际在调用模型、分配任务、处理资产的工作流。

权限问题也是类似的感受。因为宠物并不是只存在于聊天窗口里，而是最终要落到应用可识别的目录结构里，涉及真实文件读写、目录组织和安装位置，所以权限边界会真实出现。这种摩擦并不浪漫，但它恰恰说明这不是虚拟玩具，而是"真的在生成、检查、组装、安装资源"。

从用户情绪上说，当然会觉得麻烦；但从产品理解上说，这反而让人更容易意识到它的完整性。

子代理的加入，让"做宠物"这件事突然很有 Codex 味

另一个让我印象很深的点，是这件事天然适合用子代理拆分。

在 hatch-pet 的流程说明里，主代理并不需要亲自包办所有动作行。更推荐的做法是：

父代理先准备 run 目录和任务清单
先完成 base
再把不同动作行交给子代理并行处理
父代理统一回收结果、写入 manifest、做最终 QA 和打包

这种分工方式非常有代表性，因为它不是为了"炫技式多代理"，而是恰好符合这类任务的结构：动作行彼此相对独立，但最终产物又必须集中校验和统一封装。

也正因为这样，做火焰大蒜 pet 的过程，会让人很直观地理解 Codex 桌面端到底擅长什么。

它擅长的不是把聊天框做得更花，而是把任务拆开、并行推进、保留上下文、最终回收到一个可验证结果。这种感觉在 CLI 里当然也能做，但在桌面端里更容易被"看见"。

因为桌面端天然更像一个任务调度台：线程、代理、文件、产物、状态，都更容易被感知为一个完整过程，而不是一串命令执行历史。

为什么这种体验在桌面端更容易显出产品魅力

这也是我这次最大的额外感受。

如果只用 CLI，你当然也能完成很多工作，而且效率可能更高。但宠物这件事之所以让我更强烈地感受到 Codex 的魅力，恰恰因为它发生在桌面端。

原因不复杂。

第一，桌面端更容易把"结果"变成"陪伴感"。

当一只你自己做出来的火焰大蒜真的开始在桌面里待机、挥手、跳跃、忙碌、审查时，产品的反馈不再只是文本成功或命令成功，而是一个持续存在的、可观察的、具象化的角色。这种感知强度，CLI 很难天然提供。

第二，桌面端更容易把"工作流"变成"产品体验"。

你不是只在想"脚本有没有跑通"，而是在感知一个从 skill、到代理、到 QA、到安装结果的完整闭环。宠物只是最终表层，但它背后把 Codex 的几个关键能力都串起来了：

skill 不是提示词模板，而是可复用工作流程
子代理不是摆设，而是能分担具体产出
QA 不是附属品，而是决定能否交付
安装包不是截图成果，而是真资源

这时候你会发现，桌面宠物真正迷人的地方并不是卖萌，而是它把"Agentic Workflow"这件事做得非常可感知。

这只火焰大蒜让我看到的，不是彩蛋，而是产品方法论

如果只把 Codex 宠物理解成一个有趣功能，那它当然也成立。

但我现在更愿意把它看成一块非常小、却很完整的产品切片。

在这块切片里，你能同时看到：

角色资产的规格化约束
skill 驱动的标准化流程
子代理分工带来的并行生产
QA 和验证把关
最终可安装、可复用的资源封装

我做出来的当然只是一只火焰大蒜，可这只火焰大蒜真正有意思的地方，不在于它长得怪，也不在于它会动，而在于它让我第一次特别具体地感受到：Codex 桌面端并不是把大模型塞进一个 GUI 里那么简单。

它真正想做的，是把"任务"变成"流程"，把"生成"变成"交付"，把"工具调用"变成一套能被人看见、理解、复用的产品体验。

如果你对 Codex 感兴趣，但还没有认真试过桌面端，我会很推荐你别只停留在聊天或写代码这一层。找一个像宠物这样看起来轻松、实际上结构完整的小任务，亲手走一遍。

你很可能会和我一样，最后记住的不是"它真可爱"，而是：

原来一个看似像彩蛋的功能，背后竟然站着一整套相当认真的工作流。

参考信息

OpenAI 于 2026 年 2 月 2 日发布 Codex app 介绍，将其定义为一个用于同时管理多个代理、并行推进工作、协作处理长任务的 "command center for agents"；同文还在 2026 年 3 月 4 日更新说明 Windows 版已上线。
OpenAI Help Center 在 2026 年 2 月 2 日的 Codex app 发布说明中，也明确提到其支持多代理并行、长任务与后台任务、隔离 worktree diff、skills 和 automations。
OpenAI Help Center 的 Skills 文档说明，skill 是可复用、可共享的工作流封装，支持 instructions、examples、code 等内容，并已支持 Codex。
本地 hatch-pet skill 与 codex-pet-contract 文档显示，自定义宠物的安装目录为 ${CODEX_HOME:-$HOME/.codex}/pets/<pet-name>/，核心文件为 pet.json 与 spritesheet.webp；生产流程中还会生成 qa/contact-sheet.png、qa/review.json、qa/videos/*.mp4、final/validation.json 等 QA 与校验产物。