Obsidian 与工作日志

虽然从开始工作到现在已经有两年多了，但大部分时间里我需要同时跟进的事项并没有那么多，复杂度也没有太高，基本上不需要太多记录就可以完成。但是最近几个月以来，手头工作的数量和复杂度都急剧上升，完全依靠大脑跟进已经逐渐不可能了。在此背景下，我开始尝试用 Obsidian 搭建自己的工作日志系统，也读到了其他人的一些分享（如 Use A Work Journal To Recover Focus Faster And Clarify Your Thoughts）。目前我的工作日志系统已经正常运转大概三个月了，大部分坑都已经填平，也成为了我工作中不可或缺的一个部分。以下是我自己目前的一些经验，希望分享出来能帮到各位读者。

工作日志能解决的问题

1. 在多个任务间切换而不丢失信息：随着跟进任务数量的增加，将所有任务相关的信息记忆在大脑里越来越困难，然后会发现越来越多的时间被花费在信息寻找上：这个任务的代码在哪个分支上？我今天要交付的文件应该找谁要？这个项目的最新结论是上次谁在哪个群拍的板？有了工作日志之后，每个任务都有自己独立的条目，只要找到它，相关信息就能立刻获得。
2. 记录每一步尝试：有些时候第一次尝试就能成功，但更多时候并非如此。通常需要很多次修改、调试和观察，才能确认自己是否在正确的方向上前进。最终提交的代码或文件只反映了最后成功的结果，中间的探索过程却完全丢失了。有了工作日志之后，一切中间过程都能被记录和回溯。
3. 快速复用SOP以保证关键任务的可重现性：探索性的任务很有趣，但也有一部分任务是事务性的：目标明确，步骤清晰，也做过很多次了；但是步骤数量增加和操作过程的复杂度提升，都会让某一步骤遗忘/未能按照预期完成的概率增加；工作日志让维护和应用SOP（Standard Operation Procedure，标准操作流程）更简单，只要每次遵循就能避免出错。（当然更好的选择是完全将事务性工作自动化，让人不用参与，然而这并非总是可行/经济）
4. 阶段性总结时有话可说：在大厂打工，(周|月|季|半年|年)报难以避免，然而很多工作都很琐碎，一个周期过去了可能发现自己甚至说不出来做了什么；工作日志让回溯历史更加简单，避免了无话可说的窘境。

我如何使用工作日志

什么任务需要建立工作日志

目前我的标准是预估完成时间，超过 5 分钟的任务就值得建立一条工作日志了。在我目前的工作流中，我通常会在一个 4K 分辨率的屏幕上操作，左侧 70% 是我当前的核心工作区（如浏览器/代码编辑器），右侧会开三个窗口，从上到下分别是 Apple Notes（临时任务列表）、CudaText（草稿纸/scratchpad）、Obsidian（工作日志）。当我收到一个任务（可能是电话/IM消息/当面通知）后，我会先判断该事项完成所需的时间；如果预估可以在 5 分钟内完成（简单的配置修改/信息收集表填写/告警单处理），那就会放在 Apple Notes 里作为一个新的待办项；如果预估需要 5 分钟或者更长（bug 调查/开发需求），那就在 Obsidian 里创建一个工作日志条目文件。当然预估的时间可能不准，如果实际开始做的时候发现比我预估的时间更长，我也会把这个任务从 Apple Notes 的代办项提升为一个 Obsidian 日志。

工作日志模板

之前我是的每个工作日志都是从零开始，然而随着日志的逐渐增加，我观察到自己在每个日志初始时写下的信息有共同之处，于是从中提取建立了模板。目前我使用的模板很简单，只是有一个 Markdown 表格，描述了这个任务的常用关键信息，其中包含以下的 key：

• 对接人：通常是将任务分配给我的人，或者是某个项目的交付负责人
• 群：我所在的公司使用企业微信作为 IM，通常每个项目有自己的群，其中包含了这个项目的所有参与人和关键信息；如果你所在的公司使用其他的 IM，可以替换为类似的“沟通点”概念（如 Slack 中的频道）
• 需求链接：任务在到内部需求系统的链接，通常包含正式的需求标题
• MR链接：到代码库 Merge Request 的链接（提交MR后才会填写此部分）；主要用于回溯时快速找到相关的代码变更
• 其他链接：其他和此任务相关的链接，例如在线文档、内部的 Wiki 页面、配置系统地址
• 预期交付时间：该任务的预计完成时间，用于决定优先级
• 共识/结论：一个任务可能会跨越较长的时间，而其中结论可能时刻变更。我通常在这个字段中以时间倒叙记录最新结论（日期-人-结论）
• 代码分支：如果这是个开发任务，相关的代码变更在哪个分支上
• 涉及模块：如果这是个开发任务，需要开发/测试/部署的模块列表

使用工作日志

从模板建立工作日志并填充基本信息后，这个工作日志就可以使用了。

• 不限定记录内容：对于工作日志中记录的内容，我并没有做限定，而是基本想到什么/用到什么/看到什么都会记录进去，例如调试时的 trace id，自己的猜想和验证结果，模块/方法的调用链，可以参考的代码段，群聊中重要信息等等。
• 自己QA：另一个常见的做法是自己给自己提问，通常是写下一连串问题（Q：为什么这个bug在case1的情况下不会触发？），然后通过一系列探索填充答案（A：因为外部的检查提前失败报错了）（基本上把自己当作一个 LLM 来用）
• 每天分割：对于一个持续时间较长的任务，工作日志可能也会变得逐渐混乱起来；我自己的做法是用 --- 分割每天的记录，并在开头标记日期。
• 从 SOP 复制：如果这是个事务性任务，而且此前已经有 SOP，则可以直接复制 SOP（例如 checklist），以便完整并正确地重新完成任务。（注意：最好不要直接从历史日志复制，一来这揭示了你可能需要一个SOP，那就应该去正式建立一个；二来历史日志中可能存在干扰细节，例如需要每次生成的ID，直接复制可能让你出错）

特殊文件

除了每个任务特定的日志之外，我还维护了一些特殊文件，每个都有自己的特定用途。

• SOPs：当我发现我在重复历史任务时，就会提取出一个SOP，其中是整理过可以直接复制到新日志中的内容；通常包含任务描述，前置条件，步骤的checklist、每个步骤需要的信息（如配置系统链接）
• weekly：用于组会的事项列表。我所在的小组的组会是周五下午；通常我会在周五上午填写本周已完成的事项，以及下一周将要启动的事项，这样组会上就不用临时寻找了。
• lowlights：可改进的项目集合。通常会在遇到一个让我不爽的事情（如某个内部工具不好用）时快速记录，组会前再填写到专用的复盘文档。
• hacks：用来记录一些偶尔遇到但是每次想不起来怎么做的事情的操作说明。

相关的 Obsidian 插件

虽然工作日志的存在本身就是有意义的，但是和一些 Obsidian 插件配合可以更方便。

• Tasks：一个 Obsidian 体系下很强大的任务管理插件。我一般的用法比较简单，每个工作日志开头会有一个 Markdown TODO 项目（- [ ]开头），Tasks 插件会将所有这类任务收集起来，呈现在一个统一的视图中；这样我只需要看这个视图，就能定位到还有哪些未完成的任务，并快速跳转到相关的笔记了
• Unique Note Creator（时间戳笔记生成器）：在侧边栏添加一个按钮，点击时套用模板，创建一个带有当前时间戳的新笔记。目前我创建工作日志的主要方式。
• Another Quick Switcher：在快速切换选择器中，让搜索结果以修改时间逆序排列（原生的 Quick Switch 并非如此），避免切换到非预期的很久之前的笔记中
• Scroll To Top：在笔记右下角增加按钮，可以快速跳转到笔记开头或者结尾；对于很长的笔记比较有用

暂未解决的问题

最后是一些我目前还没有完全解决的问题，如果有思路欢迎分享。

• 粘贴长代码时折叠不便：虽然 Obsidian 有自带的折叠机制，但是用在代码上总感觉不太方便；用于列表/标题的 Folding 会导致文件增加不需要的结构；Callout 因为属于引用，粘贴代码的时候需要一些特殊处理才能让代码段正确放进去。希望能找到一个更接近 Github Markdown 预览中类似于 <summary> 的方案。
• 切换到其他文件时丢失阅读进度：如果关闭了某个笔记 tab，下次重新打开的时候，默认会回到文件开头而不是上次阅读/编辑的位置。尝试了几个社区插件但是效果不佳。
• 命名问题：同一个任务可能有多种描述，然而如果关键字不在标题里就搜不到；现在我的做法是把任务所有的关键字都扔在标题里（类似于 SEO），虽然看起来不太美观但是搜起来很好用。一个改进方向可能是自定义搜索，让某个关键词可以匹配多个同义的关键词？