如果你在终端里使用 Claude Code 或 Codex，你一定懂这种感觉。

你启动了一个任务。AI 需要时间回复，于是你又启动了另一个。然后第一个回复了，但这条回复需要一次澄清、一次追问和一个附带任务——而每一个都想要自己的标签页。接着第二个标签页的回复也来了。你手忙脚乱。突然之间，你发现自己要在 20 个线程之间来回跳转，试图把所有那些上下文都塞进大脑内存里。

直到你再也撑不住。你的大脑精疲力竭，专注力彻底崩溃，你不再知道自己刚才在做什么、从哪里开始、又该在哪里结束。

很多人建议休息一下、打字前先思考、限制范围。我有我自己的实验。

我认定这种工作方式有两个主要问题：排序和上下文。于是我把工作组织得有点像优先队列。

下面是它实际运作的方式。

队列存放在 git 里。每张工单都是仓库中的一个 markdown 文件，就放在它所讨论的代码旁边，而看板的状态是一份已提交的快照。重要的东西既不存放在聊天窗口里，也不存放在我脑子里。即使某个会话中断了，队列依然还在。

一个智能体按周期处理这块看板。它调研新工单，构建那些被人类标记为可安全构建的工单，运行测试和浏览器检查，并验证已经部署的内容。对于任何涉及敏感代码的改动，它会在分支上构建并先征求同意。它从不部署到生产环境——那部分由我来做。

它做不到的是做决定。所以所有需要我的事情都会汇集到一个地方，我称之为我的 owner inbox。一个脚本读取整个看板，递给我一份精确列出所有等待我判断的事项的优先列表——审查这个改动、回答这个问题、裁决这个取舍。

阅读界面是一个 Claude artifact。一个页面，每个周期都从 git 重建，镜像整个看板，外加每张工单一个审查页面。这样我就不用在终端里往回翻，试图重建某个改动到底做了什么。我打开一个链接，阅读构建了什么以及为什么，然后给出我的裁决。裁决会回到 git 里，落到卡片上。页面只是一个查看器——git 才是记录。

接下来是最重要的部分。

我取一个条目。加载它的上下文。做出决定或请求一个操作。然后把它放回队列，关闭它。

这个关闭动作就是全部诀窍。这个工单不会作为一件需要记住的事一直挂在我的记忆里。上下文随之关闭。所以当我从队列里取下一个条目时，我能真正专注。一次只做一件事。

它仍然令人疲惫。但我不会感到分心或迷失。

挑战过去是、现在仍然是围绕它的工具。让上下文以易于消化的方式呈现，这样加载一个工单只需一分钟而不是二十分钟。并且防止工单陷入无休止的循环，因为它们被阻塞，等待只有我能给出的裁决。

它是一个活的有机体，我一直在改进它。但我觉得它是我使用 AI 工具生产力上的一大步，所以我认为值得分享。