定制家具端到端制造平台——接单、设计、报价、切割、采购、分成一条闭环

定制家具这行，利润是漏在环节之间的，不是漏在某一环里

在定制家具厂管事的人都清楚，这是一条长链，每一环还都是定制的：接单、把单分给设计、设计、报价、切割、买料、给销售算钱。多数厂里，这每一步都待在不同的工具或一张表里，交接处处漏。销售手工出价；设计在 CAD 里重画一遍才拿到能用的几何；工厂照着那张图自己算下料清单；采购靠估买料；分成到月底再拿一堆早就变过的数对账。同一个柜子实际上被画了三遍，而报价之后客户把隔板挪 40mm，得靠人把这一连串全追一遍——否则厂里要么吃下报错的价，要么整块板报废、交期顺延。

一单定制的利润不是死在车间，是死在接单、设计、报价、切割、买料、分成之间的缝里——每一道缝，都是一个数字和别的数字对不上的地方。

一条闭环，跑在单一事实源上

我们把整条链做成一套平台，底下共用一套 Neon serverless Postgres 事实源，部署在 Cloudflare Pages 的边缘上，给销售、设计、工厂、采购各自一套视图。一单录一次，之后在闭环里走完，哪儿都不用重录：

接单与分单。 只录一次，自动派给对的设计和工厂队列——不重录，也没有”这单谁接”。
在线设计。 在浏览器的参数化 2D 画布上排版；同一个模型导出成 DXF 进设计的 CAD、改完干净地导回。
自动报价。 价格从设计推导——面板、五金、饰面——不另填表，所以报价不会和真正在做的东西跑偏。
切割与余料套裁。 下料清单从模型算出来，零件在整料和已记录的余料上套裁。
按 BOM 汇总采购。 物料需求从确认的订单汇总，于是你买的是订单真正需要的，不是估出来的。
分成结算。 订单关闭时按真实订单额算出来，不用月底对账。

因为每个环节读的是同一条记录，改一个尺寸，报价、下料清单、物料采购、分成会同时更新。下面这份报告讲的是真正难做对的几处，以及每一处的取舍。

一份参数化模型要扛过一趟 CAD 往返

整套平台立在一个决定上：每件产品只有一份几何模型，下游每一段都从它读，而不是各自重新推一遍。障碍在于：设计不肯放弃桌面 CAD——精度工具、吸附、手上的习惯都在那边——所以模型得离开浏览器，在 CAD 里改，再回来，而且不能把意义丢掉。

我们用一趟 DXF 往返来做这件事，而能扛住的关键，是这模型是参数化的，不是一堆线段。一块面板不是写死的四个坐标，而是一条规则——面板宽 = (总宽 − 边立梃 − 收口件) / 面板数，轨道分段从通长推出来，五金按柜体算出的位置摆放，装配吸附是公式而不是手摆的偏移。DXF 回来时，我们拿这些规则去重读它，而不是盲信原始坐标，于是设计在 CAD 里挪一下隔板，改的是那个参数，所有挂在它上面的东西跟着动。

我们否掉的另一条路是”压平后照单全收”：把设计导成最终几何，让 CAD 当主版本，回来什么就当新的事实导入。这样更好做，多数导出也是这么干的，但它把闭环弄死了——一旦几何成了主版本，报价和下料清单又回到照着图手填，正是我们要删掉的那道人工复核。让模型在往返两侧都保持参数化，导入器那边活更重，但这才是一个 40mm 的改动能一路传到锯台、没人需要重新量的原因。这种传导，正是工厂那道人工下料复核被省掉的唯一来源。

套裁是个排料问题，代价函数得自己挑

把一单分解到锯台，看着像几何活，本质是个优化问题：把每个零件摆到可用的板上，尽量少浪费。真正要拿主意的地方不在打包算法里，而在你让它优化什么、允许它往哪些料上摆。

第一个取舍是余料 vs 整板。余料库存在平台上是真的：每次切割都把记录在案的余料留回料架，套裁会先把下一单摆到这些余料上，再去动新板——省下的料大半从这儿来。但你不能只盯着余料利用率。把一单铺到十几块奇形怪状的余料上，论原始出材率能赢一张干净的整板，却仍可能是错的选择，因为这意味着锯台上十几次装夹、更多搬运、更大的切错概率。所以代价函数不是纯出材率；它把省下的板材和切割复杂度一起权衡，超过某个阈值，就宁可用一张切得干净的整板，也不用一拼省几个点的余料拼图。

第二个取舍是利用率 vs 切割路径。摆得最紧的套裁，往往切出来的是锯台跟不动的顺序——非导槽式排布、别扭的旋转、不重新装夹就取不出来的零件。我们把套裁约束到这家厂的锯实际能跑的排布上，用一点理论利用率，换一份车间能执行的下料清单。这里的最优解和厂相关，所以这些权重是可调的——一台往复锯和一台滑台锯，要的取舍不一样。

采购是把 BOM 汇总上来，不是另估一遍

采购过去是一单被算两遍价的地方——报价时一遍，有人估买料时又一遍——两边从来对不上。在平台上，采购在同一个模型的下游。每一张确认的订单已经隐含一份物料清单：参数化模型知道自己的面板、封边长度、五金数量、饰面面积。这些行项跨所有确认订单汇总成总物料需求，再扣掉料架上记录在案的余料和在手库存，扣完的净需求才变成采购需要买的。

值得点出的决定是时机——什么算”需求”。我们只从已确认的订单汇总，不算还在飞的报价，因为把未确认的活拉进采购，正是一家厂给一个根本没落地的单买了板的原因。报价和采购读的是同一份 BOM，但采购等订单坐实了才动钱。这样买的就跟着真实、已净算的需求走，而不是按单估；又因为 BOM 是从模型推导的，上游一改尺寸，需求会自动重新净算，而不是留下一张过时的采购单。

分成引擎是规则，不是写死的百分比

提成不是一个比例。不同销售走不同的分账，不同产品线毛利不同、提成规则也就不同，一张单里还可能混着各算各的产品线。把这些写死，等于厂第一次改比例或加产品线时就得重写。

所以分成是一套可配置的规则引擎，不是代码里的一个数。规则按销售和产品线索引，对着订单真实的、已关闭的金额求值——就是报价从模型算出的那个金额——所以分账是在关单时、从不可能跑偏过的数上算出来的。因为规则是数据，厂可以给销售重新分级、接入新产品线，都不用改代码；因为输入是真实订单额而不是重录的数字，过去追着变动数跑的月底对账，也就不需要了。

四角色模型，归属权在服务端强制

销售、设计、工厂、采购各有各的视图，最顺手的做法是在前端把某个角色不该看到的藏起来。我们也这么做——但前端只是方便，永远不是控制。API 回应任何一条记录请求之前，都会在服务端、每一次调用都重新算这条记录归谁、调用者有没有资格拿。

这一点之所以要紧，是因为它挡掉的，是 Web 上最常见的严重漏洞。一个合法登录、完全正常的用户，改一改请求里的 ID 就读到别人的订单，利用的就是 OWASP 列为 Web 头号风险的越权访问（Broken Access Control）。防住它不靠什么巧劲，靠的是纪律：归属权是每一次读写都做的服务端校验，对每一个接口都当默认，而不是只往敏感接口上加——因为敏感的那几个，恰恰是你会忘的那几个。

部署不打断生产

一家从早到晚都在报价、切割的厂，不能为一次部署被塞进一个停机窗口。表结构迁移前后兼容——新代码能跑旧表结构，旧代码也能跑新表结构——于是一次迁移是滚动变更，不是停线事件。设计文件存在对象存储、由 Postgres 引用，而不是当大字段塞进库里，这让库小到能快速迁移，也把文件分发挪出查询路径。CSP 与 CSRF 全程加固，部署走 CI 直传，绕开构建排队卡顿。

结果

闭环合上了。周一接的一单，在一套系统、一组数字里走完分单、设计、报价、切割、采购、分成。过去画三遍的柜子只画一次，报价、下料清单、净算后的采购需求、分成读的都是同一份模型——所以一个 40mm 的改动，会把它们同时更新。过去当废料的余料，成了套裁第一个去找的库存。过去利润漏掉的那些缝，没有了，因为不再有几份各自跑偏的”事实”。