第2篇：从0画出第一张蓝图——EJU备考APP核心功能MVP清单
一、用户痛点深挖：EJU考生到底卡在哪一步？ 我们曾以为“刷题不够多”是EJU备考失败的主因。直到2023年，团队联合东京、大阪、名古屋12所语言学校，对1,247名真实备考者展开结构化问卷 + 32场90分钟以上深度访谈（含屏幕共享录屏+错题本翻拍分析），才撕开理想主义假设的表皮——崩溃从来不是从放弃开始的，而是从一次无效点击、一页空白错题本、一个被删掉第4次的周计划开始的。 调研数据指向三个高频断点，它们像三道隐形玻璃墙，挡在“知道”和“做到”之间： “题海迷航”：76%的考生明确表示“能搜到真题，但无法判断哪套题匹配我当前N3中上/接近N2的水平”；更严峻的是，仅11%能准确说出自己近3次模考中重复出错的知识点类型（如「～にあたる」vs「～に当たる」的汉字书写混淆）； “错题黑洞”：平均每位考生手写错题本留存周期为5.7天，且76%在错题本停留时间＜90秒——多数人只抄题干、划答案，不标注错误原因，更无后续追踪； “计划脆性”：82%的考生承认“计划写得越细，放弃得越快”。他们平均每周手动调整学习计划3.2次，但其中82%的调整未带来实际行为改变（后台埋点显示：计划修改后24小时内，对应模块的实际练习完成率仅提升0.7%）。 为具象化这种割裂，我们绘制了对比场景图（见下图），左侧是教育机构宣传页上的“理想备考流”：目标清晰→计划自动同步→错题即时归因→能力雷达动态更新；右侧则是真实用户手机屏幕录屏拼接的“崩溃时刻链”：凌晨1:23，某考生反复刷新某题库网站，页面卡在“加载中…”；1:27，她退出App，打开Excel手动标红3个语法点；1:31，她关闭文档，微信发消息：“今天又没学成……” 这不是意志力问题，而是工具层缺失——当系统无法把“我错了”翻译成“我卡在动词使役形接续规则的第三变体”，用户就只能用疲惫对抗模糊。 二、MVP功能定义：三道红线筛出不可删减的核心能力 基于上述洞察，我们给MVP立下铁律三红线： 必须直击TOP3痛点中的任一核心断点（非泛需求）； 单功能可独立验证价值（可AB测试、可观测行为转化）； 开发周期≤2人周（拒绝“先搭中台再迭代”的幻觉）。 按此标准，我们砍掉了所有看起来“高级”但实则冗余的功能。例如： ❌ AI作文批改：用户测试中NPS贡献度为-23（大量用户反馈“批注太学术，看不懂怎么改”）； ❌ 直播课预约：仅12%用户在首周打开该Tab，且预约后实际参与率不足29%，属典型“伪启动动作”。 最终入选的三项能力，构成最小可行闭环骨架： 功能名称 解决痛点 验证方式 A/B测试初版效果 红线符合性 错题智能归因引擎 错题反复错，无归因路径 用户提交错题→返回知识点标签+教材页码 复练完成率↑41%，错题本有效使用时长↑2.8倍 ✔️ 全满足 动态难度题库 找不到适配日语水平的真题 每次答题后实时调整下一题难度系数δ N3水平用户首次模考正确率方差缩小63% ✔️ 全满足 计划韧性调节器 备考计划三天热度，缺乏动态反馈 计划偏离＞15%时，自动生成3种弹性方案 计划周完成率从44%→71%，且87%用户采纳推荐方案 ✔️ 全满足 关键决策逻辑在于：归因引擎不是“加功能”，而是重建认知接口——它把“这道题错了”转化为“你对『～てしまう』的语义强调功能理解偏差（教材P102），相似题已备好”。代码层面，我们采用轻量级规则引擎+小样本微调模型（仅1200条标注数据），规避大模型延迟与幻觉风险： # 归因引擎核心逻辑（简化版） def generate_diagnosis(question_id: str, user_answer: str) -> Dict: rule_match = match_grammar_rule(question_id) # 基于EJU真题知识图谱 if rule_match.confidence > 0.85: return { "label": rule_match.tag, # e.g., "て-form_emphasis" "source": f"《新完全掌握语法N2》P{rule_match.page}", "similar_questions": fetch_similar_by_tag(rule_match.tag, limit=3) } else: fallback_to_llm_fewshot(user_answer, question_id) # 仅兜底调用 三、最小闭环验证：从“能用”到“愿用”的关键转折点 MVP上线灰度期（500名种子用户），我们放弃传统“功能使用时长”指标，聚焦一个极简行为闭环： 用户提交错题 → 系统3秒内返回知识点标签+3道相似题 → 用户点击任一相似题即计为闭环完成。 ...