社区帖展示了 Anatomy 如何把一句机器描述变成可旋转、可拆看、带运动关系的水车演示。真正进入 Builder 工作流后，验收对象会从“画面像不像”变成部件、约束、参数和修改成本。
1。
句描述。
4。
验收层。
750K+。
帖主称 Token。
原帖视频中的上射式水车演示：水流带动轮子，轮轴把运动传给齿轮和上方机构。画面显示的是交互演示，不是工程验收记录。
从一张图到一套可检查的模型。
@thebuggeddev 分享的案例来自一个名为 Anatomy 的开源 Agent Skill。项目 README 把它定义为：用一句话描述一个机器或技术概念，生成带有等距视图、部件运动和交互读数的可运行图形。
它支持 SVG，也可以把水、火焰、蒸汽等效果放进 WebGL 图层。仓库还提供了可拆解的发动机、波纹水槽和 3D 转盘等示例。
原帖里的水车画面适合拿来讨论工作流，因为它同时出现了轮子、轮轴、齿轮、料斗、水槽和上方机构。画面底部还有转速、石磨和产量读数。
这些对象需要互相对应：哪个部件受水流驱动，哪个部件传递转动，哪个数值随运动变化。
第一步：把机器拆成部件清单。
Builder 接到“做一台水车”这样的任务时，第一份产物应该是一张部件清单，而不是最终渲染图。
水轮、轮轴、轴承、齿轮、料斗、导水槽、支架和磨盘需要分别命名，并写出它们的父子关系、连接位置和是否参与运动。
这一步解决的是后续修改的入口。没有稳定的部件名，用户只能重新描述整台机器；有了清单，才可以说“只改水轮叶片”“把齿轮比换成另一组”“隐藏支架后检查轴承”。它也让静态图和运行代码使用同一套对象，而不是各自维护一份看起来相似的结果。
第二步：把运动关系写成约束。
水车真正需要验收的地方，在部件交界处。轮子绕哪根轴旋转，轮轴怎样把运动传给齿轮，两个齿轮的转速和方向如何对应。
还要检查料斗在什么位置进水，水流效果是否跟随正确的部件。每一项都应该成为明确的约束，而不是靠拖动页面时“看起来差不多”。
Anatomy 的官方说明提到，项目会把部件、读数和运动放在同一个小模型中。项目还通过审计检查零件之间的穿插、连接端点和不同运动状态。
对 Builder 来说，可以按这个顺序检查：先停在静止状态检查装配，再拆开部件检查遮挡，最后以慢速运行检查碰撞和脱节。
第三步：区分演示参数和工程参数。
画面底部的“wheel 0.0”“stones 0 rpm”和“0 kg/h”适合说明模型状态，但它们还不是工程数据。
要进入真实设计流程，还要交代水头、流量、轮径、叶片数量、负载和效率的定义。还要写清这些数值由哪段模型计算出来。
因此，工作流里应该把参数分成两层：一层负责让演示同步变化，例如转速、齿轮状态和读数；另一层负责说明现实假设，例如尺寸、材料、流量和边界条件。两层混在一起，页面会显得很完整，后续却很难判断哪些数字可以继续用于设计。
第四步：把修改成本记录下来。
帖主称这次水车重建消耗超过 75 万 Token，并使用 Claude Opus 5.5 Max。这个数字首先是作者对自己过程的描述，文章不把它当作独立测试结果。
它提出了一个 Builder 必须记录的问题：生成一次之后，返工用了多少轮。
还要记录哪些修改必须回到整体提示词，哪些修改可以直接改部件、参数或约束。
一套可用的记录至少包括四项：首次生成时间，部件清单是否需要人工重命名，运动约束改了几轮，最终输出能否脱离原对话继续编辑。这样评估的对象就从“这次生成得好不好”变成“下次修改是否还接得上”。
从水车演示到可复用资产。
Anatomy 的水车案例可以被压缩成一条 Builder 工作流：先列出部件，再写清连接和运动约束。
随后让几何、动画和读数共用同一个模型。最后按静止装配、拆解状态、运动过程和参数来源逐层检查。
这套流程也适用于 OpenBrep、Blender 或 Geometry Nodes 中的机械对象。部件需要能被定位，关系需要能被检查。
参数可以被替换，结果可以被继续修改，模型才从一次演示变成可复用资产。
SOURCES
X：@thebuggeddev 水车演示帖。
Anatomy：GitHub 项目 README 与项目页。