知识库之外，还缺一层：记录当下正在做的事

English version: A todo tool where the writing is done by an AI, not me

我写了个命令行工具，叫 worklog，命令是 wl。现在我记录、计划、总结，基本都在里面。

它跟一般的 todo 工具不太一样：平时往里写东西的不是我，是 AI。

我干活基本是在终端里跟 AI 对话。今天要做什么，让它先用 wl 把任务排进当天；干活过程中的进展、决策、临时想到的事，让它随时记下来；一件事做完，让它立刻标记完成；晚上收尾，让它把当天总结一段；过几天回头总结，也在里面查。整个记录、计划、执行、总结的循环，都是 AI 一边干活一边用 wl 记的，不是我做完事再回头填。我一般只在终端瞄一眼，看它记得对不对。

它是怎么用的：AI 记录的一天

比如今天。早上让 AI 看一遍计划，把今天要做的任务排进当天：

# 今天排了什么、干到哪了
wl day
# 把 42 号任务排进今天
wl sched 42 today

干活的过程中，让它随时记下来：

wl add "修复上传超时" --para task --parent 42 --log "初步判断是重试逻辑"
wl log 618 "定位到了：重试间隔写死，改成指数退避"
wl link 618 "[[上传超时排查]]"
wl done 618 --at 14:30 --log "已上线，超时告警归零"

每条都是一行命令，可以组合。建任务、记进展、挂上排查笔记、带结果标记完成，一行做完一件事。

干活的时候常会冒出一件当下不做、以后要做的事。让它建一条、直接排到明天，免得忘：

wl add "给 downloader 加上限流" --para task --parent 42 --sched tomorrow

晚上收尾，让 AI 把当天总结一段：

wl recap

过几天我回到某件事，或者新开一个 AI 会话从头接手，一句命令就能把前因后果查回来：

# 这个任务的上下游
wl focus 618
# 按关键词全文搜
wl find 超时
# 按意思语义检索，找关键词碰不到的说法
wl query "上传超时"

现在我的事基本都在里面，工作、个人都有。连 worklog 自己的开发也用它管，一百多个任务，没再用 GitHub Issues。一个多月记了一千多个节点，都存在本地一个 SQLite 文件里，查询是毫秒级的。

任务还能跟我的 Obsidian 笔记双向关联：任务上挂着文档，从文档也能反过来查到挂它的任务。结构化的部分放 wl，成篇的文档放 Obsidian，各放各的。

这就是它是什么、怎么用。下面说说我为什么要做它。

为什么一个知识库不够用

这几年"第二大脑"这个说法挺流行。我也一样，用 Obsidian、Notion，把想清楚了、值得长期留下来的东西存进去。

用下来我的体会是，光有一个知识库不够。它适合放已经想定的结论，可当下正在进行的那些事——今天要做什么、一件事干到哪了、刚定的一个决策、突然想起来要延后处理的活——它管不了。这部分我一直没有个趁手的工具，之前要么用 Markdown 凑合，要么就散在脑子里和聊天记录里。

以前也试过一些 todo 工具，但投入和回报不太成正比。事情还没复杂到非用不可，光是每天给工具填字段就先成了负担。

AI 出现之后，这件事有了变化。我不用自己一条条填了，让 AI 在对话过程中把工作和生活里的事记进 Markdown。原来靠脑子记的东西，落到了文件里。

攒下来的量大概是这样：

月份	行数	大小
2025-11	269	10 KB
2025-12	331	18 KB
2026-01	567	40 KB
2026-02	1,027	89 KB
2026-03	2,381	294 KB
2026-04	2,487	409 KB
2026-05	1,743	537 KB

七个月，文件大小增长了五十多倍。一开始挺好用，后来问题就出来了。

拿 Markdown 记过程，为什么行不通

用了两三个月，问题一个个出来。我拿一个记知识的工具（Markdown 文件）去管当下的事，本来就不太合适：

• 几个 AI 窗口同时往一个文件里写，AI 读到的那份内容很容易就过期了：它基于旧内容生成的修改，应用到已经被别的窗口改过的文件上时，经常应用失败，只能重新读一遍再改。这种冲突很频繁，一遍遍重来，白白浪费算力和时间。
• 文件越来越大，AI 改一行，得先把文件读进来、找到那一行，读取开销一直在增加。
• 任务、会议、决策之间的关联只能用 [[wikilink]] 连。数量一多，改个文档名就断掉一片。
• 想总结一周，得让 AI 把相关文件都读一遍再归纳，既费时间又容易遗漏。

到五月底我算了一下，花在伺候这些 Markdown 上的时间——让 AI 读懂、避免写冲突、修断链——已经比 AI 帮我省下来的时间还多了。

其实原因不复杂。知识库和记录过程是两件事。知识库要的是能写长文、结构稳定、长期放着；记录过程要的是写得频繁、查起来方便、几个窗口一起写也不会互相冲突。Markdown 适合前一件，不适合后一件。

分成两层：知识库，和旁边的结构化快取

想清楚这点之后，我就不指望一个工具全干了，分成两层。

一层是知识库，放长期留存的东西——想清楚的判断、整理好的资料。这层 Obsidian 继续做，它做得挺不错。

另一层记录当下正在进行的事——今天的计划、正在做的任务、临时的想法。这层讲究写入频繁、查询方便，数据量不大，但每次读写都要轻快。

打个比方，如果知识库是我的第二大脑，那我缺的另一半，就是它旁边一块结构化快取——容量小、读写迅速，放当下高频要用的那部分。大部分人第二大脑那层早有了，这块结构化快取要么空着，要么拿 Markdown 凑合。我补的就是这一层。

使用者是 AI，整套设计就得不一样

要补就自己写一个。但我很快发现，现成的 todo、checklist 都不能直接拿来用，因为它们都是给人用的。

我觉得最关键的一点，是这个前提反过来了。现成工具都为人设计，目标是让人填起来省事——界面好看、少点几下。可我的情况反过来了，平时对着这个工具操作的是 AI，我只看结果。

使用者从人换成 AI，整套设计就得跟着变：

• 命令要短，一行做完。AI 在终端里调用，一行能做完一件事的命令最不容易出错，不用交互、不用一步步问。
• 输出是纯文本，还能省 token。读结果的是 AI，不需要好看的界面，需要的是紧凑、能直接解析的文本。
• 不预设分类。项目、任务、习惯、会议、一个想法，都是同一种节点，靠 parent_id 连成一棵树。AI 不用先学一套 project、label、priority 的分类规则，建个节点、挂到该在的位置就行。这一点跟 Todoist、Notion 这类工具区别最大。
• 结构要清楚、连得起来——这一点其实很重要。每条记录本身可以写得很丰富，但单独取出来看一条，只占很少的 token；等需要的时候，顺着父子关系又能很容易找回完整的上下文，看清整体是什么情况。平时读一个局部，开销很小；要看全局，顺着结构随时能展开。局部和整体都要，靠的就是这套结构。
• 底层用 SQLite。几个 AI 会话同时写不会互相覆盖；数据透明，人能读、AI 也能读，两边看到的是同一份。
• 关联存在数据库里，不靠文件名，改个标题不会断。

一句话，它不是又一个 todo 工具，是按"给 AI 用"重新设计的一层记录。

最大的变化：上下文不再丢失

我经常同时开好几个 AI 会话并行做事，效率高了不少，但要同时管的事也多了好几倍，注意力还得在几件事之间来回切换。切换的时候最容易丢的是细节：排查到一半的一条线索、刚随口定的一个决策、想起来要延后做的一件事。当下不记下来，切换过去就找不回了。这些事都不起眼，但后面出问题往往就在这里。

有了这一层，这些东西当时就记进去了，要用的时候一句命令查回来。不管是我隔几天回来，还是新开一个 AI 会话接手，上下文都还在，不用从头重建。几个窗口一起做的时候，看到的也是同一份记录。

AI 回答得好不好，很大程度上看你给它的上下文够不够完整。上下文有个地方稳稳放着，这件事就顺畅多了。

怎么开始用

worklog 是开源的，命令是 wl，MIT 协议。

pip install pyworklog
wl init

装完之后，在你的 AI 配置里（比如 Claude Code 的 CLAUDE.md，或者一个 skill）告诉它有 wl 这个命令、什么时候记什么，它就会在干活的过程中替你记。具体写法看 README。

（PyPI 上 worklog 和 worklog-cli 都被人占了，发布名只能叫 pyworklog，命令还是 wl。）

这是系列第一篇，先讲个大框架。后面会一篇篇展开：为 AI 设计的命令行具体长什么样、一张表怎么装下从今天到一生的事、几个 AI 会话怎么共享上下文、我平时一天怎么用它，还有它跟 Obsidian 怎么分工。

如果你也有一个知识库、也在用 AI 干活，可以试试补上这一层。