1. 需求拆解报修消息背后真正的痛点先说个我自己的经历。我家小区业主群有四百多号人平时聊天内容基本是“今天谁家狗又咬了人”“楼下广场舞声音太大”“电梯又坏了”。其中最频繁、最紧急的就是电梯报修。电梯这个东西一旦出问题就是大事有时候是困人有时候是按键失灵有时候是门关不上。但问题在于业主群里报修的方式非常随意有人发一段语音有人拍个视频有人就丢一句“三栋电梯又坏了”连具体是哪部电梯、什么故障都不说。我去翻了翻物业那边的记录发现一个很尴尬的事实很多业主在群里报修之后物业管家并没有第一时间看到。等看到的时候可能已经过去了半小时甚至一小时。更麻烦的是消息一多就被刷上去了管家不可能一直盯着群。后来我就在想能不能把这件事做成一个自动化的流程业主在群里发报修系统自动识别、自动分类、自动提醒物业、自动记录到台账里最后把全小区的电梯报修情况汇总到一块实时看板上。这就是“用 WorkBuddy 把业主群里的电梯报修变成一块实时数据看板”这个标题的来源。先解释一下 WorkBuddy 是什么。它是腾讯推出的一款效率智能体工作台核心能力是让用户通过自然语言创建自动化流程、接入各类数据源、调用大模型能力来完成复杂任务。通俗点说你可以把它理解成一个“私人数字员工”你告诉它干什么、怎么干它就能按照你的指令去执行。像本项目里WorkBuddy 承担了从业主群里提取报修信息、解析故障类型、生成结构化记录、更新看板数据这一整套流程的“大脑”和“调度员”角色。这块看板给谁看三类人。第一类是物业经理他需要知道每部电梯一天报修几次、集中在哪栋楼、响应是否及时。第二类是工程维修人员他需要知道当前有几张待处理工单、优先处理哪一部。第三类是业主代表或者业委会他们要监督物业是否真的在处理问题。所以这块看板不能只展示“今天有5条报修”而是要能够回答“哪部电梯最频繁出问题”“平均响应时间是多少”“当前有几部电梯处于停梯状态”这些具体问题。2. 整体设计与工具选型思考2.1 为什么选 WorkBuddy 而不是纯写代码一开始我确实想过自己写一套脚本用 Python 接一个微信机器人再配合数据库和看板工具。但真正动手之前我盘算了一下工作量要处理微信消息的接收、解析非结构化文本、维护运维环境、处理异常情况。这些工作加起来至少要两三天而且后续每次业主说话方式变了我都要去改代码。说白了用传统开发方式做这件事成本太高、维护太重。WorkBuddy 这类智能体平台解决的核心问题是把“解析文本”和“编排流程”这两件最折腾的事情变成了配置项。它底层已经接好了大模型你只需要把业主的原始消息丢给它告诉它“帮我提取楼栋、电梯编号、故障类型、报修人”它就能输出结构化的结果。这一点非常关键因为业主的表达方式千奇百怪“3栋电梯门关不上了”和“三栋二单元货梯坏了人在里面”是完全不同的句式但都需要被正确解析。还有一个重要的考量是交付速度。用 WorkBuddy我可以在一个小时内搭出第一版原型先跑通“从消息到数据”这条链路后面再逐步优化。如果你所在的小区没有物业群机器人这类现成工具这种“智能体看板”的组合是目前成本最低、见效最快的方案。2.2 技术链路拆解采集-解析-入库-呈现整个方案可以分成四段。第一段是采集把业主群里的报修消息变成可处理的文本。第二段是解析利用大模型从文本中提取结构化字段。第三段是入库把解析后的结果写入数据表或者多维表格。第四段是呈现通过看板把数据可视化。这四段里最容易卡住的是第一段。因为微信本身没有一个公开、稳定的接口去读取群消息而我们也不可能要求业主“报修请填写表单”。我在实际方案里用的是折中策略第一版采用“物业管家转发/手动输入”的方式管家看到报修后把消息复制给 WorkBuddy 的机器人由它完成解析和记录。这里不是不能做到全自动而是要考虑合规性和稳定性。如果你使用的是企业微信或者园区自研的 APP那可以直接接入 Webhook 实现全自动抓取。但对于普通住宅小区先手动转发跑通要比纠结全自动更实际。第二段到第四段是 WorkBuddy 的主场。解析依靠大模型能力入库可以接飞书多维表格、腾讯文档或者 Excel呈现可以用数据看板。具体到自己配置的时候不需要懂得怎么写复杂的 SQL只要把字段和规则定义清楚。2.3 第一版别追求全自动先跑通数据闭环这里我想特别强调一个经验做类似的项目第一版千万不要追求全自动。原因很简单自动化程度越高涉及的环节越多出问题的概率也就越高。如果一开始就想着全自动监听微信群你可能先得解决登录、防封、消息格式不稳定的一堆问题最终项目可能就腰折了。我的建议是分三步走。第一步先让 WorkBuddy 把“手动输入的报修消息”正确解析成结构化字段并写入表格。第二步给物业管家做一个简单的“表单模板”让他们把消息复制进来的时候带上固定格式比如“【电梯报修】3栋2单元货梯门关不上有人被困”这样解析准确率会大幅提升。第三步等前两步运行稳定了再考虑接入自动采集渠道。这样每一步都有明确产出也方便中途调整。3. 核心细节从一条闲聊消息到一条结构化工单3.1 让智能体“看懂”业主的电梯报修业主报修的消息质量参差不齐这是整个方案里最大的难点。我总结下来大概有几类典型表达按电梯位置描述“三栋二单元的电梯坏了”“1栋货梯按键没反应”按故障现象描述“有人被困在电梯里了”“电梯门一直开关”“坐到一半突然停了”“显示超载但里面没人”按情绪描述“这电梯三天两头坏到底修不修”“物业能不能干点事”如果让普通人来读后者也能判断出是电梯报修但里面缺少关键字段比如楼栋号、电梯编号不明确。所以 WorkBuddy 的解析规则必须考虑“缺失值”的情况。我的做法是强制要求输出 JSON 格式的字段字段包括building楼栋、unit单元、elevator_type客梯/货梯、fault_type故障类型、severity紧急程度、description原文描述、reporter报修人。如果原文里没有提到某个字段就标记为“未明确”而不是乱猜。具体配置的时候要利用 WorkBuddy 的自定义指令功能给它一段清晰的 prompt 说明。这段 prompt 是项目的灵魂我可以把当时写的核心部分摘出来供你参考你是小区电梯报修信息解析助手。你的任务是从业主报修消息中提取结构化信息输出 JSON 格式字段如下 - building楼栋号如3栋如果原文没有提到输出未明确 - unit单元号如2单元如果没有输出未明确 - elevator_type客梯/货梯/未知 - fault_type困人、门故障、按键故障、异响、运行异常、其他 - severity紧急程度分三档。有人被困为紧急影响正常使用但无危险为中其余为低 - description对故障现象进行简洁转述去掉情绪化词语 - reporter报修人姓名或昵称如果有的话 注意 1. 提取信息时不要凭空补充原文中没有的信息。 2. 如果一条消息包含多部电梯的报修拆分成多条记录。 3. 对业主的情绪化表达保持克制只提取事实。 4. 只处理电梯报修相关内容如果是其他诉求输出 {skip: true}。这里有两个细节特别值得说。第一是 “如果一条消息包含多部电梯的报修拆分成多条记录”。因为一个业主很可能在群里连续发消息说“2栋客梯坏了另外3栋货梯也有异响”如果不做拆分数据统计就会出错。第二是 “其他诉求输出 skip true”因为业主群里太多非报修消息了必须让智能体学会“拒绝”。3.2 看板的计算口径怎么定义如果只是把报修消息记录成表格那就还差一步。看板要能回答管理问题就必须有清晰的指标口径。我第一期定义了四个指标当日报修总数统计自然日内所有电梯报修工单数量。待处理工单数状态为“待派单”“维修中”的工单数量。平均响应时长从报修时间到物业确认受理时间的时间差平均值。高频故障电梯 TOP5按楼栋和电梯编号分组统计近 7 天报修次数。看板里的每一个数字背后都需要一个“状态”字段做支撑。我在表格里加了一个流程状态字段取值为新提交 → 已派单 → 维修中 → 已恢复 → 已关闭。WorkBuddy 在其中扮演的角色不只是提交时写入它还可以通过定时任务去自动更新状态。比如每隔 10 分钟检查一次所有“维修中”的工单如果当前时间距离派单时间已经超过 2 小时就自动标注为“超时”。看板选型上不用太纠结只要能接入表格数据源自带图表展示和筛选功能就行。我当时选用多维表格自带的仪表盘因为它直接可以从数据表生成图表而且支持按日期、按楼栋筛选不需要额外维护一套可视化服务。如果你本地有 Grafana 这类工具也可以把数据写到数据库中再呈现但对小区物业场景来说太重了完全没必要。3.3 一套可复用的事件分流逻辑电梯报修只是小区里一类典型事件。实际上业主群里还会有水管爆裂、停电、门禁损坏、噪音投诉等。从产品化的角度看我会建议把整个智能体设计成可复用的事件分流体系而不是一个只能处理电梯报修的“专属工具”。我实际的做法是在 WorkBuddy 里先做一个“事件分类器”作为入口。不管业主发来什么消息先判断事件类型是电梯报修就走电梯流程是水管爆裂就走紧急维修流程是投诉就走投诉流程。这样做的好处是后续如果物业想把其他设备也接入看板不需要另起炉灶只要扩展分类类型和字段模板就行。这也是为什么 WorkBuddy 这种智能体工作台比传统表单工具更灵活的地方你不需要预先设计好所有场景的字段而是可以用自然语言定义新场景大模型会自己理解字段之间的映射关系。对非技术背景的物业管理人员来说这个学习成本确实低很多。4. 实操过程四步搭出第一版实时看板4.1 第一步创建智能体与技能配置打开 WorkBuddy 客户端先创建一个新项目项目名称就叫“小区物业报修看板”。然后在项目里新建一个技能或者指令名称可以用“报修解析器”。不同版本的 WorkBuddy 界面可能叫“技能”“指令”或者“Agent”但原理是一样的给它一个名字、一段描述、一段处理逻辑的 prompt以及输出格式的定义。技能配置界面里除了刚才那段解析 prompt还需要设置输入变量和输出结构。输入变量就是待解析的消息文本输出结构我设置为 JSON Object。这里建议先把输出格式在 prompt 里用明确的示例写死不要只靠 JSON Schema因为大模型对例子的理解往往比对规则的理解更准确。我在 prompt 后面加了一个 few-shot 示例示例输入 “3栋的电梯又坏了关不上门半天没人管物业出来走两步” 示例输出 {building: 3栋, unit: 未明确, elevator_type: 未知, fault_type: 门故障, severity: 中, description: 3栋电梯门关不上, reporter: 未明确, skip: false}配置完技能之后最好先在 WorkBuddy 自带的调试窗口里测试几轮。把业主群里真实的报修消息粘贴进去看看解析结果是否准确。我当时测了 20 条真实消息第一版准确率大约 85%剩下的主要问题出在“住宅楼栋表述多样”上比如“三栋”“3栋”“三号楼”“3号楼”没有归一化。解决办法是在 prompt 里加一条规则把所有含“栋”“号楼”的地址统一按照“X栋”输出。4.2 第二步打通数据入口和数据存储调试通过之后下一步就是让智能体的输出落到一个可以持续累积的数据表里。WorkBuddy 支持多种数据连接器最省事的方式是接到腾讯文档表格、飞书多维表格或者你也可以接入本地数据库。考虑到物业同事不一定习惯看代码我当时选择了多维表格因为它的权限管理、公式字段和仪表盘比较成熟。具体接入方法和 WorkBuddy 版本相关但大体逻辑是在连接器里新建一个数据源配置填上表格的访问凭据和应用 ID然后在技能配置的“执行动作”里选择“写入数据表”并把解析后的 JSON 字段一一映射到表格的列上。映射的时候要注意多维表格的列类型要预先设置好比如“报修时间”是日期时间类型“紧急程度”是单选类型不然写入的时候会报类型不匹配的错误。另外一个值得提前规避的坑是数据表字段的命名。WorkBuddy 会说中文但建议你在数据表里还是用英文或者拼音字段名比如building、unit、fault_type再在表格里单独加一个“显示名称”列通过公式或者设置别名展示成中文。否则后续如果你的数据要接第三方工具中文列名很容易遇到字符集问题。4.3 第三步编写状态更新逻辑与定时任务光有数据写入还不够一块“实时”看板意味着数据要能动起来。我在 WorkBuddy 里配置了三个定时任务频率都是每 10 分钟执行一次。第一个任务叫“超时检测”逻辑是查询所有状态为“已派单”且派单时间超过 30 分钟的工单把状态改为“派单超时”并且给运营人员的微信发送一条提醒。第二个任务叫“夜间降噪”逻辑是在晚上 10 点到早上 8 点之间把新产生的报修消息推送到物业值班人员的手机而不是工作群避免打扰。第三个任务叫“日报汇总”逻辑是每天早晚各一次把最近 12 小时的报修数据汇总成一段文字报告。定时任务配置本身不复杂关键是要利用好 WorkBuddy 的“条件执行”能力。比如“夜间降噪”这个任务的触发条件要设置时间范围和时间段判断这些在智能体编排面板里都有对应的节点不需要写代码。你需要想清楚的只是业务规则什么情况算紧急、什么时间段需要通知谁、多久没有响应需要升级这些才是真正体现项目价值的地方。4.4 第四步建看板并做验收测试数据表和定时任务就绪后最后一步就是看板。多维表格仪表盘的做法很简单新建仪表盘视图添加“报修总数”“待处理工单数”“平均响应时长”“高频故障电梯 TOP5”这几个图表组件数据源分别指向数据表的对应字段。这里有个细节必须提醒统计“平均响应时长”时如果表格里有空的“确认受理时间”要先把这些工单过滤掉或者把空值默认计为“当前时间”。否则平均值会被 null 值弄乱看板上的数据看上去很怪。我当时在这个问题上纠结了很久最后是在公式字段里写了IF(ISBLANK({确认受理时间}), NOW() - {报修时间}, {确认受理时间} - {报修时间})才解决。验收测试我建议分三批数据来测。第一批用历史真实数据把前两周的报修消息导入进去看统计结果是否与实际情况吻合。第二批用模拟数据造一些极端情况比如同一条消息带两起报修、接连报修同一部电梯、非电梯类投诉等看看系统能否正确处理。第三批是试运行连续跑三天每天看日志确认没有明显的报错或者数据丢失。5. 常见问题与排查技巧实录我在做这个项目的过程中踩了不少坑整理成一张问题速查表你可以直接拿去对照。问题现象可能原因排查方法智能体把非报修消息也解析成工单prompt 里的 skip 规则不够强在 prompt 中增加“仅当消息与电梯设备故障有关时才输出记录其余一律 skiptrue”的强约束并在测试集中加入 10 条以上非报修样本同一条消息包含两个报修只生成一条记录未指定拆分逻辑在 prompt 中明确写明“若包含多部电梯/多个故障拆分为多条 JSON 输出”输出结构改成数组楼栋号不统一3栋/3号楼/三栋缺少归一化规则在 prompt 中规定“输出楼栋统一为阿拉伯数字X栋”并在技能里加一个全局替换节点定时任务不执行网络或权限问题查看 WorkBuddy 运行日志确认数据源授权是否过期确认定时任务的触发时间是否写错看板数据不更新数据表连接断连或字段映射错误先在数据源里执行一次“测试读写”确认能够正常写入一行模拟数据平均响应时长计算出负值确认受理时间早于报修时间检查是否有手动补录的数据时间字段的时区设置是否一致除了这些能明确排查的问题还有一个比较隐蔽的“坑”是模型对紧急程度的判断。大模型对“人在电梯里面”这种描述会非常敏感这当然是好事但它也容易矫枉过正把“电梯里味道很大”这种描述判断成“紧急”。我的对策是在 prompt 里明确“紧急”的判定标准只有出现“被困”“卡住”“坠落”“剧烈晃动”等关键词或者有明确人员被困的描述时才判定为紧急。另外还要提醒一点如果你把 WorkBuddy 部署在公司电脑上而且遇到日志里反复出现任务执行中断的情况多半是代理或者网络策略拦截了访问。可以检查一下任务执行的环境是否有外网访问限制或者 WorkBuddy 客户端是否有独立的网络访问开关。这类问题在局域网办公环境里特别常见排查方向是先看日志报错码再确认网络白名单。关于数据安全我再多说一句。业主群里报修消息会包含微信群昵称、有时候还会有电话号码这类信息属于个人信息。在项目上线前建议把报修人字段做脱敏处理比如只保留姓氏和手机尾号或者直接设置成“业主”两个字的匿名标识。同时不要向看板访客开放原始消息内容的查看权限这样能有效避免个人信息泄露的风险。从落地效果看这个项目上线后的两周内物业对电梯报修的平均响应时间从原先的大约 40 分钟缩短到了 15 分钟以内。管家每天不用再人工翻聊天记录去登记台账工程维修人员也能通过手机查看待处理工单列表。更直观的变化是业委会开例会的时候终于不用再靠截图争论“到底哪部电梯坏了多少次”直接打开看板投屏数据一目了然。就我个人经验来说做这类项目最关键的其实不是技术多复杂而是要理解一个朴素的道理工具是为流程服务的。WorkBuddy 给了你一个快速搭建自动化流程的能力但真正决定项目成败的是你对报修流程的理解、对字段口径的定义、对异常情况的预判。把业务想清楚剩下的配置工作反而很快。这也是我从这个项目里收获最大的地方。