社区互助服务平台

项目定位为社区上门代办场景的全栈产品，而不是单点 Demo。它同时覆盖居民下单、服务者履约、物业运营、支付订阅、通知沟通和后台审计。

社区内取快递、丢垃圾等上门代办服务看似简单，但一旦进入真实交付，就会同时出现排班、派单、支付、订阅消息、服务凭证、评价、提现和异常处理。

• 居民需要低摩擦下单和订单进度反馈。
• 服务者需要任务池、完工上传和提现入口。
• 后台需要处理审核、排班、订单、评价、月卡、提现和审计。

系统被拆成微信小程序居民端、微信小程序服务者端、Vue 3 + Element Plus 管理后台、Node.js + Express API、MySQL、Redis、Nginx 和 Docker Compose 部署层。

客户端

3

居民端、服务者端和管理后台。

后端边界

API + jobs

controller、service、model、route、middleware 和 job 分层。

1. 01

   居民下单

   选择服务、填写需求，必要时由 AI 生成订单草稿。

2. 02

   支付订阅

   月卡和支付流程进入微信支付 V3 与后端回调。

3. 03

   派单履约

   物业服务者优先，邻里服务者抢单兜底。

4. 04

   完工确认

   服务者上传完成信息，居民确认后进入评价与结算。

5. 05

   后台审计

   运营侧通过订单、提现、评价和审计日志处理异常。

订单状态机约束创建、派单、接单、服务中、完成、确认和评价。状态不散落在多个接口里，通知、结算和审计都围绕状态变化触发。

1. 创建订单后记录初始事件和用户侧可见状态。
2. 派单和接单改变服务者侧任务池与通知内容。
3. 完成、确认和评价决定结算状态与后续审计记录。

微信登录、支付 V3 回调、订阅消息、COS 上传和 WebSocket 都有独立上线约束。后端需要同时处理鉴权、回调验签、消息发送、聊天连接和文件上传权限。

• JWT 鉴权和 Token 吊销用于保护用户与后台接口。
• 支付回调和提现流程写入可追踪记录，避免只依赖前端状态。
• 订阅消息和 WebSocket 分别处理异步通知和实时沟通。

AI 能力被接在现有下单链路之前，只负责把自然语言需求解析为结构化订单草稿。它不会直接创建订单，也不会跳过用户确认、支付、派单和审计。

部署侧使用 Docker Compose 编排 MySQL、Redis、server、admin、nginx 和备份任务，并补充生产配置检查，避免只在本地开发环境可运行。

• 生产检查覆盖安全头、弱密钥检测、CORS 白名单和接口限流。
• 请求链路包含 X-Request-ID、健康检查、迁移和备份脚本。
• CI 覆盖核心模块测试和上线前配置校验。

页面不展示真实用户、订单和支付信息，而是用脱敏流程说明、系统边界和审计痕迹证明交付范围。媒体块也明确说明这是私有项目，不公开代码仓库。

审计事件

订单 + 支付 + AI

覆盖状态流转、回调、提现和 AI 草稿确认。

展示方式

脱敏

只展示架构、流程和交付质量证据。

这个项目最有价值的部分不是某个页面或接口，而是多个端、多个角色和多个外部服务围绕订单状态保持一致。AI 下单草稿也必须服从这条主线，不能让新能力破坏原有闭环。

• 继续展示时应优先补充脱敏状态流图和关键审计字段，而不是公开业务数据。
• AI 草稿可进一步增加低置信度回退策略，把风险明确交给人工确认。
• 后续若产品化扩展，应先强化运营异常处理，而不是只增加前端入口。