笑技先说清楚一个事，这不是什么公司或者团队发的活动通知，也不是噱头。“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图就成了一面非常直观的打卡墙，一天没打卡，那个格子就是灰的，看着就很难受，反而成了坚持下去的一个动力源。对于刚开始想尝试的同学，我建议不需要买任何付费工具，一个免费的GitHub仓库就足够了，关键是让自己所使用的记录工具本身也成为一个练习对象。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心细节解析与实操要点
2.1 上机环境怎么搭才顺手
上机打卡要想坚持下来，最容易忽略但影响巨大的是环境问题。我见过很多朋友说“没法坚持学习”，其实一部分原因是“不想打开电脑准备环境”，启动成本太高。所以24天里，我第一天干的事情就是彻底优化环境，把启动成本降到最低。如果你也想做类似的上机打卡，环境这一步千万别跳过。
我的环境配置思路可以总结成三条：
- 一键启动：把常用的开发环境、数据库、缓存服务全装进Docker容器里，写一个
start.sh，每次上机只需要执行这个脚本，10秒内进入能写代码的状态。如果你的机器配置不够好，不必勉强跑大型IDE，VS Code加远程SSH连接服务器就够用了。 - 目录结构固定：在电脑上固定一个
~/work/目录，里面按项目、日期、实验分成几个子目录，避免每次都在文件系统里翻来翻去。 - 备份全靠Git：所有代码和文档全部放在Git仓库里，至少推送到远程仓库一份。这样无论在宿舍、在机房还是在图书馆，换一台机器clone一下就能继续干活。
在这24天里，我确实遇到过硬盘损坏和误删代码的“惨案”，但都因为东西都推到了远程仓库而安然无恙。这一点我觉得比任何高效技巧都重要。
2.2 动手写代码前的“3分钟计划法”
很多人在上机的时候，一上来就开始噼里啪啦写代码，写了一半发现方向错了，又推翻重来。打卡的前几天，我也有这个问题。后来我强制自己在上机前花3分钟，先在本子上或者代码文件头部写清楚：
- 今天的目标是完成什么功能（一句话说清楚）
- 大概涉及哪些文件、哪些函数
- 预计怎么验证结果（比如“跑一遍测试用例”）
这一步叫“先想后做”，听起来老生常谈，但效果极好。为了直观对比，我做了一个小测试：前5天不写计划，直接上手，平均每天要返工2次以上；后5天强制写计划，返工率大概降到了0.5次。计划本身也不用很复杂，三句话左右就够。
2.3 打卡记录的具体操作流程
我每天打卡的固定流程是这样，大概15分钟到20分钟：
- 打开终端，进入
~/work/目录 - 写代码、做实验（这就是当天的主要“上机”内容）
- 每天结束时更新计划文件，把计划改成“已完成/未完成”并记录遇到的坑
- 执行
git add .、git commit -m "D24 完成XX功能"、git push - 看到GitHub上当天格子变绿，打卡完成
这里有个细节值得单说：commit message的写法。我强制自己用D编号 + 做了什么的格式，比如D24 实现快速排序的非递归版本或者D24 修复了登录接口的空指针问题。这样做的好处是半年后回溯提交记录时，一眼就能看出每天干了什么，不需要点进去翻代码。
2.4 样例行日志结构分享
下面是一份当天打卡日志的结构模板，供直接参考：
markdown复制# D24_20250115
## 今日目标
- [ ] 完成快速排序的迭代实现
- [ ] 阅读《算法导论》第7章，做笔记
## 实际完成
- [x] 完成快速排序的迭代实现，对比了递归版本和迭代版本性能差异
- [ ] 《算法导论》只读了一节，明天继续
## 遇到的问题
1. 递归转迭代时，栈的模拟搞错了，压栈顺序写反，导致无限循环。
2. 解决办法：参考了书上的例子，画了一遍调用栈，理清顺序后重写。
## 心得
- 递归转迭代的关键在于模拟调用栈，不要硬翻译，要先理解递归程式的执行流程。
每天坚持填写这个结构，会让打卡变得清晰，也方便自己随时回头查记录。
3. 实操过程与核心环节实现
3.1 第1天到第5天：从冲动期到第一个小成果
第1天的打卡内容很有意思——我啥也没干，就折腾环境。但折腾完之后，当天晚上写了一段极其简单的“Hello World”，然后郑重其事commit、push。动机很简单，我要确保“第一天”能成功打卡，先尝到一点甜头再说。这也是一个很管用的策略：第一次打卡的任务难度一定要低，低到不可能失败。别第一天就上来写红黑树，容易把自己劝退。
第2到第5天，我开始做“基础练习”，每天在LeetCode上挑一道简单题，然后强行用自己手写的数据结构来解题。比如第2天做“翻转链表”，我不用C++的std::list，而是自己定义节点、自己写遍历，这样虽然慢，但是能把基本功练扎实。第3天到第5天分别是查找算法、二叉树遍历、栈与队列的相互实现。到第5天的时候，我已经能明显感觉到写代码的速度变快了，手指和脑子开始合拍到一起。
3.2 第6天到第15天：项目推进期
环境跑通、手感回到之后，从第6天开始，我把主要精力放在一个小项目上——写一个“命令行记账工具”。为什么要挑这样一个项目？因为它的复杂度刚好合适：不太小（能练到文件操作、数据格式化、异常处理），也不太大（不会让人产生遥遥无期的挫败感）。每天加一个功能点的节奏非常舒适，比如：
- 第6天：搭骨架，实现add和list两个命令
- 第7天：加入简单的金额校验
- 第8天：把数据存储从“每次重写文件”改成“追加写入文件”
- 第9天：引入SQLite，把数据从文本文件迁移到数据库
- 第10天：做一个简易的报表输出，统计当月支出
到第15天的时候，这个命令行工具已经能跑了，界面虽然简陋，但基本功能都能用。这个过程里最重要的体会是：小步快跑带来的正反馈，完胜“憋大招”。每天都能看到新的产出，这种成就感是坚持打卡的燃料。
3.3 第16天到第24天：深度学习期
从第16天开始，我觉得基础操作已经稳定了，就开始补理论短板。我的做法是选一本有点深度的书，每天照着书里的代码敲，并加入自己的修改尝试。我选的是《算法导论》的排序章节，因为这部分内容对后续做项目太重要了，而且正好能和前面的基础练习呼应。
第16天，打卡内容是剖析归并排序，并实现一个原地归并版本。第18天，挑战快速排序的三路切分优化。第20天左右，我遇到了一个比较棘手的灵活性瓶颈：某个函数的接口设计得太死，想加功能就得推倒重来。于是我把“设计模式”加进了打卡计划，每天读一个小模式并重写一遍记账工具里对应的模块。到第24天的时候，我不光能写“能跑的代码”，开始能写出“有结构、好维护的代码”了。
为了说清楚这种“结构性提升”发生了什么，这里必须贴一段当时重构的关键代码示意。当时我写了一个简单的事件处理逻辑，一开始用if-else堆了三层，如下：
python复制def process_event(event):
if event["type"] == "click":
if event["target"] == "button":
do_button_action()
else:
do_other_action()
elif event["type"] == "key":
if event["key"] == "enter":
do_enter_action()
elif event["key"] == "esc":
do_esc_action()
第24天我按策略模式改写成了下面的结构，每一条分支变成一个独立策略，新增动作只需加一个策略类，不用改动主逻辑：
python复制class EventHandler:
def __init__(self):
self.handlers = {
("click", "button"): self._handle_button_click,
("click", "other"): self._handle_other_click,
("key", "enter"): self._handle_enter,
("key", "esc"): self._handle_esc,
}
def process_event(self, event):
key = (event["type"], event["target"] if "target" in event else event["key"])
handler = self.handlers.get(key, self._handle_unknown)
handler(event)
def _handle_button_click(self, event):
do_button_action()
def _handle_enter(self, event):
do_enter_action()
这段代码本身很简单，但改造过程中“识别坏味道、选择模式、落地重构”这一整套思路，正是靠前面每天固定打卡攒下来的手感完成的。没有前面的积累，直接看设计模式的书会很空，看不清这些模式解决的真实痛点。
3.4 用表格汇总24天打卡节奏分布
| 时间段 | 重心内容 | 每天平均时长 | 主要收获 |
|---|---|---|---|
| D1-D5 | 环境搭建 + 简单算法 | 1小时 | 环境顺手，手感恢复 |
| D6-D15 | 项目开发 | 1.5小时 | 完成一个可运行的工具，养成Git习惯 |
| D16-D24 | 理论学习 + 代码重构 | 2小时 | 补齐原理，提升代码设计能力 |
这个表可以看出打卡内容不是一成不变的，而是有明显的阶段感。阶段感的设置非常重要，因为人不能长时间做同一难度的事情。“简单—中等—进阶”的节奏既能保持挑战性，又不会让人太痛苦。
4. 常见问题与排查技巧实录
4.1 坚持不下去怎么办
D24以来，几乎每隔几天就会有“今天不想弄了”的念头。这种情况太正常了，我自己的应对方法主要是这两招：
- 降门槛：允许自己在“状态最差的一天”只做一个5分钟就能完成的任务。比如只写一个函数、只调通一个小脚本、只读5页书。关键是不能让打卡断掉，因为一旦断掉，第二天就会产生“昨天都断了一天，今天也不差这一天”的滑坡心理。
- 调整打卡时段：有的人适合早上打卡，有的人适合晚上打卡。我一开始是晚上打卡，但晚上总有舍友喊打游戏，注意力容易被分走。第10天左右我把打卡时间改到傍晚下课之后，人少安静，效率反而上来了。
一句话总结：坚持不是每天都做到100分，而是每天做到60分，但从不缺席。
4.2 上机卡壳卡到怀疑人生怎么办
在写迭代版快排和重构事件处理器的时候，我都撞到过“半小时写不出解决方案”的墙。大多数人卡壳的死法都差不多：一头扎进代码里改来改去，越改越乱，最后心态崩了。
我的排查流程是这样一个四步法：
- 停下写代码，先拿纸笔把当前的逻辑画一下。
- 画出数据流和函数调用关系。
- 找一个“最小可复现”的例子，亲手算一遍变量的变化过程。
- 找到卡点之后再动手改。
这个流程看起来简单，但效果异常好。人一着急就容易跳步，跳步就容易写出乱代码。每次卡壳的时候默念“先画图，再动手”，能省掉大量无效尝试的时间。
4.3 打卡记录丢失或者忘记提交怎么办
从D1到D24，我有两天险些“断卡”。一次是电脑没电关机，忘记保存就直接黑了；另一次是提交完代码忘了push到远程仓库，本地仓库也差点出问题。
结合这些真实翻车经历，建议做好三件事：
- 用Git自动提交：写一个简单的定时任务，每天晚上11点自动执行
git add -A && git commit --allow-empty -m "daily backup"。这样即使当天忘了手动提交，也有一个备份在。 - 多端同步：宿舍一台电脑，图书馆一台电脑，两个地方都clone同一个仓库。万一一边出问题，另一边还能顶上。
- 允许补卡：如果真的断了一天，不要懊恼，要么第二天补上，要么直接把编号变成D25，放过自己。打卡的目的是为了学习，不是为了制造焦虑。
4.4 内容纯度过低，打着打着开始刷手机怎么办
这是上机打卡最隐蔽的杀手。明明打开电脑准备写代码，结果10分钟后开始刷网页看视频。我管这种状态叫“打卡失灵”。后来我给自己立了一条规矩：上机期间手机放在拿不到的地方，电脑上不登录任何社交媒体。另外配合刚才提到的“3分钟写计划”法，因为一旦计划写下来，人就有了一个明确的方向，注意力就不容易跑偏。
5. 如果你想做类似的上机打卡，几点建议
5.1 怎么设计你自己的打卡周期
21天、30天还是100天，其实没有标准答案。我的看法是，第一个周期不要太长，建议先设14天。14天刚好能走完“兴奋期—回落期—回稳期”的完整弧线，而且即便中间有两三天划水，也不至于彻底摆烂。第一个14天如果顺利，再临时延长到30天，这样心理负担会小很多。我自己的D24就是这么走过来的。
5.2 内容规划的一个公式
打卡内容最容易踩的坑是“又大又空”。我曾经设过“今天学习Python”这种目标，结果坐到电脑前完全不知道该干嘛。后来我给自己定了一个公式：今天要写的代码 = 一个大功能拆成的小步骤 + 一个明确输出。比如“实现用户注册的密码加密存储”，这个任务具体到能写、能测、能提交，才是好的打卡任务。
5.3 什么时候该停止打卡
这可能是很多打卡博主不会提的话题。打卡不是目的，学习才是。如果你发现自己已经连续很多天在“为了打卡而打卡”，那就是时候停下来了。我给自己定的规则是：如果连续三天都没能写出让自己满意的东西，直接停止这个打卡计划，花一天时间重新规划，再开一个更适合自己的计划。
结尾留个避坑心得
最后分享一个从D24踩坑里总结出来的经验：这段上机打卡期间，我犯过最大的错误不是代码写得差，而是过于沉迷“每天都要产出一个能显摆的成果”。比如有两三天为了把打卡内容写得漂亮，我反复做那些已经掌握的基础算法，迟迟不碰真正需要克服困难的部分，一天下来看起来很充实，其实完全没有进步。后来我把打卡标准从“今天写了多少代码”改成了“今天解决了哪个曾经卡住我的问题”或者“今天弄懂了哪个以前没有完全理解的知识点”，整个打卡的质量立刻不一样了。如果你打算启动自己的打卡计划，建议从第一天就盯着“真问题”去打卡，而不是盯着“漂亮的记录”去打卡。这样等到你回头看每一天的记录时，才会觉得这些时间没有被白白耗掉。