搭贝官方 · 对比实测

先交代背景。这家酒店挂着四星的牌子，二百二十间客房，开业第八年。

设备这八年攒出了一身毛病：空调、热水、电梯、门锁、照明、水泵——全店的设备台账记在工程部办公室的一本硬皮本上；报修靠前台和对讲机——客房发现故障，前台打电话给工程部，工程部派单靠喊，修完了在本子上记一笔。

漏单是常事：旺季一天几十个报修电话，值班工程师接不过来，总有几个沉在对讲机的嘈杂里；更麻烦的是无主的故障——走廊的灯坏了两周没人报，因为「不知道归谁管」。工程部经理老盛拿着这本台账熬了八年，一直想上系统。

问系统的事，前前后后问了三家软件公司。第一家的答复最典型：设备报修属于半定制需求——酒店的行业属性强，报修流程要贴合工程部的排班和巡检，标准产品套不进去，评估下来工期半年，报价六位数起步。

第二家便宜些，但要求酒店先梳理一份完整的需求文档——「先把流程画清楚，再谈评估」。第三家是做酒店集团化的，产品很全，但人家不接单店。老盛的结论是：系统这事，再等等。

等到今年旺季前，事情有了变化。酒店换了位年轻的客房部主管，听老盛念叨过系统的事，提了一句：现在 AI 能自动生成管理系统，您试试？

老盛起初不信——评估都要两个月的活，一句话能于得了？半信半疑打开搭贝，用一句他念叨了八年的话开了头：「给工程部做个设备报修系统」。

AI 先给出方案说明：设备怎么建档、报修怎么提单、工单怎么派、修完怎么验收，逐条列出。老盛核出两处口径差。

第一处：方案默认报修单由报修人填写故障描述，实际酒店的现实是——故障描述十有八九不准确，「空调坏了」可能是遥控器没电——工程部真正需要的是报修人拍照加定位，描述让师傅到了现场自己判断，改。

第二处：方案默认工单按「先报先修」排序，实际工程部有优先级惯例——影响客人的优先（客房空调、热水）、影响安全的更优先（门锁、电梯）、公共区域靠后，改：按影响面分三级。两处当场改完，点确认。

接着 AI 问了引导问题

①问：工程部的组织管理范围是怎样的？ 答：单一项目或厂区，统一集中管理

②问：系统中主要涉及哪些角色参与协作？ 答：普通员工（负责提交报修）、调度员 / 主管（负责审核与派单）、维修工程师（负责接单与处理）

③问：报修工单的派发方式倾向于哪种？ 答：由调度员人工审核后指派给具体人员

④问：除了报修流程，还需要管理哪些基础数据？ 答：设备台账（编号、位置、型号等基础信息）

生成总览：

角色

①普通员工：发现设备故障提交报修申请，查看个人工单进度，对维修结果进行评价，可操作报修申请单

②调度员 / 主管：审核报修申请合理性，按工程师状态人工指派工单，监控整体维修进度，可操作设备台账、维修记录表、工程师档案、报修申请单，查看运维总览、工程师绩效、设备健康度看板

③维修工程师：接收指派维修任务，现场维修处理，填写维修耗时、更换配件及处理结果，上传完工照片，可操作维修执行单、配件库存表、报修申请单，查看工程师绩效看板

表单

①设备台账：存储厂区所有设备的基础信息，作为报修关联基础数据

②配件库存表：管理维修常用配件库存数量，支持预警与领用

③工程师档案：维护维修人员基本信息与技能标签，用于工单调度

④报修申请单：记录员工发起的报修请求，触发审核派单流程

⑤维修执行单：记录工程师维修作业细节，关联工单与配件消耗

⑥维修记录表：归档历史维修数据，用于统计设备故障率与维修成本

工作流

报修申请流程：普通员工发起报修提交，调度员审核派单；审核通过流程结束，审核拒绝退回发起报修节点

加数据看板和业务规则、AI智能体

一处小瑕疵：设备档案默认带「采购合同编号」字段——保修信息已经记了厂家和期限，合同编号属重复记账，老盛说了一句「设备档案去掉采购合同编号」，当天删除。

当晚验收，拿真实报修走单：一间客房的电视黑屏，前台拍照提单，系统按「客人级」自动派给当班师傅，师傅不久就反馈「机顶盒故障，已换新」，前台确认关闭——这一单，从前台提单到系统关闭，全程对讲机只响了一声（通知师傅接单）。

老盛看着看板说了一句话：「八年攒下的糊涂账，一句话理清了。」

一、软件公司评估的两个月，时间花在哪

先替软件公司说句公道话：半年不是怠工，是那套工序的固有长度。

拆开一份典型的设备报修项目评估：需求调研一月，流程梳理加文档一周，原型评审一到两月（酒店方要拉齐工程部、客房部、前厅部三个部门的人），开发三到四月，测试一周，部署培训一月——半年还是紧凑的。

问题不在每一步的长度，在这套工序为谁设计：它为「需求说不清楚」的场景设计，用文档和评审把模糊的东西钉死——而钉死的过程，每一步都要等人。

三个部门拉齐评审这件事，老盛深有体会——第一家公司约评审会就约了三周，工程部有空的那周客房部忙，客房部有空的那周前厅部忙，等三部门都空了，软件公司的顾问又在另一个项目上。

这不是谁的错，是「文档确认」这条流水线的固有成本：它按人天计，不按事计。

二、AI 这边的一天，是怎么用的

生成路径把那两个月里的环节全换了：需求文档换成一句话，流程评审换成方案说明当场核对，口径确认换成三个引导问题——老盛那个「白天」的用法是这样的：上午提需求、核方案，中午答完三个问题，下午系统生成完，晚上拿真实报修验收。

一天里的每一步都是「对事」，没有一步在「等人」。

有人会说：那半年里软件公司做的需求梳理，AI 这边没做，是不是漏了？没漏——搬到了方案说明和引导问题里做。

老盛核方案时的两处修改（拍照定位替描述、三级优先级），就是需求梳理的实质内容；三个引导问题（夜间急修、修不好升级、巡检进系统），就是流程评审的实质内容。

工序没有被跳过，是被压缩进了对话里——两个月的「梳理加评审」，对齐的是同样的口径，花的时间是几句话。

三、两条路交出的东西，差在哪

这张表里最值得看的不是时间列，是最后一行：软件公司的半年里，包含着对接门禁、楼宇自控这类硬件联动的空间；生成路径的边界在标准业务——设备报修、工单流转、巡检记录，这些它当天交货。

这家酒店后面如果想把电梯的物联网告警直接接进报修系统，依然要找软件公司——两条路是分工，不是替代。

四、一个半月后回看：快会不会糙

系统上线一个半月，工程部的变化是实打实的。

漏单清零——每个报修单在系统里有主、有状态、有时间戳，沉不掉；「无主故障」绝迹——公共区域的故障现在由巡检工单兜底，到点自动生成，不用等谁发现；

响应速度从「对讲机喊人」变成「系统派单」，客人级的报修平均响应时间缩短一半多；设备档案第一次实现了全量电子化，八年的硬皮本光荣退役。

老盛还用看板发现了两件过去看不见的事：三楼的热水器报修频次是其他楼层的两倍——设备该换了；维修师傅的工单量分布不均——排班调了一次。这些发现比系统本身更值钱：系统把故障记录下来，看板把问题亮出来，管理者才能把决策做对。

三处对话式修改：工单增加「客人赔付关联」字段（客房损坏追责用）、巡检从周巡加密到旺季日巡、看板增加了「厂家保修期内工单」的单独视图——三处都是一句话发起，当天生效。

五、这条路径的边界，也要说清

设备报修这类「东西、流程、经手人」说得清的业务，是生成路径的主场；老盛的下一步设想——电梯物联网告警自动接入、客房门锁的联网巡检——涉及硬件对接，生成路径不接，仍要软件公司。

还有一点：AI 生成的系统替代的是「工单流转」这个管理层，替代不了「维修」这个专业层——师傅的手艺、厂家的大修，系统管不了。边界之内，当天交货；边界之外，各有各的路径——这是这家酒店教给同行最清醒的一课。

常见问题