街道和社区是基层治理的最后一公里，但长期面临三个问题：居民办事要跑现场，通知靠贴告示和微信群，社区工作人员靠 Excel 记台账。居民不知道能办什么、该找谁办；社区不知道谁需要什么服务；上级要数据时只能临时统计。
本项目面向街道与社区，把高频民生服务搬到微信小程序上：居民在手机上查办事指南、提交诉求、报名活动、查看通知；社区工作人员在后台处理工单、发布信息、管理台账；街道可以按区域查看服务数据。核心是两头减负——降低居民使用门槛（不用装 App，微信里直接打开），减轻基层工作人员的重复劳动（把台账从 Excel 搬进系统）。
一、居民端小程序：办事指南查询、诉求上报（支持图片与定位）、活动报名、通知公告、常用电话与便民服务入口。
二、诉求工单流转：居民提交诉求后自动分派到对应社区，支持转派、催办、办结、回访，全过程留痕可追溯。
三、活动与通知管理：社区发布活动与通知，按小区、楼栋精准推送，支持报名人数控制与现场核销。
四、社区台账管理：居民信息、房屋信息、特殊人群、志愿者队伍等基础台账的录入、查询与统计。
五、数据看板：按街道 / 社区维度查看诉求量、办结率、活动参与人数、高频问题分布。
六、智能问答助手：接入问答机器人，回答政策咨询、办事流程等高频问题，减少人工接线量。
我在项目中担任项目经理兼技术负责人。
具体承担的任务：
一是负责与街道、社区工作人员对接需求，把他们的日常台账和口头规则整理成可执行的系统流程——这一步的难度不在技术，在于把"我们平时就是这么办的"翻译成明确的状态和规则。
二是主导小程序与管理后台的功能规划，确定一期做什么、哪些放二期，控制首次上线的范围。
三是负责技术方案设计，包括小程序端、管理后台、服务端三部分的技术选型与接口约定。
四是推动与微信生态的对接（登录、订阅消息、模板通知），解决居民触达这个最现实的问题。
五是组织多个街道 / 社区的试点上线，其中一个已正式发布运营，其余处于实施阶段。
六是负责上线后的运维与迭代，根据社区反馈调整工单流转规则。
技术栈： Java、Spring Boot、Vue、微信小程序、MySQL、Redis。服务端按业务域拆分模块，工单流转用状态机管理，保证每一步状态可回溯；消息通知走微信订阅消息，避免短信成本。
主要难点：
一是使用习惯。基层工作人员年龄偏大、习惯了 Excel，系统必须比 Excel 更快才有存在意义，最终把高频操作压缩到 2–3 步完成。
二是多社区差异。不同街道的办事流程和台账字段不完全一致，用"配置化 + 默认模板"解决，坚持不做定制开发——一旦开了定制的口子，后续维护会被拖垮。
评论