打卡工具死在第三天，问题出在「什么时候算断」

一句话

打卡这件事，绝大多数工具死在第三天。我把「什么时候算断」从人的脑子里搬到界面上，它才活得下来。

场景

给自己定一个有终点、有总量的学习目标：背完两千个单词、读完一本四百四十页的书、刷完四十节课。没有老师，没有同学，也没有人检查。

这类目标和「每天读书半小时」不一样——它有总量，所以进度算得出来；也正因为算得出来，一旦断掉，心里那笔账就再也平不了。

原来怎么做

手机备忘录加日历提醒。第一天记一行，第三天忘一次，第五天开始纠结要不要补记，第七天就干脆不打开了。

也试过现成的打卡工具，规则基本是「连续多少天」，漏一次从零开始。这条规则对健身也许合适，对「读完一本四百多页的书」就很残忍：昨天加班没读，今天打开发现连击清零——人会直接卸载。

真正的难在哪

以为最难的是记录，毕竟就是点一下。做起来才发现，三件难事没有一件是记录：

一、判断比记录难。「昨天没打卡」到底算断连、算休息、还是算滚进今天？规则说不清，使用者每天都要重新想一遍。凡是需要临场判断的工具，最后都会被放弃。

二、进度不能编。 第一版按「剩余量除以剩余天数」给建议量，但预计完成日一直显示不出来。后来才想清楚：样本不够的时候硬给一个数字，比不给更糟——使用者会照着一个错的节奏去安排时间。

三、数据会丢。 全部存在浏览器本地，意味着清一次缓存就没了，而这类工具往往要连着用几个月。

我的做法

规则只有三条，但每条都能在界面上找到解释：

• 每周一自动送一个休息日。 本周第一次漏打卡不算断连，界面给一张黄卡说明为什么；第二次才断，红卡写明已经滚进今天。等于把「允许人失误一次」写进规则，而不是交给自觉。
• 预计完成日只在有效样本够三天时才显示，否则直接写「暂无推算」。宁可少一个数字，不给一个假的。
• 累计记录到一定条数后，顶部出现一条温和的备份提示，一键导出。不做账号、不做云同步——那要后端，也就丢掉了断网可用。

取舍也说清楚：没有账号体系的代价，是换设备要手动导一次；换来的是打开就能用、不用注册，也没有任何数据离开这台机器。

结果与验收标准

• 单文件 1222 行、75 KB，零外部依赖，断网可用。
• 四个页签（今日 / 看板 / 周报 / 我的），手机底部页签、平板顶部导航、电脑左侧边栏三档布局；图标全部内联，不依赖任何字体。
• 核心算法（休息日、滚进、逾期、预计完成日、连续天数）做了七天全周模拟；交付说明记录 jsdom 全流程回归 59/59 通过。但测试代码没有入库——这是我该补的地方。
• 待填：真实使用者的连续使用天数与中途放弃率

验收标准我写的是两句话：界面上任何一张卡片的状态，都要能用一句话解释清楚「为什么是它」；样本不够时必须显示「暂无推算」，不许编。

可复用的方法论

1. 把模糊判断写成明确规则，并且把规则显示在界面上。 使用者不需要记住规则，只需要看懂今天这张卡。
2. 宁可少给一个数字，不给一个看起来合理的假数字。 数据不足就说不足，这比「智能估算」更值得信任。
3. 允许一次失误的机制，比连续打卡更能留住人。 惩罚性设计放在需要坚持几个月的场景里，一定会被卸载。

能力标签

原生 HTML ｜ 单文件架构 ｜ 本地存储 ｜ 内联图标 ｜ 手写图表 ｜ 三档响应式 ｜ 无接口调用

依据

• 行数、体积、零依赖、页签、响应式与验证结论：../11 MeiRiRenWu/overview.md
• 该项目目录下只有两个文件（../11 MeiRiRenWu/index.html 与 ../11 MeiRiRenWu/overview.md），据此确认测试代码未入库