147 lines
9.7 KiB
Markdown
147 lines
9.7 KiB
Markdown
# 数学脑｜暑期微信小程序 MVP 需求评审包
|
||
|
||
> 状态：评审准备稿 v0.1（非最终 PRD）
|
||
> 用途：用于首次需求评审，确认产品方向、MVP 边界、团队分工与暑期交付标准。
|
||
> 已知依据：现有 Flask Web Demo、既有产品描述与开发需求文档。
|
||
|
||
## 0. 本次评审需要达成的结论
|
||
|
||
1. 明确首发用户，只选择一个核心人群作为 MVP 的服务对象。
|
||
2. 确认微信小程序 MVP 的核心闭环与不做清单。
|
||
3. 锁定暑期版本必须上线的模块、团队负责人和时间节点。
|
||
4. 确认试点方式与成功标准，避免“做完了但无法判断是否有效”。
|
||
|
||
## 1. 当前 Demo 的客观基础
|
||
|
||
现有 Web Demo 已具备四个一级入口：发现视频、知识卡片、数学人生互动剧情、个人中心；另有 AI 助教、收藏、历史、昵称头像及专业模拟器。技术上采用 Flask、SQLite、原生 HTML/CSS/JS，适合快速验证。
|
||
|
||
它验证了产品表达与内容形态，但尚未验证真实用户的持续需求。当前最大的风险不是前端能否做出来，而是：首发用户是否清晰、内容能否稳定供给、互动剧情是否能带来留存，以及小程序发布所需的账号、内容安全和隐私要求是否被提前纳入范围。
|
||
|
||
## 2. 建议的 MVP 产品定义（供评审）
|
||
|
||
### 一句话定义
|
||
|
||
面向 **对大学专业与现实应用感到好奇的中学生及大学新生** 的数学兴趣小程序：用短内容建立“数学和我有关”的认知，用轻互动促成下一次打开。
|
||
|
||
### 首发核心闭环
|
||
|
||
`选择感兴趣的专业/主题 → 浏览 1 条内容 → 收藏或追问 AI → 获得下一条推荐/当日任务 → 次日回访`
|
||
|
||
### 首发价值主张
|
||
|
||
“不用刷题，也能理解数学如何进入 AI、医学、游戏和真实世界。”
|
||
|
||
## 3. 暑期 MVP 范围建议
|
||
|
||
| 优先级 | 模块 | 首发必须交付 | 验收口径 |
|
||
|---|---|---|---|
|
||
| P0 | 新手引导 | 首次进入选择 3 个兴趣主题；可跳过 | 90% 以上测试用户可在 60 秒内完成并进入内容页 |
|
||
| P0 | 发现内容 | 推荐流、主题筛选、关键词搜索、内容详情、收藏 | 100 条以内内容加载首屏 ≤ 2 秒（常规 4G/Wi-Fi 测试） |
|
||
| P0 | 知识卡片 | 每日精选、话题筛选、详情页、AI 追问入口 | 每张卡片可完整阅读、收藏并产生可追踪事件 |
|
||
| P0 | 个人中心 | 微信授权后的基础资料、收藏、浏览记录 | 用户可查看并删除自己的收藏/记录 |
|
||
| P0 | 内容后台（最小） | 内容录入、上下架、标签/封面/来源维护 | 运营同学无需改代码即可新增一条内容 |
|
||
| P0 | 数据埋点 | 首次打开、兴趣选择、内容曝光/点击/完成、收藏、AI 调用 | 每个核心事件带匿名用户标识、时间、内容 ID |
|
||
| P1 | 数学人生 | 首发只保留“第一章试玩 + 存档 + 完成页” | 5 名测试用户可不经讲解完成一条分支 |
|
||
| P1 | AI 助教 | 限次、敏感词兜底、内容上下文问答 | 90% 的测试问题在 8 秒内返回；异常时给出可理解提示 |
|
||
| P2 | 专业模拟器 | 仅保留为后续专题，不进入首发导航 | 进入下一阶段前以试点反馈决定是否开发 |
|
||
|
||
### 明确不做（首发保护范围）
|
||
|
||
- 用户自行上传视频、评论区、私信、排行榜、付费体系。
|
||
- 全量 8 章互动小说、多结局系统、角色好感度可视化。
|
||
- 推荐算法、复杂社交关系、跨校内容平台。
|
||
- 账号密码系统；首发使用微信授权与最小化用户信息。
|
||
|
||
## 4. 关键用户旅程
|
||
|
||
### 旅程 A：新用户第一次获得价值
|
||
|
||
1. 从社团/校园海报/朋友分享进入小程序。
|
||
2. 选择“AI、医学、游戏”等至少 3 个兴趣主题。
|
||
3. 看到与主题匹配的内容卡，阅读/观看一条。
|
||
4. 收藏、追问 AI，或点击“再看一条”。
|
||
5. 在个人中心看到记录，并收到下一次可回访的内容入口。
|
||
|
||
### 旅程 B：回访用户
|
||
|
||
1. 打开小程序后看到“今日数学发现”或上次未完成内容。
|
||
2. 在 3 次点击内进入内容详情。
|
||
3. 完成阅读、收藏或 AI 追问后，记录行为并给出下一步。
|
||
|
||
### 旅程 C：内容运营
|
||
|
||
1. 在后台创建内容，填写标题、摘要、主题、封面、来源与版权状态。
|
||
2. 保存为草稿并预览。
|
||
3. 经负责人审核后上线；必要时可立即下架。
|
||
|
||
## 5. 建议团队结构（7–8 人）
|
||
|
||
| 角色 | 建议人数 | 核心责任 | 暑期关键产出 |
|
||
|---|---:|---|---|
|
||
| 产品负责人 / 项目经理 | 1 | PRD、排期、需求决策、用户访谈、验收 | 版本路线图、PRD、周报、测试结论 |
|
||
| UI/UX 设计师 | 1 | 小程序信息架构、交互原型、视觉系统、可用性测试 | Figma 原型、设计规范、开发标注 |
|
||
| 小程序前端工程师 | 2 | 页面、状态、组件、性能与真机兼容 | 小程序客户端与组件库 |
|
||
| 后端工程师 | 1–2 | 用户/内容/收藏/埋点 API、CMS、部署 | 后端服务、数据库、管理端 |
|
||
| 内容策划 / 运营 | 1 | 内容选题、编辑、审核、试点拉新 | 首发内容库、运营日历、版权台账 |
|
||
| 测试 / 数据（可由产品或后端兼任） | 0–1 | 用例、真机测试、埋点校验、反馈归纳 | 测试清单、数据看板、问题单 |
|
||
|
||
**7 人最小配置**：产品 1、设计 1、前端 2、后端 1、内容运营 1、测试/数据 1。
|
||
**8 人推荐配置**：增加 1 名后端或内容运营，取决于团队更缺“技术交付”还是“持续内容”。
|
||
|
||
## 6. 暑期 8 周建议节奏
|
||
|
||
| 周次 | 目标 | 可验收产物 |
|
||
|---|---|---|
|
||
| 第 1 周 | 需求确认与用户访谈 | PRD v1、范围冻结、低保真原型、10 位目标用户访谈提纲 |
|
||
| 第 2 周 | 设计与技术方案 | 高保真原型、接口清单、数据模型、内容模板、埋点方案 |
|
||
| 第 3–4 周 | P0 开发 | 可用的发现/知识/收藏/个人中心，联调环境 |
|
||
| 第 5 周 | 后台、AI、埋点与内容导入 | 内容可配置、核心事件可查询、首批内容入库 |
|
||
| 第 6 周 | 内测与修复 | 20–30 人封闭测试、问题清单关闭率 ≥ 90% |
|
||
| 第 7 周 | 小范围试点 | 首发包、隐私说明、审核材料、试点数据 |
|
||
| 第 8 周 | 复盘与上线决策 | 指标复盘、v1.1 Backlog、是否公开发布的结论 |
|
||
|
||
## 7. 成功指标（需在评审中确认基线与目标）
|
||
|
||
| 指标 | 建议定义 | MVP 目标（建议值） |
|
||
|---|---|---:|
|
||
| 激活率 | 首日完成兴趣选择且打开 1 条内容的用户 / 新用户 | ≥ 60% |
|
||
| 首次价值达成 | 首次会话中阅读/观看 ≥ 1 条内容，或完成 1 次收藏/AI 追问 | ≥ 70% |
|
||
| D1 留存 | 次日再次打开的激活用户 / 激活用户 | ≥ 25% |
|
||
| 内容交互率 | 收藏、AI追问或分享 / 内容详情浏览 | ≥ 15% |
|
||
| 内容有效性 | 试点问卷中认为“对理解数学的实际用途有帮助”的用户比例 | ≥ 70% |
|
||
| 稳定性 | 核心流程无阻断错误的测试会话比例 | ≥ 99% |
|
||
|
||
> 注：这是试点建议目标，不应被当作已验证事实；第 1 周用户访谈后可调整。
|
||
|
||
## 8. 技术与合规前置条件
|
||
|
||
- 小程序端建议独立实现，不直接把 Flask 网页嵌入 WebView；可复用数据模型、API 设计和内容素材。
|
||
- 服务端需从 SQLite 演进到适合部署的数据库与对象存储方案（具体选型待技术负责人评估）。
|
||
- AI Key 只存在服务端环境变量，绝不能写入小程序端或仓库。
|
||
- 视频/图文须维护来源、作者授权、版权状态及下架机制。
|
||
- 首发前准备隐私政策、用户协议、未成年人保护说明、内容投诉/反馈入口；具体要求以微信平台和适用法规的最新规则为准。
|
||
|
||
## 9. 需求评审议程（60–90 分钟）
|
||
|
||
1. **5 分钟：目标对齐** — 这个暑期要验证什么，而不是“想做什么”？
|
||
2. **15 分钟：目标用户与场景** — 是否同意“中学生 + 大学新生”为首发核心？
|
||
3. **20 分钟：范围取舍** — 逐项确认 P0/P1/P2，尤其是剧情与专业模拟器是否进首发。
|
||
4. **15 分钟：内容与运营** — 首发内容数量、来源、审核人、更新频率。
|
||
5. **15 分钟：技术与合规** — 小程序架构、账号、数据、AI、审核与发布责任人。
|
||
6. **10 分钟：团队与排期** — 确认每个角色负责人、每周例会和验收机制。
|
||
|
||
## 10. 必须由你确认的决策题（PRD Discovery）
|
||
|
||
1. **核心问题**：你更想解决“学生觉得数学无用/无趣”，还是“学生不知道数学专业和真实行业的联系”？只能选一个作为首发主问题。
|
||
2. **首发用户**：首发优先服务初高中生，还是大学新生？是否限定某所学校/城市做试点？
|
||
3. **暑期成果**：8 周结束时，你最希望拿到的是可公开发布的小程序，还是 20–50 人验证后的可用试点版？
|
||
4. **成功标准**：你愿意用哪一个指标作为第一优先级：留存、内容完成率、AI 对话使用率，还是校园试点人数？
|
||
5. **内容来源**：首发 30–50 条内容由谁生产/审核？是否已有明确授权？
|
||
6. **剧情定位**：数学人生是首发的差异化主角，还是上线后再测试的实验模块？
|
||
7. **团队约束**：7–8 人中已有的技术、设计、运营成员各有几位？每人每周可投入多少小时？
|
||
8. **预算与资源**：是否有云服务、域名、主体、小程序认证、AI 调用和内容制作预算？
|
||
|
||
## 11. 评审后的下一步
|
||
|
||
你确认第 10 节的决策后，产出正式《数学脑微信小程序 MVP PRD v1.0》，严格包含：执行摘要、用户体验与功能、AI 要求、技术规格、安全隐私、分阶段路线图、风险、用户故事与逐项验收标准；并再拆成 Epic、迭代 Backlog 和 8 周排期。
|