小模型运行 Anatomy：检查通过却产出简陋

Anatomy 在 10 月 8 日还是一个新建的 repo，到 10 月 13 日星期二上午，GitHub star 已经涨到 6,632 个（我在印度标准时间上午 10:31 查了 GitHub API）。它是一个采用 MIT 许可证的 Claude Code Agent Skill，也能在 OpenCode、Codex 中运行，并且从本周开始支持 Antigravity。输入 /anatomy 加上一个想法，Agent 就应该构思出一台实体机器，用机器的运作方式来表达这个想法，再用几十个带阴影的小零件，搭建出一个可交互的等距 SVG 图。

演示很漂亮：能拆成 11 个组件的 Raptor 发动机、带 WebGL 焦散效果的波纹水槽，还有可以拖动的百分表。我想弄清楚两件演示无法告诉我的事：底层这套工具在一台普通 Linux 机器上到底能不能可靠运行？最终成果有多少归功于 Skill，又有多少取决于驱动它的模型？

先说结论：这套工具确实能用，速度快，对自身能力的描述也很实在。不过，这个 Skill 是为强模型编写的，小型本地模型远远达不到要求。下面是我实际运行的完整过程。

我测试了什么，没测试什么

测试机器运行 Debian，配有 8 个 vCPU、16 GB RAM（测试期间大约还有 4 GB 空闲），没有 GPU。机器上没有 Claude Code，没有 Codex，也没有云端 API key。因此，我用的是 OpenCode 1.19.0，通过 Ollama 连接在 CPU 上运行的本地 qwen3:1.7b。

我试着拉取 qwen3:4b，想换一个稍强的模型。但这台机器的网络下载失败了，报错是 "redirect target not allowed"，所以我唯一能运行的模型就是 1.7B。

后面的所有结果都受这个条件限制。我测试了：

• 安装流程，使用 README 推荐的 skills CLI。
• 工具套件本身：构建示例、运行测试套件、执行几何审计，以及无头 Chrome 检查。
• 在 OpenCode 中实际运行三个 /anatomy prompt，内容取自 README 和 Skill 自带的 evals。

我没有测试 Claude Code、Codex，也没有测试任何前沿模型。我还跳过了 React 输出、3D（beta）模式、由 Agent 构建的 WebGL 图，以及新推出的社区图库发布流程。README 中的那些图，几乎肯定是用比我这个强得多的模型生成的。因此，请把这里的 Agent 结果理解为“最低配置下会发生什么”，不要把它当成对这个 Skill 的最终评价。

安装：Node 版本有个坑，安装目录也不一样

README 的快速入门只有一行：

npx skills add wheresryan22/anatomy -g -a opencode -y

在这台机器的 Node 20.19.2 上，它立即崩溃了：

npm WARN EBADENGINE   required: { node: '>=22.20.0' }
SyntaxError: The requested module 'fs/promises' does not provide an export named 'glob'

Anatomy 本身只需要 Node 20.10+，但 skills CLI（这里是 1.7.2）需要 22.20+。README 确实在一个折叠区域里提到了这一点，但很容易漏看。换成 Node 22.20.0 后，同一条命令在 7.6 秒内完成。它显示了一份安全摘要（"Gen Safe, Socket 0 alerts, Snyk Low Risk"），并复制了 13 MB 的文件。

有个意外：它安装到了 ~/.agents/skills/anatomy，而不是 README 安装表中为 OpenCode 列出的 ~/.config/opencode/skills/anatomy。不过，OpenCode 仍然找到了它，因为 OpenCode 也会读取 .agents 文件夹：

opencode debug skill
# ... "name": "anatomy", "location": "/home/box/.agents/skills/anatomy/SKILL.md"

单独测试工具套件：快、确定，而且会自检

在引入模型之前，我先运行了不需要模型的部分。这是 Anatomy 最让我印象深刻的地方。

这些示例通过 Node 脚本重新构建，完全没有 npm 依赖：

node examples/dial-indicator/build.mjs
node examples/desk-computer/build.mjs
node examples/arcade-cabinet/build.mjs
git status --short     # empty

三个脚本都以退出码 0 结束，之后 git status 也显示工作区干净。重新构建的页面与仓库中提交的版本逐字节一致，完全符合 CONTRIBUTING 中的承诺。最重的示例 Raptor 发动机用了 115 秒完成构建，与 README 所说的“几分钟”相符。

测试套件在大约 38 秒内运行了 225 项测试：

# tests 225
# pass 220
# fail 5

失败的五项全部来自 react-*.test.mjs 文件，它们需要 React，而机器上没有安装。README 说只有输出 React 时才需要 React，所以这是环境配置上的缺口，不是 bug。不过，我还是希望这些测试能正常跳过，而不是直接失败。

几何审计尤其出色。它不只是把图渲染出来，还会验证没有任何部件互相穿透，并且每一处重叠都按正确的顺序绘制：

$ node examples/arcade-cabinet/build.mjs --audit
audit · 15 tubes · 243 solids · 349 items · 1 depth states · 1290 overlaps · 1290 order rules · 11.0 s
audit passed

设置好 CHROME_PATH 后，无头 Chrome 检查也正常运行了：

$ node scripts/capture.mjs examples/dial-indicator/dial-indicator-light.html --out dial.png
saved dial.png
clip 395,64 650x485 · readout "block 2 · reads 13.8 px" · scrolls sideways: no
console: clean

$ node scripts/lines.mjs examples/dial-indicator/dial-indicator-light.html
line ends: 0 of 367 ends on 23 lines float
console: clean

截图大约花了 4 秒。这个读数（"block 2 · reads 13.8 px"）来自驱动百分表指针的同一个模型，这正是 Skill 的核心承诺：图中的每一个数字，都来自图自身的模型。

下面是一张完成后的图，直接取自 repo 中最小的示例，并由 Skill 自带的脚本截图：

在 OpenCode 中用本地模型运行 /anatomy

这个 Skill 包含一个 31,600 字节的 SKILL.md，以及九份参考指南，总计约 300 KB，Agent 应该按需打开这些指南。运行命令时，OpenCode 会将 SKILL.md 注入 prompt。Ollama 日志显示，在模型还没写出一个字之前，第一次请求就已经有大约 7,700 个输入 token。在 CPU 上，仅处理这个 prompt 就花了 45 到 70 秒，生成速度约为每秒 4 到 5.5 个 token。

还没开始制作图，我就碰到了两个问题。

1. opencode run 停在 "init" 状态整整 13 分钟。它在等待 stdin。加上 < /dev/null 后就解决了：

opencode run --model ollama/qwen3:1.7b --command anatomy \
  "explain how a token bucket rate limiter works, interactive. Standalone HTML, light theme." < /dev/null

2. 第一次真正运行，在五分钟后失败了：

ProviderHeaderTimeoutError: Provider response headers timed out after 300000ms

OpenCode 默认等待响应头的时间是 300 秒，而一个处理大 prompt 的慢速本地模型，很容易超过这个限制。在 provider 的 options 中设置 headerTimeout: false 和 timeout: false 后，问题解决了。这是我尝试的唯一修复方式。

随后，我运行了来自 README 和 evals 的三个 prompt。

Token bucket 限流器（独立 HTML，浅色主题）。 这次运行了 16 分钟，以退出码 0 结束，但没有写出任何文件。模型把整个 prompt 交给了 OpenCode 的 explore subagent，后者返回了空结果。之后，它又花了 1,560 个 token 思考，始终没有给出回答。结束时，上下文已经达到 15.8k token。

CDN 边缘缓存，命中与未命中，TTL 60 秒（只输出 SVG）。 这次用了 8 分 23 秒，经过两轮交互，确实写出了一个文件。文件只有 738 字节：三个普通圆形，其中两个标着 "Hit" 和 "Miss"，再加上两个 "60s" 标签。它从未打开工具套件、示例或参考资料。它没有运行任何构建或检查，尽管 Skill 的工作流程最后明确要求“像挑刺的评审一样验证结果”。它在 SVG 的 transform 属性里使用了 CSS 风格的 rotateX(-30deg)，而 SVG 并不支持这种写法。Chrome 忽略了这些变换，于是 Hit 和 Miss 两个圆叠在左上角，大部分都落在画布之外。它还把文件写进了 Skill 自己的安装目录（~/.agents/skills/anatomy/examples/cdn-cache.svg），而不是项目目录。最后它说：“文件已成功写入……无需进一步操作。”

数据库连接池：10 个连接，全部忙碌时进入队列（独立 HTML，深色主题）。 这次用了 10 分 37 秒，依然把文件写进了 Skill 的 examples/ 文件夹。页面是在黑色背景上放了一个普通的 2D SVG。“包含 10 个连接的连接池”其实是在同一个位置画了两个圆，后面跟着注释 <!-- ... (add 10 circles) -->。队列则是一个圆，加上 <!-- ... (add 5 circles) -->。没有等距视角，没有工具套件，没有读数，没有动态效果，也没有检查。最后一句是：“文件已成功写入。”

下面是 Chrome 渲染出的那个 CDN 文件，尺寸与文件中设置的尺寸一致：

公平地说，这是在要求一个运行于 CPU、只有 17 亿参数的模型，遵循一份长达 7,700 token 的制作手册。Skill 要求模型收集真实数字、构思一个物体、编写零件清单、用工具套件构建几何结构，最后审计每个连接处并截图。这是一个很长的 Agent 执行循环，这么小的模型没法始终跟住整套流程。这些运行结果说明，Skill 中没有什么能弥补模型能力不足。只有 Agent 真正调用工具套件，它才帮得上忙。

哪些有效，哪些出了问题

• 工具套件：零依赖，示例可以逐字节一致地重新构建，Raptor 在不到两分钟内完成构建。
• 几何审计：在 11 秒内，按照 1,290 条顺序规则检查了 1,290 处重叠，并通过了审计。
• Chrome 检查：截图包含实时读数，有线段端点检查，控制台没有错误。
• Skill 发现：安装后 OpenCode 立即列出了 anatomy，即使它位于一个出乎意料的目录中。

出问题或让我意外的地方：

• npx skills add 在 Node 20 上会崩溃，尽管 Anatomy 本身支持 Node 20.10+。
• CLI 安装到 ~/.agents/skills/anatomy，与 README 中 OpenCode 对应的目录不同。
• 没有 React 时，225 项测试中的 5 项会失败，而不是跳过。
• 不加 < /dev/null，opencode run 就会卡住；它的 300 秒响应头超时限制也会导致慢速本地运行失败。这两个都是 OpenCode 的问题，不是 Anatomy 的问题。
• 使用 qwen3:1.7b 时，三次运行都没有产出真正符合要求的图。一次什么也没写，一次写出了带无效变换的 738 字节 SVG，还有一次写出了 1,049 字节的页面，所谓的 10 个连接只是两个圆和一句“添加 10 个圆”的注释。两个文件都落在 Skill 自己的安装目录里，而且 Agent 从未运行过任何检查。

如果你写文档或技术文章，而且已经在 Claude Code 或 Codex 中使用强模型，那它确实值得一试。最好的部分不是 prompt，而是底层工具套件：它的行为是确定的，而且能以我在其他“给我画张图”工具里没见过的方式进行自检。可以先构建 examples/dial-indicator，再读一读它大约 300 行的代码。这样你对输出的了解，会比看任何截图都更深入。

如果你希望用本地模型驱动它，1.7B 还不行。Skill 很长，工作流程也很长，README 还明确说它是“有意设计得慢”。要准备好让一个能力足够的模型运行较长时间，也要准备好逐张查看它生成的 PNG。

本次未测试：Claude Code、Codex、任何前沿模型、React 输出、3D 模式、Agent 构建的 WebGL 图，以及图库发布。如果你用强模型运行过它，我很想知道你做一张图花了多长时间、消耗了多少 token。新的社区图库说，这两项数据都会记录。

如需进一步采取行动，你可以考虑屏蔽此人和／或举报滥用行为。