社区服务长期存在"三多三少"：纸质台账多、线上入口少；重复填报多、一次办成少；通知群多、有效触达少。居民办一张居住证要跑社区，社区统计靠 Excel，上级要数据时再临时汇总。
本项目面向街道与社区，把高频民生服务搬到微信小程序：居民完成实名认证后在线办事、报名活动、参与投票、反映问题；社区工作人员在 PC 后台审核、发布、统计；街道可按社区查看服务数据。同时把政策法规和办事指南做成可检索的知识库，接入 AI 问答，减少人工重复解答——社区工作人员每天被问三十遍"居住证要什么材料"，这件事该由机器来答。
分三端：
一、居民端小程序
- 微信授权登录与实名认证：自动获取 openid 进入游客模式；手机号授权验证后升级为居民；支持录入房产信息（房产证拍照自动识别产权人、建筑面积、地址）、同住人信息与关系，提交社区审核。已认证居民可直接微信登录。
- 云社区：社区介绍与地图、公示栏、社区动态（支持在线报名、分享）、线上速办（居住证与暂住证在线申请，审批通过后生成 PDF 供下载打印）、调查问卷、线上投票。
- 我的：身份信息查看与修改、投诉建议（支持图片、视频、Word/PDF 附件）、系统消息、注册协议与隐私政策。
二、社区管理端（PC）
- 用户管理：居民信息增删改查、角色与权限管理、存量居民与办事人员批量导入（含校验报告、重复数据覆盖/跳过策略）。
- 社区管理：社区与小区维护、社区动态发布（支持定时发布、报名人数上限）、公示栏内容管理。
- 问卷与投票：问卷创建、预览、按人群范围（年龄段/片区）推送、结果统计与 Word 导出；投票支持候选人与候选事项管理、匿名/实名模式、结果一键公布。
- 知识库管理：文档上传（多格式）、二级分类体系、标签管理。
- 业务审批：居住证/暂住证审批与驳回，结果推送至居民端。
- 投诉建议处理、系统设置。
三、AI 问答
知识库优先检索，大模型兜底：问题先拆关键词检索知识库，匹配度 ≥80 分直接返回知识库答案并附文档链接；60–79 分返回相关内容并推荐 2–3 篇文档；低于 60 分转大模型生成，同时记录该问题供管理员补充知识库。支持语音输入（转文字）与回答语音播报。含敏感词过滤与单日对话频次限制。
我在项目中担任技术负责人兼项目经理。
具体承担的任务：
一是需求拆解与功能清单编制。把社区工作人员口中的"我们平时就是这么办的"拆成 200 多条可验收的功能点，逐条标注负责人、起止时间与完成状态——这件事看着琐碎，但它是项目能不能按 2025 年 10 月到 2026 年 1 月这个周期交付的前提。
二是技术选型与成本核算。确定小程序端、PC 管理端、服务端的技术栈，并核算第三方能力的年度成本（知识库、云服务器、语音识别、大模型精调、OCR、内容审核），把预算控制在可接受范围。
三是主导 AI 问答的降级策略设计。设定知识库匹配度阈值与转大模型的触发条件，解决两个极端——直接接大模型会"答得流畅但不准确"，纯知识库又"答不上来就卡死"。
四是设计居民实名认证链路：微信手机号授权 → 房产证 OCR 识别 → 同住人关系校验 → 人工审核与自动审核双模式可切换。
五是设计存量数据导入方案。先上传文件拿预览地址，再提交预览地址加导入模式，避免大文件直传；配套生成校验报告，支持下载错误数据修改后重导，重复手机号可选择覆盖或跳过。
六是团队协调。UI、前端、后端三条线并行排期，按模块拆分交付，前端与后端各自领取功能点。
技术栈： 微信小程序、Vue（PC 管理端）、Java / Spring Boot（服务端）、MySQL、Redis、腾讯云对象存储、DeepSeek 大模型、OCR 与语音识别服务、内容审核接口。
主要难点：
一是 AI 回答的可控性。政策类问题答错代价很高，所以不能让大模型自由发挥。解法是知识库优先 + 阈值分档 + 低分才转大模型，同时把答不上来的问题回沉淀进知识库，形成"越用越准"的闭环。
二是居民身份的真实性。社区服务涉及居住证办理，身份不能出错。采用微信手机号 + 房产证 OCR + 同住人关系三重校验，再叠加审核模式开关，在效率与准确之间留出配置空间
评论