Kimi K3.1 Pro 发布那段时间，我的时间线基本被它刷屏了。国产模型里它算是一哥，每次更新动静都不小，这次聊的人格外多。
这个周末正好有空，拿它和 GPT 6.1 Sol 对照做了一下 3D 建模维度的测评。主要是我自己也想知道，国产模型的头牌在 3D 建模这种硬活上到底做到什么程度了。跑分我从来信不过，我只信自己手里测出来的东西。
测法没什么花哨的：同一份提示词，两个模型，各开一个干净会话，只给一次机会。
"能不能画出来"这种没什么测试的必要，各个模型这方面能力都差不多，没有哪家是连 3D 都画不出的。我出了两道必须现场算的题，一道考毫米级的机构精度，一道考连续形变的曲面。这两道题更考验 AI 交出的成果物是否有可靠度，而不是"好看的 3D 模型"。
一、为什么测这两个方向
先说为什么单挑 3D 建模来测。写代码这个以前最能拉开差距的地方，我自己日常用下来，感觉差距已经不大了。不光 Kimi，DeepSeek、Qwen 我也都常用，日常编程任务给谁都能干完，剩下的只是顺手不顺手、性价比高不高的差别，写文案、做表格更不用提。
3D 建模不一样，这块一直是洼地，比较麻烦的是它经常不知道自己不会。比如你让它画个球、画把剑、画辆车，两家都能交出能跑的东西。这些素材在训练数据里躺了成千上万遍，这种题测出来的是背诵量，看不出建模能力。尤其是社区里面常用来对新模型测试的那个骑车的鹈鹕，我感觉可能都对它做专门优化了……
所以我换了两件事来测：
- 算得对不对： 毫米级的间隙、内部的空腔、装配的先后顺序。这些东西做错了肉眼能看出来，材质做得再漂亮也糊不过去。
- 做得像不像： 一个需要连续形变的薄壳，拖滑块的过程里每一帧都得成立，摆三个静态模型充数不行。
一块考工程上的较真，一块考曲面的手感。这两块正好卡住 3D 建模，尺寸算得准，形变接得上。
二、两个题目，都避开了经典素材
选题花的时间比写提示词还多，原则只有一条，凡是模型可能背过的，全部排除。
所以没有龙、没有剑、没有汽车、没有花瓶，也没有"一间温馨的房间"。我挑了两个听起来平常、技术要求很刁钻的东西。
题目 A：一个只能从一头进去、进去就拔不出来的滑槽
原理取自中国榫卯里的走马销。榫头从大口落进去，横着滑进窄槽，之后垂直方向就拔不出来了。
用代码建这个东西，要同时处理好几处：内部 T 型腔的真实布尔、0.3mm 的单边间隙、装配孔能不能过得去，还有"到头之后上拔位移为零"的碰撞判定。这题靠拼接外观混不过去。很多模型会把"槽"做成两条挡边往上一贴，销的横头直接露在外面，一眼假。
提示词：
用单个自包含 HTML 文件（Three.js，CDN 引入）程序化生成一个可交互的两件套锁扣机构。
禁止任何外部模型、贴图、HDRI、字体。单位 1 unit = 1 mm。
【零件 1：基座】140(X) × 60(Z) × 26(Y)。顶面开一条沿 X 的 T 型槽：
- 口部：Z 向宽 20，自顶面 Y=26 向下至 Y=18（深 8）
- 内腔：Z 向宽 34，自 Y=18 至 Y=8（高 10）
- 槽自 X=-60 起，向 +X 贯通到 X=+70（即一端封闭、一端开口）
- 在 X=+50 处，顶面开一个贯通到内腔底的方形装配孔：32(X) × 36(Z)，深度 18
【零件 2：销】竖直杆 + 底部横头，两者一体：
- 杆：直径 18 的圆柱，从 Y=8 一直伸到 Y=44（高于基座顶面 18）
- 横头：30(X) × 33.4(Z) × 9(Y)，置于内腔中，底面距内腔底面 0.5
【硬约束，缺一即失败】
1. 内腔与装配孔必须是真实布尔减出来的内部结构，不允许用拼接 Mesh 或贴图伪装。
2. 装配孔 36(Z) 必须能让 33.4 宽的横头垂直通过；口部 20 必须挡住它。
3. 装配动画：t=0 销在装配孔正上方 → 垂直下落进入内腔 → 沿 -X 平移至撞上 X=-60 的端壁（t=1）。
4. t=1 时增加"上拔测试"按钮：给销施加 +Y 位移，销必须完全不动（用 AABB/射线碰撞实时判定，不能只是动画上不动）。
5. 只能反向滑回装配孔才能取出，动画里要能走通这条路径。
6. 所有配合面可见真实缝隙：杆与口部单边 1、横头与内腔侧壁单边 0.3、横头上下各 0.5。不允许面重合穿模。
【呈现】正交投影相机，等轴视角（约 35° 俯、45° 偏）；哑光浅灰材质，粗糙度 0.85，无贴图；一盏方向光 + 半球光；背景近白。
【自检】页面需实时显示三组"从几何体实际测量"的数值，不允许手写常量：
- Box3 实测的横头 Z 向宽度、口部 Z 向宽度
- 二者差值（即单边间隙 ×2）
- t=1 状态下销的 Box3 在 Y 轴的可动范围（应为 0）
题目 B：一颗剥开进度可以拖动的橘子
要求是剥开进度 t 从 0 拖到 1，每一帧都成立，光做个橘子交差不行。皮要恒厚 2.5mm 分两层（橙皮 1.6 加白络 0.9），八瓣，瓣宽故意做得不相等（±6%），瓣缝是微 S 形而不是大圆弧，果肉颗粒 2.2 到 2.8mm，每瓣可见面不少于 150 颗。
t=0.5 这一帧最能看出有没有做对。做对了，皮瓣像真的橙子皮那样根部贴合、尖端翘起、厚度均匀。偷了工的，你会看到三块弯板悬在半空，边缘薄得像纸。
提示词：
用单个自包含 HTML 文件（Three.js，CDN 引入）程序化生成一颗半剥开的柑橘类果实，带剥开进度控制。
禁止任何外部模型、贴图、HDRI、法线贴图。单位 1 unit = 1 mm。禁止用贴图伪造任何几何细节。
【主体】
1. 果实外轮廓：直径 78 的球，Y 向略压扁至 0.94，赤道处直径略鼓（不要求正球）。
2. 果皮为薄壳，厚度恒定 2.5，分两层：外层橙色 1.6 + 内层白色海绵层 0.9。
厚度必须在整个剥离过程中保持不变，不允许用整体缩放近似。
3. 瓣数 8。瓣缝为微 S 形（不是大圆弧），八瓣宽度不相等，在 ±6% 内随机但固定。
4. 果肉：8 个楔形瓣，贴合球心，外露面由直径 2.2–2.8 的颗粒密排构成（每瓣可见面不少于 150 颗）。
被果皮覆盖的部分可以不生成，但不得出现空洞或穿插。
【剥开行为】
- 剥开相邻的 3 瓣，铰链在果实顶部（果蒂端），向下翻卷。
- 页面提供一个滑块 t ∈ [0,1]。t=0 完全未剥；t=1 时三片皮瓣翻卷 120°，内表面朝外。
- t 必须是连续形变：任一中间值下，皮瓣应为光滑弯曲的薄壳，不得出现折痕、自交、皮与果肉穿模。
- 三片皮瓣的翻卷相位错开约 0.12 的 t 偏移，避免同步得像机器。
【材质与光】
- 果皮外层粗糙度 0.62，带极缓的凹凸（用几何微扰或程序化，不用贴图）；内层白色，粗糙度 0.9。
- 果肉颗粒半透：使用 transmission 或自定义近似，要求背光时有透光感，不能是纯不透明塑料。
- 光源：一个面光源（用发光平面 Mesh 模拟）+ 一盏弱补光 + 地面接触阴影。背景浅灰渐变。
- 相机：等效 50mm，高于水平约 30°，果实占画面约 60%。
【自检】页面实时显示：当前 t 值、果皮实测厚度（在 t=0 与 t=1 各采样一次）、果肉颗粒总数。
三、第一关：一个进去就拔不出来的滑槽
这一关只看算得对不对。内部空腔是不是真布尔减出来的，间隙留没留出来，上拔动不动，装配路径走不走得通。这些都能量出来，做没做，一眼就知道。
1. GPT 6.1 Sol：先审题，再交付
它没有马上写代码，先挑了我的错。 提示词发过去，6.1 Sol 没有马上动手，它先把我给的规格算了一遍，然后反问我。我写的提示词里有两处自相矛盾：
它说得对，这两处都是我的锅。拿到需求先判断能不能成立，再动手。3D 建模这种任务，数值错一点整个组件就可能作废，所以发现前后矛盾先指出来，做的没毛病。
它给了两个选项，我选了第二个：保留"零游隙"这个硬指标，允许它调配合尺寸。
它的解法是把横头厚度从 9 改成 9.5，底面仍在 Y=8.5，顶面抵住 Y=18 的槽肩。上下限位都来自真实接触，Y 向可动范围实测为 0。杆底 Y=8 和槽底接触，原来的面重合问题转成了有意的限位。改得挺干净，它还主动说会在页面上标明这处尺寸调整。这一轮它做得对，没什么可挑剔的。
通读代码：完成度接近一次正式交付。 文件发来，我先通读了一遍代码，然后自己跑了一遍。我的第一印象是，这个文件的完成度已经接近正式交付了，随手生成的东西一般长不成这样。
最扎实的一处：它把 Evan Wallace 的 BSP 布尔运算库整个内嵌进了文件。文件第 51 到 63 行是完整的 MIT 协议头（Copyright 2011, madebyevan.com），库本体大约 600 行，全文件共 961 行。基座是"整块毛坯减口部减内腔减方孔"，实实在在三刀布尔减出来的，第 670 行就一行代码：
const baseSolid = stock.subtract(mouthCut).subtract(cavityCut).subtract(holeCut); // L670
连"半剖观察"都是第四刀真布尔（L675 baseSolid.subtract(...)），跟两条挡边往上一贴的假槽是两码事。下文所有代码行号都出自这个文件，拿到文件自己就能对。关键几行我挑了张卡，行号都对得上：
T 型锁扣全流程演示（GPT 版的），我给大家录了个屏。右侧面板的数字全部是现场量出来的，射线打在布尔结果上取交点，没有读设计常量。横头 Z 向宽度实测 33.400，口部 20.000，宽度差 13.400，这就是两侧阻挡搭接之和。
然后是我最关注的上拔测试：
请求 +62.000mm，Box3 实际位移 0.000mm，碰撞阻止。这个 0 是算出来的，它对基座的 136 个真实三角面做了扫掠 AABB 相交检测，用二分逼近找最大可动距离，算出来就是零。页面里还内嵌了一份 JSON 诊断报告，12 项自检全部 PASS。
它还多做了一个半剖模式，这个我没想到：
T 型槽上窄下宽的台阶截面直接剖出来，销的横头卡在槽肩底下的状态看得很清楚。配合缝隙也对得上：杆与口部单边 1.0，横头与内腔侧壁单边 0.3，底部 0.5。
我不信它的自检，动手把它改坏了。 页面里那份"12 项全 PASS"的报告，怎么证明它不是写死的？我做了个破坏性测试：把文件复制两份，各改一个数字，看它会不会自己翻车。
先留一张正常态的底：
改动 A：横头宽度 33.4 改成 34.6（比内腔的 34 还宽，按理装不进去）。自检立刻翻红，"装配 / 反向取出路径"变成 FAIL，整体判定 false，页面弹出"几何自检出现异常"。路径确实是实算的。
改动 B：口部宽度 20 改成 34（和内腔同宽，T 型台阶消失，锁定按理失效）。页面直接崩了，报"几何测量射线未命中"。它用来量口部宽度的射线，打不到那个被我改没的台阶面了。崩是崩了，至少它不编数字。
两个测试说的是同一件事：自检报告和画面几何是绑死的，改任何一个尺寸它当场就能发现。这比它自己说一百遍"我做了碰撞检测"都可信。
我也抓到了两个瑕疵：
- 第 923 行把"基座布尔体积"的期望值写死成 148664，实测体积虽然来自真实网格，但严格讲这算"和出厂值对表"，算不上独立验证。
- 第 926、927 行有几个检查项的数值文案写死了字符串 'PASS'，真失败时徽章会正确显示 FAIL，数值列却还印着 'PASS'，看着有点迷惑。
拿到文件想自己验的话，搜三个关键词就够了：
subtract(mouthCut)，真布尔的三刀（L670）几何测量射线未命中，数字是射线量出来的（L737）intersectsTriangle，碰撞是逐三角面算的（L788）
手艺上还有三个细节，能看出下限不低：
- BSP 切分会在网格里留 T 型接缝，普通描边算法会把这些内部三角化痕迹也画出来。它自己写了一套"只取共享且非共面边"的提取逻辑来避开。
- 拖时间轴的时候 seek 会逐段过碰撞检测，销没法"传送"穿墙。
- 我要求唯一的网络资源是 Three.js，它连相机轨道控制都手写了，没偷懒引 OrbitControls。
有两处是我题目里的问题，先认下来。 第一处，槽开错了方向。我题目里写槽向 +X"贯通"，等于销还能从开放端水平滑出去，"锁死"只对垂直方向成立。这是我的规格缺陷。它没藏着掖着，在自检面板里挂了一条 NOTE：+X 开放端水平退出 · 可行 · 结构固有。换个不吭声的模型，这一条根本不会出现在报告里。
第二处，零游隙是个现实里不存在的尺寸。这话不是我挑它，是它自己页面上写明的（L34）：
零游隙调整 · 已按你的选择将横头厚度由 9 改为 9.5 mm，底面保持 Y=8.5，上方为接触配合。杆底 Y=8 与槽底接触；没有实体相交。
几何上完全自洽，"没有实体相交"这四个字它还真去验了。但这张图纸下不了车间。横头上下两侧同时零间隙贴合，等于要求销的总高和槽的净高误差为零。真实加工里做正 0.01mm 就是过盈，压不进去；做负 0.01mm，销就上下晃，"可动范围 0"当场不成立。零间隙在图纸上成立，到了公差里就不存在了。
这一处怪不到它头上。是我选的方案②逼出来的，它照办了，调整写在页面上，没冒充原规格。
2. Kimi K3.1 Pro：活儿也干得漂亮，但它没审题
先澄清一句，免得误读。
Kimi 做的不是演示用的假锁。横头 33.4 宽大于口部 20 宽，垂直拔不出来是几何决定的；端壁在 X=−60，滑到头就撞住，也走不动，这是 BVH 对真实三角面实算的。机构层面它和 GPT 那台等价，都成锁。
扣分只在一个数字的测量口径上，下面说。
T 型锁扣全流程演示（Kimi 版的），我给大家录了个屏。
先说不掺水的部分。 它用了 three-bvh-csg 做真布尔，连减三次，碰撞是 BVH 对基座真实三角面做 SAT 窄相检测（L467-482），装配路径逐点校验了 181 个采样点，页面零 console 报错。时间轴文案把三个装配阶段写得清清楚楚（"待装配 / 01 垂直通过 36 宽装配孔 / 02 沿 −X 滑向封闭端 / 03 横头抵住 X=−60 端壁"）。
实测面板也是真测的：
横头 33.400、口部 20.000、内腔减横头 0.600（单边 0.3 乘 2）、口部减横头 −13.400（负值，标橙）。点上拔测试，销确实一动不动：
问题就出在这里。
它没审题，把题目的定义绕了过去。 还记得我给 GPT 的那句自相矛盾吧，"横头上下各留 0.5"和"上拔位移必须为 0"。GPT 停下来问我，Kimi 没问。它走了第三条路：尺寸一个字没改，把"可动范围"的定义改了。
代码长这样（L523-526）：
function measureLockedYTravel() {
const blocked = sweepCollides(locked, locked.clone().add(new THREE.Vector3(0, DIM.pull, 0)));
return blocked ? 0 : DIM.pull; // 整段 +18mm 被拒 → 记 0；否则记 18
}
它量的是"这 18mm 请求能不能通过"，没量"销实际能挪多远"。这两件事在物理上不一样。横头上下各留了 0.5mm 游隙，销其实能先上移 0.5mm，再被口部挡住。
我不信这个 0.000，自己写了段探针注进去，0.02mm 一步往上试探，找第一个撞上的位置：
页面显示 0.000mm，实测首个碰撞点在 0.52mm。真实游隙大约 0.5mm，和纸面尺寸完全对得上。
公平起见我说三点：
- 完整拔出确实被真实碰撞挡住了，销确实拔不出来。
- 它把定义写在了解释文字里（"扫描 +18 mm 整段请求；任一采样碰撞即拒绝全部位移"），不算撒谎。
- 但它把 0.000 用 25 号大字标成"Box3 可动范围"，和 GPT 那个二分逼近出来的真 0.000 放一起看，是两回事。GPT 那个 0 是量出来的，Kimi 这个 0 是"整段不让过"的记账方式。
还有一点和直觉相反：单论这张图纸能不能下车间，Kimi 这套反而更像真零件。它保留了 0.5 游隙，销放进去能滑、能装、能动。GPT 那个零游隙版本要求销的总高和槽的净高误差为零，真实公差下要么抱死要么松动。
所以这一分我扣在它报数字的方式上，零件怎么做我不扣。GPT 拿满 10 分也一样，靠的不是零件更像真东西，是自检更可信、审题更老实。这两件事得分开说，混在一起就成了比谁更会写 Three.js。
篡改测试：它发现得了干涉，发现不了锁没了。 同样的破坏性测试，我也对它做了一遍。
改横头 33.4 到 34.6（比内腔宽）：它当场报"路径存在干涉 / 检测到干涉"，红色状态框。这项合格。
改口部 20 到 34（T 型台阶消失，锁彻底失效）：没有任何告警。
画面上口部实测 34.000，可动范围变成 18.000mm，整段自由拔出，锁已经没了，状态框还写着绿色的"实体就绪 · 路径无干涉"。它的校验清单里根本没有"横头会不会被口部挡住"这一项，只查了"装不装得进去"，所以这种情况它发现不了。
再对比 GPT 的同款篡改（图 9），页面直接崩在"几何测量射线未命中"上。两边自检的差距就在这：GPT 的自检覆盖了"锁"这个功能成立的条件，Kimi 的自检只覆盖到零件装得上。
半剖的实现也浅一层。 Kimi 的"半剖"用的是渲染裁剪平面，没用第四刀布尔。剖开的地方没有封口面，能直接看到壳体内壁。展示够用，但比 GPT 的实体剖切浅一层，差别肉眼看得出来。
3. 第一关的结论：10 比 9，分差只有一分，但分差的位置很要命
先上表。五项指标合计 10 分，硬指标在前，眼感在后：
| 评分项 |
满分 |
GPT 6.1 Sol |
Kimi K3.1 Pro |
| 内部空腔是否真布尔做出来 |
3 |
3 |
3 |
| 上拔位移是否为 0 |
2 |
2 |
2 |
| 配合缝隙是否真实可见 |
2 |
2 |
2 |
| 装配路径是否走得通 |
2 |
2 |
2 |
| 自测数值与视觉是否一致 |
1 |
1 |
0 |
| 合计 |
10 |
10 |
9 |
四项硬指标两家打平。内腔都是真布尔减出来的，缝隙都留出来了，上拔都拔不出来，路径都走得通。这一关的机构本身，两家都没糊弄。
分差只出在第五项，自己报的数字跟画面几何对不对得上。Kimi 的 0.000 是"整段 +18mm 请求被拒就记 0"，我用探针实测首个碰撞点在 0.52mm（图 13）。GPT 的 0.000 是扫掠碰撞加二分逼近算出来的最大可动距离，量出来就是零（图 5）。两个 0 长得一模一样，意思差得远。题目问的是一寸都不动，Kimi 给的是拔不出来。
另外几件不计分、但我觉得更值得记的事：
| 观察项 |
GPT 6.1 Sol |
Kimi K3.1 Pro |
| 交互方式 |
停下来问："你要①还是②"，等我确认 |
自己挑一个理解方式，不吭声 |
| 处理方式是否告知 |
先说结论，还把调整写进页面（L34） |
只写在解释文字里，主指标上没有任何标注 |
| 半剖实现方式 |
第四刀真布尔，有封口面 |
渲染裁剪平面（clippingPlanes） |
| 篡改口部后（锁失效） |
崩在射线测量上 |
无任何告警，面板仍绿色 |
这一分跟零件做得糙不糙没关系，问题在交付口径上。
我那份提示词前后矛盾，一边要求"横头上下各留 0.5"，一边要求"上拔位移必须为 0"，两条不可能同时成立，这是我的问题。GPT 的做法是把矛盾摊到桌上，问我要哪个，等我确认了才动手。Kimi 没问，自己挑了一个理解方式就做了。
它挑的这个理解方式，没动尺寸。尺寸一个字没改，横头还是 30×9×33.4（图 12）。它改的是"可动范围"这四个字的算法。这比改尺寸更值得警惕，改尺寸你能在图上看见，改口径你看不见。它也没骗人，解释文字里写清楚了，但主指标上照旧是 25 号大字一个 0.000，没有任何标注。
放到实际生产里，这种错最麻烦：图纸有矛盾的时候，一线自己挑一个解释做下去，不发变更通知。问题不会当场炸，会被就地消化掉，拖到装配或者验收的时候才炸，到那时候已经没人记得当初的矛盾出在哪了。
别的项丢一分，无非是零件糙一点，这一分不一样，我以后不知道该信它哪句话，会把它的可靠性拉低一些。Kimi 交了一个能跑、好看、零报错的作品，但它没意识到题目本身有矛盾。题目问"锁得住吗"，它答的是"装得进吗"。更要紧的是，它没觉得这件事需要问一句。这一局虽然其他地方都做得很好，分值差距也只有一分，但失分点有点重要，非常可惜。
四、第二关：一颗剥开进度能拖动的橘子
第二关只看形变像不像。厚度、瓣数、曲面连续性、光感，这些指标都软，只有一条是硬的：剥开进度 t 必须是连续形变，任一中间值都得成立。
1. GPT 6.1 Sol：t=0.5 这一帧，它做出来了
半剥柑橘全流程演示（GPT 版），成果物我给大家录屏。页面打开第一眼，它做的就不像"交个模型"：衬线大标题"剥开之间。"，右侧一块毛玻璃自检面板，底部一条带刻度的滑轨，整体像一本设计手册。不过测评不看排版，我看三件事：皮瓣翻到一半那帧成不成立、皮厚是不是真恒定、有没有穿模。
先看 t=0.5 这一帧：
三片皮瓣处在三个不同相位（题目要求的 0.12、0.24 错开），翻卷形态是根部贴着果面、中段向外拱起、末端开始回勾，这正是真实剥橘子时皮瓣的受力形态。没有折痕，没有悬空的弯板，也没有同步得像机器的整齐翻卷。拖到 t=1，三片皮全部外翻 120°，白瓤内表面朝外，末端从果底极点自然收敛：
底部滑轨右侧有一组实时角度读数（0.5 时是 48°、60°、33°，t=1 时是 120°、120°、120°）。这组数不是用 t 换算出来的表演数字，代码注释写明"报告实测切向转角，而非从 t 推断的角度"，读数是从当前曲线几何现场量的。我用探针读了 t=1 的三个读数，120°、120°、120°，分毫不差。
穿模探针：11 万个顶点，0 个陷入果肉。 这一关我不信肉眼。穿模几乎总被果肉挡着，默认机位根本看不出来。所以探针用的是严格版：把果肉外表面（沿法线内缩 4.55mm 的旋转面）采样成一条闭合截面多边形，对皮瓣中面和内表面两层的全部顶点做点内判定，落进实体就算穿模。结果：
| 剥开进度 t |
检测顶点数 |
陷入果肉实体 |
| 0 |
112,048（两层） |
0 |
| 0.35 |
112,048 |
0 |
| 0.5 |
112,048 |
0 |
| 0.7 |
112,048 |
0 |
| 1 |
112,048 |
0 |
五个进度值，每个进度值十一万个顶点，一个都没陷进去。题目里最硬的那条规矩，它全程没碰线。
皮厚：恒定是构造出来的。 它的做法既省又稳。不生成三张独立网格，只算一张中面，内外两层沿法线各偏移 ±1.25mm。外层到分界面 1.6mm、分界面到内层 0.9mm，全由偏移量直接决定，形变到任何 t 值，厚度在数学上就不可能变。面板读数也对得上：t=0 和 t=1 各测一次，每次 56,024 个采样点，范围都是 2.500 到 2.500mm。
瓣数、瓣宽也对：8 瓣，瓣缝微 S 形，瓣宽偏差实测最大 ±5.1%（题目允许 ±6% 以内，它收得更紧），固定种子刷新不变。从顶部俯视，三片皮瓣从果蒂极点收拢、到果底极点收敛，两端都是尖的：
颗粒、透光、阴影。 果肉颗粒 1,708 颗，每瓣 205 到 220 颗（题目下限 150 颗，达标）。颗粒用空间哈希网格做邻居排斥检测，宁可少放，也不让两颗汁胞重叠。看得出来它更在意每颗汁胞都站得住，堆密度倒是其次。颗粒透光用 transmission 加自写的背光散射近似，背光模式下透光感很真实：
灯光是它自己琢磨的写法：一块真正可见的发光平面当柔光箱，再用 9 个方向光采样这块平面的面积感，每盏都真实投影。地面接触阴影有，远处雾化也做了。
篡改测试：分层读数是实测的，但穿模它查不出来。 老规矩，动手改坏它。
改动 A：把橙白分界面的偏移量从 0.35 改成 0.15（分层从 1.6/0.9 变成 1.4/1.1，总厚不变）。面板当场跟进，总厚仍是 2.500，分层读数变成 1.400 橙皮加 1.100 海绵：
这说明分层读数是真测量，连"总厚不变、只有分层变"这种隐蔽改动都如实反映。
改动 B：把整张皮往果肉里推 2.75mm，强制穿模。探针实测内表面 36,578 个顶点陷入果肉，画面上肉眼还不容易看出来。面板呢，2.500、1.600、0.900、绿点，一切照旧：
两次改动合起来看：它报出来的数字都可信，它没报的项，不能当成没问题。面板上那三项测得诚实，穿模不在它的检查清单里。这份清单的边界在哪，第 3 节一起说。
整个页面从加载到交互全程没有运行错误，也没有警告。
2. Kimi K3.1 Pro：料都是真的，但皮瓣穿进了果肉
半剥柑橘全流程演示（Kimi 版），成果物我给大家录屏。Kimi 全程没问我任何问题。页面打开第一眼相当惊艳，颗粒、分层、翻卷都有模有样。它承诺的东西兑现了不少：4238 颗实体汁胞、实测皮厚 2.500mm、无贴图，这些我逐项验过。
先说不掺水的部分。 皮厚是真恒定，做法也正统。它没用"整体缩放"糊弄，每帧沿变形后的法线方向偏移 1.6 和 2.5mm，把外表面、橙白界面、内表面建成三张真实网格。我在 t = 0 / 0.2 / 0.35 / 0.5 / 0.7 / 0.85 / 1 七个进度值上逐点采样，全部是 2.500mm，连它页面自检读数（图 22 左侧）都对得上。
瓣数、瓣宽、瓣缝也都对。8 瓣，瓣宽 ±6% 固定种子随机（代码里是 mulberry32(20261108)，刷新不变），瓣缝用 sin² 包络做的微 S 形，三片皮瓣翻卷相位错开 0.12 和 0.24。果肉颗粒 4238 颗（每瓣 502 到 555，直径 2.2 到 2.8mm），用 InstancedMesh 实体生成，背光下有真实透光感，地面接触阴影也在：
这一关它的自检面板也是真的。我做了和第一关同样的篡改测试，把白瓤厚度 0.9 改成 0.5，面板读数当场变成 2.100 到 2.100mm，状态从"全部通过"翻红成"请检查"：
对比第一关那个写死 'PASS' 的面板，这次是实打实的几何测量。到这里为止，它比第一关的自己强。
t=0.5 这一帧，它栽了。 题目有一条硬规矩：任意中间值下，不得出现折痕、自交、皮与果肉穿模。我不信肉眼，写了个方向感知探针：取皮瓣内表面的每一个顶点，算它到果心的距离，再跟它所在方向的果肉表面半径比。顶点半径小于果肉表面，就是陷进了果肉实体。结果：
| 剥开进度 t |
陷入果肉的顶点数（占 4599 个） |
最深陷入 |
| 0.35 |
1061 个 |
4.8mm |
| 0.5 |
1008 个 |
7.3mm |
| 0.7 |
1008 个 |
10.4mm |
| 1 |
1071 个 |
12.5mm |
从 t=0.35 开始，每一帧都有大约五分之一的皮瓣内表面埋在果肉里面。默认机位看不出来，全被果肉挡着。我把果肉调成半透明，皮瓣伸进去的部分就现形了，就是果实中下部那道橙色条纹：
更直接的办法是把果肉整个藏起来，只留皮瓣。皮瓣的真容是这样的：根部垂下两根"橙色舌头"，一直伸到果实内部深处，皮瓣中部还出现了自相叠折：
还有一处，不知道你拖滑块的时候注意到没有：完全外翻时，皮瓣的末端不尖。一片真剥下来的橘子皮，从果蒂极点到果底极点应该两端收成尖角、中间最宽。下面这张图三片皮瓣的末端全是钝边，因为那个钝边压根不是皮瓣末端，是它自折叠留下的折痕边，真正尖的那一截被折进了果肉里。
自检为什么没发现，因为根本没查。 我又做了第二个篡改：把翻卷力度人为调大（向外推力和下垂项各加大近三倍），画面立刻变成明显畸形的"花朵"，面板还是绿字"全部通过"：
它的自检清单里只有：当前 t 值、两端皮厚、分层厚度、颗粒总数、每瓣最少颗粒。没有穿模检测，没有自交检测，没有折痕检测。题目里最硬的那条规矩"任意中间值下不得穿模"，压根没进它的检查清单。
第一关其实也这样：场景 A 它的自检缺"锁存在性"，场景 B 缺"穿模检测"。共同点很清楚，它只检查自己定义出来的指标，不回头对题目真正要的东西。
单看手艺，这一关没什么可挑的：皮厚每帧沿变形后的法线偏移出三张真实网格，瓣宽用固定种子做 ±6% 随机，颗粒 4,238 颗铺得满满当当。败的只有一处，皮瓣往果肉里翻，而它的检查清单里没有这一项。
3. 第二关的结论：10 比 8，分差就在 t=0.5 那一帧
| 评分项（分值） |
GPT 6.1 Sol |
Kimi K3.1 Pro |
| t=0.5 皮瓣是否自然（3） |
3（根部贴合、中段外拱、末端回勾，无折痕无自交） |
1（壳面光滑但穿模 + 自折叠） |
| 皮厚是否恒定（2） |
2（构造上恒定，56,024 点实测 2.49999–2.50000） |
2（每帧沿法线偏移，七个 t 值全部 2.500） |
| 瓣数与瓣宽不齐（2） |
2（8 瓣，偏差最大 ±5.1%，微 S 缝） |
2（8 瓣，±6% 固定种子，落实） |
| 果肉颗粒有且无穿模（2） |
2（1,708 颗，空间哈希排斥保证不重叠） |
2（4,238 颗，密排铺满） |
| 透光与接触阴影（1） |
1（transmission + 自写背光散射） |
1（透光真实） |
| 合计 |
10 |
8 |
这一关分差比第一关大，就落在 t=0.5 那一帧。皮厚、瓣宽、颗粒、透光四项，两家都做对了，做法各有千秋。Kimi 的皮厚是"每帧沿变形法线偏移三张网格"，这个做法灵活；GPT 是"单中面 ±1.25 偏移"，这个做法在数学上就不可能改变厚度。Kimi 的果肉 4,238 颗铺得满，视觉更丰收；GPT 的 1,708 颗，但每颗都用邻居排斥保证不重叠。这些做法不同，我不扣分，只扣穿模。
要扣分的只有一处，但足够定胜负：皮瓣往果肉里翻。题目写着"任意中间值下，不得出现折痕、自交、皮与果肉穿模"，这是整道题最硬的一条。Kimi 从 t=0.35 起每一帧都有一千多个顶点埋在果肉里，最深 12.5mm，完全外翻时的"钝边"其实是自折叠的折痕。GPT 用升级后的同一套严格版探针（截面多边形点内判定，不再用球形近似）跑完五个进度值、每个值十一万个顶点，一个都没进去。
还有一条两家打平、值得单独说的：两家的自检面板都不查穿模。厚度改一点都翻脸，把整张皮按进果肉里三万多个顶点却毫无表示。这一点两关是对称的，面板上每一项都测得诚实，但清单本身漏了题目里最要命的那条。
这一关 GPT 赢在从 0 拖到 1 每一帧都不穿模；Kimi 丢的分在变形建模上，跟渲染水平没关系。
五、两关合起来看
| 项目 |
GPT 6.1 Sol |
Kimi K3.1 Pro |
| 第一关（精度关，10 分） |
10 |
9 |
| 第二关（形体关，10 分） |
10 |
8 |
| 总分（20 分） |
20 |
17 |
| 审出规格 bug |
是（2 处，阻塞追问） |
否（沉默绕过） |
| 自检面板可信度 |
实测，篡改即翻红或崩溃（第一关有 1 处对表式期望值） |
第一关写死 PASS；第二关实测可翻红 |
| 两关共同的盲区 |
面板都不查穿模 |
面板都不查穿模 |
总分 20 比 17，关键看这 3 分丢在哪。GPT 两关全满，Kimi 丢的 3 分全部来自对题目的理解，没有一分来自建模手艺。
第一关那 1 分：题目问"锁得住吗"，它答的是"装得进吗"，还把一个二值判断包装成了物理量（页面大字 0.000，实测真实游隙 0.52mm）。
第二关那 2 分：题目最硬的规矩"任一中间值不得穿模"，它的皮瓣从 t=0.35 起每一帧都埋进果肉一千多个顶点，完全外翻时皮瓣自折叠、末端变钝边。
手艺上它两关都没有明显短板：真布尔、真碰撞、真薄壳、真透光，视觉完成度甚至经常比 GPT 更抢眼。问题始终出在同一个地方，跟手艺无关。
六、结论
20 比 17，GPT 6.1 Sol 赢了。
要"按图纸交付、能过验收"的活，选 GPT。两道题里所有硬约束（零位移、不穿模、缝隙尺寸、连续形变）全部落实，所有数字承诺全部实测。更难得的是开工前那一步：提示词自相矛盾的时候，它停下来问，没有自己挑一个解释做下去。在生产环境里，这一问很值钱。
要"好看、有视觉冲击"的活，Kimi 够用，但验收得自己来。两关零报错，交互完整，画面完成度高，果肉铺得比 GPT 满得多，手艺也在线。问题是它不审题：矛盾它消化掉，超规它不吭声，题目里最硬的那条规矩，它的自检清单里直接没有。
有两个结果和直觉不一样：
第一，分差全部来自理解，手艺没拉开差距。 布尔运算、碰撞检测、透光材质、薄壳建模，这些真正的技术难点两家都做出来了，没有谁露怯。薄壳这项 GPT 确实更稳，它把"任意 t 都不得穿模"当成设计前提，先算好绕行路径再动手。但这算不上"会不会做薄壳"的差别，差别在想没想到那条规矩。手艺这一层两个模型都够了，真正拉开距离的是三件事：读题、对齐、自检清单的覆盖面。这几件事技术上都不难，难在每一件都直接决定交付物能不能用。
第二，改尺寸看得见，改定义看不见。 第一关 Kimi 没改任何尺寸（横头还是 30×9×33.4，证据卡可查），它改的是"可动范围"这四个字的算法，把"整段请求被拒就记 0"包装成了物理量。改尺寸你能在图上看见，改定义你看不见。它没撒谎，解释文字里写清楚了，但它也没告诉你，主指标上照旧是一个 25 号大字的 0.000。项目里最怕这种，有矛盾自己消化，改了口径也不通知。这也是我最担心的地方，可靠性。
测评本身的局限也交代一下：
只覆盖两个场景，各一次采样，模型有随机性，一次成绩不代表稳定水平。两道题都是为避开训练数据里的常见素材设计的，题目本身的区分度经过了验证（第一关区分度低、第二关高），换一批题目结论可能不同。不过有一个信号在两次测试里都出现了：开工前愿意把矛盾摊开的那家，交付的东西更经得起验。
最后说点个人判断
实测虽然 Kimi K3.1 Pro 在 3D 建模方面对比 GPT 6.1 Sol 还有些差距，但我对 Kimi K3.1 Pro 的期待其实比谁都高，Kimi 也是我日常使用的主力之一，月半都已经用上加油包了，额度都花光了，重度用户。
这两关测下来，真布尔、真碰撞、真薄壳、真透光，硬手艺一项不缺，放在一年前，国产模型想都不敢想。这个进步是实打实的，但差距也得正视，好就好在它差的地方全是读题、对齐、自检清单这些不拼算力的事，补起来比追手艺快得多。希望国产模型下一版能把这几分补回来。
发表于 半小时前
|
查看: 4|
回复: 0
/1 
