如果你在终端里使用 Claude Code 或 Codex，你一定懂这种感觉。
你启动一个任务。AI 回复需要时间，于是你又启动一个。然后第一个回复了，但这个回复需要一次澄清、一次追问和一个附带任务——而每一个都想要自己的标签页。接着第二个标签页的回复也来了。你手忙脚乱。突然之间，你发现自己要在 20 个线程之间来回跳转，试图把所有那些上下文都塞进大脑内存里。
直到你再也撑不住。你的大脑精疲力竭，专注力崩溃，你不再知道自己刚才在做什么、从哪里开始、又该在哪里结束。
很多人建议休息一下、想清楚再打字、限制范围。我有自己的实验。
我认为这种工作方式有两个主要问题：顺序和上下文。于是我把工作组织得有点像优先队列。
下面是它实际运作的方式。
队列存放在 git 里。每张工单都是仓库中的一个 markdown 文件，就放在它所讨论的代码旁边，而看板的状态是一个已提交的快照。重要的东西不会留在聊天窗口里，也不会留在我的脑子里。即使某个会话中断了，队列依然还在。
一个 agent 按周期处理这个看板。它研究新工单，构建那些被人类标记为可安全构建的工单，运行测试和浏览器检查，并验证已经部署的内容。对于任何涉及敏感代码的改动，它会在分支上构建并先征求同意。它从不部署到生产环境——那部分由我负责。
它做不到的是做决定。所以所有需要我的事情都会汇集到一个地方，我称之为我的 owner inbox。一个脚本读取整个看板，递给我一份精确列出等待我判断的事项的优先列表——审查这个改动、回答这个问题、裁决这个取舍。
阅读界面是一个 Claude artifact。一个页面，每个周期从 git 重建，镜像整个看板，外加每张工单一个审查页。这样我就不用在终端里往回翻，试图重建某个改动到底做了什么。我打开一个链接，阅读构建了什么以及为什么，然后给出我的裁决。裁决会回到 git 里，写到卡片上。页面只是查看器——git 才是记录。
接下来是最重要的部分。
我取一个事项。加载它的上下文。做出决定或请求一个操作。然后通过把它放回队列来关闭它。
这个关闭动作就是全部的诀窍。工单不会作为一件需要记住的事继续悬在我的记忆里。上下文随之关闭。所以当我从队列里取下一个事项时，我能真正专注。一次只做一件事。
这仍然很累人。但我不再感到分心或迷失。
挑战过去是、现在仍然是围绕它的工具。让上下文以易于消化的方式呈现，这样加载一张工单只需一分钟而不是二十分钟。以及防止工单陷入无尽循环，因为它们被阻塞在等待只有我能给出的裁决上。
它是一个活的有机体，我一直在改进它。但它感觉像是我使用 AI 工具生产力上的一大步，所以我觉得值得分享。