Blog Title

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

2026-07-26T00:00:00Z

I wrote a command-line tool called worklog (wl). These days most of my recording, planning, summarizing and reviewing happens in it.

It's a little different from a normal todo tool: the one writing into it day to day isn't me, it's an AI.

I do most of my work in a terminal, talking to an AI. What to do today — I have it lay the tasks out. Progress, decisions, things that come up mid-task — it jots them down as we go. When something's finished, it marks it done. In the evening I have it write up the day. When I come back to something days later, I look it up there too. The whole loop — record, plan, do, summarize, review — is the AI writing into wl while it works, not me filling in a form after the fact. I usually just glance at the terminal to check it got things right.

How it's used: a day, recorded by the AI

Take today. In the morning the AI looks over my plan and pulls the tasks into the day:

# what's scheduled today, and where it stands
wl day
# schedule task 42 for today
wl sched 42 today

While working, it records as it goes:

wl add "fix upload timeout" --para task --parent 42 --log "suspect the retry logic"
wl log 618 "found it: hardcoded retry interval, switching to exponential backoff"
wl link 618 "[[upload-timeout-notes]]"
wl done 618 --at 14:30 --log "deployed; timeout alerts gone"

Each is a single line, composable — create a task, append progress, link the debugging notes, close it with the outcome, one thing per command.

Something you'll need to do later, but not now, often comes up mid-task. Have it capture the task and schedule it for tomorrow, so it doesn't get lost:

wl add "add rate limiting to downloader" --para task --parent 42 --sched tomorrow

At the end of the day, the AI writes up a summary:

wl recap

When I come back to something later, or a fresh AI session takes over cold, one command pulls the whole history back:

# this task's ancestors and children
wl focus 618
# keyword full-text search
wl find timeout
# semantic search by meaning, catches phrasings keywords miss
wl query "upload timeout"

Almost everything I do lives in it now — work and personal. Even worklog's own development runs on it: 100+ tasks, no GitHub Issues. In a bit over a month it's a thousand-plus nodes, all in one local SQLite file, queries in milliseconds.

Tasks also link both ways with my Obsidian notes: a task holds its documents, and from a document you can find the tasks that reference it. Structured state lives in wl; long-form writing stays in Obsidian; each keeps to what it's good at.

That's what it is and how it's used. Here's why I built it.

Why a knowledge base alone isn't enough

The "second brain" idea has been popular for a few years. I'm no exception — I use Obsidian and Notion to keep the things I've thought through and want to hold on to for a long time.

What I found is that a knowledge base alone isn't enough. It's good for settled conclusions, but the things actually in motion right now — what to do today, how far a task has gotten, a decision just made, something I suddenly remember to defer — it can't hold those. I never had a good tool for that part. Before, I either made do with Markdown, or left it scattered across my head and chat logs.

I'd tried a few todo tools earlier, but the payoff never matched the effort. Before things get complicated enough to really need one, just feeding the tool fields every day becomes the burden.

AI changed that. I no longer fill things in one by one — I let the AI drop the details of work and life into Markdown as we talk. What used to sit in my head landed in files.

Here's roughly how it piled up:

Month	Lines	Size
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

Seven months, the size grew more than fiftyfold. It worked well at first, and then the problems showed up.

Why Markdown falls short for tracking process

Two or three months in, the problems came one after another. Using a knowledge tool (Markdown files) to manage what's in motion was a poor fit to begin with:

Several AI windows write into one file at once. The copy an AI is holding goes stale fast: the change it generates against the old content often won't apply to a file another window has already edited, so it has to re-read and redo it. These collisions are frequent, and the retries waste compute and time.
The file keeps growing. To change one line, the AI has to read the file in and locate that line — the read cost keeps climbing.
Relations between tasks, meetings and decisions can only be [[wikilinks]]. Once there are enough of them, renaming one document breaks a swath of them.
Reviewing a week means having the AI read all the related files and re-derive it — slow, and easy to miss things.

By the end of May I did the math: the time spent tending the Markdown — getting the AI to parse it, avoiding write conflicts, fixing broken links — had passed the time the AI was saving me.

The reason is simple enough. A knowledge base and a record of process are two different jobs. A knowledge base wants long-form text, stable structure, long-term storage; a record of process wants frequent writes, quick lookups, and several windows writing at once without fighting. Markdown suits the first, not the second.

Two layers: a knowledge base, and a structured quick context beside it

Once that was clear, I stopped expecting one tool to do everything and split it into two layers.

One layer is the knowledge base, for the long-term things — conclusions I've thought through, references I've organized. Obsidian keeps doing this, and does it well.

The other records what's in motion right now — today's plan, the task in hand, a passing idea. It wants frequent writes and quick lookups; the volume is small, but every read and write has to be light.

Put it this way: if the knowledge base is my second brain, the other half I was missing is a structured quick context sitting next to it — small in size, quick to read and write, holding the part I need often right now. Most people already have the second-brain layer; this structured quick context layer is either empty or faked with Markdown. That's the layer I set out to fill.

The user is an AI, so the whole design changes

Once I decided to build it, I quickly saw I couldn't just take an existing todo or checklist tool, because they're all built for people.

The key thing, I think, is that the premise is reversed. Existing tools are designed for humans, aimed at making it easy for a person to fill in — a nice UI, fewer clicks. My case is the other way around: the one operating this tool day to day is an AI, and I only look at the results.

Change the user from a human to an AI, and the whole design has to follow:

Commands are short, one line each. An AI calls them in a terminal, and a command that finishes a thing in one line is the least error-prone — no interaction, no step-by-step prompts.
Output is plain text, and cheap on tokens. What reads the results is an AI; it doesn't need a pretty interface, it needs compact, directly parseable text.
No preset categories. Projects, tasks, habits, meetings, a stray idea — all the same kind of node, joined into a tree by parent_id. The AI doesn't have to learn a project / label / priority scheme first; it just creates a node and hangs it where it belongs. This is the biggest difference from tools like Todoist and Notion.
The structure has to be clear and connected — this part matters a lot. Each record can be rich on its own, but pulling up a single node costs very few tokens; when you need more, following the parent/child links makes it easy to recover the full context and see the whole picture. A local slice stays cheap to read, and the whole picture is always one expansion away. Having both at once is exactly what the structure buys you.
SQLite underneath. Several AI sessions writing at once don't overwrite each other; the data is transparent, readable by people and by the AI, and both sides see the same thing.
Relations live in the database, not in filenames, so renaming a title doesn't break them.

In short, it isn't another todo tool — it's a layer of record redesigned around "an AI uses it."

The biggest change: context stops leaking

I often run several AI sessions in parallel. That's fast, but there's several times more to keep track of, and my attention keeps switching. Switching is where the details get lost: a lead I was halfway through chasing, a decision just made in passing, something I meant to defer. If it isn't written down right then, it's gone once I switch away. None of these look important, but that's often exactly where problems come from later.

With this layer, those things get written down as they happen, and one command brings them back when needed. Whether I come back days later or a fresh AI session takes over, the context is still there — no rebuilding from scratch. When several windows are working together, they're looking at the same record.

How good an AI's answers are depends a lot on whether the context you give it is complete. With the context sitting somewhere reliable, this whole thing gets much smoother.

Getting started

worklog is open source, the command is wl, MIT.

pip install pyworklog
wl init

Once it's installed, tell your AI about it in your config (Claude Code's CLAUDE.md, say, or a skill) — what wl is and when to record what — and it'll keep the record for you while it works. See the README for how.

(worklog and worklog-cli were both taken on PyPI, so the package is pyworklog; the command is still wl.)

This is the first post in a series. Later ones open up each piece I passed over here: what a CLI designed for AI looks like, how one table holds everything from today to a lifetime, how several AI sessions share the same context, how I use it day to day, and how it splits work with Obsidian.

If you've got a knowledge base and you're getting real work done with AI, this missing layer is worth a try.

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

2026-07-26T00:00:00Z

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 干活，可以试试补上这一层。