Archived

This repository has been archived on 2026-08-09. You can view files and clone it. You cannot open issues or pull requests or push a commit.

Files

T

Jacky 0a7207fa0e Demo

2026-08-08 15:49:06 +08:00

28 KiB

Raw Blame History

数学脑（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 独立规划）

需要老板拍板的开放问题

模拟器填充是 P0 还是 P1？ PM 和 Dev 一致认为120节点是内容工作而非产品创新，建议降为 P1 但仍排在合理优先级。如果老板坚持 P0，需在迭代1/2插队。
用户登录之后，要不要做"账号找回"？ 方案C是邀请码+密码，没有邮箱/手机绑定。如果用户忘记密码，目前没有找回机制。老板是否接受"联系运营手工重置"？
多剧本"状态继承"要不要做？ Dev 建议本期只做解锁+跳转，状态继承留到 V2。这会带来用户期望落差。如果老板认为继承是刚需，工作量需翻倍至8人天。
小程序壳的方向确认。 如果老板短期内要推微信小程序，前端架构可能需要提前往 Taro/uni-app 方向规划，不能继续在原生 JS 上堆功能。这会改变整个迭代计划。
预算确认：DeepSeek API 的 token 成本。 AI 多轮记忆上线后，每次对话的 token 消耗量将增加数倍。需确认月度预算上限。

一句话执行摘要

本次评审共通过12项（含5项有条件通过）、延后3项、驳回0项；核心结论是用登录+章节选择器"闭环体验"，用模拟器填充+低配星露谷"囤厚度"，小程序壳和双语作为长期战略暂不启动——2个月内可交付4个迭代，总工作量约38.5人天。

会议记录：PM & Dev 联合纪要 | 下次评审：迭代1完成后（≈第3周）

28 KiB Raw Blame History Unescape Escape