接诉即办服务规划

1. 背景理解

2. 当前已知情况

2.1 产品与载体

• 社小智：ToC 产品，接诉即办能力在界面中体现较完整（含 小程序、PC 等多端）。
• 基层治理 AI：ToB 产品，面向社区书记、社工及街道主任、科室等内部人员；能力正在从少到多补充进现有产品。
• 小程序现状：不改变既有 chat 交互。用户在 chat 页点击「诉办通」，当前仅有两个服务按钮：诉求分析、法律法规（对应原办件思路、法律法规能力）。
• 街道 PC：已有档案馆、历史工单上传等能力，部分资料能力后续在小程序侧按需调用；居民台账（包含走访记录）两端都有，可支撑接诉即办产品调用数据。

2.2 规划补齐目标

2.3 近期数据观察

统计周期为 2026-05-01 至 2026-05-28。

2.4 当前交互

• 当前小程序以 chat 连续对话为主，用户进入会话后持续交流；点击「新对话」或底层按钮时开启新的对话上下文。
• 「诉办通」作为当前会话内的服务入口按钮，点击「诉办通」级别按钮本身不新建对话，也不直接切换到另一个 Agent。
• 诉办通（其他同级别一致）下的底层按钮用于表达本次诉求类型，目前包含办件思路、法律法规2个按钮，分别调不同agent。

3. 产品定位

3.1 近期定位

在不改变现有 chat 交互的前提下，面向社区工作者（一期主用户）补齐诉办通内的接诉即办 AI 能力，先解决个人办件减负和提质：

• 更快理解诉求、形成办理思路（结合历史工单、居民台账、走访记录）。
• 匹配法规政策依据。
• 生成办理回复等文书。
• 进行语音转文字等材料辅助处理。
• 增加多轮交流能力，方便多维度完成咨询辅助。

3.2 中期定位

• 继续沿用 chat +「诉办通」按钮的方式，由同一个综合调度 Agent 承接入口并按需调用具体能力，不另做独立接诉即办工作台形态（小程序侧）。
• 形成单位内资料共享与复用：社区内共享；街道与科室按单位边界使用工单与资料（跨社区/街道调用规则见待定问题）。
• 支持将档案馆整体或指定文件夹作为当前部门知识库，供法律法规、办件思路等 Agent 检索引用。
• 在有一定使用数据后，对比基层治理 AI（chat + 按钮调 Agent）与社小智（界面功能模块提供服务）在访问人数、调用次数、连续会话、人均使用等方面的差异，为后续是否调整呈现方式提供依据。

3.3 长期定位

• 在使用数据触达和稳定后，结合中期使用结果，建设统计分析、失分工单分析、重复诉求识别、区域问题画像和主动治理建议等能力（见未来需求）。

4. 服务流程

1. 用户进入 chat 页面后保持连续对话；点击「新对话」或诉办通底层按钮时开启新的对话上下文。
2. 用户点击「诉办通」级别按钮时，只打开当前会话内的服务按钮区，不开启新对话，也不直接切换 Agent。
3. 用户在诉办通服务区选择 5 个底层按钮之一：办件思路、法律法规、办件回复、语音转文字、历史工单查询。
4. 底层按钮均调用同一个综合调度 Agent，并同时发送按钮 id；综合调度 Agent 根据按钮 id 或用户提问中的对应关键词分流到具体能力。
5. 后续连续对话不再强制裹挟按钮信息，由综合调度 Agent 继续根据用户语义、上下文和关键词进行分流；无法命中具体能力时进入兜底 AI 对话。
6. 需要材料时，可走本地上传、微信上传、从档案馆选取等已有能力；语音转文字按文件格式与数量限制执行（如单场景加限制太过复杂可放弃）。

flowchart LR
  user["社区工作者"] --> chat["基层治理AI chat页面"]
  chat --> suban["诉办通按钮区"]
  suban --> dispatcherAgent["综合调度Agent"]
  dispatcherAgent --> analysisRule["按钮id或提问包含：办件思路/诉求分析关键词"]
  analysisRule --> analysisAgent["诉求分析Agent"]
  dispatcherAgent --> lawRule["按钮id或提问包含：法律法规/政策依据关键词"]
  lawRule --> lawAgent["法律法规Agent"]
  dispatcherAgent --> replyRule["按钮id或提问包含：办件回复/回复文书关键词"]
  replyRule --> replyAgent["回复文书Agent"]
  dispatcherAgent --> voiceRule["按钮id或提问包含：语音转文字/录音转写关键词"]
  voiceRule --> voiceAgent["语音转文字Agent"]
  dispatcherAgent --> historyRule["按钮id或提问包含：历史工单/历史查询关键词"]
  historyRule --> historyAgent["历史工单查询Agent"]
  historyAgent --> oldCases["历史工单"]
  dispatcherAgent --> fallbackRule["未命中具体能力"]
  fallbackRule --> fallbackChat["兜底AI对话"]
        

5. 必做需求

6. 待定问题

以下事项需在实施前或试点中继续拍板：

7. 未来需求

• 统计分析与管理驾驶舱：高频/重复诉求、热点、三率相关分析、多层级看板等。
• 失分工单分析：归因、复盘、相似工单预警；数据来源可为历史工单库、上传文件、档案馆等组合。
• 主动治理建议：从诉求数据中识别共性问题并输出治理建议。
• PC 端接诉即办：是否在 PC 沿用 chat + 按钮，或另做界面；PC 侧重档案与批量管理，小程序侧重移动办件与采集。
• 二期Agent优化：更多类型附件处理交叉审核、质检复核、失分分析、统计报告等（在数据与规则成熟后）。

8. 一期验收指标建议

• 使用指标：诉办通入口访问人数、各按钮服务调用次数、人均使用次数、连续会话轮次分布。
• 能力指标：综合调度是否能按首轮按钮要求和后续语义正确分流；办件思路、法律法规、办件回复、语音转文字、历史工单查询是否能完成基本任务。
• 试点目标：使用次数、使用人数达到预期即视为一期触达有效；后续再扩展质量与业务类指标。