先校验家具布局，再让 AI 生成装修图

AI 装修图最容易让人心动的，是房间突然变漂亮了；最容易被忽略的，是沙发到底放不放得下。作者做的 Nookflip 把顺序倒过来：先生成带尺寸的家具方案，在可拖动的平面图里检查布局，确认后再把效果渲染到用户的房间照片上。

这篇值得看的地方，是作者如何把确定性的布局检查交给 JavaScript，再处理图像模型不听布局、忽略用户要求和风格跑偏的问题。不过，效果图是否严格遵守平面图，原文还没有给出量化验证。

先让家具放得下，再让房间变漂亮

Nookflip 运行在 AI 应用市场 Anna 内，没有自己的后端。用户上传房间照片、选择风格后，模型生成一份方案，包含家具及其实际尺寸、带 hex 色值的墙漆颜色、材料和灯光。

随后，家具会出现在按比例绘制的 SVG 平面图上。为了让照片和图纸说的是同一个方向，作者约定：照片里的远端墙对应平面图顶部，拍摄相机所在的一侧对应底部。用户拖动家具时，位置会吸附到网格，并限制在墙体以内。

每次移动都会触发四类实时检查，全部由普通 JavaScript 完成：

• 家具的包围盒是否重叠。
• 两件家具之间的间距是否小于 45 cm。
• 家具是否进入向内开启的门扇扫过区域。
• 家具尺寸是否超过房间能容纳的范围。

模型负责提出方案，代码负责执行明确的空间规则。

如果模型最初给出的摆放位置发生重叠，应用会自行重新安排：先尝试模型指定的位置，再尝试方案文字提到的墙边，最后寻找能留下通道的空位。

这部分布局逻辑被放进一个纯模块，不依赖 DOM，也不访问网络，并用 node:test 测试套件覆盖。对前端开发者来说，这种拆法很实用：拖拽只是输入入口，碰撞检测和位置搜索可以独立运行、独立验证。

为什么多给一张平面图，模型反而更不听话

作者认为最难的部分，是让最终效果图遵守已经确认的布局。

最初，作者把平面图和房间照片一起发给图像模型，结果更糟：模型移动了窗户，还添加了没人要求的椅子。图纸没有被稳定地理解成约束，反而参与了房间的重新创作。

作者随后改为用文字描述布局，明确沙发和椅子的朝向，并省略位于相机后方区域的家具。这样做让渲染输入更贴近当前照片能看到的内容，但原文没有提供修改前后的成功率。

另外两次调整也很具体。

一次渲染替换了用户明确要求保留的床。作者的修复办法，是把用户备注逐字放在提示词最前面，再写风格细节。这里的关键不只是补一句「请保留」，而是调整约束的排列顺序。

另一个问题是风格漂移。用户输入 Contemporary，结果却反复偏向 mid-century。作者让规划阶段先写一份简短的风格指南，既说明目标风格，也说明它不属于哪些风格，再让后续生成围绕这份指南展开。

这些都是作者实际遇到问题后采用的做法，但不能据此认定它们适用于所有图像模型。原文没有说明模型名称、版本或重复测试次数。

我的判断

我认同把空间检查留给代码。重叠、间距和门扇范围都有明确条件，适合做成可测试的规则；如果每次拖动都交给 AI 判断，交互延迟和结果一致性都更难控制。

但通过布局检查，不等于已经验证家具能在真实房间里落地。 原文没有交代房间尺寸如何获得、照片透视如何校准，也没有说明家具尺寸是否对应真实商品。如果这些输入存在误差，按比例绘制的 SVG 仍可能给人过强的确定感。

45 cm 也应理解为这个应用采用的检查阈值。作者没有说明它的依据，不能直接把它当成所有房间、家具和使用需求都适用的通行标准。

渲染部分更接近经验之谈。文字布局、备注前置和风格排除描述都有合理性，但缺少对照数据，无法判断各自贡献了多少改善，也无法与其他布局控制方式比较。原文甚至没有展示最终渲染与平面图的一致性指标。

作者还根据试用反馈加入了购物清单：把家具尺寸和估价放在一起，超预算时提示；布局仍有冲突时，询问是否继续渲染。这些交互能帮助用户做决定，不过估价来源和准确性同样没有说清。

能拿来做什么

• 做前端拖拽或空间布局工具时，可以把坐标、碰撞检测和位置搜索抽成不依赖 DOM、网络的纯模块，再通过 node:test 验证关键规则。
• 做包含规划和图像生成的 AI 应用时，可以先明确照片与布局共享的方向，再把位置、朝向和可见范围写进生成输入，减少描述歧义。
• 排查模型忽略要求的问题时，可以参考作者的做法，把用户必须保留的内容逐字前置，并用简短风格指南补充正向要求与排除项；同时保留案例，验证调整是否有效。
• 当应用允许用户带着布局冲突继续生成时，可以明确展示冲突并询问是否继续，同时把尺寸、估价和预算提示放在同一处，方便用户取舍。