AI保姆式编程的隐藏成本：200个存在缺陷的脚本浪费了数百万美元

概述

AI 编程代理的快速普及暴露了软件开发工作流程中一个隐藏的 inefficiency：基础自动化脚本的冗余且昂贵的重建。最近的分析表明，数千名开发者独立编写了有缺陷的“PR babysitting”脚本，导致数百万美元 API 令牌被浪费。

这种现象突显了开发者社区中更广泛的问题。虽然 Claude Code 和 Codex 等 AI 代理提供了强大的功能，但它们往往缺乏对速率限制和历史背景的细微理解，而这正是稳健集成所必需的。结果是，一种试错和重新实现的循环消耗了资源，却未能带来相应的价值。

“我在 Github 集成上花费了太多时间……在我把它弄到能用的程度之前，不得不做了大约 30 次 PR 监控器的实现。”

问题的核心在于管理 GitHub API 限制的复杂性。开发者经常指示他们的 AI 代理监控拉取请求（PR）中的特定更改或批准。然而，由于这些指令通常是通用的，每位开发者最终都在重新发明轮子。

Theo 是科技社区的知名人物，也是 T3.gg 的创始人，他最近对自己代理的历史记录进行了一次审计。通过要求他的 AI 助手审查与 Claude Code 和其他代理的交互，他发现了一个惊人的重复努力数量。

这个例子并非孤例。它反映了一种系统性模式，开发者将 API 集成视为每个新项目的novel问题，而不是利用现有的、经过优化的解决方案。缺乏用于 AI 代理交互的共享知识库加剧了这个问题，迫使每个团队都从零开始。

这些脚本失败的主要原因之一是 GitHub 速率限制政策的复杂性质。与简单的网页爬虫不同，稳健的 PR 监控器必须穿越 GraphQL (GQL) 和 REST API 端点组成的复杂景观，每个端点都有不同的速率限制bucket。

Julius 是 T3 Code 项目的贡献者，最近对 T3 Code 的 GitHub 集成进行了大规模优化。目标是将速率限制使用量减少超过 75%，同时提高监控的可靠性。这需要放弃在某些操作中使用的命令行界面（CLI），转而采用更高效的直接 API 调用。

该解决方案涉及一个动态回退系统。代码不是坚持使用一种 API 类型，而是根据哪个 API 在给定时刻消耗的速率限制更少，在 GQL 和 REST API 之间轮换。

这种复杂程度很少能通过“监控这个 PR"这样的简单提示来获得。因此，大多数由 AI 生成的脚本会很快触及速率限制，导致它们静默失败或需要昂贵的人工干预。

通往稳定实现的道路往往是漫长而艰辛的。对于 T3 团队来说，实现一个可靠的 PR 监控器大约需要 30 次单独的实现。每次迭代都旨在解决前一版本中发现的特定 bug 或性能瓶颈。

虽然最终产品是稳健的，但这段旅程凸显了 AI 代理理论上能做什么与它们在 production 环境中可靠地能做什么之间的差异。代理可以编写代码，但它们通常难以预测由现实世界 API 限制引起的边缘情况。

与这些有缺陷的脚本相关的财务和时间成本代表了开发者社区的重大机会损失。如果花在冗余 PR 监控器上的努力哪怕只有一小部分被 pooling 在一起，由此产生的协作工具可能会先进得多。

那些深入研究源代码的人和那些复制现有解决方案的人之间存在有趣的张力。Theo 对他团队的辛勤工作表达了复杂的情感。一方面，他欣赏他们的 GitHub 集成细节在源代码中可见，供任何愿意学习的人查看。

另一方面，他承认讽刺的是，许多人会简单地复制他们的工作而不理解潜在的挑战。这种“复制粘贴”文化虽然在短期内高效，但 perpetuates 了对 API 管理和速率限制缺乏深入理解。

优化这些集成所需的工作对终端用户来说大多是隐形的。没有哪个功能公告会强调花费数十小时调整回退逻辑或优化令牌使用。然而，这种隐藏的劳动对于现代开发工具的可靠性至关重要。

随着 AI 代理变得越来越普遍，期望是它们将处理例行任务。然而，当这些任务涉及像 GitHub API 这样复杂的外部依赖时，工程专业知识负担仍然落在人类开发者身上。AI 充当倍增器，但它并没有消除对基础知识的需求。

这些经验带来的教训很明确：AI 代理是强大的工具，但它们不能替代架构知识。开发者必须认识到，提示的好坏取决于所提供的上下文和限制。

为了减少令牌和时间的浪费，社区应考虑：

通过解决这些领域，行业可以远离重新发明的循环，转向在软件工程中更可持续、更高效地使用 AI。“babysitting”代码的成本太高，不容忽视，而认识到它是减少它的第一步。