社区活动报名小程序需求澄清与技术方案

1. 需求摘要

为社区居民和社区工作人员建设一个移动端活动报名小程序。首个版本聚焦活动浏览、居民报名、工作人员发布活动和查看报名名单，并以一个月内形成可上线版本为目标。

2. 已确认信息

目标用户：社区居民、社区工作人员。
居民侧能力：浏览活动、报名活动。
工作人员侧能力：发布活动、查看报名名单。
交付约束：希望一个月内上线，预算尽量低。
使用环境：主要在手机上使用。
容量线索：预计同时在线人数不超过 100 人。

3. 待确认问题

居民和工作人员分别采用什么方式登录，是否需要对接现有社区账号？
活动需要记录哪些字段，是否包含人数上限、报名截止时间和候补规则？
居民能否取消报名，工作人员能否手动调整名单？
报名信息需要保存哪些个人数据，保存多久，谁可以导出？
“一个月内上线”的验收日期、审核流程和成功指标分别是什么？
“预算尽量低”的可接受金额上限是多少？

4. 范围与优先级

Must（MVP 必须具备）

活动列表与活动详情。
居民提交报名并查看报名结果。
工作人员创建、编辑和发布活动。
工作人员查看活动报名名单。
基础角色鉴权和输入校验。

Should（建议具备，待确认）

报名人数上限和重复报名拦截。
报名截止时间控制。
居民取消报名。

Could（后续迭代）

消息提醒、候补队列、名单导出和活动数据看板。

Won't（本期建议不做）

复杂推荐、积分体系、多社区租户和原生 App。

5. 技术方案

以下均为建议方案，待确认：

客户端：使用目标小程序平台的原生能力实现移动端页面。
服务端：采用单体 API 服务承载活动、报名和权限模块，以降低一个月交付周期内的复杂度。
数据层：使用关系型数据库保存用户、活动和报名关系，并为“活动 + 用户”设置唯一约束以阻止重复报名。
核心数据流：工作人员发布活动 → 居民浏览并报名 → 服务端校验身份、截止时间和名额 → 写入报名记录 → 工作人员查看名单。
接口草案：活动列表、活动详情、创建/更新活动、提交/取消报名、查询报名名单。接口字段和鉴权方式需在待确认问题闭环后定稿。
实施节奏：第 1 周完成需求确认与原型；第 2 周完成活动和身份模块；第 3 周完成报名闭环与测试；第 4 周完成验收、修复和上线准备。

6. 风险与对策

优先级	风险	触发条件与影响	概率	严重度	缓解措施	确认责任人
高	身份与权限未定义	无法区分居民和工作人员，可能造成越权发布或数据泄露	高	高	开发前确认登录方式和角色授权矩阵	业务负责人、技术负责人
高	报名规则不完整	并发报名可能超额，取消和候补行为不一致	高	高	明确名额、截止、重复报名和取消规则，并在服务端事务中校验	业务负责人
高	个人数据边界不清	收集或导出名单时产生隐私风险	中	高	遵循最小收集原则，确认字段、可见范围和保存周期	数据负责人
中	一个月范围蔓延	新增提醒、导出等功能导致延期	中	中	锁定 Must 清单，其余功能进入迭代池	项目负责人
中	预算没有上限	技术方案和云资源无法做成本取舍	高	中	在架构定稿前确认预算上限和已有资源	项目负责人

7. 验收标准

以下为建议验收标准，需由项目负责人确认：

居民可以在手机端查看已发布活动并成功提交一次报名。
对同一活动的重复报名会被拒绝，并显示可理解的提示。
工作人员可以创建活动，并查看与该活动一致的报名名单。
普通居民不能访问工作人员的发布和名单管理功能。
在 100 个并发会话的约束场景下，核心报名请求无超额写入。
Must 范围的自动化测试和人工验收用例全部通过。

8. 下一步行动

由业务负责人回答六个待确认问题并确定 Must 清单。
由技术负责人确认目标小程序平台、登录方式和现有基础设施。
由数据负责人确认个人信息字段、权限和保存周期。
根据确认结果更新接口契约和验收用例，再进入开发。