我希望有一个数字分身，替我 24h 打工

不得不说，AI 让我更忙了。没有 AI 的时候我只需要面对一个编辑器窗口，现在却要管理 4-6 个终端和多个 AI 助手。人的精力终究有上限。 于是我想：能不能造一个分身，替我干这些？ 我把它叫做「24h 打工人」。

一个真实的场景

用户提了个 bug：「搜索结果列表的分页有问题，切换页码后数据没更新」。

半小时后，AI 自动完成了这些事：

1. 分析需求，判断是否需要澄清
2. 生成技术方案（spec.md + plan.md）
3. 拆解成 3 个可执行任务
4. 并发执行前后端代码修改
5. 通知我 review

这是我最近一个多月的尝试。下面说说它是怎么工作的。

为什么要规模化？

痛点：手动管理 4-6 个终端就是极限

在做 24h 打工人之前，我的日常是这样的：

开 4-5 个终端，跑着 codex、gemini-cli、claude；同时 Cursor 里还开着几个 Agent 窗口。它们各自处理不同的需求，或者协作完成一个大需求。

这种模式的上限大概是 4-6 个。再多就开始混乱：

• 这个终端跑到哪了？那个终端等的是什么？
• 某个任务失败了，要翻好几屏日志才能找到原因
• 下次遇到类似需求，之前怎么做的完全想不起来

解法：自建调度层

在《从 Demo 到生产：打造我的技术资讯 + 知识库 Agent》里，我讨论过 Agent 的核心设计决策。24h 打工人是代码版，架构更复杂，但思路一脉相承。

从 Demo 到生产：打造我的技术资讯 + 知识库 Agent

既然手动管理有上限，那就让代码来调度。

我的方案是：自建调度层，把 AI CLI 当成执行后端。

为什么选 CLI 而不是 API？

codex、gemini-cli、claude-code 这些 CLI 工具，已经内置了读文件、改代码、跑命令的能力。调度层只需要：

1. 接收任务：用户反馈进来，写入文件队列
2. 分发执行：轮询队列，调用 CLI 执行
3. 状态管理：记录每一步的输入输出，持久化到文件
4. 失败切换：某个 CLI 配额用完，自动换下一个

这样就能支持多个 AI 后端（codex、gemini、claude 随时切换），同时保持完整的执行留痕。

补充说明：Claude Agent SDK 最近发布，提供了 Hooks、Sessions 等更细粒度的控制能力。我没用它的原因：一是没订阅 Claude（使用公司内部 claude cli）；二是基本 AI CLI 都提供非交互式调用（-p 或 --print），对于调度场景够用了。如果你需要在 tool 调用前后注入逻辑、或者管理复杂的会话状态，SDK 是更好的选择。

我的第一原则：每一步都要留痕

每一步都要留痕：

• 输入了什么 prompt
• AI 输出了什么
• 状态怎么流转的
• 失败在哪里

这不只是 debug 用的——留痕是 Agent 自我进化的前提。

SDD：Agent 的运行日志

这里引出一个关键概念：SDD（Spec-Driven Development）。

在我的系统里，每个需求处理完都会留下一组文档：

这套 SDD 文档，就是 Agent 的运行日志。

有了它，我能：

• 复盘每个需求的处理过程
• 发现 AI 容易犯的错误类型
• 沉淀经验到 Constitution（架构约束文档）

SDD 不只是文档规范，是 Agent 自我进化的基础设施。

系统架构

有了思路，下一步是设计。我把整个流程分成两个阶段。

两阶段流程

Clarification（需求澄清）：判断需求是否清晰，不清晰就生成澄清问题让用户补充。

Feedback（需求开发）：采用完整的 SDD 流程——spec → plan → tasks → execute。

轻量选型：文件存储 + 轮询执行

很多人一听到 Agent 系统，就想到复杂的技术栈：消息队列、向量数据库、Redis、K8s……

我的选型很简单：

没用消息队列、没用数据库、没用 LangChain。

文件系统的好处是：

• 出问题让 AI 直接看文件，不用查数据库
• 方便 Git 版本控制
• 本地开发和生产环境一致

架构图

SDD：让 AI 在框架内工作

这是整个系统的核心。Feedback Handler 执行完整的 SDD 流程：

Step 1：从用户反馈生成 spec.md

用户的反馈经过 Clarification 阶段后，会有一个结构化的摘要。我把它转换成 spec.md：

关键点：

• 验收标准：给 AI 明确的完成定义
• 编码原则：注入项目级别的约束
• 项目范围：明确是前端、后端还是全栈

Step 2：AI 生成 plan.md

有了 spec.md，下一步让 AI 生成技术方案：

Constitution 是项目的架构约束文档，包含不可违背的设计原则。这让 AI 能在项目的规范下工作，而不是写出「能跑但不符合团队风格」的代码。

Step 3：AI 生成 tasks

plan.md 是人能读懂的方案，但 Agent 需要结构化的任务列表：

project 字段很关键，后面会用它来决定任务的并发策略。

Step 4：智能并发执行

任务拆解完，就可以执行了。这里有个关键设计——按项目分组，组间并发、组内串行：

为什么这样设计？

这个策略在实践中效果不错：既利用了并发提升效率，又避免了文件冲突。

并行的本质不是"同时做很多事"，而是"让每件事都不需要等别人"。 前后端任务之间没有依赖，所以可以并行；同项目任务之间可能有文件冲突，所以必须串行。

两个关键设计

决策 1：工具失败自动切换

AI CLI 工具（codex、gemini、claude）经常会遇到配额限制、服务不可用等问题。我的方案是失败切换：

配合 Tool Prober 定时探测工具可用性：

这套机制保证了：

• 单个工具挂了不影响整体
• 配额耗尽自动切换备用工具
• 工具恢复后自动重新使用

决策 2：状态机设计

任务状态用显式的状态机管理，而不是隐式的标记文件：

状态流转有严格定义，禁止出现别名或自造状态。这让整个系统的行为可预测。

Agent vs Skill，用哪个？

最近 Skill 概念很火。聊聊 Agent 和 Skill 的区别。

核心区别

用一句话说：

Agent 是「用时间换钱」，Skill 是「用钱换时间」。选哪个，看你的 n 有多大。

我的选择

24h 打工人用的是 Agent 模式，原因：

1. 可靠性要求高：这是服务真实用户的生产系统，不能靠「LLM 指令跟随」赌
2. 目标是规模化：要支持每天可能跑几十上百个任务，O(n) 成本扛不住
3. 需要留痕：SDD 流程的每一步都要存下来，方便复盘

但这不是说 Skill 不好。如果你的场景是：

• 任务类型多变，难以预定义流程
• 对成本不敏感
• 能接受 Claude 级别的 LLM 依赖

那 Skill 是更好的选择。

选哪个，看你要解决什么问题。

踩过的坑

Vibe Coding 的诱惑

24h 打工人项目初期，我也尝试过 Vibe Coding：不写 spec、不做设计，直接让 AI 写代码，跑通就算。

结果：

• 前几天效率很高，「wow 这 AI 真厉害」
• 一周后代码开始乱，AI 对功能的实现越来越差，偶尔陷入打地鼠状态
• 两周浏览代码，大量过度设计，冗余逻辑，只是表面能跑出结果

最后被迫亲自 review 每个文件。

先手写了一版存储设计与架构流程文档。然后花了一整天做「设计与实现对齐」：把 AI 写的代码和设计文档一一对照，发现到处不一致，再逐个用 Cursor 重构。

那一天的工作量，奠定了让 24h 打工人自举的基础。

Vibe Coding 是「先易后难」的捷径。

让 24h 打工人自己开发自己

有了设计文档、代码基础和 SDD 流程后，一个有意思的事情发生了：

24h 打工人可以自己开发自己了。

以前我要逐个 review AI 写的代码，现在流程变成：

1. 我提需求（通过反馈系统）
2. 24h 打工人自己澄清、规划、执行
3. 我只需要 review 最终的 PR

关键在于：有了 constitution.md（架构约束）和存储设计文档，AI 在生成 plan 和执行任务时，会自动遵循这些约束。它不再是「自由发挥」，而是「在框架内工作」。

这不是完全的自举。核心设计决策、架构变更，还是需要人来把关。但日常的功能开发和 bug 修复，已经可以放心交给它了。

一个真实的自举案例：

有一天我发现需求澄清页面有 bug——「无法选择待确认问题的选项，也没有提交按钮」。

于是我直接通过反馈系统提交了这个问题：

几分钟后，企微收到通知：需求澄清完成，待确认。

点进去看，AI 已经理解了需求，拆解了目标、验收标准，还生成了几个待确认的问题：

确认后，24h 打工人开始执行：需求分析 → 任务执行 → 执行完成。

整个过程我只做了两件事：提交反馈、确认澄清。剩下的，24h 打工人自己搞定了。

它自己修复了自己的 bug。

自举的前提是：先有明确的设计文档、代码基础和 SDD 流程。

这也是为什么那一天的「设计与实现对齐」如此重要——它不只是修复了代码，更是建立了让 AI 自举的基础设施。

SDD：先难后易的大道

后来我切换到 SDD 模式：每个需求先写 spec，再出 plan，再拆 tasks。

初期确实慢了一些，但收益是：

• 每个需求都有完整的决策记录
• AI 的错误可以追溯到哪一步
• 好的做法可以沉淀到 Constitution

大道如夷，而民好径。 SDD 就是那个初难后易的大道。

结尾：规模化

回到最开始的问题：24h 打工人解决了什么？

不是「替代人写代码」——AI 写代码早就能做到了。

而是：规模化。

一个人同时开 4-6 个终端，就是极限了。但有了调度层，可以轻松扩展到 20-30 个并发任务。

一个人每天能 review 的代码量是有限的。但有了 SDD 流程，AI 在框架内工作，只需要 review 最终结果。

一个人的经验会遗忘。但有了 spec/plan/tasks 的留痕，每次执行都在积累可复用的知识。

规模化不是让一个人做更多，而是让「必须依赖人」的节点越来越少。

SDD 就是这个系统的核心：

• spec.md 把模糊的需求变成明确的目标
• plan.md 把目标变成技术方案
• tasks 把方案变成可执行的步骤
• constitution 把经验变成可复用的约束

在之前的文章《ELI5: 并行计算在 AI 演进中扮演的角色》里，我讨论过一个核心观点：

能否并行，取决于任务之间是否有依赖。

ELI5: 并行计算在 AI 演进中扮演的角色（修订）

24h 打工人的设计思路一脉相承：用 SDD 把任务拆成自包含的单元。每个任务只需要 spec + plan + constitution 就能执行，不依赖漫长的对话历史。

这就是规模化的底层逻辑。

如果你也想试试，不用搞那么复杂。先从一件事开始：

下次写代码前，先写一个 spec.md。

哪怕只有三段话：要做什么、不做什么、怎么验收。

这就是规模化的起点。

而我，终于可以少管几个终端了。