Anatomy：让 AI Agent 先造一台机器，再解释一个概念

一句话：Anatomy 不是“又一个画图工具”，而是一套让 AI Agent 先造一台机器、再解释一个概念的技能包。

调研对象：wheresryan22/anatomy · MIT License · 截至 2026-10-17 约 14,851 Star / 1,134 Fork。

过去两年，AI 生成图表已经不难：给一段文字，几秒钟就能得到方框、箭头和渐变色卡片。但大多数结果仍然像“把 PPT 自动排版了一遍”——能看，却很难让人真正记住一个系统是怎么运转的。

GitHub 上的 Anatomy 走了一条不同的路。它不要求模型画流程图，而是要求模型先发明一台真实存在的机器，再让读者通过机器的结构、运动和读数理解抽象概念。仓库创建于 2026 年 10 月 8 日，截至 10 月 17 日已拿到约 1.48 万 Star、1,134 Fork，并保持 MIT 开源。

1. 它到底是什么：一个会“造机器”的 Agent Skill

Anatomy 是一个标准的 Agent Skill：根目录放一份 SKILL.md，Agent 读取后按其中的工作流执行。它明确支持 Claude Code、Antigravity、OpenCode、Codex 和 MiniMax Code，不是某个模型厂商的私有功能。

你给它的不是“画一张架构图”，而是一个技术概念和最终落点：

• “解释 token bucket 限流，做成可交互的等距图。”
• “把缓存失效画成一把弹子锁，输出独立 HTML，浅色主题。”
• “解释 GPU 上下文如何服务多个画布，做成 React 组件。”

它交付的也不是一张不可编辑的位图，而是你自己拥有的源码：一个 Node 构建脚本加上它生成的页面；如果选择 React，则是几何模块、静态图服务端组件和一个客户端交互组件。

这也是它和“AI 生图”最根本的区别：位图生成的是结果，Anatomy 生成的是可运行、可检查、可继续修改的模型。

2. 核心方法：给概念发明一台机器

README 里有一句话总结了它的设计哲学：

“Explain an idea by building it as a real, working object.”
通过把想法做成一个真实、可运转的物体来解释它。

比如：

• 一个“什么都没变就跳过工作”的缓存键，被做成一把弹子锁：只有每一根弹子都对齐，锁芯才能转动。
• 一个“GPU 上下文服务多个画布”的概念，被做成一台龙门点样机：一个打印头依次访问 16 个孔位。

物理对象的好处是，它天然携带因果结构：锁为什么打不开、点样机为什么一次只能服务一个孔位、阀门打开后压力如何传递——读者不需要先理解一堆抽象名词，就能从机械结构里“看见”因果。

更关键的是，Anatomy 要求图上的每一个数字都来自驱动零件运动的同一个模型。不是先画一张漂亮的图，再在旁边编几个数字；而是先有小模型，模型产生读数，读数再驱动指针、液面或零件的位置。这样，图才不会“看起来专业，但经不起追问”。

3. 它是怎么工作的：一次小型工程

Anatomy 的 SKILL.md 把生成过程拆成了一条相当克制的工作流：先收集真实数字，再发明物理对象、列零件表、规划世界、建几何、上色、装框、做交互，最后像评论家一样验收。可以压缩成下面六步：

• 收集真实数字：压力、频率、尺寸、阈值先确定，后面所有几何和读数都围绕它们展开。
• 发明物理对象：不是给概念套一个好看的壳，而是找到一个“机制本身就能解释概念”的物体。
• 列零件表：每个零件有形状、尺寸、材料和安装位置；这一步决定了后面能不能画对。
• 建等距几何：用同一台相机、同一套 kit 画出可复用的零件；圆件走 lathe，管线走 tube。
• 做交互与着色：悬停、拖拽、键盘、实时读数；需要时再用 WebGL 叠加火焰、水波和光影。
• 自动验收：几何审计证明零件不互相穿透、端点都有安装面、遮挡顺序正确；截图脚本再检查每一帧的视觉结果。

仓库里的 kit/ 是这套方法的底座：等距相机、实体与零件库、任意轴旋转体、管线与电缆、WebGL 图层、3D 运行时和 React 组件。除了 React 组件需要 React 18+，其余全部只依赖 Node 内置模块，不需要 npm install，也不需要 API Key。

验收部分尤其值得注意。Anatomy 不是“生成完就让用户自己看”，而是内置了 audit.mjs、capture.mjs、drive.mjs、lines.mjs、turn-check.mjs 等检查脚本：审计几何、截取特写、生成接触表、检查悬空线头、验证 3D 遮挡与性能。换句话说，它把“好看”拆成了可以被程序检查的约束。

4. 八个示例：从 300 行到 380 个零件

仓库自带八个完整示例，覆盖了从最小可读到高密度机械的不同难度：

5. 安装与使用：一条命令，五种 Agent

最省事的方式是通过 skills CLI 安装：

npx skills add wheresryan22/anatomy -g

CLI 会询问要装到哪些 Agent；也可以直接指定：

# Claude Code
npx skills add wheresryan22/anatomy -g -a claude-code

# Codex
npx skills add wheresryan22/anatomy -g -a codex

# OpenCode / Antigravity / MiniMax Code
npx skills add wheresryan22/anatomy -g -a opencode
npx skills add wheresryan22/anatomy -g -a antigravity
npx skills add wheresryan22/anatomy -g -a minimax-code

装好后，在 Claude Code 里用 /anatomy，在 Codex 里用 $anatomy：

$anatomy explain how a token bucket rate limiter works, interactive

也可以把需求说得更具体。以下是我建议的提问模板：

$anatomy 把“Odoo 销售订单确认”画成一台点样机：
- 订单校验、库存检查、信用检查、确认、生成交货单各对应一个工位
- 输出独立 HTML，浅色主题
- 鼠标悬停时显示当前工位和真实单据数量
- 最后运行几何审计

需求里最好同时给出三件事：要解释的概念、希望对应的物理对象（如果已经有想法）、最终落点（独立 HTML / 单个 SVG / React 组件，浅色还是深色）。信息越具体，Agent 越不容易把它做成一张普通的流程图。

6. 边界：它不适合做什么

Anatomy 的 README 把边界写得很清楚，这一点反而增加了可信度：

所以它不适合“今天下午要 20 张数据图”的场景。更适合那些值得被记住、被反复引用、需要建立长期认知的核心概念。

7. 对技术内容与产品表达的意义

对做企业软件和开源项目的人来说，Anatomy 提供了一种新的内容思路：

• 把功能清单换成机械隐喻：ERP 的订单流、库存周转、审批链、MES 工单，都可以找到对应的物理对象。读者记住一台机器，比记住十个功能点更容易。
• 把文档变成可交互的教具：产品手册里的关键流程，不一定要用长文解释；一个可以悬停、拖拽、显示真实数字的图，往往更有效。
• 把“专业感”落实到可验证的细节：零件不穿模、线头不悬空、读数有模型依据。这些约束让图不只是“看起来高级”，而是真的经得起工程师审视。

当然，物理隐喻不是万能的。强行把每一个概念都做成机器，容易变成过度设计。更合理的做法是：先判断这个概念是否真的存在“机制”——有输入、状态、约束和输出——如果有，Anatomy 会非常合适；如果只是分类、对比或趋势，传统图表仍然是更好的工具。

8. 结论

Anatomy 最值得关注的，不是“AI 会画等距 SVG”这件事本身，而是它把解释变成了一件可以被工程化验收的事：先有真实数字，再有物理对象，再有零件表和几何，最后用审计脚本和截图检查每一帧。

当 AI 的输出从“一张看起来不错的图”，变成“一套可运行、可检查、可交互的模型”，它才真正开始接近“作品”，而不只是“素材”。这或许也是 Agent Skill 接下来最值得探索的方向之一：不是让模型多会一种格式，而是让它多掌握一种把复杂事情讲清楚的方法。

项目地址：github.com/wheresryan22/anatomy
官网：skills.wheresryan.sh/anatomy
许可证：MIT · 作者：Ryan（@wheresryan22）
数据说明：Star / Fork 数据取自 2026-10-17 GitHub API；功能、示例与限制以仓库 README 和 SKILL.md 为准。