原帖作者用 1 个 Git 队列拯救被 AI 榨干的大脑

Hacker News 上有个帖子吵起来了，楼主吐槽用 Claude Code 和 Codex 写代码，任务一多直接大脑宕机。评论区一半人附和，另一半人还在劝他多任务并行效率更高。

这事戳中了现在所有用 AI 编程的人的痛点。你以为开了十个终端窗口是生产力拉满，其实你的大脑内存早就溢出了。原帖作者搞出的这套单线程队列玩法，给所有被 AI 搞到精神衰弱的打工人提供了一个现成的解法。

楼主一开始也是老老实实开任务。AI 回复慢，他就开第二个。结果第一个回复需要澄清，又开第三个。最后他在二十个线程里反复横跳，试图把所有上下文塞进大脑 RAM 里。直到他彻底崩溃，大脑耗尽，注意力粉碎，连自己最初要干嘛都忘了。很多人建议他休息、限制范围。但他发现核心问题是排序和上下文。于是他搞了个优先级队列。队列存在 git 里，每个 ticket 是个 markdown 文件。Agent 按周期处理，研究新 ticket，构建安全的，跑测试。敏感代码在分支构建并询问。Agent 绝不部署到生产环境。

大家以为搞定 AI 需要更聪明的提示词，其实最缺的是人类自己的决策边界。Agent 不能做决定。所有需要人类拍板的事，全扔进一个叫 owner inbox 的地方。脚本读取整个 board，给出一份优先列表：审查变更、回答问题、裁决权衡。阅读界面是用 Claude artifact 做的一个单页，从 git 重建，镜像整个 board。不用在终端里翻历史记录。核心 trick 在于，一次只拿一个 item，加载上下文，做决定，然后关掉它，扔回队列。上下文随之关闭。这就是不迷失的秘密。

这套玩法不是谁都能直接抄。它的前提是你得有一个能自动跑测试和浏览器检查的 Agent 环境。如果你只是用网页版聊天，这套 Git 队列纯属给自己加戏。它最适合那些需要处理长周期、多分支代码库的独立开发者或小团队。原作者也承认挑战在于工具链。上下文摘要必须足够可消化，否则加载一个 ticket 就要二十分钟。另外，得防止 ticket 陷入死循环，一直等着人类给裁决。想落地，先别急着搞全套，先从把待确认事项写进 Markdown 并关闭当前对话这一步开始试。

这事给咱们的启发是，AI 工具越强大，人类越需要扮演路由器而不是处理器的角色。把记忆和上下文外包给 Git 和 Artifact，把大脑留给做决定。别试图用肉身去对抗机器的并发能力，承认自己大脑 RAM 有限，才是用好 AI 的第一步。那些还在试图同时盯五个 AI 线程的人，迟早会付出注意力涣散的代价。

看完想聊两句？
你现在用 AI 写代码，是习惯单线程死磕，还是多线程同时开火？