笑技先说清楚一个事，这不是什么公司或者团队发的活动通知，也不是噱头。“DHU上机打卡D24”是我个人的一个小项目，严格来说是给我自己定的规矩——每天上机操作、写代码、做实验，然后打卡记录，到今天正好第24天。用DHU这个缩写，是因为我熟悉的一个场景里大家都这么叫某个校区机房，但这不是重点，重点是我用24天验证了一件事：想靠“自律”养成技术习惯，光靠意志力大概率会翻车，真正能让人坚持下来的是把打卡变成一个低成本、可复盘、有反馈的闭环。这篇文章就把我这24天怎么设计、怎么执行、踩过哪些坑，完整拆开来讲。如果你也是自学编程、准备上机考试、或者单纯想逼自己每天碰一碰代码的人，这篇对你应该有参考价值。
1. 内容整体设计与思路拆解
1.1 为什么是“D24”而不是“D7”或“D30”
先回答一个最表面的问题：为什么打卡要卡在24天这个数字上？说实话，我一开始定目标的时候也没想过要精确到24，原计划是21天，因为大家都知道那个“21天习惯养成”的理论。但实际操作下来，我发现21天其实卡在一个很尴尬的位置——第20天到第23天这段时间，正好是新鲜感耗尽、身体和大脑都开始产生“已经够了”信号的时候。如果我在21天就停下来，大概率第三天就会松懈回老样子。
所以我临时把目标延长到了30天，但到了第24天出现了一个很有意思的现象：习惯已经开始自动化了。具体表现是，到了晚上固定的时间点，我的手会下意识去摸键盘，打开终端，不需要再给自己做心理建设。于是我把这个节点单独拎出来复盘，觉得“24天”比“21天”更像一个真实的习惯固化点。当然这没有严格的科学依据，就是个经验值，但对个人来说，D24代表的意义是：已经渡过了最难熬的那一段，后面的坚持成本会低很多。
1.2 打卡内容怎么选才不会三天打鱼两天晒网
打卡最怕的一件事情就是“不知道今天该干什么”。如果每天的内容都是临时想，时间全浪费在“想”上面了。我的做法是把上机内容拆成四个固定模块，每天随机组合，确保每天的打卡都有新鲜感，又有延续性：
- 基础练习：比如数据结构中的链表、二叉树、排序算法，选一题写一遍，不求难，求熟练。
- 项目推进：给自己定了一个小项目，每天往上面加一个功能点，有点像搭积木，每天都有可见的产出。
- 读书笔记转实践：把当天看的书上代码片段手动敲一遍，不能复制粘贴，敲的过程就是理解的过程。
- 踩坑记录：把当天遇到的报错、卡壳、诡异现象记录下来，附上解决过程。
这套组合的好处在于：如果某天特别忙，就只做“基础练习”一个模块，10分钟也能完成打卡，不会断档；如果某天状态特别好，可以把四个模块全做完，打卡记录里就写得满满当当。这样设计是为了回避一个常见问题——把打卡变成负担，最后为了打而打。
1.3 打卡记录工具的选型逻辑
打卡记录这件事，我前后试过三种方案：手写笔记本、手机备忘录、GitHub仓库。最终长期使用的是第三种——用GitHub仓库来记录。
手写笔记本的问题在于检索困难，而且没法统计任何数据。手机备忘录虽然方便，但太容易在写完一条之后顺手刷走注意力。GitHub仓库的好处是，每天打卡本身就是一次git操作，这无形中又练习了一遍git的日常使用，真正把“打卡”和“上机”这两个动作绑在了一起，一箭双雕。
具体做法是单独建一个仓库，每天的内容以日期和序号命名，比如20240115_D24.md，里面写当天做了什么、花多久、遇到什么问题、明天打算做什么。每次更新就是一次commit，commit message就跟打卡的标题一样。这样坚持下来，git仓库的commit图就成了一面非常直观的打卡墙，一天没打卡，那个格子就是灰的，看着就很难受，反而成了坚持下去的一