2 年 AI 编程实战总结：配对编程最真正改善质量

在近两年的 AI 辅助开发中——从 ChatGPT 3.5 一路用到 Claude Code——我始终在反复遇到同一个问题：每个模型都会犯下一些自己无法发现的错误。受结对编程和 Ralph Loop 启发，我搭建了一套双 Agent 工作流：一个 Agent 负责编写代码，另一个负责审查。上周，一份完全由这两个 Agent 编写的 PR，在经过维护者三轮反馈后，被合并进了一个拥有 1.5 万颗星的开源 Electron 项目。而我并不会写 TypeScript。

我反复遇到的问题

我使用 AI 辅助编程已经快两年了。一开始是用 ChatGPT 3.5 生成代码片段，后来陆续用过 Claude、Cursor、TRAE，最终爱上了 Claude Code。

从最开始，我就注意到，每个模型、每个 Agent 都有自己特有的问题。不是随机出现的 bug，而是具有一致性的失败模式：

Claude Code 会在上下文变长时跳过错误处理。它在架构设计方面非常出色，但到了对话后半段，编写防御性代码时就会开始变得草率。

Codex 往往会过度设计抽象层，但它能发现 Claude 遗漏的边界情况。

Gemini 不擅长处理复杂的多文件变更。

Cursor 存在上下文依赖问题——在较小的作用域内表现很好，但一旦涉及跨文件修改，就容易陷入混乱。

严重程度各有不同，但模式是一样的：单个 Agent 无法可靠地发现自己的错误。它既负责写代码，又负责判断这些代码写得好不好——就像自己给自己的考试打分。

每个开发者都知道，这个问题有一个名字。它叫作：“我们为什么要做 code review。”

结对编程，但参与者是 AI

20 世纪 90 年代末，Kent Beck 将结对编程正式纳入 Extreme Programming（XP）。这是敏捷运动中影响最深远的实践之一。

它的核心理念很简单：两名开发者共用一台工作站，一个负责操作，另一个负责导航。导航者会实时发现错误、质疑设计决策，并始终关注全局。研究一再表明，尽管这种做法看起来像是“浪费”了一半的开发者，但它确实能减少缺陷，并带来更好的设计。

同样的原则也适用于 AI Agent。如果一个 Agent 编写代码，另一个在旁边审查，就能发现更多 bug。

所以，我开始这么做了——只不过最初是手动完成的。

早在我还使用 Claude 聊天版、Claude Code 尚未出现的时候，我就会把 Claude 的输出复制到 ChatGPT，让 ChatGPT 审查，然后再把反馈带回 Claude。这个方法很原始，但比单独信任任何一个模型都更有效。

Claude Code 和 Codex CLI 出现后，这套工作流变得更加正式：Claude Code 编写代码，我把 diff 复制给 Codex；Codex 审查并指出问题，我再把反馈带回 Claude Code。如此反复。

这种手动协调多个 Agent 的方法确实有效，但它速度慢、重复性高，而且非常消耗认知精力。最糟糕的是，人在疲惫时很容易跳过这一步。你会对自己说：“这个改动看起来没问题，我就不审查了。”——结果偏偏总是这个改动会让你吃尽苦头。

后来，我发现了 Geoffrey Huntley 提出的 Ralph Loop：用一个外部循环封装 coding Agent，让它不断迭代。这个想法非常强大，也推动我开始自动化自己的双 Agent 工作流。

不过，Ralph Loop 团队也很坦率地说明了它的一些局限。对于具有明确完成标准的全新项目，它的表现很好；但在面对遗留代码库、复杂重构，或者需要在执行过程中设置多个检查点的多步骤任务时，处理起来就更困难。

这和我的实际体验一致。我并不是从零开始构建新项目，而是在 fork 一个现有的大型 Electron 应用，并对它进行深度改造。我需要一套能够处理模糊需求、维护者反馈和渐进式共识的机制。

于是，我构建了一个结构化循环：一个 Agent（Claude Code）负责写代码，另一个 Agent（Codex）负责审查；它们轮流工作，只有双方达成一致后，流程才会继续推进。

我则以 tech lead 的身份处在中间——划定范围、作出架构决策，并在双方意见不一致时裁决。

效率立刻得到了提升。不是因为 Agent 变聪明了，而是因为审查纪律实现了自动化，不再依赖我凌晨两点时还剩多少意志力。

真正的考验：我的第一个开源 PR

我一直在用这套工作流，将 AionUI——一个拥有约 1.5 万颗星的 Electron + React 应用——fork 并改造成公司内部的 AI 助手。

30 次 commit，零手写代码。完整品牌重塑、核心引擎重写、数据库迁移、CI/CD 重建——所有工作都通过双 Agent 循环完成。

在这个过程中，Agent 发现了上游项目中一个真实存在的 bug：使用 ACP agents 终止对话时，会遗留下没有被清理的孤立 CLI 进程。

我向 AionUI 提交了一个 PR。维护者审查后指出了三个问题：

• super.kill() 被重复调用时存在竞态条件——需要增加幂等保护
• 错误被吞掉了——.catch(() => {}) 应该记录 warning
• treeKill 描述不一致——PR 描述与上游项目的实际实现不符

我把维护者的反馈交给两个 Agent，让它们自行处理。

作者 Agent 分析问题、编写修复，并运行测试，结果是 133/133 全部通过。审查 Agent 检查 diff、验证正确性，并确认类型检查没有问题。

它们来回进行了几轮。我全程旁观，但没有写任何代码。

最终，PR 被合并了。

“LGTM——三项 review 反馈都得到了妥善处理。”

这是我第一次向别人的项目提交 PR，也是第一次有这样的 PR 被合并。

我拥有 30 年的软件行业经验，但过去 25 年主要从事产品和商业工作，而不是编写代码。我不会写 TypeScript。

AI 工具让我重新回到开发工作中，而双 Agent 循环让我得以为一个真实项目贡献真正有价值的修复。

不约而同的探索

我发布这套方法后，另一位开发者 Hwee-Boon Yar 与我分享了一种类似的方案。他是一名独立开发者，同样拥有 30 年经验。

他实现了一个 skill，可以通过 shell 调用第二个 Agent 进行审查，并不断循环，直到审查 Agent 再也找不出问题。它比我的方案更轻量，可以在单个 session 内运行。

取舍不同，但核心洞察相同。

多个人正在独立得出同一个结论：一个 Agent 不够。你需要另一双眼睛。

这并不是什么魔法般的解决方案。下面这些问题依然没有解决：

• Agent 崩溃后无法自动恢复。Agent 在 session 中途崩溃时，循环也会停止。你必须手动重启，目前还没有自愈机制。
• 迭代轮次被浪费。有时 Agent 会陷入来回拉扯：一次修复引入了新问题，审查发现这个问题，而下一次修复又引入另一个问题。这时你必须介入并重新划定范围。
• 上下文窗口问题——但这里有一个转折。在长 session 中，质量会下降；当 Agent 压缩上下文时，也会丢失信息。不过，双 Agent 架构在这里反而提供了帮助：当一个 Agent 的上下文被压缩并丢失细节时，另一个 Agent 仍然记得。它们并不共享同一个上下文窗口，所以不会在同一时间丢失相同的信息。这是一个意料之外的架构优势。

我正在考虑为未来版本构建跨 Agent 的共享记忆管理机制，让它们可以明确共享各自已经遗忘的信息。

两个 AI 完全可能愉快地对一个糟糕的设计达成一致。如果没有具备领域判断力的人类参与，这就只是两个 Agent 互相走过场、给对方盖章。

人类仲裁者不是可选项。

这不是自主开发，而是结构化的 AI 辅助开发。这个区别很重要。

围绕 AI 编程的讨论过于关注生成，却没有给予审查足够的重视。所有人都在评测模型生成代码的速度和数量，却没人问：谁来检查这些代码？

如果 AI 生成的代码需要结构化批评——就像人类编写的代码一直都需要 code review 一样——那么真正的问题就是：如何把审查纪律内建到 AI 工作流中？

我已经把从 AionUI PR 流程中学到的经验整合进去，并发布了一个新版本。主要内容包括：

• npm i -g ralph-lisa-loop
• 支持 Claude Code（Ralph）+ Codex CLI（Lisa）
• turn 控制、tag 系统、共识协议和 policy 检查
• 通过 tmux 运行的 Auto mode（实验性）
• 原则上与具体 Agent 无关——任意两个 CLI Agent 都可以承担这两个角色

目前还处于早期阶段。我每天都在用它处理真实工作，而不是做演示。

如果你一直在进行 AI 编程，并反复遇到那种令人沮丧的“差不多对了，但还是差一点”问题——你并不孤单。

它也许能帮到你，至少也能为你自己的方法提供一些思路。欢迎讨论。相比成功案例，那些失败模式其实更有意思。

部分评论可能仅对已登录的访客可见。登录后可查看全部评论。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。