一个工程师把3D分割从"看图说话"改成了"量房思维"，效果猛了

传统视觉模型在暗光环境集体失语时，一套基于深度几何的分割系统正在跑通。开发者用 carpenter（木匠）读水平仪的逻辑替代 photographer（摄影师）看照片的直觉，让 RGB 失效的场景里，深度场成为唯一可靠的证人。

从一次"废片"开始的思路转向

这套系统的起点是一张看似毫无价值的图像——RGB 帧几乎全黑，深度图却保留了完整的结构信息。开发者意识到：当环境暗到一定程度，纹理成了错误的证人，深度场才是说真话的那个。

这个观察直接改写了问题定义。分割从"颜色问题"变成了"几何问题"：不再问"这块区域是什么颜色"，而是问"这些点在三维空间里是否连续"。

深度流水线的工作逻辑类似木匠用水平仪：阈值过滤、区域分组、检测不连续面、验证表面可信度。 它不追求"理解"一堵墙的油漆或木纹，只关心找到连续表面、在深度跳变处分割、并确保结果在 RGB 失效时依然可用。

架构设计：浏览器打杂，GPU 干活

完整链路从 web 应用发起，但重活全在 GPU 服务器。浏览器发送深度数据到 API 路由，路由转发至深度分割服务，服务器将深度图转化为标注区域——全程靠几何结构而非视觉纹理。

流程极简：原始深度输入 → API 路由 → GPU 服务器 → 阈值处理 → 连通区域分析 → 表面不连续检测 → 孔洞处理 → 输出标注区域。

API 路由被刻意设计得很薄。它的存在只是把请求送进 GPU 服务、把结果带回应用，避免让 web 层变成图像处理的坟场。

代码层面，这段 Next.js 路由不到 30 行：解析请求体、转发至 GPU 服务、透传响应或返回错误。没有冗余的转换层，没有试图在 web 端做聪明的预处理。

为什么"薄"是一种美德

开发者对这段路由的偏爱恰恰在于它的"少"。当整个系统需要处理深度分割这类计算密集型任务时，web 层的职责边界变得清晰：只做交通指挥，不做体力活。

这种设计也暴露了常见反模式——很多团队习惯在 API 层塞入图像解码、格式转换甚至轻量推理，结果 web 服务既当调度员又当工人，延迟和稳定性双双崩塌。

把深度图扔给专用 GPU 服务，本质是对计算异构性的承认。浏览器和 Node.js 运行时擅长 I/O 和状态管理，CUDA 核心擅长并行几何运算，强行让一方跨岗只会两头耽误。

从"看懂"到"量准"的范式迁移

这套系统的真正价值不在技术栈选择，而在问题 framing（框架设定）的切换。计算机视觉长期被"识别"叙事主导——模型要"看懂"场景，要语义理解、要上下文推理。

但在低光照、无纹理、高反差的边缘场景，"看懂"是个奢侈目标。"量准"才是刚需：知道哪里是连续表面、哪里是物理边界、哪里可以信任。

开发者用木匠类比精准描述了这个差异。水平仪不"理解"木材，只判断平面是否水平；这套深度流水线不"理解"墙壁，只验证几何连续性是否成立。

这种降级不是能力收缩，而是可靠性提升。当视觉纹理这个证人被黑暗收买，几何结构成为唯一不会作伪的证据。

目前系统已完成从 web 到 GPU 的全链路跑通，API 路由的极简设计让迭代重心始终停留在算法本身。开发者没有透露后续计划，但留下一个值得追问的线索：当更多传感器数据（如 IMU、LiDAR）接入时，这套几何优先的分割逻辑会扩展成怎样的多模态融合框架？