AI多线程开发工作流：休假周产出50个PR的秘密

作为T3.gg创始人、知名开发者兼YouTube博主，Theo（t3.gg）坦言自己早已不是全职工程师——运营公司、拍视频、对接赞助占据了他绝大部分时间。然而，看看他在T3 Code项目上的贡献曲线：7月中旬从每周一到三个PR飙升到23个、37个、41个，最终突破52个PR。更夸张的是，其中52个PR的那一周，他正在参加DEF CON大会，靠着飞机、Uber和酒店糟糕的WiFi完成。

他是怎么做到的？答案不是他变强了，而是他找到了一套让AI Agent多线程并行开发的工作流。本文将系统拆解Theo的这套方法论，其核心哲学可以浓缩为一句话：用Token换取心智负担的降低。

核心原则：代码不跑在本地机器

Theo工作流的第一步是新建线程、粘贴、然后——确保任务不在你自己的电脑上运行。

他强调，你日常办公用的笔记本或机器，绝不应该成为AI开发任务的瓶颈。为此，他在隔壁房间搭了一台Linux主机（代号BB1），上面部署了所有代码库和一个T3 Code服务器，同时挂载了Codex、Claude等多种模型harness。所有开发线程都被调度到这台机器上执行。

这里有一个反直觉但极其重要的观点：为什么是Linux而不是Mac？ Theo指出，macOS在可靠并行化方面存在大量问题，很难稳定地跑多个Agent。而在Linux上，他曾同时运行40多个Agent而机器毫无压力——即便是一台花600美元买的16线程二手机器，CPU占用率也仅在12%左右。他称这是"让自己更高效的最大黑客技巧之一"。

提示词策略：给指令也给退路

Theo在演示修复一个技能触发Bug时，展示了他精心设计的提示词结构。这段提示词的每一句话都有明确意图：

明确优先级与不可妥协线

他会告诉模型"这个问题影响了大量真实用户"，赋予任务重要性和可靠性预期。接着划出底线："我要一个实现简单、且不会让用户困惑的修复方案"——这是一条不可妥协的红线。

给模型推翻你的空间

关键在于，他会用"在我看来（in my opinion）"这样的措辞，明确告诉模型：如果方案不可行，你可以反驳我、可以忽略这部分。他还会坦诚交代自己的知识边界："我不确定Claude Code内部是如何触发这些行为的"。这样做有两个好处：一是防止模型盲目相信issue描述，二是让模型在回复时更好地解释他不懂的部分。

允许模型随时叫停

最巧妙的一句是："如果你发现一个简单的修复方案，请停下来告诉我，这样我们可以立刻应用。"这给了模型在多个子Agent并行探索时，一旦找到答案就自信地中断、直接汇报的权限，而不是死磕到底把所有17个方案都跑完。

关键一步：无视线程直到完成

Theo认为landing大量代码最关键的一步，是在任务跑完之前彻底无视它。

盯着线程等结果，会给你一种"很有生产力"的错觉，因为你看到自己负责的代码在不断变化。但事实是，你盯着它并不会让它跑得更快，99%的情况下你也不会看到需要立刻叫停的问题。所以，去做别的事。

他自己也承认，代码量大到"我根本不知道自己任何时候有哪些PR是开着或关着的"。解决办法依然是烧Token——他会用便宜又强大的GLM 5.3 Flash或Luna模型，开一个线程专门审计所有PR：哪些可以合并、哪些该关闭、哪些还需再过一遍，并按行动难易度排序，方便他优先合并简单的。他甚至同时用两个不同模型跑同一个审计任务，交叉验证结果。

用Token对抗动力流失

这是Theo工作流中最具个人色彩、也最有洞察力的部分。他明确表示自己优化的核心目标之一是防止动力流失。

他举了个例子：假设有个PR看起来能用，但要测试就得费力搭一套环境。结果搭好后一测，代码明显是坏的。这种"投入大量努力后失败"的时刻会重创当天的工作动力，让人忍不住切到Twitter或去冰箱拿瓶汽水——然后脑中所有的上下文就此丢失。

应对策略同样是烧Token：在自己动手测试之前，先让Agent做彻底审计。他会让模型先审查PR、找出所有潜在失败点和明显问题，甚至去调研其他开源项目（如CodexBar）的类似实现来对比。这样能大幅降低"投入后失败"的概率。

他还有一个对抗ADHD的小技巧：当模型给出的修复方案太长、他读不下去时，他不会强迫自己集中注意力，而是直接对模型说："你的问题描述我很喜欢，但解决方案难以理解，能不能给我一个像对五岁小孩解释一样简单易懂的版本？"——用Token买回自己的专注力。

Agent自动管理GitHub：Babysit技能

Theo介绍了他最有用的自定义技能之一——babysit（保姆）技能。它本质上只有一段半的文本，却创造了一个自动化循环。

这个技能告诉Agent：这个PR可能会收到自动化审查机器人的评论，请你持续盯着它，每次有新评论就判断是否值得处理，如果值得就修改、推送、继续监控，直到所有审查机器人都无话可说，才把状态从"进行中"改为"完成"。

在实际演示中，这个Agent自主完成了首轮修改，处理了12条评论,又收到4条并处理，再收到1条再处理，最终获得所有AI审查机器人的批准——整个过程Theo完全没有介入。他还建了一套"评论风格技能"，让Agent以"Claude Fable 5代表Theo发言"的署名留言，既透明又高效。

降低测试门槛：远程测试方案

合并前的验证是Theo投入极大精力的领域，他针对Web、iOS、桌面三个平台分别建立了测试通道：

• Web端：他给T3 Code加了--share-dev命令，配合Tailscale生成一个带配对码的URL，让他能在本地浏览器直接测试跑在远程机器上的PR。为此他还重构了打包逻辑，因为在10Mbps的酒店WiFi下加载dev服务器原本要花20-30分钟。
• iOS端：借助社区推荐的Squim项目，实现远程构建后生成一个可在手机上直接点击安装的链接，无需VPN或Tailscale的繁琐配置。
• 桌面端：他实现了通过给PR添加preview:mac标签，自动触发macOS预览版DMG构建并出现在线程中供下载。他甚至专门改造了权限逻辑，让这类预览下载无需GitHub登录认证，方便在一台"纯净"的旧MacBook Air上测试全新用户的auth流程。

核心哲学：安全网而非护栏

即便如此，Theo坦承错误依然会发生——尤其是当团队不再逐行阅读代码时，大多数Bug本来也无法靠读代码发现。因此他的最终防线是安全网（safety nets），而非护栏（guardrails）。

T3 Code拥有约20万用户，其中几千名"nightly（每日构建）用户"是关键的安全网。所谓nightly实际每3小时构建一次，一旦有改动出问题，这批深知风险的尝鲜用户会立刻涌来报告。正因如此，T3 Code的稳定版几乎从不出现真正的回归Bug——问题在触及万分之一用户前就被发现修复了。

Theo将这一切归结为"给合并按钮去风险（de-risk the merge button）"：

1. 进入PR之前，先让一堆Agent达成较高置信度，你根本不该在此之前打开PR；
2. 打开PR之后，用便捷的测试手段建立你自己的信心；
3. 合并之后，用安全网确保即使出错也能被快速捕获和修复。

把摩擦力变成改进机会

Theo这套工作流最值得借鉴的，或许不是具体的技巧，而是他反复强调的一种元方法论：留意工作流中一切让你不愿点下合并按钮的摩擦——无论是心理负担、测试麻烦还是风险恐惧——然后把每一处摩擦都当作改进项目、改进工作流、改进工具的机会。

"当你做出越来越多这样的改进，你会感受到自己交付能力和交付信心的指数级增长。"正是这些点滴优化的累积，让一个身兼数职的"兼职程序员"，在休假期间的产出反而翻了一倍。