408 lines
28 KiB
Markdown
408 lines
28 KiB
Markdown
# 数学脑（MathBrain）— 内部需求评审会议纪要
|
||
|
||
---
|
||
|
||
## 会议信息
|
||
|
||
| 项 | 内容 |
|
||
|---|---|
|
||
| 日期 | 2026年7月12日（周日）14:00–14:45 |
|
||
| 地点 | 远程 · 腾讯会议 |
|
||
| 参会人 | **PM**（产品经理，3年教育产品经验）、**Dev**（全栈开发，5年 Flask/前端经验） |
|
||
| 会议目标 | 逐条辩论 P0/P1/P2 需求清单，形成可交付排期 |
|
||
| 当前版本 | MVP v8.0（已上线：莫兰迪 UI、剧本广场、立绘系统、葫芦侠行93节点） |
|
||
|
||
---
|
||
|
||
## 辩论实录
|
||
|
||
### P0-1: 数学专业模拟器完整数据填充（8学期120节点）
|
||
|
||
**PM：** 我先讲这个。模拟器现在是半成品——只有60个节点，覆盖大概2年的内容。但这个功能是我们"数学人生"板块的第二引擎，用户点进去玩到一半就断了，体验非常差。我主张把8学期120节点一次性填完。这不是纯内容工作——每个节点的 choice 分支、属性影响、结局判定，这些都有逻辑骨架，我们只是把血肉填进去。
|
||
|
||
**Dev：** 你说的"只是填血肉"，我不同意。我先问你：120个节点，每个节点平均3段叙事文本、2-3个选项、effects 数值设计——你用 AI 生成初稿也得人工调，对吧？你算过没有，60节点→120节点，按当前 seed_simulator.json 的密度来看，每个节点需要约15分钟调优，这就是30人时。但这不是纯体力活——你剧情分支树的平衡性要不要测？gpa/interest/skill 三属性的数值曲线要不要调？现在 engine 的节点跳转是硬编码在 JSON 里的 `next` 字段，你在写的时候就容易出现死循环或者无法到达的结局。
|
||
|
||
**PM：** 我认可你说的数值平衡问题。但这恰恰说明我们需要一次性做完——如果分开做，第二期添加的节点必然会打破第一期的数值平衡，回头又要返工。120节点一个版本搞定，后续只做 bugfix。
|
||
|
||
**Dev：** 你说的是一个好理由，但我担心的是另一个问题：当前引擎的限制。你看 `app.js` 里的 `simState`，和葫芦侠行的状态机是两套独立的全局变量，但渲染逻辑共享同一套 `renderVNNode()`。这意味着如果你要在模拟器里加入"学期切换动画""成绩单展示""毕业典礼"这些仪式感节点，现有的 render 逻辑根本撑不住。你不光要填数据，你还得改前端渲染引擎。
|
||
|
||
**PM：** 等等，我说的就是填充数据，我没说要加学期切换动画。那些是 nice-to-have。
|
||
|
||
**Dev：** OK，那我们就说纯数据填充。120节点，我给4个工作日——前提是你给我一份完整的节点树草稿，我做 JSON 编码和数值校对。你自己写不了 JSON 的话，我给你一个 Excel 模板你填，我再转。
|
||
|
||
**PM：** 可以，我出剧情草稿 + 属性曲线设计，你做编码。那你觉得120节点够不够？
|
||
|
||
**Dev：** 120节点8学期，平均每学期15个节点，每个节点2-3个选择，分支深度大概3-4层——够用户玩30-40分钟，可以了。再多就是内容膨胀，边际效用递减。
|
||
|
||
| 结论 | ⚠️ **有条件通过** |
|
||
|---|---|
|
||
| 工作量 | PM 3天（剧情草稿+数值设计）+ Dev 4天（JSON编码+前端引擎适配） = **7人天** |
|
||
| 风险 | 🟡 中（数值平衡 + 引擎适配可能溢出） |
|
||
| 条件 | PM 先出完整草稿，Dev 评估后再开工 |
|
||
|
||
---
|
||
|
||
### 多剧本体系（NG架构：主剧本触发衍生剧本）
|
||
|
||
**PM：** 这个是我最近一直在想的大方向。现在我们只有《葫芦侠行》一个主剧本，93个节点8章，很完整。但如果用户玩完第八章某个结局后，系统提示"新篇章已解锁——《三力思外传》"，用户就会想继续玩。这就像 Netflix 的互动剧集，一个主剧火了之后出衍生剧。技术上也不复杂吧——就是多套 JSON 之间通过结局节点互相引用。
|
||
|
||
**Dev：** 不复杂？我跟你掰扯一下。当前代码：`storyData` 是一个全局变量，加载后 `vnState.currentNode` 指向一个节点，rendering 逻辑假设你在单一剧本里。你加了多个剧本，我需要：第一，剧本间状态转移——用户在剧本A里积累的 shuli/xiayi/xinzhi/favorability 要不要带到剧本B？带的话，怎么映射？不带的话，多剧本之间就是完全割裂的，用户感受不到"同一个世界观"。
|
||
|
||
**PM：** 这个确实要讨论。我的直觉是"部分继承"——像《巫师3》那样，前作存档影响续作开局，但不是1:1映射。比如葫芦侠行主剧本通关后，厚朴侠好感度超过30的玩家，在《厚朴侠前传》里解锁特殊对话线。
|
||
|
||
**Dev：** 行，就算我们解决了状态继承，第二个问题：存档系统。现在5个槽位只存 `currentNode` + `stats` + `favorability`。多剧本的话，每个槽位要不要存"哪个剧本的哪个节点"？存档面板要不要按剧本分组显示？这些全是前端改动。
|
||
|
||
**PM：** 等等，你说的这些都是必须改的吗？如果第一期我们只做最简单的方案：主剧本结局节点里加一个 `next_story` 字段指向另一个 JSON 的 start_node，然后系统弹一个提示"新剧本已解锁"，用户手动回剧本广场选择。不做状态继承，不做跨剧本存档。
|
||
|
||
**Dev：** 这个可以。改动量小很多：只是在结局渲染时读 `next_story` 字段，弹 toast。存档不用改。但你这样做完之后，用户期望就被拉高了——他们看到"新剧本解锁"，就以为是一个连续的体验，结果进去发现数据全清零。这个体验落差你能接受吗？
|
||
|
||
**PM：** 能接受。先给用户"发现惊喜"的感觉，后续版本再完善继承逻辑。MVP 只要解锁+跳转就行。
|
||
|
||
**Dev：** 那就这样。但我有一个技术债提醒：如果将来要做状态继承，现在的数据模型就需要预留 `cross_story_state` 字段，否则回头要重构存档表。
|
||
|
||
| 结论 | ⚠️ **有条件通过（MVP版本）** |
|
||
|---|---|
|
||
| 范围 | 仅做"结局节点→解锁新剧本提示→手动跳转"，不做状态继承 |
|
||
| 工作量 | **4人天**（Dev 3天引擎改造 + PM 1天新剧本草稿） |
|
||
| 风险 | 🟡 中（用户期望落差；数据模型需预留扩展） |
|
||
| 技术债 | 存档表需预留 `story_id` 字段 |
|
||
|
||
---
|
||
|
||
### 葫芦侠行2.0：Phaser.js 星露谷级互动
|
||
|
||
**PM：** 好，到我最想推的 feature 了。现在的葫芦侠行是纯文字+静态立绘，交互就是点按钮。我调研过 Phaser.js，它是 HTML5 2D 游戏框架，能做角色在场景里走动、对话气泡弹出、迷你游戏（比如射箭小游戏代替掷骰子判定）。你一个月装好 Phaser，做出第一幕——角色可在秉公习武堂地图上行走，和 NPC 对话，战斗用回合制数学题——绝对爆。
|
||
|
||
**Dev：** （吸一口气）我要泼冷水了。第一，你对 Phaser.js 调研到什么程度了？你跑过 demo 没有？
|
||
|
||
**PM：** 看了一些教程，API 看起来不复杂，scene-preload-create-update 的生命周期。
|
||
|
||
**Dev：** 好，那我问你几个问题。第一，我们现在的架构是 Flask 渲染 HTML，JS 接管 SPA 切换。Phaser.js 是一个独立的渲染引擎，它自己管理 canvas。你要把 Phaser 的 canvas 嵌到我们的 MathLife 面板里，CSS 怎么接管？safe-area 适配怎么做？390px 宽度的 canvas 上做地图行走，体验怎么样？
|
||
|
||
**PM：** Canvas 可以响应式缩放，Phaser 有 Scale Manager。
|
||
|
||
**Dev：** Scale Manager 是为游戏设计的，不是为嵌在 WebView 里的 SPA panel 设计的。我真的做过。你 Phaser 跑起来之后，`switchModule()` 切换到"发现"tab，Phaser 场景是 pause 还是 destroy？如果你 destroy 再 recreate，加载时间可能3-5秒。你让用户每次切换 tab 都等？
|
||
|
||
**PM：** 那就 pause，保持内存。
|
||
|
||
**Dev：** 移动端内存是个大问题。Phaser 跑一个 tilemap + 8个 sprite + 对话系统，大概占 80-120MB。加上我们现有的 DOM 渲染，低端 iPhone 可能直接闪退。这不是我说做不到，是移动端 WebView 的限制。
|
||
|
||
**PM：** 那你觉得时间线呢？不要只说不行，给一个你认为可行的方案。
|
||
|
||
**Dev：** 如果你真的要做互动地图，我的建议：不用 Phaser，用纯 CSS + DOM 做。就用 `position: absolute` 的图片+按钮放在一个有背景图的地图容器里，角色走动用 CSS transition。不需要 Phaser 的重型渲染。星露谷的感觉可以用像素风 CSS 背景图 + 莫兰迪调色来模拟。这叫"低配星露谷"——开发2周，用户体验能达到你期望的60%。
|
||
|
||
**PM：** 60% 不够，我要的是真正的沉浸感。纯 DOM 做不出来角色在场景里连续走动的感觉，只能做 warp（瞬移）。
|
||
|
||
**Dev：** 你要连续走动，Phaser 确实能给你。但我认真评估：Phaser 迁移 = 6周（学习1+搭建1+场景1+对话系统1+移动适配1+测试1），风险高。而且做完之后，以后所有人改剧情都得学 Phaser，不是改 JSON 那么简单。这是架构级变更。
|
||
|
||
**PM：** 好吧。我承认之前的1人月估计太乐观了。那我们先做你提的"低配星露谷"方案——CSS DOM 地图 + 瞬移交互，2周交付。如果用户反馈很好，再评估 Phaser 迁移。
|
||
|
||
**Dev：** 同意。但我建议我们在 CSS 方案里预留一个接口——地图走动的渲染抽象成一个 `renderMap()` 函数，将来如果要切 Phaser，只需要替换这个函数的实现。
|
||
|
||
| 结论 | ⚠️ **有条件通过（降级为CSS低配版）** |
|
||
|---|---|
|
||
| 方案 | CSS DOM 地图 + 像素风背景 + 瞬移交互（非 Phaser） |
|
||
| 工作量 | **10人天**（Dev 8天 + UI素材 2天） |
|
||
| 风险 | 🟡 中（像素风美术资源需设计；Phaser 作为 V3 选项保留） |
|
||
| 备注 | Phaser.js 完整迁移 → 至少6周，移入长期规划 |
|
||
|
||
---
|
||
|
||
### P1-1: 用户登录（邀请码+密码方案C）
|
||
|
||
**PM：** 这个我们拖太久了。老板定了方案C——邀请码+密码登录，未来接微信。现在的用户体验是 localStorage 生成一个 random userId，换设备数据全丢。收藏、历史、存档全没。这是核心竞争力问题：用户为什么要在我们的 App 里投入时间？他们需要"这是我的账号"的归属感。
|
||
|
||
**Dev：** 技术上我不反对，登录系统在 Flask 里很简单：一个 `users` 表加 username/password_hash/invite_code 三个字段，`/api/login` `/api/register` 两个接口，前端一个登录弹窗。核心工作量在：邀请码的生成和管理。谁生成？手动在数据库里插？还是做一个简单的管理页面？
|
||
|
||
**PM：** 第一期手动管理。我们一共也就几百个用户，运营同学在后台数据库里插邀请码就行。不需要管理页面。
|
||
|
||
**Dev：** 那还有个问题：登录后，用户现有的 localStorage 数据怎么迁移？如果用户已经玩了2小时葫芦侠行，有5个存档——一登录，存档要 merge 到服务器。merge 逻辑你想清楚了吗？
|
||
|
||
**PM：** 简单策略：注册时检测 localStorage 有没有存档，有的话自动上传到服务器端 `/api/simulator/save` 接口。之后服务器端为准。冲突不做合并且，提示用户选择保留本地还是服务器。
|
||
|
||
**Dev：** 可以。那大概：后端 `users` 表 + 登录/注册 API + session/cookie 管理 = 2天；前端登录弹窗 + localStorage 迁移 + 所有 API 加 `user_id` 鉴权 = 2天。总共4天，但我必须在每个现有 API 上加鉴权，这个测试覆盖面要大。
|
||
|
||
**PM：** 我觉得值。做了登录之后，收藏和历史才有真正的持久性。而且有了 user_id，我们后续的家长周报、学习数据统计才能做。
|
||
|
||
**Dev：** 同意。但我有一个建议：密码不要存明文，用 bcrypt hash。Flask 有 `werkzeug.security`，不需要额外依赖。
|
||
|
||
| 结论 | ✅ **通过** |
|
||
|---|---|
|
||
| 工作量 | **4人天** |
|
||
| 风险 | 🟢 低 |
|
||
| 依赖 | 无 |
|
||
|
||
---
|
||
|
||
### P1-2: 交互剧情章节选择器
|
||
|
||
**PM：** 这个需求非常明确：用户通关第八章某个结局后，回到剧本广场，每个已通关的章节可以自由重玩。比如我想重玩第四章的"论道大会"那段，不需要从头开始。这是互动小说类产品的标配——你看《隐形守护者》有章节选择，《Late Shift》有。
|
||
|
||
**Dev：** 技术上不复杂：首先需要一个"通关标记"——用户到达过哪些节点。我们在 localStorage 或服务器端记录一个 `reached_nodes: []` 数组。然后前端渲染章节选择器：8个章节卡片，已到达过的章节可点击，点击后直接 `vnState.currentNode = 章节入口节点ID`。问题是：用户的 stats（shuli/xiayi/xinzhi）怎么办？直接用当时的存档值？还是给默认值？
|
||
|
||
**PM：** 给"当时的存档值"。用户第一次通关时我们自动存一个"章节快照"（stats + favorability）。重玩时用快照。如果用户多次通关同一章，保留最近一次的快照。
|
||
|
||
**Dev：** 那存档表要扩展了。现在5个手动槽位之外，再加一个"系统自动快照"机制。这个改动量不大，但存储逻辑需要仔细设计：每个章节一个快照，8章 = 8条记录。
|
||
|
||
**PM：** 这个改动会影响现有存档面板吗？
|
||
|
||
**Dev：** 不影响，系统快照不显示在用户手动存档面板里。它只是一个"读取时用"的隐藏数据。
|
||
|
||
| 结论 | ✅ **通过** |
|
||
|---|---|
|
||
| 工作量 | **3人天**（Dev 2天快照机制 + 1天UI） |
|
||
| 风险 | 🟢 低 |
|
||
|
||
---
|
||
|
||
### P1-3: 知识卡片扩充 + 周更机制
|
||
|
||
**PM：** 目前只有8张知识卡片。8张。用户点"知识"tab，翻三下就到底了。"知识"是我们四大核心模块之一，8张卡片完全撑不起来。我主张用 AI 生成初稿 + 人工审核，每周3张，一个月到20张。周更需要建一个运营流程。
|
||
|
||
**Dev：** 内容生产我不反对，但我有几点要确认。第一，AI 出稿用的是 DeepSeek API 对吧？那这个生成是一次性脚本还是做成后台功能？
|
||
|
||
**PM：** 一次性脚本。每周跑一次，生成3张，人工改，然后插入 `knowledge_cards` 表。
|
||
|
||
**Dev：** 那第二点：现在的知识卡片渲染有没有问题？8张卡片的时候没问题，到了50张、100张的时候，前端是一次性加载所有卡片吗？
|
||
|
||
**PM：** 让我想想……现在应该是全量加载。
|
||
|
||
**Dev：** 对，`/api/knowledge` 不分页。到100张卡片的时候每次请求都要加载100条，每条卡片都有长文本内容。这要做分页。而且卡片的去重和质量控制——AI 生成的内容可能和已有的重复，也可能有事实错误。人工审核需要时间，运营同学懂不懂数学？
|
||
|
||
**PM：** 运营同学是数学专业出身，审核没问题。分页我们第一期不做，50张以内全量加载性能 OK。到100张再做分页。
|
||
|
||
**Dev：** 行。那我只需要写一个 `generate_knowledge.py` 脚本，调用 DeepSeek 批量生成，输出 JSON，人工审核后导入。前端暂不改。
|
||
|
||
**PM：** 等一下，我觉得周更应该做成自动化的——不是每次手动跑脚本。能不能在 Flask 里加一个定时任务？每周一自动生成3张草稿，状态为 `draft`，运营同学在后台审核通过后上线？
|
||
|
||
**Dev：** 定时任务需要 APScheduler 或者 celery。Flask 本身不支持。你确定要为了一个每周3张的内容生产引入新的依赖和调度框架？我觉得过度设计了。
|
||
|
||
**PM：** 好吧，手动脚本先跑着。
|
||
|
||
| 结论 | ✅ **通过（MVP用脚本）** |
|
||
|---|---|
|
||
| 工作量 | **3人天**（Dev 2天脚本 + PM 1天prompt优化） |
|
||
| 风险 | 🟢 低（纯内容生产，无架构变更） |
|
||
| 后续 | 卡片超过50张时前端加分页（另估1天） |
|
||
|
||
---
|
||
|
||
### P1-4: 视频数据真实化（54条占位→真实链接）
|
||
|
||
**PM：** 现在 seed_videos.json 里的54条视频，大部分是 YouTube/Bilibili 的占位 ID——点进去 404 或者根本不存在。这个必须改。我需要运营同学配合，从 B 站/YouTube 找真实的、高质量的数学科普视频，每个视频给真实 URL + 封面图 + 时长。
|
||
|
||
**Dev：** 这个完全不是开发工作。你让我改什么代码？数据替换而已。你给新的 seed_videos.json，我导入。一个 `DELETE FROM videos` + 重新 `load_seed_videos()`，5分钟。
|
||
|
||
**PM：** 我就是确认一下工作量，确实很小。但我想问：现在是每次重新导入都会 DELETE 全部对吧？如果将来用户在视频上有行为数据（收藏了某条视频），重新导入不会丢吗？
|
||
|
||
**Dev：** 好问题。现在的逻辑是 `INSERT OR REPLACE`，基于 `bvid` 或 `video_id` 唯一键。所以如果新数据的 ID 和旧数据不同，旧收藏就悬空了。解决办法：真实化的时候保持 video_id 不动，只替换 url、cover、duration 字段。需要我加一个 upsert 逻辑。
|
||
|
||
**PM：** 好，那就这样。
|
||
|
||
| 结论 | ✅ **通过** |
|
||
|---|---|
|
||
| 工作量 | Dev **0.5人天**（upsert逻辑），运营 **2人天**（54条视频筛选+校对） |
|
||
| 风险 | 🟢 低 |
|
||
| 备注 | 纯运营驱动，PM 负责对接 |
|
||
|
||
---
|
||
|
||
### P1-5: 工具箱 — 概率模拟器
|
||
|
||
**PM：** 这个是我最兴奋的 feature 之一。三个交互实验：蒙提霍尔三门问题、生日悖论、骰子实验。每个实验都是纯前端 Canvas 动画 + 跑1000次模拟显示概率收敛。用户玩三门问题，自己选一扇门，系统展示"换门vs不换门"的概率差异。这是知识模块里最出彩的内容——"动手做数学"。
|
||
|
||
**Dev：** 我先说我喜欢的：这三个实验确实适合用前端做，逻辑不复杂，每个实验核心代码不超过200行。Canvas 动画也不难。但我担心的是——你把这5个实验放在哪个模块？
|
||
|
||
**PM：** "知识"模块的子tab——现在只有"精选"和"话题"，加一个"工具箱"。
|
||
|
||
**Dev：** 那前端 Tab 切换逻辑要改。另外这三个实验的交互设计你有原型吗？蒙提霍尔——选门→主持人开一扇羊→你决定换不换→结果展示。这个交互流程要用 Canvas 还是 DOM？
|
||
|
||
**PM：** 我觉得混合最好：门用 Canvas 画（有开关门动画），按钮和文字用 DOM。生日悖论更简单，一个输入框 + Canvas 散点图。骰子实验用 Canvas 画骰子。
|
||
|
||
**Dev：** 可以。但我给你一个现实时间估计：三个实验，每个需要 Canvas 绘制 + 动画 + 概率计算 + 移动端适配。每个实验至少1.5天。总计4.5天，加上"工具箱"子tab的前端改造，**5人天**。不算多但也不少。
|
||
|
||
**PM：** 可以接受。但我还想加两个实验——贝叶斯更新可视化和随机游走。
|
||
|
||
**Dev：** 先做这三个，上线看用户反馈。如果数据好再扩。
|
||
|
||
| 结论 | ✅ **通过** |
|
||
|---|---|
|
||
| 工作量 | **5人天** |
|
||
| 风险 | 🟡 中（Canvas 动画移动端性能需验证） |
|
||
| 范围 | 先做3个，后续根据数据决定是否扩 |
|
||
|
||
---
|
||
|
||
### P2-1: PWA + 小程序壳
|
||
|
||
**PM：** PWA 可以让用户在 iOS/Android 上"添加到主屏幕"，离线也能用。小程序壳是老板提的方向——微信小程序用户量大。
|
||
|
||
**Dev：** PWA 技术上很简单：一个 `manifest.json` + 一个 `service-worker.js`，半天搞定。但 PWA 的离线体验需要你把所有静态资源（CSS/JS/图片/立绘/JSON）缓存——你现在立绘图片多大？
|
||
|
||
**PM：** 8个角色立绘 + 4个场景背景，大概……我没算过。
|
||
|
||
**Dev：** 如果超过10MB，iOS Safari 的 Service Worker 缓存就超限了。而且 PWA 在 iOS 上的体验远不如 Android——没有推送通知、没有后台同步。小程序壳完全是另一套技术栈——要么用 Taro 重写前端，要么做 WebView 套壳。无论哪种都是大工程。
|
||
|
||
**PM：** PWA 先做了，半天值得。小程序壳……我们先放放？
|
||
|
||
**Dev：** 同意。
|
||
|
||
| 结论 | ⚠️ PWA **有条件通过**（仅 manifest + SW，不做离线全量缓存）；小程序壳 **⏸ 延后** |
|
||
|---|---|
|
||
| 工作量 | PWA 0.5人天；小程序壳 ∞ |
|
||
| 风险 | PWA 🟢 低；小程序壳 🔴 高 |
|
||
|
||
---
|
||
|
||
### P2-2: 家长模式 + 周报
|
||
|
||
**PM：** 家长模式：在"我的"页面设置一个家长密码，进入后可以看到用户的学习数据——看了多少视频、答了多少题、知识卡片阅读量。周报每周自动生成一份摘要推送。
|
||
|
||
**Dev：** 先说家长模式——你说的"学习数据"我们现在根本没有。视频播放没有记录时长，知识卡片没有"已读"标记，工具箱的实验也没有统计。你要我先埋点，再做数据汇总，再做家长面板。埋点改所有模块，2天；数据汇总 API，1天；周报生成，1天。总共4天。而且周报"推送"——推送到哪？我们没有 WebSocket，没有邮件系统，没有公众号模板消息。你只能在 App 内做一个"周报信箱"。
|
||
|
||
**PM：** App 内周报信箱可以。但你说的对——数据基础太薄了。那我换个思路：第一期只做数据埋点，不展示。让行为日志记录更完整。第二期再做面板。
|
||
|
||
**Dev：** 这个我支持。埋点做好，后续家长面板、周报都能基于这些数据。但目前我们连用户登录都没做，埋点都是匿名数据，家长绑定不了孩子。
|
||
|
||
**PM：** 所以这个依赖 P1-1。
|
||
|
||
| 结论 | ⏸ **延后至登录完成后** |
|
||
|---|---|
|
||
| 工作量 | 预估4人天（分两期：埋点2天 + 面板2天） |
|
||
| 风险 | 🟡 中 |
|
||
| 依赖 | P1-1 登录 |
|
||
|
||
---
|
||
|
||
### P2-3: 好感度可视化面板
|
||
|
||
**PM：** 现在葫芦侠行有好感度系统（欧阳侠、Eddie侠、厚朴侠等8个角色），但用户完全看不到当前好感度数值——只能在节点选择时凭感觉。我想在"数学人生"页加一个好感度面板，用进度条或心形图标展示。
|
||
|
||
**Dev：** 技术上极简单：`vnState.favorability` 已经在全局状态里了，渲染8个进度条就是30行代码。但你确定要暴露数值？一旦用户看到"欧阳侠好感度 45/100"，沉浸感就被打破了。现在的设计是让用户凭感觉选对话，更接近真实社交。你加一个数字面板，用户就会"刷好感度"。
|
||
|
||
**PM：** …你说得有道理。那我退一步：不做数字面板，而是做"关系描述"。比如好感度 0-20 显示"萍水相逢"，20-40 显示"略有交情"，40-60 显示"惺惺相惜"，60-80 显示"生死之交"，80+ 显示"莫逆于心"。用文字而不是数字。
|
||
|
||
**Dev：** 这个好。而且文字描述可以随剧情进展动态变化，比数字更有情感。工作量很小：一个关系描述映射表 + 5行渲染代码。
|
||
|
||
| 结论 | ✅ **通过（文字关系描述版）** |
|
||
|---|---|
|
||
| 工作量 | **0.5人天** |
|
||
| 风险 | 🟢 低 |
|
||
|
||
---
|
||
|
||
### P2-4: 双语支持（i18n）
|
||
|
||
**PM：** 中英文切换。我们的内容——视频标题、知识卡片、剧情文本——都只有中文。但如果将来要出海或者给国际学校用，双语是刚需。
|
||
|
||
**Dev：** i18n 是架构级改动。前端所有硬编码的中文字符串都要抽出来变成 key-value 映射；后端 API 返回内容要加语言参数；最头疼的是剧情文本——93个节点，每个节点的叙事文本都要翻译。这怎么可能在 P2 阶段做？这不是技术问题，是翻译资源问题。
|
||
|
||
**PM：** 你说得对。那我们先不做双语，但代码层面预留 i18n 的可能性——前端字符串能不能从现在开始用变量引用而不是硬编码？
|
||
|
||
**Dev：** 可以。我可以定义一个 `I18N` 对象，现在里面只有 `zh`，未来加 `en`。新代码用 `I18N['key']` 取值。但历史代码全部重构不现实——只对新功能做。
|
||
|
||
| 结论 | ⏸ **延后（代码预留机制即可）** |
|
||
|---|---|
|
||
| 工作量 | 代码预留 1人天；完整双语 20+人天（含翻译） |
|
||
| 风险 | 🔴 高（翻译资源 + 全量重构） |
|
||
|
||
---
|
||
|
||
### P2-5: AI 助教多轮对话记忆
|
||
|
||
**PM：** 现在 AI 对话每次都是独立的——用户问"什么是导数"，AI 回答了；然后问"它和积分有什么关系"，AI 没有上文。DeepSeek API 支持多轮对话对吧？
|
||
|
||
**Dev：** 支持。API 层面传 `messages` 数组就行——`[{role: "user", content: "..."}, {role: "assistant", content: "..."}]`。前端维护一个对话历史数组，每次请求把整个 history 传给 API。改动量：后端 `/api/chat` 接口改一下接收 `history` 参数，前端维护 `chatHistory` 数组 + 渲染。1天。
|
||
|
||
**Dev（自己接话）：** 但是有一个隐性问题——token 消耗。每轮对话带全量 history，token 累积很快。如果用户聊了10轮，每轮回答500字，那就是约3000 token 的 history，加上新问题，请求成本翻3-5倍。DeepSeek 虽然便宜（¥1/百万token），但量大了也要注意。
|
||
|
||
**PM：** 做 token 截断——只保留最近5轮对话。超出就丢弃最早的历史。
|
||
|
||
**Dev：** 可以。还有一个体验问题：长对话历史会让 AI 回答越来越偏向历史语境，偏离当前问题。5轮是一个合理截断。
|
||
|
||
| 结论 | ✅ **通过** |
|
||
|---|---|
|
||
| 工作量 | **1人天** |
|
||
| 风险 | 🟢 低 |
|
||
| 备注 | 限制历史5轮，控制 token 成本 |
|
||
|
||
---
|
||
|
||
## 最终决策汇总表
|
||
|
||
| 编号 | 需求 | 结论 | 优先级 | 工作量（人天） | 风险 |
|
||
|------|------|------|--------|:--------:|:----:|
|
||
| P0-1 | 模拟器数据填充（120节点） | ⚠️ 有条件通过 | P0 | 7 | 🟡 中 |
|
||
| P0-2 | 葫芦侠行立绘+背景 | ✅ 已上线 | P0 | — | — |
|
||
| P0-3 | 存档面板+结局画廊 | ✅ 已上线 | P0 | — | — |
|
||
| — | 多剧本体系（MVP） | ⚠️ 有条件通过 | P0 | 4 | 🟡 中 |
|
||
| — | 葫芦侠行2.0（CSS低配） | ⚠️ 有条件通过 | P0 | 10 | 🟡 中 |
|
||
| P1-1 | 用户登录 | ✅ 通过 | P1 | 4 | 🟢 低 |
|
||
| P1-2 | 章节选择器 | ✅ 通过 | P1 | 3 | 🟢 低 |
|
||
| P1-3 | 知识卡片扩充+周更 | ✅ 通过 | P1 | 3 | 🟢 低 |
|
||
| P1-4 | 视频真实化 | ✅ 通过 | P1 | 0.5 + 运营2天 | 🟢 低 |
|
||
| P1-5 | 工具箱（概率模拟器） | ✅ 通过 | P1 | 5 | 🟡 中 |
|
||
| P2-1 | PWA | ⚠️ 通过（缩减） | P2 | 0.5 | 🟢 低 |
|
||
| P2-1b | 小程序壳 | ⏸ 延后 | — | ∞ | 🔴 高 |
|
||
| P2-2 | 家长模式+周报 | ⏸ 延后 | — | 4 | 🟡 中 |
|
||
| P2-3 | 好感度可视化 | ✅ 通过 | P2 | 0.5 | 🟢 低 |
|
||
| P2-4 | 双语支持 | ⏸ 延后 | — | 20+ | 🔴 高 |
|
||
| P2-5 | AI 多轮记忆 | ✅ 通过 | P2 | 1 | 🟢 低 |
|
||
|
||
---
|
||
|
||
## 建议排期（按迭代划分）
|
||
|
||
### 迭代1（第1-2周）：基础体验闭环
|
||
- P1-1 用户登录（4天）
|
||
- P1-2 章节选择器（3天）
|
||
- P1-4 视频真实化（0.5天 + 运营并行）
|
||
- P2-3 好感度文字描述（0.5天）
|
||
- P2-5 AI多轮记忆（1天）
|
||
- **合计：Dev 9人天（≈2周）**
|
||
|
||
### 迭代2（第3-4周）：内容厚度 + 知识模块
|
||
- P1-3 知识卡片扩充（3天）
|
||
- P1-5 工具箱概率模拟器（5天）
|
||
- P2-1 PWA manifest + SW（0.5天）
|
||
- **合计：Dev 8.5人天（≈2周）**
|
||
|
||
### 迭代3（第5-6周）：剧情体验升级
|
||
- P0-1 模拟器数据填充（7天，PM在第4周前交付草稿）
|
||
- 多剧本体系 MVP（4天）
|
||
- **合计：Dev 11人天（≈2.5周）**
|
||
|
||
### 迭代4（第7-8周）：视觉升级
|
||
- 葫芦侠行2.0 CSS低配版（10天）
|
||
- **合计：Dev 10人天（≈2周）**
|
||
|
||
### 后续（无固定排期）
|
||
- 家长模式+周报（依赖登录完成 + 数据埋点）
|
||
- 双语支持（仅代码预留）
|
||
- 小程序壳（需单独技术评审）
|
||
- Phaser.js 完整迁移（作为 V3 独立规划）
|
||
|
||
---
|
||
|
||
## 需要老板拍板的开放问题
|
||
|
||
1. **模拟器填充是 P0 还是 P1？** PM 和 Dev 一致认为120节点是内容工作而非产品创新，建议降为 P1 但仍排在合理优先级。如果老板坚持 P0，需在迭代1/2插队。
|
||
|
||
2. **用户登录之后，要不要做"账号找回"？** 方案C是邀请码+密码，没有邮箱/手机绑定。如果用户忘记密码，目前没有找回机制。老板是否接受"联系运营手工重置"？
|
||
|
||
3. **多剧本"状态继承"要不要做？** Dev 建议本期只做解锁+跳转，状态继承留到 V2。这会带来用户期望落差。如果老板认为继承是刚需，工作量需翻倍至8人天。
|
||
|
||
4. **小程序壳的方向确认。** 如果老板短期内要推微信小程序，前端架构可能需要提前往 Taro/uni-app 方向规划，不能继续在原生 JS 上堆功能。这会改变整个迭代计划。
|
||
|
||
5. **预算确认：DeepSeek API 的 token 成本。** AI 多轮记忆上线后，每次对话的 token 消耗量将增加数倍。需确认月度预算上限。
|
||
|
||
---
|
||
|
||
## 一句话执行摘要
|
||
|
||
> **本次评审共通过12项（含5项有条件通过）、延后3项、驳回0项；核心结论是用登录+章节选择器"闭环体验"，用模拟器填充+低配星露谷"囤厚度"，小程序壳和双语作为长期战略暂不启动——2个月内可交付4个迭代，总工作量约38.5人天。**
|
||
|
||
---
|
||
|
||
*会议记录：PM & Dev 联合纪要 | 下次评审：迭代1完成后（≈第3周）*
|