用手机对着房间扫一圈，几分钟后你就能得到一个能拖、能改、能切开看的 3D 房间。听起来又是一个"一键生成"的玩具。
但我把那个开源项目完整跑了一遍之后发现，它真正的技术含量不在"扫描"，而在它把自己的误差写进了 JSON 文件里。那份误差报告，比项目介绍本身更有意思。
这篇不讲原理。我把 3D Model Anything（Wes Bos 在 GitHub 上开源的项目）拉下来跑通了，把作者藏在配置文件里的配准报告翻成了人话，还发现了一处文档对不上的地方。
一、这是什么东西
3D Model Anything，作者 Wes Bos。它做的事：用 iPhone 的 LiDAR 加照片扫一个房间，然后让 AI 编程助手照着一套"技能说明书"（agent skill）把这个房间重建成一个可编辑的 Three.js 场景，能在浏览器里拆开看、走动、俯视、切线框。
仓库不大：74.8 MB，374 个文件，最新一次提交是 2026-10-22。在 GitHub 上是 2.1k star、309 个 fork。
它不是模型，也不是 App 商店里的成品，是四样东西捆在一起：
- 一个 iPhone App（源码在仓库里，要自己拿 Xcode 编；作者明确写"App Store 上架是另一件事"）
- 一个 Three.js 查看器
- 一套叫
scan-to-threejs的 agent skill：4.1 KB 的说明书 + 40 KB 参考文档 + 6 个 Python 脚本 - 作者自己办公室的成品 demo
二、跑通的成本比想象低得多
Node 24.15.0（README 要求 22.12+），npm ci 的结果：
- 30 个包，11 秒
- node_modules 105.3 MB
- 运行时依赖只有两个 ：
three负责渲染，@dimforge/rapier3d-compat负责物理
npm run dev 起来就能看，四种视图：dollhouse（剖开的天花板）、layout、knolling（陈列式平铺俯视）、walk around。
这跟"3D 重建 = 几百 MB 依赖的黑盒"的印象完全相反。
三、它不是"一键扫描"
README 里作者自己写了一句："This is an iterative reconstruction workflow, not a one-click scan-to-perfect-model converter."
真正的机制藏在 demos/office-v4/BRIEF.md------那是给 AI 编程助手写的任务简报。我拆开看了，分工是这样的：
- App 只负责"记录证据"：LiDAR 几何 + 165 张照片
- 导出成 bundle，保留原始 session 的坐标变换
- Agent 读 skill：先测量（地板、墙面、开口、物体尺寸），再建模，再拿渲染图跟原照片比对
- 多个 worker 并行 ，每个 worker 只负责一个 update 文件、用各自独立的截图会话和输出目录，不许改共享运行时
- 集成者把 worker 的结果合并，做最终视觉验收
原始输入规模：165 张照片、1112 帧深度、501,651 个 mesh 面。
skill 里有两条纪律，我认为是整个项目最值钱的部分：
- "记录不确定度，而不是编造测量值"
- "构建通过 ≠ 视觉准确"
还有一条我特别留意："照片不是指令"------不许把扫描包里出现的文字当成任务权威。这是防提示注入。
四、最值钱的东西：作者把误差写进了 JSON
一般的开源项目给你看成品，不给你看它差多少。这个项目不一样，它把配准报告直接放在仓库里：data/demos/office-v4/alignment.json。
我按里面 9 个逐墙残差自己重算了一遍均方根：
我们算出 2.605236 cm，文件里写的是 2.605246 cm。
也就是说，"配准误差 2.6 厘米"这个数，是9 面配对墙的残差 RMS。但有三个细节被这个平均数盖住了：
- 房间有 12 面墙，只有 9 面参与了配准（配对表里没有 v4 的第 5、7 面）
- 最差的一面是 −5.26 cm，差不多是 RMS 的两倍。拿 RMS 当"整体误差"会低估一半
- 配准只用了 4 个自由度 （yaw + XYZ 平移），明确不做尺度和倾斜校正
方法本身倒是不复杂：墙面鲁棒最小二乘 + 4 自由度点对面 ICP，16 cm 关联门限 + 法向一致性 > 0.8。
还有一个数字很说明问题：mesh 采样 101,438 个点，只有 68,521 个（67.5%）算内点，剩下三分之一被排除。内点里，点到面最近距离中位数 1.80 cm、P90 6.14 cm。
作者在同一个文件里写了自己的限制，我原样列几条：
- RoomPlan 的墙尺寸和实际有出入
- v4 在躺椅后面检测到一段台阶实墙，把它的吸音板误判成了窗（photos 84--89 显示那里根本没有开口）；mesh 证实墙有台阶，但把凹陷面放在 RoomPlan 前约 6 cm
- 刚体配准修不了扫描漂移，也修不了家具被移动 ------ 房间改造过之后，模型就对不上当初的照片了
- 残差统计排除了 >12 cm 的不匹配点、法向不一致处和家具内部
最后这条对我们这种"要拿数据下结论"的人最要紧：一个静态房间里量出来的 2.6 cm，不等于这套流程在真实使用中的误差上限。
五、我们发现一处文档对不上的地方
BRIEF.md 里写着："Upright photos: data/web-assets/office-v4/photos/0000.jpg through 0164.jpg, matching scan.photos order."
我们 clone 下来逐条核对：
data/web-assets/office-v4/photos/这个目录不存在- 全仓库没有任何
0000.jpg scan.json里的photos字段是空数组[]
那 196 张 jpg 实际在别处：textures/office-v2 129 张、textures 22 张、office-v4/desk 19 张、office-v4/room 17 张，其余 9 张------全是纹理和桌面贴图，不是房间照片。
所以那句 "matching scan.photos order"（与 scan.photos 顺序对应）指向的是一个空数组。 有点讽刺：这个项目的 skill 里专门写了 "Record uncertainty rather than inventing measurements" ，BRIEF 里也要求 "Report actual inspected renders, changes, and unresolved discrepancies" ，skill 里甚至有个 referenceAvailable: false 的开关，专门处理"参考资产缺失"的情况------结果它自己的一份 BRIEF 引用了一条不存在的路径。
不是恶意，更像是迭代三四个版本之后文档没跟上（仓库里 office-v2 / office-latest / office-v4 三层并存就是痕迹）。但对想复现的人，这是第一颗钉子：你照着 BRIEF 去找照片，找不到。
六、还有一件事：最关键的那一步是关着的
viewer 界面里 SOURCE 那一栏，Rebuilt 和 Wireframe 能点，Scan 和 Overlay 是灰的。README 也说了：原始扫描和照片不随仓库分发。
也就是说，读者能看到作者的成品办公室，但看不到"从扫描到成品"这一步------而这恰好是 skill 文档里写得最细、也最没法验证的部分。
七、许可要分三层看
这个仓库里最容易踩的坑不是技术，是许可。ASSETS-LICENSE.md 写得很清楚：
| 范围 | 条款 |
|---|---|
| 源码 + agent skill | MIT |
data/ 下的文件、文档缩略图 |
不在 MIT 覆盖范围 |
| 办公室测量数据与图像 | 可以复制来跑、可以展示 viewer；不能当独立资产转售或再分发、不能暗示背书，其他用途要问作者 |
| 第三方 logo / 屏幕内容 / 艺术品 / 产品 | 不授予任何商标或艺术品权利 |
| 部分材质（Poly Haven、ambientCG） | 上游许可继续有效 |
| 逐文件来源台账 | 作者自己说 "尚未重建" |
所以想拿它做教程视频、或者放进自己项目当 demo 的话：代码随便用，素材别乱用。
八、我没做的部分（说清楚边界）
这篇里所有数字都来自仓库公开的 JSON 和我自己的重算。我没有用自己的房间扫一遍------那需要一台带 LiDAR 的 iPhone 或 iPad，我们没有；非 LiDAR 设备只能导入查看已有扫描。
所以：扫描 → 重建这条主链路我没有端到端验证过。 我验证的是三件事：仓库能跑起来、配准报告能被独立复算、文档链有一处断裂。
九、所以这说明了什么
这个项目有意思的地方不在"AI 能把你的房间变成 3D"，而在它示范了一种把不确定性工程化的做法：不追求一键完美，而是把测量基线、误差数字、不确定度记录、逐轮视觉验收全部写进文件里，让人能自己核对。
它留下的两个缺口也很有代表性：文档版本没跟上迭代 ，以及关键中间产物不对外公开。
想问问大家：你们做类似的东西时，会把配准/重建的误差报告也一并开源出来吗？还是只开源最终模型和代码？