标准场景 报告文书 行业 · 城市治理与园区

GM-02 · 巡查日志 → 工单转化

走过的路生成日报

痛点 网格员每天走 2 万步 · 大半走了等于白走

① 场景引入

一、这件事现在是什么样

网格员 · 事件采集与巡查 · 真实业务触发

每日下班前需交巡查日志,传统做法是回忆或手写今日所见,黄冈 12345 办法明文要求承办单位「推动接诉即办向未诉先办转变」,但日志形式化严重,没有线索进入处置流程

二、痛点 · 每条都有来源

  1. 痛点一:巡查日志形式上是台账,实际只有日期+几句话,无法与事件库交叉——日志里的「井盖松动」三个月后才有人报修,白白错过最佳处置期
    依据:住建部建办督〔2021〕54号《关于全面加快建设城市运行管理服务平台的通知》及配套 CJJ/T312-2021、CJ/T545-2021 技术与数据标准,要求 2025 年底前一网统管体制机制基本完善,体征监测与指挥监督为地级以上城市法定动作
  2. 痛点二:网格员每天走 2 万步,但真正进系统的不到 10%,因为录入成本远大于「装没看见」的代价
    依据:成都某区 30 名网格员入职半年离职 20+;网格员月薪 2000 上下,每天 2-3 小时耗在系统操作上,高流失率
  3. 痛点三:「未诉先办」是黄冈 12345 办法明文要求,但前提是分析过去数年的工单找出「类高发点」,区里没人做得了这个分析
    依据:《黄冈市 12345 政务服务便民热线管理办法》:按时办结率低于 97%、回访满意率低于 90% 且连续三个月排名靠后由政府督查机构约谈
  4. 痛点四:日志归档即束之高阁,领导调阅时翻 Excel + 纸质材料是常态——蓬莱区官方自认
    依据:蓬莱区官方自认闲置资产数据「分散在各镇街 Excel 和纸质材料中,领导问起来需临时电话调度」——真实主数据不在平台里

三、换个做法之后

变化不在「快」,在「参与的角色」和「覆盖的范围」

✕ 现在的做法

  • 痛点一:巡查日志形式上是台账,实际只有日期+几句话,无法与事件库交叉——日志里的「井盖松动」三个月后才有人报修,白白错过最佳处置期
  • 痛点二:网格员每天走 2 万步,但真正进系统的不到 10%,因为录入成本远大于「装没看见」的代价
  • 痛点三:「未诉先办」是黄冈 12345 办法明文要求,但前提是分析过去数年的工单找出「类高发点」,区里没人做得了这个分析
  • 痛点四:日志归档即束之高阁,领导调阅时翻 Excel + 纸质材料是常态——蓬莱区官方自认

✓ 交给 Agent 之后

  • 多来源文件一次读入,先做口径与完整性校验,再开始算
  • 每条结论绑定来源文件、字段或条号,可以被审
  • 产出是企业真会流转的正式件(带签批栏),不是一张展示用的表
  • 该拦的地方给出「现在还不能提交」,并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

  1. 要素校验 · 轨迹与点位GPS 点位缺失 >30% 标黄,建议补打
  2. 口径归一 · 语音转结构化备注「这家门口堆了好多杂物」→ 疑似事件=群租/杂物堆放
  3. 交叉核对 · 与近三月事件库对齐同类高发点位自动标红,列入「待人工核实」
  4. 异常识别 · 异常点位与静止轨迹在非巡查点位长时间静止 = 疑似市民反映问题
  5. 留证与签批 ·生成巡查日报含今日行程、已上报事件、待核实线索、巡查覆盖率

要准备什么:当日巡查轨迹(GPS 点位)网格员手持终端的当日 GPS 轨迹,2 万步约 1500 个点现场语音 / 照片(沿途随手拍)网格员一路的随手拍照与语音备注本街道近三月事件登记单用于交叉匹配判断是否同类高发

为什么这个场景值得做

优先级评分:痛感 4 × AI 适配 4 ÷ 落地难度 2 = 9.6

最大差异点:不要求网格员额外写日志。语音+轨迹+拍照自然记录,Agent 自动汇总并标注「疑似事件线索」,与本街道事件库交叉匹配后写入「待人工核实」队列。

评分口径:痛感看「这事没做好谁会生气、生气到什么程度」;

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」;

落地难度是分母 —— 需要客户先做数据治理的场景,分数会被压得很低。

五、会产出什么

判断标准只有一个:这份东西能不能直接进企业的流程

  • 正式件本体:巡查日报.xlsx 含行程、事件、线索、覆盖率
  • 可派发清单:未诉先办线索清单.xlsx 疑似事件点位· 需人工核实
  • 可派发清单:巡查覆盖率报告.xlsx 本月巡查覆盖率与高发点位热力图

这套东西不承诺什么:不替网格员回忆今天走过哪里;不自动生成事件工单(线索进入「待人工核实」队列);不跨区共享巡查日志(数据归属本街道)。

② Live Demo(演示逐步)

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」,用的是真实业务格式的脱敏构造数据, 不宣称已接入客户生产系统,也不承诺任何效率提升百分比。

案例设定:还是网格员周雪。2026-09-01 17:40 回到街道,18:00 前要交当日巡查日志。今天她的手持终端里躺着:轨迹点 1,892 个(约 2.1 万步)、随手拍 7 张、语音备注 4 段、正式登记事件 2 件。9 月起,街道月度考核新增「必巡点位覆盖率」指标。

当日轨迹点1,892 个必巡点位覆盖8 / 9自处置事项3 起待核实线索1 条

输入城运治理与园区手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

  • 01_当日轨迹抽样.xlsx 手持终端 GPS 轨迹——行程、停留、绕行都在里面系统自动记录 · 实时
  • 02_随手拍照记录.xlsx 一路的随手拍——照片没挂到轨迹上就是死数据网格员随手拍 · 当日 7 张
  • 03_语音备注转写.txt 一路的语音备注——巡查的「顺手记」,日志最值钱的原料网格员语音 · 当日 4 段
  • 04_近30日网格事件台账.xlsx 本网格近 30 日已登记事件——查复发线索的底账网格员自行维护 · 每日更新

注意标橙色那一份 —— 03_语音备注转写.txt。它网格员语音 · 当日 4段,平时压根不在核对范围里。这个场景的价值,很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

今天走了哪里、看到了什么,说几句话就行。 没特别的事就一句话:今天无异常。 GPS 与拍照 App 自动开着,别管它。

短是因为轨迹和拍照都是后台自动记录,Agent 不会要求你额外做任何动作。

触发18:00 前要交日志,写日志的时间靠挤

9 月起新增考核:必巡点位覆盖率

传统写日志靠回忆:今天走了哪、看了啥、处理了啥。回忆会漏、会美化、会对不上考核口径。轨迹、照片、语音三样东西当天都发生了——缺的只是把它们变成日志的人。

第 1 步 · 轨迹回放 · 1,892 个点串成一条线

停留点自动识别,行程不再靠回忆

演示数据(表格原文)时段路段停留点对应作业08:30-11:50滨河路—育才巷—纺织厂宿舍3劝导、扶正、事件登记13:30-14:50滨河公园片区1清捡15:20-17:30滨河路—老街口—龙川路2事件登记、线索备注合计—6—停留 6 处全部有照片或语音对应,无「轨迹在、记录不在」的悬空点。

第 2 步 · 照片归位 · 7 张照片各找各的主

每张照片挂到轨迹点位,去向分四类

演示数据(表格原文)照片挂点结果去向IMG\_0901\_0108:47 滨河路6号自处置备案(劝导)IMG\_0901\_0209:12 育才巷口自处置备案(扶正)IMG\_0901\_0310:05 滨河路118号历史对照留存IMG\_0901\_0411:38 纺织厂宿舍3栋转事件登记(BY-0901-018)IMG\_0901\_0514:22 滨河公园北门自处置备案(清捡)IMG\_0901\_0616:33 滨河路118号转事件登记(BY-0901-041)IMG\_0901\_0717:05 龙川路22号线索 · 待核实7 张照片:自处置备案 3、转事件登记 2、对照留存 1、待核实线索 1。看点 · 该拦的地方拦住了上午 10:05 的 IMG\_0901\_03 拍到这口井「未见异常」,下午 16:33 即破损——两张照片拦住了「长期破损未上报」的错误口径,损坏发生在当天 6.5 小时窗口内。这个对照自动附进下午那件事件的材料里,主办单位判断成因(重车碾压还是设施老化)时有了前后状态。

第 3 步 · 语音线索识别 · 「又堆起来了」值得一个动作

语音备注里的疑似事件,先检索历史再定

演示数据(表格原文)线索台账检索复发间隔建议动作龙川路22号建筑垃圾堆积BY-0819-053(8-19 清运办结,费用 800 元)13 天明早首站现场核实,属实即登记看点 · 从历史记录里想起了踩过的坑上次清运后 13 天复发,语音里「怀疑同一伙人偷倒」是个有价值但未经证实的判断——Agent 只把它列为核实方向(夜间时段、同类渣土),不写进正式日志,免得先入为主。复发间隔 13 天不用人翻台账算日子,这条线索不靠网格员还记得 8 月清过一次。

第 4 步 · 覆盖率核算 · 8 / 9,缺的那 1 个有原因

考核指标前置消化,不等月度排名出来再解释

演示数据(表格原文)必巡点位覆盖情况备注滨河路全段已覆盖—育才巷已覆盖—纺织厂宿舍已覆盖—滨河公园北门已覆盖—龙川路已覆盖—云溪二小周边已覆盖—农贸市场已覆盖—河堤路已覆盖—老街口未覆盖15:40-16:10 市政封闭施工,轨迹绕行合计8 / 9—看点 · 排除性结论老街口未覆盖不是漏巡——轨迹里 15:42 的绕行记录加施工封闭说明直接附进日报,月度考核的扣分争议提前消化,不用等考核出来再补情况说明。覆盖率 88.9% 是「算得清的 8/9」,不是「大概齐」的 8/9。

第 5 步 · 生成日报 · 行程、事件、线索、覆盖率四段成篇

格式对齐街道口径,直接可交

演示数据(表格原文)日报板块内容来源条目数行程回放轨迹 + 停留点6事件登记BY-0901-018 / BY-0901-0412自处置事项照片 + 语音3待核实线索龙川路22号1看点 · 把技术动作翻译成钱自处置 3 起(劝导、扶正、清捡)按街道网格自办口径入账,不进 12345工单盘子;若龙川路线索明日核实属实,清运参照上次同类约 800 元(街道年度清运预算内)。日报的四段结构对着考核口径写——覆盖率、自办率、线索转化率每个数都有出处,月度排名会上不用现编。龙川路 22 号的线索今天不能直接转工单语音备注只是「疑似」——未现场核实位置、责任主体与是否偷倒,按网格化流程线索转工单前必须核实,否则误报消耗城管执法大队处置资源,回头退单还是网格员的账。两个不用干等的走法:方案一:明天 8:30 首站现场核实,属实当场登记(普通件 24 小时时限,清运参照上次约 800 元,街道年度清运预算内);方案二:今晚把线索连同 BY-0819-053 的 13 天复发记录推城管执法大队联络人做非正式提醒,请夜巡顺路查看,不立工单、不产生费用——属实则明日再走方案一。两条都不用干等。之后这一次跑完,公司多了什么

不讲省了多久 · 讲少了几个隐患、沉淀了什么

演示数据(表格原文)✓台账多了一条:巡查日报口径入库,避免网格员重复填字段✓两条识别规则被固定下来:异常静止判定、疑似事件线索匹配✓一条历史教训被真正用上:「未诉先办」前置识别省下来的 11 天/件✓岗位角色变了:网格员从「日志表填写员」变回「现场记录员」,日志从「无产出」变「未诉先办入口」追问现场可能被问到的答不上来的问题,比答得漂亮的问题更能决定这场演示的结果GPS 漂移怎么办?室内定位失效时自动用当日其他时段的轨迹均值补偿,偏差 >50 米的点位标「需现场补打」。会不会越权登记其他网格的事件?不会。Agent 只标「待人工核实」,不自动转工单;事件登记权仍在现场网格员本人。覆盖率怎么算?按本街道实际巡查路线与网格划分覆盖率计算,覆盖率 < 80% 标黄,建议第二日补补打。

③ 能力沉淀(Skill / 提示词 / 预期输出 / 人工边界)

1. Skill 能力包

导入之后,同类任务会自动按这套规则走 —— 提示词才能写得那么短

巡查日志 → 工单转化 —— 走过的路生成日报 · Skill

SKILL.md 主本 + references(输出骨架 / 判据 / 渲染脚本)· 符合 WorkBuddy Skill 规范

版本 v1.0

patrol-log-to-ticket.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

  • SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
  • references/output_template.md 输出骨架(sheet 名 / 分区顺序 / 列头)+ 可直接运行的渲染脚本
  • references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细,不会拖慢每次对话。

2. 原始素材

这些就是城运治理与园区手上真实能拿到的东西 —— 格式不统一是常态,不是问题

📁GM-02 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

  • 01_当日轨迹抽样.xlsx 手持终端 GPS 轨迹——行程、停留、绕行都在里面
  • 02_随手拍照记录.xlsx 一路的随手拍——照片没挂到轨迹上就是死数据
  • 03_语音备注转写.txt 一路的语音备注——巡查的「顺手记」,日志最值钱的原料
  • 04_近30日网格事件台账.xlsx 本网格近 30 日已登记事件——查复发线索的底账

怎么用

  • 把素材全部拖进 WorkBuddy 对话框(不需要整理格式、不需要改文件名)
  • 粘贴下方提示词发送
  • 拿到正式件初稿 —— 签批栏留空,推荐意见留空,由你填

3. 提示词卡片

今天走了哪里、看到了什么,说几句话就行。 没特别的事就一句话:今天无异常。 GPS 与拍照 App 自动开着,别管它。

为什么这么短就够了:短是因为轨迹和拍照都是后台自动记录,Agent 不会要求你额外做任何动作。

换成你自己的业务:把素材换成你手上的真实文件即可。导入 Skill 之后,

该走几步、什么口径、什么情况必须拦住,Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

  • 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说:什么事、什么文件、什么要求。不用讲究格式。
  • 调用 Skill 补齐专业规则 —— 导入本页 Skill 后,流程、口径、硬规则 Agent 自己知道。
  • 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮,把随口说的话补成更完整的表述。

分工:自然语言负责「这是什么事」,Skill 负责「该怎么做」,增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

  • GM-02_巡查日报.xlsx 正式件本体 · 含行程、事件、线索、覆盖率
  • GM-02_未诉先办线索清单.xlsx 疑似事件点位 · 需人工核实
  • GM-02_巡查覆盖率报告.xlsx 本月巡查覆盖率与高发点位热力图

Skill 里固化了什么:从历史里想起了踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单:当日巡查轨迹(GPS 点位)网格员手持终端的当日 GPS 轨迹,2 万步约 1500 个点现场语音 / 照片(沿途随手拍)网格员一路的随手拍照与语音备注本街道近三月事件登记单用于交叉匹配判断是否同类高发

人工边界:不替网格员回忆今天走过哪里;不自动生成事件工单(线索进入「待人工核实」队列);不跨区共享巡查日志(数据归属本街道)。

升为客户真实案例还缺什么:客户当前真实输入文件(不要整理过的)岗位现行 SOP 与审批链(金额分档、谁签字)至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径(多少天算临期、多少金额算大额)

5. 同一角色下的其他场景

网格员 · 事件采集与巡查 · 产出即下一步输入

上下游串起来就是完整链路。每一步的产出都是下一步的输入,不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理,演示中的企业、人物与数据均为虚构,不代表任何客户的实际成效;痛点引用的公开来源已做脱敏处理。网页版由原资料转换,部分演示表格以原文形式展示。

想把这个场景在你们企业跑通?

顾问会先看你们的数据和流程够不够,再决定从哪一步开始。