现在我们拥有极其擅长编写代码的编码代理，我经常遇到许多需要修复的小任务。这是我从与初创公司和应用程序合作中总结出的一个普遍观察：由于编写代码的精力大幅降低，提供产品反馈的门槛降低，快速修复的请求大幅增加。当然，当这样做时，你可以为每个任务启动一个 Claude Code 或 Codex 会话。然而，一旦你每天收到 50 到 100 个任务，你显然不想启动那么多独立的编码会话。同时，你也不一定想把所有任务都放在一个会话中，因为你可能会遇到上下文长度限制，模型可能难以有效协调所有任务。这就是我开始经常遇到的问题，我刚刚开始制定一种哲学和方法论，以有效的方式解决数百个较小的任务。在这篇文章中，我将带你了解我每天用来更有效地与 Claude Code 会话协作以解决大量编码任务的方法论。这篇文章的信息图突出了主要内容，并讨论了如何使用 Claude Code 或 Open AI Codex 等编码代理有效地解决大量较小的编码任务。为什么要优化解决较小任务的方法 正如我一贯所做的，我将带你了解为什么你应该关注优化解决较小任务的方法。你可能会认为，编码代理已经变得如此高效，以至于简单的快速修复是你可以直接扔给编码代理，它立即就能为你解决一切，而你不必为此费心。在某种程度上，这是真的。我的意思是，在许多情况下，你可以，例如，把一个 Linear 任务发给编码代理，它在许多情况下能够自行解决它，并以非常少的人工互动将其驱动到开发和生产环境。然而，问题出现于你开始大量接收这些较小任务时，这可能会因为以下原因发生：Bugs 较小的功能请求 设计更新以及许多其他情况。因此，你需要一个强大的方法论来完成所有这些任务，验证它们是否正确解决，并将它们标记为完成。一些较小的任务可以由编码代理完全自主完成。然而，我也发现许多看起来相似的任务有点模棱两可。如果你仅仅让编码代理在没有任何额外输入的情况下修复这样的任务，你可能会发现编码代理并没有实际解决问题，或者更糟糕的是，编码代理做了它本不该做的事情，并改变了你应用程序的一部分，而你并不想改变。由于我提到的这些挑战：解决大量较小任务 较小任务的模棱两可 你需要一个好的方法论来完成所有这些任务，这就是我将在以下章节中涵盖的内容。我的编码方法论 现在我将介绍我的编码方法论，以更有效地解决大量这些任务。我将带你了解我的高级流程以及我解决这些任务的哲学和心态。流程如下： 问题通常通过 Slack 发布 一个代理为其创建一个 Linear 问题 我有一个 Claude Code 会话来处理所有这些任务，通常针对特定的时间段，对我而言，是一天中的特定时间。我通过我的 Claude Code 会话对任务进行分类。如果是一个简单的快速修复，我使用 Claude Code 会话来修复它。如果是一个更大的问题，我让会话中的代理提前进行转交，并单独在一条线程上解决问题，因为它需要更多的人工互动。我让 Claude Code 创建所有我们想要处理的较小问题的 HTML 报告。如果它对我有任何问题，我需要澄清它们并给出完成...