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

## 1. 需求摘要

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

## 2. 已确认信息

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

## 3. 待确认问题

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

## 4. 范围与优先级

### Must（MVP 必须具备）

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

### Should（建议具备，待确认）

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

### Could（后续迭代）

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

### Won't（本期建议不做）

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

## 5. 技术方案

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

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

## 6. 风险与对策

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

## 7. 验收标准

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

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

## 8. 下一步行动

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