卡住你所有项目的，从来不是 AI，是你自己

我一个人同时跑着六摊性质完全不同的活：写软件、维护代码、编排内容、制作内容、跑社群、交付产品。AI 员工要多少有多少，按理说产能应该起飞。实际情况是：所有项目都在等同一个人——我。

后来我想明白了：雇 AI 干活的那一刻，我其实同时给自己发了一张新的岗位聘书，叫调度员。这个岗位，才是整个系统里真正的瓶颈。

调度员是一份全职工作，你在免费兼任

把「调度」拆开看，它到底是什么活：记住每个项目跑到哪了；决定下一步谁先谁后；把 A 项目的产出翻译给 B 项目用；验收每个 AI 交回来的东西。在一家正经公司里，这叫项目经理，是一个全职岗位。

而多数人（包括之前的我）的默认做法是：每个项目开一个窗口，人在窗口之间跳。表面上是切窗口，实际上是切大脑——每跳一次，都得把「这个项目上次到哪、卡在哪、下一步干嘛」重新加载进脑子。

这里有一个不对称，值得讲透。AI 的上下文是外置的：写在窗口里、文件里，它「切换项目」几乎零成本。你的上下文在脑子里，每次切换都要真金白银地重建，每切一次就 lose 一次 focus。也就是说，这套系统里最贵、最不可再生的资源，是你的专注力；最便宜、管够的，是 AI 的算力。「自己当调度员」这个默认姿势，恰好让最贵的资源去承担最高频的操作。方向反了。

AI 可以无休止地响应你的命令。你是碳基生物，你不行。

解法不是更强的 AI，是换你的站位

我现在的做法叫 orchestration，我管它叫「指挥家系统」：在所有项目之上，立一个总调度的 AI——我给它起名叫 Buddy。我只跟这一个窗口讲话。需求用自然语言说明白，它去对应的项目里派 agent 干活、收结果、拉齐进度，我所有的决策，在这一个交互里做完。

注意这一步真正改变的是什么：不是 AI 变强了，一个模型都没换。变的是我的站位——我从「管线之间的人肉中转站」，退到「只出判断的那个人」。切换消失了，专注力收口到一个点。

代价我直说：token 用量会涨，因为中间多了一层调度在消耗。但这笔账不难算——token 是花钱能买的，专注力每天就那么多，买不来。拿可再生的资源，去换不可再生的，划算。

顺带说清一个岔路：这和最近 X 上很火的 Loop Engineering（让 AI 自己循环迭代）不是一回事。loops 解决的是单条管线上的深度——一个任务，让 AI 自己磨到好。我的问题从来不在单条管线的深度，在管线之间的宽度。你的瓶颈在哪，决定你该搭哪种，而不是哪个火就搭哪个。

立得住靠三根柱子，少一根就塌

这套架构的坑我自己踩过一轮。用一个真实故障来讲：我的 webXport——一个类似小 RPA 的 Chrome 插件——有用户报了个 bug。我把用户截图丢给 Buddy，说：去查。之后发生的每一步，刚好对应一根柱子。

柱子一：脑手分离，指挥家绝不自己下场。

Buddy 收到截图后做的事，是派一个 worker 进 webXport 的项目环境去查，而不是自己上手改。

这条规矩的机制值得讲透：上下文窗口是有限的。指挥家的窗口里装的是全局——六个项目的状态、优先级、进度，这就注定它装不下任何单个项目的完整语境：代码规范、历史坑、该跑哪些检查。所以指挥家一旦亲自动手，必然是从一片特别薄的上下文里瞎干，项目该守的纪律全被跳过，干得稀巴烂。这是结构性的取舍，不是模型不够聪明——换再强的模型，只要它的窗口用来装全局，就装不下局部。

跟公司一个道理：老板下场干活干不过员工，不是老板笨，是一线的上下文不在他脑子里。而且老板一动手还有个副作用：没人验收他。

柱子二：干活的和验收的，必须是两个「人」。

worker 说修好了。Buddy 不信。它同时生成了一个完全独立的审核员，拿着结果专门挑毛病，有问题直接打回重做。

这里的关键变量是「全新上下文」，不是「多看一遍」。写代码的 agent，它对问题的理解、它做的假设，全在它自己的上下文里——如果理解本身歪了，bug 就是这个理解产出来的，让它复查，还是会被同一个理解放行。自己审自己，错误是相关的。全新上下文的审核员不带这些假设进场，还被明确设定成「默认这活是坏的」——立场对抗，错误才不相关。有研究统计过，多 agent 协作里三成多的失败，就栽在自说自话上。就像上班搭子干活质量一般，你也睁一只眼闭一只眼——不是你坏，是你们共享同一套「差不多得了」。

我不是程序员出身，这套设计对我还有一层意义：我人工审代码，等于假装看懂。好在代码的对错是客观的，对就是对，错就是错，不需要人的审美判断——所以这一环可以全自动，agent 审 agent 就够了。反过来，什么时候这招不成立？交付物需要 taste 的时候：内容、设计、对外的话，终审还是得我自己来。

柱子三：红线靠结构拦，不靠 AI 自觉。

那个 worker 进的是生产服务器，但它只有只读权限。它没乱来，不是因为它乖，是它想乱来也动不了。

「写在手册里」和「结构上拦」的区别是本质的。手册是提醒，依赖 AI 在每一步都记得——而 AI 老喜欢自说自话，你以为写进执行手册它就守了，都tm是放屁。结构是权限、是 hook、是契约：把「不应该」变成「不可能」。门上贴「请勿入内」和门上装锁，是两种东西。

哪些事该上锁？我的分法看可逆性：撤得回的，放手让 AI 干，错了重来就是；撤不回的——生产环境、钱、删数据——结构上挡死，最后一个键留给人。

什么时候别搭：三个条件，各自怎么判断

诚实地讲，这套东西不是人人都该搭。它要三个条件同时成立才回本，每条给你一个判断法：

一，你真的多项目并行。判断法：回想昨天，你有没有在想 A 项目的事时被 B 项目打断、一天重建三次以上上下文？如果你手上就一个项目，直接在那个项目的文件夹里干，更快也更省——调度层对你是纯开销。

二，活是 AI 能接的。判断法：看交付物。是文件、文字、代码、数据，AI 接得住；要碰实物、要真人出镜的，接不住。我自己视频的拍、剪、发，到今天还是我亲自来。

三，你已经是瓶颈。判断法：看谁在等谁。AI 闲着等你派活、等你拍板——你是瓶颈，该搭；你在等 AI 出结果——瓶颈不在你，先别搭。

三条不齐就上架构，那不是生产力，是装备竞赛。搞清楚最适合自己的方式，比猛猛学重要得多。

至于具体怎么搭——指挥家的契约文件怎么写、hook 怎么挂、验收流程怎么设——是另一个篇幅的事，骨架我放在社群里带人一步步搭。这篇你至少可以带走一个判断：下次觉得「AI 不够快」的时候，先看看是不是你自己堵在中间。

这套架构我还在实时更新。最近刚给 Buddy 加了个反向蒸馏我的功能：它把我平时的判断标准蒸馏成文档，以后我跟指挥家讲话能更省力。说白了，懒惰是人类的第一生产力。

相关资源

站上跟这篇相关的东西，都在这：

• 一人多项目 Orchestrator 起步包 —— 这篇讲的这套架构的可拿走版本，起步三件套：hub-spoke 文件夹骨架、orchestrator 的 CLAUDE.md 模板（大脑职责 + 派活流程 + 红区 + 验收标准 + 循环上限，占位符替换即用）、派活指令话术模板。看完想动手，照着这个起，不用从零想。需注册登录后领取。
• 通识公开课 —— 免费的 AI 认知课（全部模块免费），从「AI 到底改变了什么」讲起，是这套打法的地基。需要邮箱注册登录。
• 工具 —— 文中提到的 webXport 等我自己在用的工具，安装包在这领。
• 联系卡尔 —— 想让我陪你把你自己的这套搭出来（诊断卡点 + 带你亲手做），两种接入方式都在这页，明码标价、有担保条款，看清楚再决定。