2023 年留下来的东西并不整齐：几篇数据库课程笔记、一段 Node.js 服务练习、一些自动化脚本，还有后来重新打开时已经看不太懂的配置。它们不像一个完整项目，却组成了我第一次认真保存代码的方式。
那时我更在意“页面能不能打开”。数据库章节写完以后，习惯是把答案和命令贴在文档里；服务跑起来以后，习惯是把终端关掉。问题往往在第二次打开时出现：端口忘了，依赖版本变了，某张表为什么这样设计也记不起来。代码没有消失，背景却丢了。
数据库学习让我第一次看见结构的价值。表、索引、完整性和权限不是考试里的名词，它们决定数据能不能被修改、被找到和被解释。课程练习很小，但它们让我开始注意“谁能改什么”以及“错误应该在哪一层被挡住”。
Node.js 练习则把我推到另一端：请求、路由、部署和日志连在一起以后，一个缺少校验的接口很快就会变成一串难定位的问题。把服务放到网络上以前，至少应该知道它监听在哪里、哪些端口需要公开、失败以后怎样重新启动。
这一年也留下了不少只适合私下保存的草稿。它们有当时的情绪，却没有足够证据成为公开文章。现在回看，我不再把“写过”当成“值得发布”，而是把它们当作后来学习的底稿。
2023 年的关键词不是成长，也不是逆袭。更准确地说，是开始把东西做出来，再慢慢学着为它们留下说明。很多后来更复杂的项目，都从这份不完整但真实的记录开始。
如果重新整理那年的目录，我会给每个练习补三行说明：它解决了什么问题、怎样运行、哪里没有完成。这样做并不会把作业变成产品，却能让未来的自己少花一晚上猜环境。
后来我重新看这些目录，最先补的更先要补的是入口，而不是新功能。一个练习至少应该有运行命令、依赖版本和一段说明，告诉未来的自己它当时想验证什么。没有这三样，代码即使还在，重新运行也像是在考古。
这也是我后来愿意把小项目放进同一个归档里的原因。它们不需要被包装成“完整产品”，只要诚实说明做到哪里、没有做到哪里，就已经比一张只写着完成的清单更有用。
我后来还给旧仓库补了一份最小运行说明：使用的 Node 版本、安装命令、启动入口和一次可以观察到的请求。说明不需要长，关键是让它和代码一起变化。依赖升级以后，先在干净目录重新安装，再把结果写进记录，避免只在原来的 node_modules 里得到“可以运行”的错觉。
这些小补丁没有让 2023 年的练习变成产品，却让它们从一次性作业变成了可以回看的样本。以后再遇到新的框架或服务，我仍然会先把入口和停止条件写下来，功能反而会在边界清楚以后变得更容易。