开发者分享用Git优先队列管理AI编程任务的方法

如果你在终端里用 Claude Code 或 Codex 干活，这场景你一定不陌生。

你起了一个任务。AI 半天不回，于是你又起了一个。然后第一个回了，但回复里需要一次澄清、一次追问、还有一个附带任务——每一个都想独占一个标签页。接着第二个标签页的回复也来了。你手忙脚乱地切换。突然发现自己已经在 20 个会话之间来回跳，试图把所有上下文都塞进脑子里的内存。

直到塞不下了。大脑疲惫不堪，注意力彻底崩掉，你再也搞不清自己在做什么、从哪儿开始的、本来该在哪儿结束。

很多人建议休息一下、想清楚再打字、缩小范围。我有我自己的实验。

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

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

一个 agent 按周期处理这个看板。它会调研新工单，构建那些被人标记为“可以安全构建”的工单，跑测试和浏览器检查，并验证已经部署的内容。凡是涉及敏感代码的，它都在分支上构建，并且先询问。它从不部署到生产环境——那部分是我的事。

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

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

我拿一项。加载它的上下文。做一个决定或请求一个动作。然后关掉它，把它放回队列。

这个“关掉”就是全部诀窍。工单不会一直挂在我记忆里，变成一个“要记着”的东西。上下文随它一起关闭。所以当我从队列里拿下一项时，我能真正专注。一次一件事。

它依然累人。但我不再感到分心或迷失。

挑战过去是、现在仍然是围绕它的工具链。要让上下文以容易消化的方式呈现出来，加载一张工单只要一分钟而不是二十分钟。还要防止工单陷入无限循环，因为它们被卡在等待一个只有我能给的裁定上。

它是一个活的东西，我一直在改进它。但我觉得它让我用 AI 工具的生产力前进了一大步，所以我觉得值得分享。