AI能改变家装行业吗?(一):项目状态,怎样被系统持续理解?家装企业并不是不知道项目状态的重要性。今天稍具规模的装企，通常已经有ERP、施工管理、供应链、验收等系统，项目经理也会上传进度、照片、日志和整改记录。一些数字化工具还能汇总项目群、现场记录和系统数据。但这些系统有一个共同的不足：现实中发生的变化往往无法被及时、完整、准确地捕捉并同步到系统中。现场已经完工，系统里的节点可能还没有更新；材料已经延期，供应链系统知道，施工计划却未必同步变化；客户在群里提出新的要求，这条信息可能还停留在聊天记录里；验收、整改、施工进度分别存在不同系统中，最终仍需要把它们拼在一起，才能判断“这个项目现在怎么样”。AI工具带来的新变化，可能能够弥合这个裂缝。大模型开始可以直接读取过去主要供人阅读的照片、视频、语音和聊天记录，也可以通过工具调用连接企业已有系统。这意味着，过去由项目经理承担的大量“看、听、找、核对、综合判断”，其中一部分开始有可能由机器接手。虽然每家装企的节点划分、状态定义和管理规则都不同，不存在一套统一的“家装AI状态模型”，但企业可以自己梳理：每个节点有哪些状态，以及每种状态成立需要满足哪些具体条件。然后把这些条件逐项拆解出来，分别判断它们依赖的是系统数据、现场视觉信息、语言信息还是专业规则，再据此选择是走API、VLM、LLM、Skill、Workflow、规则系统还是人工判断。
一、系统已经知道的事实，直接取
签收、验收、整改、正式变更等信息，只要已经形成系统记录，就没有必要再经过一次模型判断。最直接的办法，是从ERP、供应链、工程管理或客户系统中通过API、数据库查询或系统集成取得。比如一家企业规定，水电节点进入“完工”之前，所有整改项必须关闭。整改系统已经显示未关闭，这个条件就有了明确答案。再把整改照片交给大模型重新判断一次，不但多此一举，还会增加不确定性。一个节点成立所需要的信息往往散在几个系统里，因此这部分虽然谈不上多少“AI含量”，却很重要。系统里的确定数据没有先接起来，后面的视觉识别和语言理解做得再好，也很容易重新形成新的信息孤岛。AI更适合补那些传统系统原来无法直接读取和理解的信息，而不是重新判断系统已经确认过的事实。二、现场可观察的事实，要看VLM够不够
水电、防水、泥瓦、木作、涂饰、主材安装，大量状态条件最终都要落实到现场：一道工序是否已经开始，某一区域是否施工，某种材料或构件是否出现，有没有明显异常。这些内容适合交给视觉语言模型，也就是VLM。但同样是“看照片”，不同任务需要的技术深度相差很大。工程负责人偶尔收到一张照片，只想知道这里大概在做什么、有没有明显问题，这种低频、开放、结果最后仍由人阅读的任务，通用VLM通常已经够用。到了每天几十个项目反复处理同类施工照片时，性质就变了。以防水为例，企业可能长期只需要判断：拍摄的是哪个空间，是否已经施工，指定区域有没有覆盖，有没有明显漏刷、开裂或起鼓，这组影像是否足以支持判断。Prompt更多解决一次性的提问；Skill则要考虑这件事以后是不是要反复、稳定地做。进入企业流程以后，输入范围、检查项目和输出结构都应该相对固定，还需要保留证据来源，明确什么情况下必须回答“无法确认”，并能够持续统计准确率和错误类型。这样，同一个VLM才从一次性的图片问答，变成可以反复调用和持续改进的业务能力。视觉模型的边界也很清楚。防水照片里没有看到裂缝，只能说明画面中没有看到，不能证明整个卫生间没有问题；最终完工照片无法证明此前规定的施工步骤都发生过；泥瓦验收要求毫米级平整度时，也不应该靠普通VLM目测。因此，视觉AI首先适合做的是把可见事实提取出来。完整性要靠拍摄范围、角度或巡场路径保证，精确尺寸则交给测量工具。它能不能承担更多工作，还要看企业自己的真实数据。无论直接调用VLM，还是已经做成视觉Skill，都应该先拿企业历史照片和视频试跑。真实工地的光线、遮挡、拍摄角度、材料和施工方式都有自己的特点，公开Benchmark上的表现不能直接等同于它在某家装企里的实际识别能力。比较稳妥的办法，是先拿一批已经有人工答案的数据建立Baseline。效果不好时先找原因：关键区域没有拍到，应该调整采集；任务定义太宽，就继续拆；缺少空间、上一节点等背景信息，就补上下文。任务已经足够窄、输入也比较稳定，通用模型却仍然持续在同一种问题上犯错，而且企业已经积累了足够可靠的标注数据，这时微调才值得进入比较。Skill和微调解决的也不是同一个问题：前者把任务做稳定，后者是在任务已经定义清楚之后，进一步改善模型本身仍然存在的能力短板。三、语言里的事实，要区分LLM和Skill
“主卫今天做完了。”“这个位置客户让先不要动。”“瓷砖明天下午才能到。”“今天验收还有两个地方要整改。”这些话过去不是没有价值，而是很难自动进入系统。项目经理看到或听到以后，还要自己判断哪些事情会影响项目，再决定是否更新状态。LLM首先降低的是“读这些信息”的成本。临时问一句“总结一下今天项目群发生了什么”，属于开放、低频、最后给人阅读的任务，直接使用LLM即可。企业每天都要从大量项目群中持续寻找新增需求、暂停施工、明确确认、异常、返工和长期未关闭事项，情况就不同了——它已经变成一项固定业务工作。企业可以规定它只识别有限几类事件，每条事件必须返回涉及哪个项目、哪个空间或节点、谁提出、发生了什么、确认状态是什么，同时保留原始证据。LLM不再只是“总结聊天”，而是在执行一个边界明确的业务任务。高频只是一个信号。结果要被ERP或其他系统继续读取、输出格式需要稳定、错误类型需要长期跟踪、必须保留原始证据，或者需要调用企业其他系统，都会让Skill的必要性明显增加。比如项目群里有人说“瓷砖还没到”。LLM可以识别出“材料可能延期”，但企业准备据此调整项目状态时，不能只依赖一句聊天，还要去供应链里核对订单、配送和签收情况。这时，一个语言Skill实际上已经开始调用企业内部的Tool或API。语言任务也要用企业自己的数据测试。家装群聊高度口语化，简称、行业用语、指代和省略都很多。客户的一句“可以”“再看看”“那就这样吧”，在不同语境下可能代表完全不同的业务含义。识别效果不好时，先检查业务分类和上下文是否合理。与其逼模型判断“确认”还是“未确认”，有时不如允许它区分“明确确认、倾向接受、明确拒绝、无法判断”。一个稳定、重复的任务经过这些调整仍然存在持续的识别错误，再考虑微调模型。四、能够量化的条件，先把数字拿准
家装施工和验收中，还有相当一部分条件本质上就是数字，比如长度、垂直度、压力、含水率、坡度、高差。最终只是判断某个数值有没有达到企业规定的范围时，路径通常很简单：测量工具先取得数值，再由普通程序按规则判断。设备能联网就直接取数，不能联网可以人工录入，只有仪表照片时再考虑OCR或视觉模型辅助读数。水电压力测试、泥瓦平整度都属于这一类。数字已经拿到，是否达标通常不需要再经过LLM推理。对企业来说，重要的是事实取得得够不够准、成本够不够低，而不是让更多环节出现大模型。五、需要证明历史过程，关键不是模型，而是Workflow
还有一些条件关注的并非“现在看起来如何”，而是此前要求的过程到底有没有完整发生。防水和隐蔽水电都是典型场景。最终照片再清晰，也无法证明前面的每一道工序都已经执行；一旦隐蔽工程封闭，有些信息甚至再也无法恢复。这时候继续提升VLM能力意义不大，真正需要解决的是过程留证和Workflow。企业要规定什么动作发生以后必须留下什么证据，步骤之间是什么顺序，缺少证据能不能继续，以及什么时候才能进入下一阶段。比如某家企业的防水流程要求不同施工步骤分别留证，之后才能进入闭水和验收。视觉Skill可以识别照片里“看到了什么”，但无法保证这些证据是在正确时间、按照正确顺序产生的，这要由Workflow约束。Skill、Workflow和状态机容易混在一起，但解决的问题其实不同。Skill处理某一个具体任务怎样稳定执行；Workflow管这些任务和证据如何前后衔接；状态机则负责维护节点当前处于施工、待验收、整改还是完成，以及什么情况下可以从一个状态进入另一个状态。比如防水Workflow可以负责采集影像、调用视觉Skill、记录时间并触发下一步，状态机则只根据企业规则维护节点状态。把这几层分开，系统反而更容易解释。六、需要专业经验的条件，AI先帮助人判断
还有一些条件，即使证据已经齐全，也很难靠简单规则裁决。它可能同时涉及现场情况、材料特性、历史整改和施工经验。这时候，大模型未必要直接给最终结论。更现实的用法，是先把判断前的信息工作接过去：找相关照片、调施工记录、汇总历史整改、提取客户沟通，把材料信息和企业规范整理到一起，再交给专业人员。遇到少见材料、特殊基层或非常规施工条件，可以再通过RAG查询企业SOP、材料说明或专业资料。每天反复执行的固定标准则没必要每次重新检索，直接写进程序更清楚。RAG更适合处理长尾知识，而不是直接判断项目状态。至于那些即使信息齐全仍然高度依赖经验的部分，继续留给人即可。AI能把原来二十分钟的翻记录、找照片、查资料压缩到几分钟，已经有价值。七、所有条件确认以后，才真正形成节点状态
前面的API、VLM、LLM、Skill、测量工具、Workflow、RAG以及微调模型，都还没有直接回答“这个节点现在是什么状态”。它们解决的是更小的问题：构成这个状态的各项条件，到底成立没有。比如水电“完工”需要多个条件，其中可能既有系统数据，也有现场影像、测量结果和整改记录。逐项确认以后，系统得到的也许是：A成立，B成立，C不成立，D暂时无法确认。这时候再由企业自己的业务规则决定，是继续停留在原状态，转入整改，还是允许进入完工。对于企业已经明确规定的状态迁移，没有必要再让大模型自由做一次综合判断。模型负责理解非结构化信息，规则负责执行已经确定的业务逻辑。这样还有一个现实好处：出了问题能够往回追。是视觉模型看错了，语言Skill抽取错了，数据接口有问题，Workflow漏了证据，还是状态规则本身需要修改，企业能够找到具体原因，而不是面对一个无法解释的黑盒答案。真正做这件事时，企业不妨从自己的节点和状态条件开始，一项项往下追：这个条件靠什么证据证明，证据现在在哪里，今天是谁在判断，机器能不能接；接不住时，问题究竟出在数据、任务定义、上下文，还是模型本身。这些问题弄清以后，需要API、VLM、LLM、Skill、Workflow、RAG还是微调，反而不会那么难判断。
夜雨聆风