我用Claude Code同时管15个项目的工作流设计

Fifteen projects, one person. The obvious failure mode is that you spend your day switching between them, and by evening you have touched six and finished none.

所以我不切换。无论我在哪个项目里，打开终端输入两个词：order backlog。Claude Code 读取该项目队列，按优先级排序，然后开始跟我聊那件最重要的事。这就是我的全部交互界面。

这两个词背后是一套我在过去几周里构建的系统，这篇文章就来剖析它的架构。work 从哪里来，如何分类，什么在我睡觉时运行，以及哪些部分我坚决不自动化——无论它们看起来多诱人。先看一张总览图，因为比起描述它要容易理解得多。

一张图看清全貌

本文接下来逐个阶段讲解这张图。

Where orders come from

一个 order 就是文件中的一段 Markdown。每个项目一个文件。这就是全部的数据模型。

没有数据库，没有 ticket 系统，没有带列的看板。我几年前试过正经工具，最后放弃了，因为每一个都需要你去维护这个工具本身。Markdown 什么都不要求我。

工作从四个方向涌来。

我给自己发邮件。当我在外面时突然想到什么，就给自己发一封邮件，只有一行字，没什么值得写进 subject 的。这是我的首选入口，因为手机是我唯一随时带在身边的设备。

我在做某个项目时开口说了出来。 session 进行到一半，冒出来一件事我不想现在处理。我说"给这个项目提一个 order：上传框滚动时抖动"，session 就把它写进去了。另一种情况正好相反：我坐在一个项目里，想想还有多少事没做，每一件事就变成一个 order。

我的 assistant 发现了它。一个独立的 Claude Code session 处理我的收件箱。当它碰到一个错误报告且能判断属于哪个项目时，就把 order 归档到那里。

一次失败的 merge 也会产生一个 order。这一点下面会展开，因为它正是让整个系统自我修正的循环。

The drop box, and why mail does not go straight in

这是我想得最久的部分，也是我在做任何其他事情之前首先要做对的部分。

我给自己发的邮件不会直接变成 order。它先落入一个 drop box。每隔十五分钟，我 Mac Studio 上的一个小任务就把 drop box 清空，分发到各个项目队列。

为什么要绕这一圈？提示词注入。我的邮件地址是公开的，任何人都能给我发邮件。

想一下这意味着什么。如果邮件文本直接变成可执行的工作，一个陌生人可以礼貌地发一条消息要求删除一个生产域名，而我自己的系统会把它格式化成规范 order，交给一个有提交权限的 agent 处理。根本不需要有人闯入，只要会写就行。

所以 drop box 读的是语义，不只是格式。这段文本所请求的事情有任何道理吗？在此基础上还要扫描有杀伤力的动词：delete、drop、truncate、transfer、pay、cancel、shut down。

任何触发这个规则的文本都会被强制要求我在场。注意不是阻止——合法的 order 经常出现这些词。"Delete the old backups" 是一个完全正常的请求。只是它永远不会在没人盯着的时候发生。

底层规则比关键词列表更严格，这是我愿意分享给任何构建类似系统的人的：通过邮件到达的文本永远不会启动无人值守运行。即使它被标记为已批准且无害也不行。来源的优先级高于分类。来自外部的消息可以请求工作，但它不能授权工作。

How the system decides what runs without me

每个 order 携带一个字段说明它可以如何处理。三个值：

## ORDER <id>
status: approved
art: autonomous | dialogue | decision

autonomous 无人值守运行。dialogue 等待有我在场的 session。decision 只能由我亲自点击：支付开关、域名购买、任何公开可见的操作。

有趣的问题是这个字段谁来填。Claude Code 在 order 被写入时填的，它要做出的判断主要是大小：这个任务小到可以一次无人值守运行完成吗？太大了就自动进入 dialogue 堆。系统被允许决定自己无法决定，这是我越用越喜欢的一个特性。

如果没有指定任何值，默认是 dialogue。fail safe，倾向于伤害较小的那一边。一个 order 闲置太久损失的是我等待的时间。一个 order 在不该运行的时候运行了，损失的是生产环境。

每三十分钟一个 dispatcher 唤醒，取出排在最前面的 approved autonomous order，然后运行它。不在我的仓库里运行。在一个新鲜的 git worktree 里，在所有仓库之外独立的分支上创建。

这个细节不是装饰。它是整个系统能在我一并工作的同时运行的原因——因为我很可能在同一个时刻正坐在同一个项目里。worktree 给 agent 它自己的完整 checkout，而我的打开的文件完全感知不到。

运行结束后，工作必须回来。如果 merge 干净且测试通过，就落地，order 关闭。如果有冲突，系统不猜测、不强制。冲突变成该项目里的一个新 order，等待我处理。它的 failure mode 是写一个关于自己的 ticket，我能接受这个结果，远好过一个即兴发挥的系统。

Three brakes, because the meter is running

我每月为 Claude Code 付 200 欧元。从财务角度说，自动启动的 agents 就是我睡觉时也在烧钱的机器，我来自德国的一个地区，这个念头让人夜不能寐。所以有三个独立的刹车。

每次运行的限额。每个 worktree 有一个硬性的美元上限。它宁可撞墙也不跑飞。

自动化整体的单日上限。从运行日志计算。当天总额达到后，dispatcher 停止启动新工作。

同时运行的数量上限。两到三个，不能再多。这跟 CPU 无关，跟账户有关。我不得不把这个数字往下调过一次。起初允许四个并行，结果配额用完的速度比我看 dashboard 还快。等我注意到时，这个月已经比计划短了一大截。两个在现在感觉是对的。等我更信任这套机制之后三是我的目标。

我更喜欢第四个刹车：每个 order 最多三次尝试。之后标记为 incomplete，再也不会自动启动。它等我的手。一个无限重试的系统最终会找到花更多钱的重试方式。

还有一个小优化我没想到它影响这么大：运行从最便宜的模型开始，只有失败了才升一级。大多数 order 被最便宜的可能方案完成。

The other path: working through a project with me

dialogue orders 才是我实际的日子怎么过的，对它们的交互界面就是开头那两个词。

我进入大约十五个项目目录中的一个，输入 order backlog。Claude Code 列出该项目的 orders，按优先级排序，然后立即开始处理排在最前面的那个。它以固定格式呈现，这被证明比我想的重要得多：

鸟瞰。一句话说明这件事在项目中的位置。不是任务，是上下文。

细节。一句话说明它实际上是什么。

一个带建议的具体方案，外加两三个备选，每个都有理由。

然后我做三件事之一：接受、选一个备选、或者写"我们来换个做法，像这样"。它构建、测试、部署、在生产服务器上再测一遍、标记 order 完成、移到下一个。我在各个项目间走过，在每一个里工作都自动滚动。

固定格式之所以重要，是因为它去掉了我最不擅长的部分：读两个星期前写的一个 order，打开一个十天没碰的项目，然后搞懂过去的我到底在想什么。过去的我不是一个靠谱的同事。他写简洁的笔记就走人。

现在我读三句话和一个建议，然后用大约十五秒回到上下文。

在一个项目里我还可以说另一件事：关于这里的 orders 有什么一般性问题吗？它把整个队列里所有不确定的东西汇总起来。我一次性回答完，然后它独自运行很长一段时间。

批处理问题而不是每十分钟打断一次。小变化，巨大的不同。

The one repository that may look everywhere

普通项目之间是隔离的。项目 A 的 session 永远不会碰项目 B 的 orders，永远不会。钩子强制每个仓库只有一个 writer。

我不是出于整洁才建立这个规则的。有过两个并行 session 写了同一个共享配置文件，各自读取，各自改了自己那一行，各自把整个文件写回去。最后写入者赢，其中一个 session 的工作无声无息地消失了。经典的读-改-写，只是我根本没想过我的 agents 是并发进程。它们确实是。

master-supervisor 是例外，它也是 portfolio 视图所在的地方。从那里我可以问：我拥有的所有项目中最重要的那个 order 是什么？如果任何项目夜间收到了错误报告，那就是浮现出来的东西，不管它属于哪个仓库。

我还可以说"现在就做"。然后它先检查一件事：该项目里是否已经有 session 打开了？如果有，它告诉我不可以直接在主仓库工作，改用 worktree，做完了再合并。它假设我可能正坐在里面，因为我通常确实在。

What it costs to build something like this

如果你在考虑为自己构建这个，以下是它实际上需要什么。我今天统计过。

当把它放进表格时，有两件事很突出。

首先是比例。约 9,800 行代码对抗 11,100 行 prose，文档和指令文件一并计算。这个系统超过一半根本不是代码。是给语言模型的书面指令加上给唯一涉及的人的文档。这让我惊讶，但回想起来不该惊讶。代码只是搬动文件和启动进程。所有的判断力都在文本里。

其次是测试。308 个测试，覆盖 9,400 行的编排层，而系统只有一个用户。听起来过分了，直到你记住这个系统是干什么的：在我睡觉时启动持有十五个仓库提交权限的 agents。测试不对真实的 orders 运行，它们对副本运行。

表格里有一个数字值得警告，因为我自己最初也算错了。仓库约有 2,800 次 commits，把这个作为构建工作的引用是夸张的废话。其中 1,833 次是机器在自言自语，因为索引和优先级排序按定时器刷新，每次刷新就是一次 commit。另外 706 次是簿记：批准、重新分类、关闭。剩下的，真正改变系统如何运作的 commits，是 263 次。

我在这篇文章初稿里写的是 1,360。感觉差不多对，这恰恰是"感觉差不多对"的数字的问题所在。每当你看到有人拿 commit 数量作为工作量的证明时，问一下那个仓库里还有什么。

关于这 263 次 commits 我应该说一句，因为它改变了这个数字的含义：我自己没有写一行代码。

一行都没有。全部来自我和 Claude Code 的协作，而且有相当一部分我根本没动手敲。我通过说话来描述我想要的，用 Superwhisper 做听写，然后读回来、争论、修改。

我十六岁开始编程。这是我生命中第一次没有手写代码的年份，我还是不太习惯把它说出口。我在这个仓库里的工作不是打字。是决定什么东西应该存在，是注意到什么时候出了问题，以及足够频繁地说不。而从这套系统来看，事实证明那才是大部分的工作。

至于时间，我从来没有认真追踪过，所以只能估计：超过一周的全职工作量，分散在晚上和周末。也可能更多。我宁愿给你一个粗略的数字而不是我编出来的精确数字。

这是否值得完全取决于你运行多少个项目。三个项目，不要构建这个。用每个项目一个 Markdown 文件就够了，我这样做了一年。大约在八个或十个项目时算术翻转了，因为失去对一个项目的跟踪的成本开始超过这套机制的成本。

What this actually gave me

它没有让我写代码更快。Claude Code 已经做到了那部分。

它解决了一个不同的问题，而这才是同时跑太多东西的个人开发者真正被拖垮的那个：项目安静下来，没人注意到。不是因为它们失败了，而是因为我这个 setup 里没有任何东西会举手。一个 Markdown 文件不会告诉你它已经被冷落了三周。一个按优先级对十五个项目排序的队列会。

第二件事更小但我更珍视。我不再靠问自己"想做什么"来决定做什么，因为我想做的总是那个进展顺利的项目。现在我输入两个词，排序由一个没有情绪、没有偏好的东西来完成。对十五个项目来说，"眼不见心不烦"是一个真实存在的风险，而这是我发现的最便宜的疗法。

如果你构建类似的系统，先建 drop box 和审批门。这个系统里其他所有部分我都至少重建过一次。那两个从来不需要修复，而它们是我能在 agents 持有提交权限的同时安然入睡的原因。

整个系统是私有的，没有公开仓库。如果有足够多的人想看，告诉我，我就知道把它做漂亮是值得的。