把走过的路, 留给下一次出发

写上一篇代理网络的文章时, 我发现, 最难的竟不是落笔.

那套网络已经用了许久. 每天打开电脑, 接通, 查资料, 和 AI 说话, 事情便往前走. 真要回头写它是怎样搭起来的, 脑子里最先浮现的, 却只有一句模糊的话: 折腾了很久.

多久, 折腾了什么, 又为什么非得那样改, 需要慢慢找回来.

我和 AI 翻回以前留下的记录. 有些故障查明了原因, 有些只是恢复了连接; 有些备用路径早就写在配置里, 后来才真正验过它能不能接管. 当时觉得不会忘的细节, 到了今天, 已经不能只凭印象分辨.

好在, 它们还有地方可找.

那是我的个人 Wiki. 一些 Markdown 文件, 几页索引, 按项目归拢的事实, 以及一条条并不起眼的维护记录. 平日里看着很寻常, 直到要写这篇文章, 我才发觉, 那些零碎的字已经替我保存了几个月的来路.

我不想每次都做一个重新介绍自己的人

和 AI 一起做事久了, 会发现, 把问题说清楚也是一份工作.

一个项目为什么这样安排, 哪个方案已经试过, 哪一步只是编译通过, 哪一步确实用起来了. 这些事情在当时的对话里都很清楚. 可是换一次任务, 隔一段时间, 又得把它们从头铺开.

重讲一遍也未必能讲全. 人往往记得结论, 却忘了结论成立的条件. 记得那天说过可以, 却未必记得后面还有半句: 在这个环境里可以, 另一端还没有验证.

我渐渐舍不得花在这里的时间. 一个问题已经认真想过, 一条路已经亲自走过, 下一次再遇见, 总该比第一次从容一点.

于是, 我开始把这些东西往固定的地方放. 不再任由它们留在不同的聊天窗口, 等到需要时再凭几个关键词翻找.

项目有项目的页, 做事的方法有工作流的页. 某个决定写下缘由, 某次验证留下边界. 下次接着做, 先读相关记录, 再去看眼前的文件和实际环境.

这样的开始让我舒服许多. 不必急着开工, 也不必重新交代一遍所有背景. 先把上一次放下的事情认出来, 再往前走.

让记录成为做事的一部分

有一个文件夹, 还不够.

文件可以越积越多, 经验却未必更容易找到. 一份笔记写在这里, 另一份留在那里, 内容相近, 日期不同. 到最后, 连自己也说不准该信哪一份.

所以我给这套知识库配了一个 wiki skill. 它是一份交给 AI 的查阅与维护规则: 从哪里找, 先读什么, 哪些内容值得写下, 写到哪里, 又有哪些东西不该放进去.

需要接续项目时, 先看索引, 找到对应的页面, 只读与眼前这件事有关的部分. 完成了有用的工作, 再把新的事实和决定整理回去. 页面确实属于哪个项目, 就写回哪个项目; 归属还拿不准, 先留下待整理的记录.

知识库的位置是固定的. 我可以在不同项目之间来回切换, 记录仍回到同一个地方. 这条规则看着朴素, 却省掉了日后寻找许多个副本的麻烦.

我也希望整理发生在事情刚刚弄清楚的时候. 那时还知道为什么要改, 什么已经验证, 哪个疑问尚未解决. 若等到很久以后再补, 写下的常常只剩一个结果, 过程里的分寸已经丢了.

一次值得保留的收尾, 因而多了几件小事: 更新相关页面, 写清验过什么, 留下尚未完成的部分, 在维护记录里添上日期和简短说明.

不必把每一次操作都记下来. 没有新结论的检查, 不用反复抄写; 已经说清的事情, 也不用换个措辞再存一遍. 我想让后来读到它的人省些力气, 其中当然也包括未来的自己.

真正做起项目, 它省下了什么

这些规矩的用处, 要放回具体的事情里看.

比如这个博客. 第一次上线, 要弄清内容放在哪里, 怎样构建, 怎样部署, 又怎样确认外面的人确实能打开. 这些做完以后, 知识库里便留下了维护记录. 到第二篇文章要发布, 不用再把服务器和目录重新摸一遍. 先找到那份记录, 核对仓库里的发布脚本, 就能沿用已经走通过的流程.

省下来的不只是几条命令. 我们知道这套站点不需要数据库, 知道发布前该做哪些检查, 也知道旧版本留在哪里. 真出了问题, 至少不用一边着急, 一边重新寻找退路.

代理网络的记录则更像一份有日期的病历. 软路由上曾经有一条为内网互联工具准备的 UDP 直连规则, 后来发现范围太宽, 会让普通的 STUN 请求也直接出去. 后续记录写下了怎样收窄它, 怎样重新验证. 只翻到早先那一页, 很容易把已经改掉的做法当成答案; 把前后缘由一并留下, 才知道为什么今天的配置长这样.

这让排障少了一种很消耗人的循环: 好不容易修过的地方, 隔了一阵, 又被自己当作新办法改回去.

还有跨设备接着做事的时候. 某一端同步成功, 不等于另一端也拿到了最新内容. 把已确认和待确认的部分分别记清, 下次开始就知道该先检查哪一端, 不必把整套流程再跑一遍, 也不会把旧副本误当成新的起点.

有时, 最有用的甚至是一个没有采用的决定. 当时为什么觉得某个方案收益不大, 为什么暂时保留简单的做法, 如果只留下最后的配置, 这些考虑是看不出来的. 记下理由, 再遇到相似建议时, 就可以先问条件有没有改变, 而不必重新争论一遍.

我喜欢这些很具体的便利. 少找一份文件, 少走一次回头路, 接手时少猜一个环节. 每次省下的都不多, 但项目做得久了, 人会明显轻松些. 精力终于可以用在眼前真正没解决的事情上.

比记得更多更要紧的事

整理旧记录时, 我最看重的是其中的区别.

怀疑一个原因, 和查明一个原因, 要分开写. 在本地打开页面, 和线上已经可以访问, 要分开写. 一端的文件更新了, 另一端尚未核对, 就把那一端留在那里, 不急着替整件事画上句号.

这些句子不够漂亮. 有时一页读下来, 尽是限制和未完成. 但接着做事的时候, 它们很有用. 我知道哪里可以放心沿用, 哪里还需要停下来看看.

我不愿意让一份总结, 把过程修饰得比实际更圆满.

因此, 确认的事实放进项目页, 暂时的线索另行留下. 原始材料也保留自己的位置, 不因为后来有了新的理解, 就回头把旧材料改成新结论. 真要追问一件事, 仍然有来处可以核对.

还有些内容, 本来就不该出现在普通笔记里. 密码, 令牌和密钥, 不会因为一句顺手的总结, 就被带进项目页或维护日志. 需要知道它们在哪里, 和需要把它们写在这里, 是两回事.

知识库要便于翻阅, 就更该在写入时有所取舍.

同样, 旧笔记也会老去. 曾经运行正常的服务, 今天未必还正常; 上一次使用的配置, 此刻可能已经变了. Wiki 告诉我过去确认过什么, 也帮助我找到这次应当复查的地方. 至于现在, 还是要到现在去看.

有了这样的分寸, 我才敢逐渐依赖这些记录.

一张书签, 和书架上的那些书

与 Wiki 一起用的, 还有 Task Anchor.

它负责的事情更近一些: 一项长任务还没做完, 先留住目标, 约定, 已经确认的进度和下一步. 对话中断, 或者上下文经过压缩, 接着做的时候, 有一张短笺可读.

比如, 文章写好了, 但我还没审稿. 那么眼下该做的是本地预览, 而不是发布. 这类约定, 就适合留在任务锚点里.

等这项工作完成, 锚点可以收起来. 工作中形成的, 以后仍有用的经验, 则整理进 Wiki. 前者照看眼下尚未合上的一页, 后者慢慢收存已经读过, 还会再翻的内容.

两者都不需要事事启用. 简单的问题, 直接回答就好. 我不想为了防止遗忘, 让每一件小事都先经过一套仪式.

真正需要它们的时候, 是那些投入过时间, 隔天还要继续, 或者日后值得重访的事情.

留下来的, 也是我自己

最初整理 Wiki, 我想的多半是实用: 少找几次文件, 少解释几遍背景, 少重复一段已经走过的弯路.

后来读旧页面, 才发现里面还有别的东西.

为什么宁可多验一次, 也不愿意把尚未确定的事说成完成. 为什么一个看上去更先进的方案, 最后没有采用. 为什么有的东西拆掉了, 有的东西明明简单, 却一直留着.

这些选择分散在不同项目里. 单看每一次, 都是很小的决定; 放在一起, 慢慢就看出了自己的习惯. 我在意什么, 愿意为什么花时间, 又从什么时候开始, 不再急着给每个问题找一个漂亮的答案.

AI 可以帮我查阅, 帮我归纳, 帮我把零散的内容整理得更清楚. 但那些取舍仍然来自一次次实际的合作, 来自我说过的可以, 不行, 先等等, 再看一眼.

我希望它下次读到这些的时候, 能更明白我们为什么这样做. 我也希望自己隔了很久再看, 还能认出当时的心思.

于是, 写上一篇博客的时候, Wiki 又有了一个我起初没有特别安排的用处: 它让回忆有了细节.

几个月不再只剩下一句折腾很久. 哪次恢复了连接, 哪次推翻了猜测, 哪条备用路径终于经过验证, 都还留着痕迹. 文章里的底气, 有一部分就来自这里.

我并不想把生活里所有的事都存下来. 只是那些认真做过的, 好不容易弄明白的, 若能留下几行字, 往后再遇见, 就不至于全然陌生.

事情做完了, 屏幕会暗下去. 下一次打开, 又是新的一天.

而索引里的那几行字还在. 顺着它们翻过去, 我能找到上一次的自己, 接过他留下的东西, 继续往前做一点.