AI 编码工具的生产力上限
运行速度提高 10 倍，犯错也多 10 倍
导语
我在晚上 11 点坐在笔记本前，运行着 Cursor，同时开着 4 个独立的 Claude Code 对话。我感觉比以往任何时候都更高效。但我很快想睡觉，除非我继续坐在这里，主动地提示和审阅，否则没有任何工作会完成。
我们已经处在现代 AI 编码工具的早期拐点。你可以在一小时内完成过去需要一天的功能，或更快更全面地进行头脑风暴与打磨。但你的生产力受限于注意力容量，有时并不清楚你到底是实际完成了更多工作，还是只是启动了更多永远做不完的事情。
一个非常有共鸣的例证：
在过去几个月里，我帮助过几位客户探索将 AI 编码工具有效集成到他们开发工作流的不同方法。在大多数情况下，感觉我们在提高生产力，这很棒，但又觉得我们没有足够努力。如果我们的目标是最大化生产力呢？
我想知道：如果我能定义 20 项任务，把它们在后台触发，去睡觉，醒来后再检查它们的</span><em>状态</em><span>会怎样？</span>
这个问题促使我构建了 GZA。
从美好到具体的需求
我一开始怀抱着一个关于美好世界的简单愿景：
- 定义一堆任务
- 在后台运行它们
- 同时做别的事一段时间，比如睡觉、锻炼、参加会议，或发呆望窗外
- 稍后回来查看结果
但一旦我开始深入思考细节，需求就变得更明确：
- 以任务作为提示。 不需要正式格式或产品需求文档。我希望像直接对 Claude Code 表达一样来描述工作。模糊的提示可能会产生模糊的结果，但那没关系——我可以反复迭代。
- 异步执行。 工作在后台进行，我可以稍后查看日志。我消除了自己作为实时瓶颈的角色。
- Git 分支隔离。 每个任务拥有自己的分支。我可以合并、改进或弃置它们。
- 执行隔离与安全。 代理应运行在受限环境中，例如 Docker，这样它们就不可能意外炸坏我的本地机器。
- 代理灵活性。 我最初的目标代理/模型是 Claude Code，但这可以演进。不同任务类型应能使用不同的代理。
- 成本意识。 我不想在不知情的情况下让一个定义不清的任务运行数小时并浪费大量金钱。我希望积极限制对话长度，如果在可接受时间内无法解决再进行优化。
遥遥领先
我目前使用 Cursor 搭配 Claude Code，有时用 Cursor 聊天，有时在 VSCode 中使用 Claude Code。所有这些选项都很出色，但都是为同步、有人参与的工作流程而设计的。
以下是我调研过的其他工具：
- opencode 和 aider 都看起来不错，但工作流程与直接运行 Claude Code 类似。
- Amp 看起来很棒。概念上的 threads 和 handoff 都很有意思，而且一旦并发或多步骤代理工作达到一定规模，某种形式的这些概念可能就是必要的。
- Ralph 直接解决了后台执行问题，这正是我的主要需求。但我不想把产品需求文档（PRD）作为输入，而且我觉得“持续工作直到队列清空”这种总体方法并不是我想要的。
- Gas Town 非常吸引人——一个由不同角色代理组成的全自动化社区。这远超我当前的目标，但可能是行业很大一部分的发展方向，不管我们现在是否能看到它。
所有这些工具看起来都很强大，但没有一个满足我所有的要求。我需要更多地了解问题领域。最有教学意义的前进方式是去构建点什么，于是我投入其中。
初步草图
据我记得，最初版本的 GZA 是一个 bash 脚本，使用一个 Markdown 文件来存储任务。任务完成后，会在前面加上一个勾并移到下一个。出奇地好用。
但很快我遇到了一些限制：
- 用 Markdown 来管理任务很笨拙，因为当我正在编辑以添加新任务时，代理常常会同时更新该文件，造成混乱和轻微的数据丢失。
- 我把任务移动到了 YAML，这让我可以使用像
status和completed_at这样的字段来组织任务，但文件很快就被已完成的任务填满，导致难以编辑。
我已从 bash 迁移到 Python，并将任务定义从 YAML 转移到了 SQLite。我对使用 SQLite 仍然没有完全信服，但我们稍后会讨论这个问题。
更重要的是，一种工作流程开始显现。从你的初始提示出发，你规划（可能）、你实现、你评价（可能）、你合并：
每一步都比看上去复杂。部分原因是我们在自动化几十年来由人类完成的工作，但更重要的是涉及的环节太多：
这些工作流程的每一步都比预期更为复杂：
- LLM 可靠性： 连接中断、响应超时、代理陷入重复相同行为的对话循环
- 计划质量： 太模糊、过于详尽，或以其他方式……就是错的
- 实现噪音： 尽管有明确指示，仍在奇怪的位置创建不必要的文件
- 评价清晰度： 过于微妙以致无法以程序化方式采取行动的反馈
- 合并冲突： 随着并发任务增加呈指数级增长
每一项都值得单独发一篇文章。现在我只想说，GZA 通过设置最大回合限制、人工审核门控、结构化审核输出和自动变基来处理这些问题。它并不完美，但对于日常使用已经足够实用。
GZA 原则与使用
首先说明一下，这个项目非常新且粗糙。有些功能可能不完善，尤其是在失败的边界情况方面。请提交错误报告，我会修复，或者提交合并请求。我用 GZA 构建了 95% 的 GZA——欢迎你也这么做。
阅读 快速入门 是开始的最佳途径。但我在这里做个概述：
# install GZA
uv install gza-agent现在，如果你为虚拟环境的 activate 脚本执行了 source 操作，就可以直接运行 gza，否则每次调用都需要运行 uv run gza。
# initialize config file
gza init# add task prompt (opens $EDITOR)
gza add# run single task (with -b to run in background)
gza work -b# run 5 tasks in background
gza work --count 5 --background# show running tasks
gza ps# view logs for task
gza log 1# view status of task
gza show 1# show tasks with unmerged work
gza unmerged# merge task 1 which just completed
gza merge 1我将在未来的文章中详细介绍这些功能及更多内容。
自动化编码的混乱
在过去几周构建和使用 GZA 的过程中，我将讨论我学到的一些较重要的内容。
对话循环
我提出了一个模糊的功能要求，但代理没有足够的项目上下文来推进它。它循环往复进行多轮，直到获得所需的信息。
幸运的是我有几样东西：
- GZA 配置中“ 最大回合数 ”的概念，该配置在 50 回合后终止对话。
- 对话记录
然后我：
- 启动了一个交互式 Claude 会话
- 请它查看日志并评估为何耗时如此之久
- 请求它将该信息作为项目上下文添加到
AGENTS.md - 重新运行了任务
这次运行得快得多。这个例子是我在解决一个错误，但如果放大来看，有一个更大的模式：评估任务是如何被理解、规划和执行的，并寻找方法让这个过程更快且质量更高。
换句话说：这不仅仅是我介入去修复一个问题。这是我介入去改进系统，使得类似的问题在未来发生的可能性大大降低。
合并冲突
我在后台启动了许多任务。然后我试着按重要性合并它们，但那并不是它们完成的顺序。接着我遇到了一些合并冲突。
最简单的可以通过一次简单的 rebase 修复。这看起来很容易实现自动化。去年我有一个客户的 monorepo 禁止直接合并，所以所有更改都堆在一个巨大的合并队列里，通常等上几分钟，有时甚至几个小时。25% 的时候，合并会失败，你得 rebase 并推送分支，然后合并才会成功。既令人不快又低效。
对于简单 rebase 无法修复的合并冲突，我看不出我们为什么不能让 Claude 来修复它。
但超越具体的技术问题，使用 GZA 完全改变了我对开发工作流的思考方式。这就引出了一个更大、更深、更让人不安的问题……
校准人的参与度
自从开始这个项目以来，我一直感到一种潜在的紧张：在我自己的项目软件开发中，我需要多大程度上亲自参与？
在我看来，架构设计目前还不能完全实现自动化，至少现在还不能。但在创建和审查设计方案时，绝对可以由人工智能提供辅助。
编码则完全可以实现自动化。
代码审查可以实现自动化。
如前所述，合并可以实现自动化。
多年来，部署、错误检测、告警以及其他可观测性方面都已实现自动化。
从更宏观的角度看，我们离运营构建这些系统的系统并不特别遥远，当前状况只是对昨日状态的逻辑延伸。技术只需跨过最后几道障碍。
如果要我总结，我会说：人类参与的程度现在是个人和/或组织的选择，而不是技术问题。
在我之前链接的 Gas Town 文章中，Steve Yegge 提到 AI 辅助编码的各个阶段，Stage 1 是“零 AI”，Stage 8 是“构建你自己的协调器”。
我作为一名独立顾问，在个人工作中处于第 5 到第 8 阶段之间，而在客户项目中，我会在他们的环境内尽我所能大胆行事。
但对你来说？选择权在你手中。
接下来是什么？
在构建这个非常早期的版本 GZA 的过程中我学到了很多东西，现在我已经在日常开发工作中使用它。它还很粗糙，但有趣且实用。
我计划在未来发表关于我发现的具体问题和解决方案的文章，例如：
- 使用 Docker 隔离代理执行
- 自动化代码审查与迭代
- 自动合并冲突解决
- 处理嵌套任务与中断
