Anatomy 开源：别再用方框箭头讲技术了，让 AI 把概念造成一台真机器

一、先从一个具体场景说起

读技术文章的你，一定见过这样的配图：一个圆角矩形写着「Cache」，另一个圆角矩形写着「Origin」，中间一根箭头。这样的图除了把文字翻译成图形，几乎没有增加任何信息。你记不住它，是因为图里压根没有值得记的东西。

更尴尬的是动态机制。LRU 的淘汰、令牌桶的补充、TCP 的三次握手，本质都是「随时间发生的一连串动作」，而静态框图只能表达谁连谁，表达不了谁在动、动了意味着什么。于是作者只能靠更多文字硬扛，读者只能靠脑补。

AI 画图工具火起来之后，这个问题解决了一半，又带来了新问题：你让它「画一张解释缓存机制的图」，它交上来的大概率是一张好看但说不清的插画——颜色漂亮、构图均衡，但每个部件的尺寸、数量、连接关系都是编的。示意图一旦数字是假的，解释力就是负的。

能不能让 AI 别「画」概念，而是「造」概念？ GitHub 上有个叫 Anatomy 的项目就是这么干的：你描述一个想讲清的技术机制，它引导 Claude 发明一台机器——机器的运转方式本身就是解释。缓存 key 没变就跳过重算，它造的是一台弹子锁：所有弹子对齐了，锁芯才转；一张 GPU 上下文服务多块画布，它造的是一台龙门绘图仪：一个打印头依次巡视 16 个孔位。

读者认出那台机器的瞬间，机制就被理解了。

二、Anatomy 是什么

Anatomy 是开发者 Ryan 开源的一个标准 Agent Skill——就是根目录带 SKILL.md 的那种技能包，MIT 协议，仓库在 wheresryan22/anatomy。它不是一个独立应用，也不是插件，就是安进 AI 编程助手里的「能力集」。

装好之后，你在 Claude Code 里输入 /anatomy explain how a token bucket rate limiter works, interactive，它就会接管整条流水线：收集真实数字 → 发明物件 → 写零件表 → 规划世界 → 建几何 → 从后往前上色 → 装框加交互 → 当审查员自检。

它支持 Claude Code、Antigravity、OpenCode、Codex 和 MiniMax Code；产出可以是独立 HTML 页面、单个 .svg 文件，或者 React/Next.js 组件。浅色是它设计的第一主题，官方所有截图都是浅色——连着色器都是按浅色设计的。

三、核心拆解

3.1 它发明的不是图，是「物件」

普通 AI 画图是「把文字翻译成图形」，Anatomy 是「把概念翻译成机器」。这不是文字游戏：翻译成图形，产出的是示意图；翻译成机器，产出的是机制——每个零件各司其职，动起来之后，原理不言自明。

官方文档里给了一组映射，很能说明品味：七个字节深度不同的渲染目标，是七格抽屉柜，每一格的深度和它的字节数一样；可分离模糊 49×49 拆成 49+49，是一块钉板印章加两条导轨上的梳子；光照取决于朝向，是一间小摄影棚，主光和补光围着一台转台。

它甚至把两种失败模式写进了文档：太抽象（堆在一起的板子、漂浮的方块、贴标签的盒子，什么都不像）和太平太素（一大块板加几条线，没有体积、没有零件、没东西可看）。解法只有一个：一台认得出的机器，由几十个小而精确、各司其职的零件搭起来。

dial-indicator 示例：架在滑台上的百分表，最小的官方示例，约 300 行代码。悬停可以推动滑台，指针会读出每个量块的高度

3.2 规矩先于几何：零件表是质量的分水岭

这个技能的工作流是反直觉的：先写概念和零件表，一个零件都不许先画。官方对零件表的要求细到有点「轴」：至少 40 个零件，分组为底座（底板、底脚、沟槽、角螺钉、铭牌、尺条）、结构（立柱、导轨、框架、限位）、机构（滑台、轴套、弹簧、柱塞、指针）、控制（滚花旋钮、拇指螺钉、冠形轮）和「主角」——唯一被重点打光的部分。而且每个零件都必须坐在另一个零件上。

尺寸也不是随便定的，官方分了三级：Figure 是单个机构，40–80 个零件，SVG 加最多一层 WebGL，通常一小时以内；Hero 是密集物件，80–150 个零件，约 2–4 小时；Epic 是整车、整栋楼、整个工厂，6 小时以上。最狠的是 Epic 这一档——技能会直接拒绝开工，让你先出个 Hero 版本保住核心想法。一个「画图工具」给自己划这种上限，本质上是在说：宁可慢，不可糊。

整条流水线的大致步骤是这样的（节选自官方工作流）：

步骤 它在干什么
定尺寸 按 Figure / Hero / Epic 分级，先声明工作量再动手
真数优先 先把真实的数字收集齐：尺寸、数量、阈值、曲线。所有读数、运动、图注必须来自同一套模型
发明物件 选一台机器，用一句话说清「什么在动、动意味着什么」
写零件表 至少 40 个零件，分组排布，每个零件坐在另一个零件上
建几何 静态几何只建一次，之后按「画家顺序」从后往前涂
自检 审计跑到 0、线头检查跑到 0，再放大 4 倍像批评家一样逐处验收

最后一行值得多说一句：大部分力气花在画之前和画之后。 这就是它和「一句话出图」工具最本质的区别。

仓库里还躺着 8 个完整示例，成品页面全部提交，双击就能打开：从约 300 行的最小示例（一个架在滑台上的百分表），到一台 1984 年风格的台式机（约 85 个实体，键盘真能打字，关机时整幅画面塌缩成一条线和一个点）；从一台侧板拆掉的街机柜（约 240 个实体、15 根线缆，投进一枚 25 分硬币，它沿滑道滚下、撞开投币开关、脉冲一段段沿线缆跑到主板、CRT 慢慢亮起来），到 Raptor 2 火箭发动机吊在试车台上（可拆成 11 个装配体，尾焰是 WebGL 着色器）。

3.3 审计跑到 0，才准收工

这是 Anatomy 最「轴」的地方，也是我最想让人知道的部分。

它有几何审计器。管道有没有穿过别的管道、法兰有没有浮在支座外面、哪根线在半空中断掉、两处重叠的画序有没有反——全部由审计器按真实几何计算，而不是靠人眼调。官方跑 Raptor 发动机那张图的审计结果是这样的（这是官方数据）：80 根管道、267 个实体、478 个图元、1119 个深度状态、170 多万次重叠检测、4292 条绘制顺序规则，耗时 151.9 秒，最后只输出一个词：audit passed。

还有一道线头检查：图里每一根纹理线、刻度、肋条、指针的端点，都必须落在另一根线、一个点或者一条轮廓上，不许停在半空，官方管这叫 line ends: 0。验收标准也写得很直白：放大 4 倍，像批评家一样逐处看。这个严格程度，是照着「会不会被人放大挑错」定出来的。

raptor-engine 示例：火箭发动机拆开后的状态，管路与线缆散落在试车台立柱之间。审计会证明任何一根管道在拆开的每一帧里都没有穿到别的零件里面

3.4 三种产出形态：SVG、SVG+WebGL、3D（beta）

核心形态是 SVG：四色灰阶的等距实体，从后往前涂，装进带标题、提示和实时读数的卡片里，动效克制。线条画不了的东西——火、尾焰、水、焦散、灯光、蒸汽——交给 WebGL 着色器，跑在前后两层 SVG 之间的画布上，用的是同一套等距相机，所以特效是「长在画里」的，不是贴上去的。就算环境没有 WebGL，SVG 依然完整可读。

ripple-tank 示例：学校的水波槽。水波与纸面上的焦散不是贴图，而是由一个色散与光学模型算出来的，右下角的频率、波长、节点线数目会跟着参数变

3D 模式目前是 beta：零件在真三维里转动，每一帧重新投影、重新上色。官方性能数据（这是官方数据）：小的 3D 图能跑 60fps；380 个零件的压力测试手，1440px 宽下约 20fps，模拟手机（390px、CPU 四倍降速）掉到 13–15fps。上生产前要掂量。

turning-dial 示例：3D 模式（beta）。一个真正在三维里转动的密码盘，上面还搭着一只小机器手

3.5 仓库本身也是一份工程样本

翻一遍仓库结构，你能看出作者对「可维护」的执念：根目录的 SKILL.md 是 Claude 真正读的东西——工作流、设置和工艺规则；kit/ 是绘图库（等距相机、实体与零件库、任意轴车削、管道线缆、WebGL 层、3D 运行时）；references/ 是 Claude 按需打开的长文档；scripts/ 是一整套无头 Chrome 检查；examples/ 是 8 个完整示例；evals/evals.json 里甚至存着测试提示和「好答案应该包含什么」。

贡献规则也写得很硬：改动 kit 不能改变任何一个现有示例的产出（要求逐字节一致）。做出满意的图之后，还可以让 Agent 一句话提交到社区画廊，不用自己 fork、不用手写 PR。

四、容易被忽略的设计取舍

它故意慢。 一张图是一个长会话：写零件表、建几何、跑审计、两种主题下逐处放大检查。发动机那张光构建就要几分钟；3D 模式的完整环绕审计，30 个零件要跑 15–20 分钟。想「一句话出一张图」的人会失望，但反过来说，它交付的东西也对得起这个时间。

它不是图表库。 没有坐标轴、没有数据系列、没有折线柱状饼图。数字只以两种形式出现：模型驱动的实时读数，和零件真实的尺寸与数量。要画数据图，请找别的工具。

它只画机器、仪器、工具和家具，不画人，也不画精确地图。 一个没有「机构」可以搭的概念，出来的东西会明显弱一档。这是边界，也是专注。

它产出的是源码，不是位图。 一个 Node 构建脚本加它写出的页面，绘图库（等距相机、实体库、车削、管道线缆、WebGL 层、3D 运行时）一起给你。React 输出那一档需要 React 18+，其余部分零第三方依赖，只用 Node 内置模块，Node 20.10+ 就能跑。顺带一提，它甚至能打印：发动机和街机两个例子可以直接输出三份 A4 PDF——一页海报、一页带零件表和规格的技术制图、两页详细讲解。

3D 审计的严格程度是按「每一帧」算的。 官方文档里写，深度顺序检查会重放爆炸过程的每一帧，连弹簧错峰边界前后各 8 毫秒的反转都不放过（发动机的弹簧错峰是 35 毫秒）。换句话说，它审的不是一张静态图，而是一段会动的机械。

五、安装和使用

标准技能包，官方 CLI 一条命令：

npx skills add wheresryan22/anatomy -g

会问你装给哪个助手，想跳过提问就加参数，比如只要 Claude Code：

npx skills add wheresryan22/anatomy -g -a claude-code

装完直接用斜杠命令，说清它要解释什么：

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

Codex 里是 $anatomy。不点名也行——你说「要一张等距插画」「给文档配张解释性插图」，它也会被加载。

官方给了三条提高成功率的建议，我觉得挺关键：说概念，别说画法，并把真实数字给它（尺寸、数量、速率、阈值），物件让它自己发明，比你自己描述「这里画个框」强得多；或者直接点名物件，心里已经有机器了（咖啡机、本生灯、一把锁）就说出来，并说清什么该动；说清它住哪儿——独立 HTML 页面、裸 .svg 还是 React 组件，浅色还是深色，三者的构建方式不一样。

六、适合谁用

第一类，写技术文档和博客的人。 首页主图、原理讲解，一张图能顶掉一大段文字，这是它最值钱的场景。

第二类，做技术演讲和分享的人。 开场图要有记忆点，等距机械图天然适合投影，而且浅色主题本来就是为「纸质页面」设计的。

第三类，需要落地页插图的独立开发者和设计师。 React 组件能直接进 Next.js，源码级修改，不用担心「图改了要重新出」。

第四类，想真正搞懂某个机制的工程师和学生。 这条是我的私心：要让它造出机器，你得先回答「这里到底什么东西在动？动一下意味着什么？这个数字是真数还是编的？」想不清楚，它就搭不出来。它逼你把概念想清楚——图反而只是顺手的结果。

七、结尾：解释的粒度，决定了理解的深度

我们这行习惯了用「关系」解释系统：A 调用 B，B 返回 C。但很多机制的本质不是关系，是过程——东西在动，动完了，状态就变了。过程是很难用框图讲的，却天生适合用机器讲。

Anatomy 的价值不在于「AI 画图更好看了」，而在于它把「解释」这件事拆成了可审计的工程步骤：真数、零件表、几何、审计、4 倍放大验收。它逼着 AI 像一个严谨的制图员那样工作，而不是像一个即兴的插画师。

我的判断标准很简单：如果一个概念能对应到「有个东西在动、动完你就明白了」，就值得交给 Anatomy；如果它本质上是一堆条目和关系，那方框和箭头才是对的形态。

满屏方框箭头的时代，也许该换一种讲法了。

相关链接：