2025 年的项目开始离开单纯的课程环境：图床要处理存储和转换，文件平台要处理分片和权限，设备项目要面对网络和状态，模型项目要解释数据和指标。它们的共同点，是“页面能点”不再足够。
我在 thus-note 上花的时间，让“记录”这件事变得具体。一个快速输入框背后有本地存储、导入、同步、搜索和版本；功能越克制，越需要把数据生命周期想清楚。后来我更能理解，极简需要少写按钮，也要把复杂性放在不打扰用户的地方照看。
图床 Snaply 看起来最有个性，工程问题却最普通：原图放哪里，格式转换失败怎么办，AI 标签能不能修改，换部署方式以后链接是否稳定。Idrop.in 则把这些问题放大成任务、分片、回收、统计和审计。项目越接近真实使用，越不能只展示一条成功路径。
模型和硬件项目也提醒我尊重证据。一个漂亮的推理图不能证明诊断能力，一个准确率不能替代数据划分，一个网页上的“已发送”不能证明设备已经响应。把演示、模拟和真实结果分开写，文章会少一点热闹，却更接近工程。
这一年还留下许多没有公开的草稿。它们有当时的焦虑和想象，但缺少提交、截图或原始记录支撑。把它们留在后台不代表否定过去，只是承认记忆有边界，公开文字应该比私下感想更谨慎。
2025 的关键词，是把项目放回它们会遇到的世界：网络会断，数据会错，用户会迟疑，维护会落到某一个具体的人身上。代码从这里才真正开始变得有重量。
年末回看时，我也把“做过”和“留下”分开。做过的项目很多，真正留下的可能只是一个稳定的脚本、一份能恢复的备份，或者一段终于能解释清楚的文档。它们不壮观，却比标题里的成长更可靠。
这一年我也逐渐接受，项目的价值不只在发布当天。一个接口被别人调用以后，兼容性就是承诺；一份数据被保存以后，备份和删除就是责任；一个功能无人使用时，停止维护也是一种判断。
所以我现在整理项目，会把“已经实现”“已经验证”和“只是计划”分成三栏。这样回看时不会把愿望误读成成果，也不会因为某个小工具不够热闹，就忽略它确实替我减少过一次重复劳动。
我也开始给项目做一张很小的状态表：代码是否能构建，最小路径是否能跑通，数据是否有备份，哪些功能只是设计稿。状态表没有漂亮的图，却能防止年末回顾时把“曾经想做”写成“已经完成”。
项目放回真实世界以后，暂停也需要记录理由。依赖变得难以升级、数据来源不再可用，或者维护成本超过了它解决的问题，都可以成为停止条件。留下这几行说明，未来重新打开时就不必把停止误读成失败。