从倒计时到复盘：JLPT Sprint Desk 的学习闭环设计

备考 JLPT 最容易失控的地方，不是“今天有没有学”，而是学了之后很难判断：时间花到哪里了？薄弱项有没有真的被照顾到？离考试越来越近时，今天的计划还适不适合继续执行？

JLPT Sprint Desk 就是围绕这个问题做的一张学习驾驶舱。它不是单纯的 todo list，而是把「目标设置 → 自动生成计划 → 每日记录 → 复盘分析 → 导出备份」串成一个闭环，让备考从“凭感觉努力”变成“看数据调整”。

一眼看到今天该做什么

总览页的核心不是堆功能，而是帮用户快速回答三个问题：

• 距离考试还有多少天？
• 今天要投入多少时间？
• 下一步最该打开哪个页面？

在截图里的示例档案中，N1 考试还剩 25 天，今日目标是 120 分钟，最近累计投入 12.5 小时。右侧同时显示 7 天趋势：学习 6 天、投入 750 分钟、平均完成 87%。这类数字不会替代学习本身，但能很快暴露节奏是否稳定。

总览页下方的“今日学习循环”会把计划拆成可执行任务：复盘昨日、汉字词汇、文法、读解、听力、错因记录。每项任务都有时间预算，避免一天的计划变成一坨模糊的“多学点”。

计划不是日历，而是预算

计划页把用户填写的等级、考试日期、每日时间、薄弱模块和教材偏好转成一份 14 天可见、全周期可滚动的学习计划。

这个页面最有价值的地方是“合理性体检”。比如当前样例里，系统会根据剩余 25 天、工作日 120 分钟、周末 210 分钟、阅读/听力/语法薄弱等条件，计算：

• 每日平均目标是否充足
• 词汇和文法预计还要多少天完成
• 复习窗口是否被压缩
• 模块时间预算是否偏斜

右侧的学习预算饼图很直观：听力、阅读、语法占比较高，符合这个档案的薄弱项设置。下方还有最低可执行版，用来处理忙碌日或状态差的日子，让计划不会因为一天崩掉就整盘作废。

记录要快，也要留下颗粒度

每日记录页的设计目标是两分钟内完成，所以它只追关键字段：各模块用时、完成度、正确率、错因、超时原因和明日第一步。

这些记录不是为了“打卡好看”，而是给后面的分析页喂数据。比如同样是学习 120 分钟，如果 80 分钟都被读解定位拖走，系统应该给出的建议就不是“继续努力”，而是“降低读解任务粒度，做限时定位训练”。

复盘页把努力翻译成判断

复盘分析页是整个项目最像“驾驶舱”的地方。顶部先给结论，再给图表。

示例数据里可以看到：

• 最近 7 天记录 6 天，中间有 1 天缺口
• 7 天投入 750 分钟，距离目标 840 分钟还差一点
• 平均完成 87%，计划健康分 86
• 工作日平均 134 分钟，高于 120 分钟目标
• 周末平均 80 分钟，明显低于 210 分钟目标

这组数据给出的判断很明确：平日节奏不错，周末并没有承担预期中的加量任务。对真实备考来说，这比一句“最近状态还可以”有用得多。

找到真正吃时间的模块

模块投入深度分析把最近记录按汉字、词汇、语法、阅读、听力汇总。

截图里的 750 分钟中，阅读占 220 分钟，是最高投入模块；语法 175 分钟、听力 160 分钟紧随其后。这正好说明用户把时间放在了薄弱项上，但也暴露了一个问题：汉字只有 50 分钟，长期可能变成新的短板。

错因热力分布则把“为什么错”拉出来看。样例中“定位慢”出现 4 次，“听漏关键词”出现 3 次，“接续形式”出现 2 次。这样下一轮计划调整就不必靠回忆，而是可以直接围绕最高频错因做训练。

技术上保持轻量

这个项目的技术栈很克制：

• React 19 + TypeScript + Vite
• React Router Hash Router，适合静态部署
• 纯 CSS 变量系统，没有引入 UI 框架
• SVG 自定义图表，避免为了几张图拉重型图表库
• React Context + localStorage 做默认本地持久化
• Supabase 云同步作为可选能力

我喜欢这个取舍：默认数据只存在浏览器 localStorage，用户不用注册账号也能直接开始；需要跨设备时，再接入自己的 Supabase 项目。对学习工具来说，这种“本地优先、云同步可选”的模式很舒服。

它解决的不是学习焦虑，而是反馈延迟

JLPT 冲刺期最怕的是反馈太晚：等到刷完几套题才发现听力一直没补上，或者考前一周才意识到复习窗口被新内容挤没了。

JLPT Sprint Desk 的思路是把反馈提前到每天：今天记录，明天调整；本周偏科，下周修正。它不承诺替你通过考试，但它能把备考过程里的盲区照亮，让每一次投入都更容易被看见、被解释、被修正。

这也是我觉得它最有价值的地方：不是把学习变得更复杂，而是把复杂的备考状态压缩成几个能行动的判断。