干这一行第十二年我最大的感受是全屋定制从来不缺审美在线的设计师缺的是能把设计师脑子里那套东西原封不动、不出错地搬进车间的“转译员”。你去问任何一个工厂的拆单主管他们都能给你讲出一堆“设计图画得挺漂亮一到拆单就各种打架”的故事。门缝算错、背板方向反了、抽屉轨道和铰链打架、台面下翻边撞到拉手……这些事听起来都不大但每一件都意味着返工、补板、延期以及客户在微信里越来越短的耐心。这两年大家都在说 AI、说智能体我一开始也以为是又一个概念吹风。直到我把一套面向全屋定制场景的智能体跑通了真实订单才确信这个行业真正值得被重构的不是渲染图的逼真度而是从设计意图到拆单参数这条又长又脆的信息链路。这篇文章就是把我在模拟项目“某跨平台定制系统的智能拆单模块”里积累的思路、选型、踩坑和工程方案完整写出来——给正在考虑用 AI 改造设计流转、拆单环节的朋友一个参考。1. 全屋定制行业的真正瓶颈从方案到板材的信息断层1.1 一条定制订单要过多少道手我先带你过一遍一条普通橱柜订单的旅程。量尺的师傅带着激光测距仪到现场记下一串墙距、梁位、水管位置设计师拿到这些数据做方案在软件里拉出柜体、门板、台面接着是审图很多工作室里审图等于“设计师自己再看一眼”然后订单进入拆单环节拆单员把整体柜子拆成一块块板件决定每块板的尺寸、封边方向、开孔位置、五金数量再往后是排产、开料、封边、打孔、试装、包装、运输、安装。问题出在哪每一道手之间信息都要被“重新解释”一遍。量尺师傅说的是现场厘米尺设计师画图用的是毫米和逻辑坐标拆单员读图的时候得自己脑补“这块板是不是要和左边侧板齐平”“抽屉面板和柜门之间的缝留多少”。每一步的解释都有损耗损耗积累到拆单环节就变成实打实的错误。我见过最夸张的一次一张重复单从设计端到拆单端柜体深度从标准 600 悄悄变成了 620最后整排柜子突出来一截现场师傅用角磨机现场切了两天才救回来。量尺环节现场墙体未必平直数据天然带误差设计环节图形化表达为主缺少结构化规则审图环节依赖经验注意力覆盖不了所有细节拆单环节靠人工脑补把“视觉意图”转译为“加工参数”这就是“信息断层”四个字的含义。每个环节的人都觉得自己看得懂图但图不会告诉你设计人员当时脑子里那些隐藏假设。1.2 人工拆单为什么慢又为什么容易错拆单员是个典型的经验工种。一个新人在工厂里跟着老师傅学最快也要一年半载才能独立接单。而且拆单最大的矛盾是订单总是扎堆来的。月底冲量的时候全屋定制门店一批单子涌进工厂拆单员一天要拆七八个完整的柜子每个柜子几十块板。人一赶脑子里那根弦就容易绷断。错一张拆单图意味着什么假设一块柜体侧板算错了长度开料阶段已经切好封边已经把三合一孔位打上去这时候发现方向反了——板废了。一块门板大几百块一批错下来就是几万块的材料损耗和工期损失。更麻烦的是很多错误是安装阶段才暴露的那时候客户已经拉着安装师傅的袖子问“今天能装完吗”。我并不是说人的经验没用。恰恰相反拆单员积累的那些“这里要加 1mm 余量”“这种门板模压后要预缩”的直觉才是智能体最值得学习的东西。问题的本质是这种经验太私有化存在每个人的脑子里没有变成可以被校验、被复用、被测的规则。1.3 智能体能插手的环节其实就三个打开一条定制订单的价值链能被智能体“准确介入”的地方总结下来是三个设计意图理解把设计师用自然语言、草图、初步模型表达的需求转成清晰的、结构化的设计约束集合空间规则校验把柜子放进具体空间里做碰撞检测、尺寸回溯、五金兼容性验证提前发现问题参数化拆单把校验后的三维模型拆成带加工属性尺寸、封边、孔位、五金的板件清单这三个环节的共性是什么它们都是“信息转换”而不是“物理加工”。大模型最擅长的恰恰就是信息转换。它不需要替你控制开料锯也不需要替你封边它只需要做好那个翻译官把花花的图形世界翻译成车间机器认识的数字和表格。想清楚这一点之后我反而松了一口气。因为这意味着我们不需要造一台 AI 木工机床也不需要让大模型去学刀具路径的底层运算——那些东西传统软件已经做得很好了。我们需要做的只是一层聪明的“翻译中间件”。2. 技术选型先想清楚大模型能干什么再谈框架2.1 智能体能做的四件事和处理不了的领域在选任何模型和框架之前我先给自己列了一份“能力边界清单”。这是我后来觉得最值钱的一步。智能体在定制场景里能稳定做到的事意图识别与抽取理解“我要一个两米宽的电视柜开放格不要把手”这类描述并抽取出柜体类型、宽度、风格、模块化元素、约束条件规则匹配执行把抽取出的需求对照空间规则知识库找到适用的尺寸标准、五金配置、结构要求结构化数据生成输出 JSON 格式的柜体参数、板件清单、封边和孔位要求给拆单软件直接消费上下文解释与对话客户改需求时智能体能快速说明修改会影响到哪些板件、成本和周期处理不了的领域也得提前认清力学与材料形变计算板材的握钉力、抗弯强度、热胀冷缩不是大模型能“近似”出来的必须走物理公式高精度数值运算柜体体积、板材利用率的最优排版需要专门的排产算法来解决没必要让大模型硬算实时设备控制智能体不能也不该直接控制开料机、封边机运行把这些边界列清楚之后很多“要不要让 AI 干这件事”的问题就不纠结了。智能体的定位是“智能决策和翻译中枢”不是“万能计算器”。2.2 模型、框架、数据存储怎么组合选型阶段我做了好几轮对比核心考虑三个点数据安全、响应速度、私有化能力。全屋定制的图纸和客户信息是不能随便传到公有云去做推理的尤其工厂端对数据出厂的接受度很低。所以我的建议是私有化部署为主用中小参数模型做高频、轻量的意图识别把复杂的、非结构化的规则判断留给更大参数的模型或云端模型中间用一套 Agent 调度框架把它们串起来。模块推荐方案理由意图识别引擎7B~13B 私有化部署模型响应快、成本低意图抽取任务不需要超大模型规则推演引擎更大参数模型 外部规则库处理复杂多约束场景推理能力强Agent 编排轻量流程引擎 外部状态库减少框架本身的学习和运维成本流程可控向量检索私有化向量库存放历史订单、设计案例检索工艺知识结构化数据关系型数据库 JSON 文档库存放参数、板件清单、订单状态保证事务一致性框架选择上我一直是“能用轻的绝不用重的”。Agent Orchestration 这件事本质就是“意图识别 → 工具调用 → 结果校验 → 状态更新”一个带状态存储的流程引擎完全够用非要套一堆重型编排框架反而把排障的难度拉高了。团队只有三五个人维护的时候简单就是最大的安全。2.3 空间规则知识库才是真正的壁垒很多人以为智能体落地的难点在大模型本身真正跑起来之后发现难点在你喂给它的“规则质量”。全屋定制的工艺知识散落在哪在老师傅的脑子里。一位干了二十年的木作师傅你说“这块板要加见光面”他会自动翻到对应方向贴同色封边你说“双门抽屉抽屉面随便留”他会骂你——因为里面轨道的安装间隙早就在他的肌肉记忆里了。这些知识传统的软件配置表里写不全就算写下来也往往没法被校验更谈不上版本管理。我的做法是建一张“空间规则知识库”把设计约束拆成可测试的规则条目。举个例子规则ID场景条件参数/动作优先级来源RULE-0101柜门铰链门宽 ≥ 400 且 600配 2 个普通铰链铰链侧边距 3mmP1五金供应商手册RULE-0102柜门铰链门宽 ≥ 600 且 900配 3 个铰链上下两端各内缩 100mmP1五金供应商手册RULE-0203背板柜体深度 ≤ 300背板厚度 5mm普通插槽式P2工厂工艺标准RULE-0301抽屉滑轨类型托底轨抽屉面高度 ≥ 150mm轨道侧边间隙 ≥ 2mmP1五金规范每条规则都有出处、有优先级、有可执行的动作。这些东西不需要大模型去“发明”大模型要做的只是根据场景把对应规则捞出来组合成合适的参数。这样有个巨大的好处规则库可以单独测试、版本管理出问题可以回溯到具体某条规则改完规则重新跑一遍回归测试就行。Prompt 会飘规则不会。3. 实操链路从设计意图到拆单参数中间件怎么搭3.1 数据结构设计先有公共语言再谈智能我和团队定过一条铁律智能体输出的东西必须是一个任何人都能看懂、任何系统都能消费的“中间态”。不要直接让大模型吐 CAD 配置文件也不要让大模型替拆单软件做决定。我们定义了一套 JSON Schema作为最核心的公共语言{ schema_version: 1.0, project_id: PRJ-20240601-001, space: { wall_height: 2600, floor_length: 3600, depth: 600, corner_info: 无转角, unit: mm }, intent: { type: tv_cabinet, width: 2000, height: 2400, depth: 350, style: modern, features: [开放格, 无拉手, 免拉手反弹器] }, constraints: [ { type: edge_banding, visible_side: left_top_front, material: ABS, thickness: 1.0 }, { type: hinge_spec, door_width: 450, count: 2, model: offset_hinge }, { type: back_panel, thickness: 5, install: insert_slot } ], stages: [design_intent, rules_validated, bom_generated], derived_from: { designer_input_id: SHEET-8823, nlp_extraction_confidence: 0.94 } }这套结构解决了一个很根本的问题——整个链路里面设计师说的是“我要个现代风的电视柜”大模型理解的是“电视柜 现代”拆单软件需要的是“板件尺寸 封边方向 孔位坐标”。大家讲的不是同一种语言但有了这个 JSON 中间态所有人都对着同一个“翻译稿”工作。我特别设置了四个字段intent、constraints、stages、derived_from。constraints是给规则引擎用的stages是给流程控制的系统可以知道这个订单走到哪一步了derived_from是给回溯用的智能体抽参出错时能一路查到最初的设计师输入。3.2 Prompt工作流让模型先讲约束再给参数很多人做智能体 Prompt 的时候上来就让大模型“帮我生成一个柜子”这样很容易翻车因为它缺了一个关键环节先说清楚约束。我设计的 Prompt 工作流是这个顺序角色限定明确告诉模型它是一个全屋定制拆单助理不是家具销售、不是室内设计师。这两者的输出习惯完全不同。输入解析输入设计师的原始描述、户型数据、修改指令先不分心去算参数只做意图抽取。约束唤醒让模型根据意图去知识库检索适用的规则条目这一步要在生成具体尺寸之前完成。参数生成基于约束清单生成结构化的参数不直接生成最终板件尺寸而是先生成“设计中间态”。自我校验模型需要检查每个数值是否落在约束允许范围不满足就提示冲突而不是继续往下编。一个可参考的系统提示词骨架长这样你是某工厂的全屋定制拆单助理。你的任务是把设计师的描述转换为符合工厂工艺标准的参数化设计约束。 重要原则 1. 在输出任何具体尺寸之前先列出你检索到的相关工艺规则并注明规则ID。 2. 所有尺寸必须使用毫米所有板材厚度必须符合工厂料表未知信息不要自行假设用 null 留空。 3. 如果输入信息与现有规则冲突必须输出冲突描述与建议方案不可以默默选择一个参数。 4. 最终输出必须是符合 schema 的 JSON不要输出额外解释。 5. 设计师没有提到的部分如封边、铰链型号不主动补充留给拆单员确认。第五点是踩过坑之后加的。最初版本里智能体会“自作聪明”补全缺失的五金和封边参数结果就是拆单员每次还要花时间改掉一堆画蛇添足的东西。现在要求它“不主动补充”整体返工率直线下降。3.3 工具调用链接入拆单软件和数据库的工程做法智能体不是一个人在战斗它要和现有的工具链协作。行业里大多数设计软件和拆单软件是闭源的不可能直接改内核所以我的方案是加一层“桥接中间件”本质上是一个消息通道 文件管道。整体调用链是这样的智能体接收设计师输入更新“订单状态表”为 processing智能体调用知识库检索接口获取候选规则智能体生成 JSON 中间态写入订单中间表桥接中间件把 JSON 转换为拆单软件能识别的数据格式可能是 DXF、CSV 或特定接口的 JSON拆单软件执行拆单计算把板件清单、孔位坐标回写智能体读取拆单结果做一致性校验如果存在冲突则生成修改建议反馈给设计师这套设计里最关键的是“回写闭环”。很多方案只做单向流——智能体把参数吐出去就完了拆单后面发生什么它一概不管。结果就是智能体改了 A 参数拆单软件在 B 处报错设计师完全看不到最后现场凭经验硬装。我在中间件里专门加了一个校验回读模块把拆单软件返回的板件列表重新映射成约束状态如果发现“背板厚度超出工艺允许范围”立刻回到订单状态表里标记为validation_failed同时通知人工介入。不要小看这一步。跑过真实订单之后你会发现90% 的所谓“智能拆单”问题不是输不出来而是没人对“产出结果是否正确”负责。桥接层回读校验相当于给智能体配了一个质检员。3.4 上线前必须完成的三件事智能体进车间之前我要求团队必须过三关缺一不可。第一关样本积累。从历史订单库里抽出不同类型、不同复杂度、不同错误案例的订单至少 200 单做数据清洗统一字段格式、单位、术语。没有这批数据后面所有的效果评估都是空谈。第二关人工比对。跑 100 张历史订单智能体拆单结果与老拆单员的原始结果做逐板比对。注意不能只看尺寸对不对还要看封边方向、孔位数量、五金型号这些“属性级”的对错。比对完成后组织老拆单员给智能体的输出打分把分歧点全部登记。第三关指标基线。给项目设定一个“可验收”的底线参考标准如下指标建议阈值说明参数生成准确率≥ 98%全部板件属性与复核结果一致订单占比平均拆单时长从数小时降到 ≤ 15 分钟设计输入到生成 BOM 的耗时返工率下降 ≥ 50%因拆单错误导致补板/返工的比例人工干预率≤ 30%需要拆单员修改或确认的订单占比留足边界这里特别想提一句人工干预率不是越低越好第一版本能把干预率控制在 30% 以内同时确保准确率能到 98%已经非常理想剩下的那部分订单大多是各种非标特殊结构留给人处理才是务实的。4. 真跑起来会踩的坑和排查录音4.1 模型幻觉怎么压下去大模型在实际拆单任务里最容易犯的毛病不是不懂工艺而是“一本正经地编尺寸”。我见过最离谱的一次门缝间隙从规则的 2mm 被模型“美化”成了 20mm理由是因为门板长度超过 1.8m它觉得“应该留大一点”——听起来还挺有逻辑但问题是谁敢按 20mm 装门解决幻觉我用了三道防线数值范围约束在每个参数的 JSON Schema 里强制写死min、max、unit模型生成时如果超出范围直接报错后置校验器模型生成结果先不落库先过一个独立的校验函数规则库比对、参数合法性检查、协调性检查比如门宽和铰链数量的关系外部优先原则任何可以计算的参数不依赖模型直接生成而是让模型先给出条件让传统代码去算模型只背书“条件本身”实操中最见效的是第三点。把一个参数从“让模型生成”改成“让模型给条件、代码来算”之后幻觉类错误直接砍掉了七成。模型擅长的是语义判断而不是精确计算这话说得一点没错。4.2 长对话上下文怎么不丢状态全屋定制里设计师和智能体的对话不可能一两轮就结束。今天改一下内部分隔明天换一下台面材质后天客户又说“预算超了减少两个抽屉”。如果全靠模型上下文窗口里的聊天历史来记状态注定漏。我的解法是外部状态优先。所有已经被确认的参数、约束、板件属性都实时写进订单状态表对话记录只作为旁证不作为唯一依据。每一轮处理时智能体会从状态表里加载当前确认过的最小上下文拼接到系统提示词里而不是把二十轮聊天记录都塞进去。具体实现上我给订单做了一套轻量状态机draft → intent_parsed → rules_matched → param_confirmed → bom_generated → validated → approved。状态之间流转必须通过工具函数完成每转一次状态表里就多一条带时间戳的审计记录。这样不仅上下文不丢连“这句话是谁在什么时候改的”都能追溯。4.3 非结构化订单数据和单位混乱怎么清理真实业务里的输入一点都不干净。设计师的备注里可能写着“柜子做 2 米宽深 350注意左边靠墙插座”还可能写“宽 2m 深 350mm 左边有插座”——单位混用、“靠墙”位置到底是左右视图的理解差异都能让智能体判断翻车。我建了一个专门的数据清洗管线单位标准化把米、厘米、毫米全部统一为主单位毫米正则抽取数值与单位成对处理术语归一化给常见口语建同义词表“敞开的格子/开放格/无门区域/漏空”都映射为同一个内部字段 open_shelf方位消歧要求输入必须定义“面向柜体正面时的左右”并写进规则避免左右视图歧义异常值拦截数值超出常见范围比如墙体高度 26000mm直接人工介入不进入自动链路单位混乱这个问题看着小实际是排障时最烧时间的。后来我把清洗逻辑的每一条规则都录成日志一旦智能体输出可疑结果先查是不是输入侧的脏数据导致的抽参错误。很多时候“智能体抽错了”其实是“输入垃圾输出垃圾”。4.4 拆单员和智能体的分工怎么设计系统刚上线时工厂里的拆单员最抵触。他们的原话是“这玩意要是把单都拆错了最后还不是我们来擦屁股。”这话没法反驳因为他们确实承担了结果责任。我的做法不是让智能体替代拆单员而是重新设计分工。现在的工作流是智能体出首版拆单方案拆单员在界面上做复核确认确认时如果改了参数系统会记录这次人工修改周末定期汇总所有人工修改记录逐条分析把高频修改写回规则库让智能体下次不要犯同样的错。这个过程有个非常强的正反馈拆单员发现自己只需要处理真正疑难的非标情况不用每天画图改孔位了而智能体因为在不断学习“人的否决”越跑越准。我管这个叫“人机协作的闭环反馈”是这套智能体方案里我认为最有价值的部分。4.5 现场问题速查表症状可能原因排查方法解决思路尺寸偶尔明显超常输入单位混乱/数值抽取错位检查中间态 JSON 的 unit 字段加强清洗管线统一毫米制异常值拦截门缝等间隙参数乱变模型幻觉查看 validate 阶段的报错日志增加数值范围约束后置校验器拦截多次对话后参数丢状态模型上下文过长/被覆盖检查订单状态表时间戳外部状态机兜底不依赖聊天历史五金数量与门宽不匹配知识库规则缺失查询 RULE 表中对应门宽区间补充规则库优先级人工复核回写拆单员频繁改同一参数规则库未覆盖该业务场景汇总人工修改记录 TOP N把高频修改转成新规则并回归测试上游图纸与输出参数左右镜像方位定义不明确检查输入里的左右视图约定强制“面向柜体正面”的定义并校验这张表是我在项目文档里常年更新的内容大部分“智能体犯的错”到最后都能追到规则缺失或者输入脏数据模型本身反而是最不容易背锅的一环。5. 如果想少走弯路我建议这么做5.1 别一上来就搞端到端全自动我见过不少团队立项的时候直接奔着“全屋定制全流程无人化”去结果项目组研究了三个月连一个柜子的拆单都没跑通。问题就在于他们把目标定义得太浪漫了。全屋定制里面量尺现场有太多不可预知的因素安装环节有太多现场调整中间还有水电交底、墙面找平这种传统人情世故——这些东西根本不适合一上来就自动化。我的建议是选一条最窄、最痛的链路先跑通比如只做“标准柜类的拆单参数生成”。范围不要大大了全是坑。一个标准柜定义成矩形柜体、常规铰链、无特殊造型、背板插槽式、常规抽屉滑轨。这条链路一旦跑顺积累了真实数据和规则库再慢慢扩展异形件、特殊五金、梁柱避让。步子大了容易扯着数据质量这是我在项目里最深的一次复盘。5.2 指标盯两个兜底留一条智能体上线之后汇报材料不要堆十个指标盯两个就够了拆单返工率衡量结果质量低于原来的五成才算有效益拆单时长衡量效率从“小时级”压缩到“分钟级”才是真改进这两个指标是业务方、管理层、研发团队都能听懂的共同语言。至于准确率、召回率、置信度这类算法指标内部自己看就行别拿出去汇报业务方听了只会觉得你在讲技术黑话。兜底那条一定要留人工复核。我宁愿人工干预率是 30%也不愿意强行压到 5% 结果出一次大事故。定制家具这个行业一次安装现场的返工代价远大于后台多花五分钟人工确认。智能体是用来帮人省心的不是用来替人担责的这一点在落地策略里一定要想透。5.3 落地节奏和团队配置的建议如果要按我的节奏来我会把项目分成三个阶段。第一阶段两个工程师加一个资深拆单员四周内只做“标准柜拆单参数生成 人工复核闭环”目标是把 100 单跑通第二阶段加一个前端/集成工程师两周接桥接中间件把拆单软件的 BOM 回流打通第三阶段才让业务团队全面铺开试点门店和工厂线这时候再上数据分析看返工率变化。人员上必须有至少一个“懂工艺又会测试”的人他负责把老师傅的脑子翻译成规则库里可执行的条目。这个角色往往是项目能不能活下来的关键。没有他模型再强也就是个漂亮的聊天机器人有了他智能体才是真正懂得“见光面要封边、抽屉轨道别打架”的行家。我最后想多说一句这套做法的本质不是把 AI 当成热词去包装而是花三个月时间把老师傅脑子里那套没法言说的手艺一点点磨成可以被校验、被测试、被传承的系统知识。我个人的体会是智能体最大的价值不是替代谁而是让那些藏在老师傅手里的经验终于有机会变成工厂资产。只要照着这个思路走不管模型参数怎么迭代、框架怎么换你都站在了一个不会被淘汰的位置上。