我在 5 天内使用 Taskwarrior + Claude Code 完成了 706 次提交
发布: (2026年2月6日 GMT+8 11:49)
4 分钟阅读
原文: Dev.to
Source: Dev.to
概览
上周我在 5 个代码库中合并了 38 个 PR，短短 5 天内产生了 706 次提交。我分享这个是因为很多 Claude Code（CC）用户都会遇到同样的生产力瓶颈。
当你尝试通过打开多个终端——每个终端对应一个任务——来扩展 CC 时，你很快会陷入 上下文切换：
- 哪个会话刚刚完成？
- 这个会话需要从那个会话获取什么？
- 两个会话是否在编辑同一个文件？
据说 Claude Code 的创始人会运行 10+ 并行会话，但真正的优势并不是超人般的多任务处理，而是一个 消除协同开销 的系统。
我把这个系统称为 TTAL — The Taskwarrior Agents Lab。
工具
| 工具 | 角色 |
|---|---|
| Taskwarrior | 任务队列 + 事件系统 |
| Zellij | 终端会话管理器 |
| Claude Code | 执行工作的代理 |
- Taskwarrior 钩子会生成 Zellij 窗格。
- 每个窗格运行一个注入了任务上下文的 CC 会话。
- 当一个会话结束时，下一条最高紧急度的任务会自动启动。
你不再管理会话，而是管理任务。
提交日志（周一 – 周五）
| 日期 | 提交次数 | 亮点 |
|---|---|---|
| 周一 | 199 | 语音/ASR 管道 + 代理心跳系统 |
| 周二 | 182 | 后端功能 + TUI 贡献 |
| 周三 | 122 | 基础设施 + 文档 |
| 周四 | 49 | 受速率限制，改为进行代码审查 |
| 周五 | 154 | 配置合并 + 新功能 |
周四是关键的一天：一次 API 速率限制导致吞吐量下降 75 %。系统，而不是开发者，成为了瓶颈。
设计原则
代理永远不会因为等待你而阻塞。
大多数 CC 工作流是 同步的：你下达任务，观察其执行，审查，然后再下达下一个任务——这使你在每一步都成为瓶颈。
在 TTAL 中：
- 代理从队列中挑选任务。
- 完成工作、提交更改，然后继续下一个任务。
- 你在 准备好 时审查 PR，而不是在代理需要你时审查。
这就是 5 个异步会话优于 10 个同步会话 的原因。
架构与文档
完整系统的文档位于 ttal.guion.io。
该架构并不局限于 Claude Code——Zellij 可以在其窗格中托管任何 CLI 代理。
瓶颈从来不是 AI，而是粘合层。
后续步骤
本文是 TTAL 系列的 第 1 部分。请关注系列文章，并在 ttal.guion.io 探索实现细节。