Hulumath-Web-Demo/docs/产品文档/数学脑_暑期MVP_需求评审包.md

数学脑｜暑期微信小程序 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 周排期。