2026 年 4 月 13 日，我在备忘录里列了一张清单。
文件收集、短链、笔记、API 开放平台、统一认证，后面跟着各自的网址。那条记录写得很短，没有用户数，也没有一段适合放在产品介绍里的起源。它更像是一次盘点：这些年随手搭起来的东西，现在还有哪些留在网上？
几个月后，我按着清单重新打开它们。2026 年 8 月 1 日，六个公开页面在检查时都返回了 200：
六个 200 看起来很整齐，含义其实很窄。它只记录了那一次访问的结果。页面里的主要功能是否顺手，移动端有没有错位，说明文字是否过期，这些都要另外去看。至于有没有人长期使用，原来的备忘录没有留下信息，我也不准备替它补上。
当时可以确认的事情只有一件：这六个入口还在回应。
一张清单把几年压成了六行
网址排在一起，很容易让人把它们想成同一批产品。公开仓库里的时间却是散开的：cai-api、thus-note、idropin 和 caiths-auth 出现在不同阶段，技术选择和完成程度也各有差异。有的仓库说明写得比较完整，有的更像一个仍在调整的工具。
这些公开记录适合回答一些朴素的问题：代码大致在什么时候出现，页面和哪个项目有关，后来是否还有更新。再往前追问每个工具为何开始、期间改过几次方向，单靠仓库便不够了。那张备忘录同样没有保存完整过程。
那张清单只用几个词概括用途：文件收集、短链、笔记、API 和认证。它没有写这些工具因何开始，我也无法在这里还原一段起源。能看到的是几个范围不大的功能，分别落在六个入口里。
功能范围小，验收标准看上去也简单：入口能否打开，页面是否给出预期反馈。项目规模却不会替开发者留下说明。公开仓库里，有的 README 信息较多，有的只保留了很短的介绍；隔一段时间回来，需要的上下文并不因此减少。
公开仓库把代码留了下来，当时没有写进文档的取舍却很难从文件名里恢复。这是重新盘点时最明显的落差：六个页面占不了多少书签位置，理解它们却要分别捡回旧上下文。
可打开，离“还好用”有一段距离
重新检查时，“网址能访问”很容易被当成一句完整的结果。可公开页面会继续处在变化的环境里，即使代码暂时没有更新。
浏览器升级后，曾经合适的布局可能显得拥挤；第三方接口调整后，旧说明里的一句话就会把人带偏；依赖停在旧版本，下一次想改一个很小的功能，也可能先花时间理解过去的环境。这里没有惊险的事故，大部分只是细碎的不一致。它们积在一起，足以让一个“还能打开”的页面变得不太好用。
所以检查页面时，我想把“可达”与“可用”分开记。前者用一次访问就能看到，后者需要真的点进去：文件入口是否说得清楚，短链的提示是否容易理解，笔记页面在常用屏幕上是否舒服，API 文档是否还对应当前行为，登录后的去向是否符合预期。
这些检查不一定能写进项目首页，也很难成为一张好看的成果截图。它更像打扫房间时顺手拧一下松动的把手。没有新功能，页面却少了一处让人迟疑的地方。
维护也包括说明。旧 README 如果只适用于最早的版本，就应该补上现在的入口和限制；项目已经很少使用，也可以直说它处在什么状态。含糊地让所有仓库看起来都在进行中，对以后回来的人没有帮助。这个“以后的人”常常就是隔了几个月的我自己。
留下来的东西会占用注意力
这六个页面都不大，放在一起却列出了不少待回答的问题：入口是否仍然正常，说明有没有跟上修改，仓库还准备不准备继续。每件事只占一点，加起来便成了一个没有完成的后台列表。
现有材料还回答不了每个工具处在哪个阶段。有些也许值得继续修整，有些保留代码就够了，还有两个入口之间的关系需要确认。这里不适合替它们统一安排新版计划，逐个重新判断更实际。
公开主页上的更新时间也无法单独回答这个问题。很久没有提交和最近仍有更新，各自只是一条状态信息。是否继续，要回到使用本身：它现在解决什么，我是否还需要它，下次打开时最容易困惑在哪里。
如果决定继续，就把最基本的说明补齐，把主要页面再走一遍。如果决定停下，也可以写清状态，收起失效的入口，让代码作为一段已经结束的尝试留下。结束并不会抹去当时解决过的小麻烦。
先逐个重新认识
重新整理这篇文章时，我发现自己更想写的，其实是浏览器里的这六行。技术选择会变化，页面为何还留着、代码是否还能读懂，才是我每次回来都会遇到的问题。
备忘录没有把它们写成多大的成果，我也不打算现在替它们换一套更隆重的说法。它们就是文件、链接、笔记、接口和登录，是我在不同时间留下的几件小工具。
8 月 1 日那次检查，像一次很简短的点名。六个名字都有回应。接下来不急着再加第七个，我想先逐个点进去，看看哪些地方仍然顺手，哪些说明已经旧了，哪些项目可以安静地停在这里。
能继续使用的，好好维护。已经完成任务的，好好收尾。六个页面不需要被写成一段宏大的经历，只要下一次打开时，我还知道它们为什么在这里。