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 中增加“仅当消息与电梯设备故障有关时才输出记录，其余一律 skip=true”的强约束，并在测试集中加入 10 条以上非报修样本 |
| 同一条消息包含两个报修只生成一条记录 | 未指定拆分逻辑 | 在 prompt 中明确写明“若包含多部电梯/多个故障，拆分为多条 JSON 输出”，输出结构改成数组 |
| 楼栋号不统一（3栋/3号楼/三栋） | 缺少归一化规则 | 在 prompt 中规定“输出楼栋统一为阿拉伯数字+X栋”，并在技能里加一个全局替换节点 |
| 定时任务不执行 | 网络或权限问题 | 查看 WorkBuddy 运行日志，确认数据源授权是否过期，确认定时任务的触发时间是否写错 |
| 看板数据不更新 | 数据表连接断连或字段映射错误 | 先在数据源里执行一次“测试读写”，确认能够正常写入一行模拟数据 |
| 平均响应时长计算出负值 | 确认受理时间早于报修时间 | 检查是否有手动补录的数据，时间字段的时区设置是否一致 |
除了这些能明确排查的问题，还有一个比较隐蔽的“坑”是模型对紧急程度的判断。大模型对“人在电梯里面”这种描述会非常敏感，这当然是好事；但它也容易矫枉过正，把“电梯里味道很大”这种描述判断成“紧急”。我的对策是在 prompt 里明确“紧急”的判定标准：只有出现“被困”“卡住”“坠落”“剧烈晃动”等关键词，或者有明确人员被困的描述时，才判定为紧急。
另外还要提醒一点，如果你把 WorkBuddy 部署在公司电脑上，而且遇到日志里反复出现任务执行中断的情况，多半是代理或者网络策略拦截了访问。可以检查一下任务执行的环境是否有外网访问限制，或者 WorkBuddy 客户端是否有独立的网络访问开关。这类问题在局域网办公环境里特别常见，排查方向是先看日志报错码，再确认网络白名单。
关于数据安全，我再多说一句。业主群里报修消息会包含微信群昵称、有时候还会有电话号码，这类信息属于个人信息。在项目上线前，建议把报修人字段做脱敏处理，比如只保留姓氏和手机尾号，或者直接设置成“业主”两个字的匿名标识。同时不要向看板访客开放原始消息内容的查看权限，这样能有效避免个人信息泄露的风险。
从落地效果看，这个项目上线后的两周内，物业对电梯报修的平均响应时间从原先的大约 40 分钟缩短到了 15 分钟以内。管家每天不用再人工翻聊天记录去登记台账，工程维修人员也能通过手机查看待处理工单列表。更直观的变化是，业委会开例会的时候终于不用再靠截图争论“到底哪部电梯坏了多少次”，直接打开看板投屏，数据一目了然。
就我个人经验来说，做这类项目最关键的其实不是技术多复杂，而是要理解一个朴素的道理：工具是为流程服务的。WorkBuddy 给了你一个快速搭建自动化流程的能力，但真正决定项目成败的，是你对报修流程的理解、对字段口径的定义、对异常情况的预判。把业务想清楚，剩下的配置工作反而很快。这也是我从这个项目里收获最大的地方。
