用一份工作日志，接住下次继续时的自己

项目暂停几天后，最费时间的事情有时不是写代码，而是想起自己上次做到了哪里。

文件可以说明“现在有什么”，却未必说明“为什么变成这样”。一次失败的尝试、一个还没验证的推测、一个已经排除的原因，往往最先从记忆里消失。

给任务一个稳定的身份

我的工作日志以 workflow 为单位。一条任务可以跨多个会话，也可以在不同日期继续；只要目标还是同一件事，就沿用同一个 ID。

它与日期目录解决的是不同问题：日期方便归档，workflow ID 负责把同一件事的过程连起来。

把当前快照放在前面

我希望下一次打开日志时，先看到这样一小段：

目标：把文章页接到现有博客
状态：进行中
已经完成：内容读取与页面生成
当前阻塞：无
下一步：检查筛选、搜索与移动布局
证据：生成目录、关键文件、检查结果

快照要短，细节放在后面。它应当足以说明当前任务和下一步，又不会让人一打开就掉进完整时间线。

记录判断如何发生

过程部分留下真正改变判断的东西：

• 尝试了什么，观察到了什么。
• 为什么放弃一条路径。
• 哪些文件发生变化。
• 验证到哪一步，哪些地方仍未验证。
• 下一次从哪个命令、脚本或文件继续。

例如“配置解析通过”与“当前进程的行为已经恢复”是两种结果。在日志里保留这个区别，下一次就不容易把尚待验证的问题当成已经解决。

索引负责把记录找回来

日志多了以后，搜索标题仍然有用，但需要一个稳定入口。我给项目保留索引，也维护全局索引，列出状态、目录和下一步。

大项目使用自己的日志目录；一次性工作按时间归档。目录形式可以调整，索引始终指向实际文件。

日志之后，还有笔记和文章

工作日志保留过程，知识笔记提炼稳定结论，博客再把适合公开的部分写给读者。

这三层可以互相链接。一个排障过程完成后，日志里还保留尝试与证据；短笔记只留下判断方法；文章则补充读者需要的背景与解释。

这座数字花园也从这条路径开始生长。它会逐步把那些“当时终于弄明白了”的瞬间，变成下一次还能找到的东西。

→ 关于这座数字花园