用三个简单提示提升你的编程助手并理解其推理过程

使用本文中的自定义提示和链接的代码库，让AI代理（1）规划、（2）实施和（3）审查任何代码，以获得更好的结果。

这些是直接、经过验证的客户端提示工程技术。无论使用哪种LLM，这种方法都能持续改善结果。你需要手动应用它们，每个步骤在单独的对话中进行。一些LLM代理已经使用了这些技术，但大多数没有。如果你使用的代理已经采用了这些技术，你可能已经意识到了。

当前LLM编码代理的现状

如果你最近使用过任何编码代理，无论是在像Cursor这样的IDE中还是像CodeX这样的基于云的代理，你可能已经注意到代理输出的显著可变性。有时它们能完美地提供有效的解决方案，但在处理复杂任务时，它们经常陷入困境，不必要地过度复杂化解决方案。

最近几个月，我们目睹了基于云的LLM代理的激增，它们被营销为智能开发助手。然而，在实践中，大多数只是围绕基础模型（如Claude或GPT-4）的包装器。它们主要提供与GitHub、Slack或Notion等工具的集成，加上一个时尚的UI，但对核心功能添加的实际智能很少。这些“云中的Claude”代理完全依赖基础模型进行推理和执行，使用编排层主要是为了便利而不是增强能力。本质上，它们是你最喜欢的IDE中已经存在的Claude的云版本。

为了提供更好的解决方案，这些代理应该采用经过验证的提示工程策略，比如由SWE-agent和Refact.ai等开源项目实施的策略。这些先进系统使用的客户端提示技术确保了两个关键结果：正确识别问题并有效实施解决方案。即使使用现成的代理采用这些技术的基本手动版本，也能提供对LLM高级工作原理的宝贵洞察，显著提高输出质量。

使用这些超级简单的步骤立即产生更好的输出，这真的很迷人。我预计本文中详细的工作流程很快将成为事实上的标准，被所有主要参与者广泛采用，并且成为所有使用LLM代理工作的开发者的第二天性。

如果你已经使用过LLM代理，你可能已经注意到这些步骤单独使用效果也很好，但由于每个步骤都给LLM一个改进代码的机会，结合它们能带来最好的可能结果。我相当确定，一旦LLM变得足够便宜，更复杂的算法将成为主要提供商的标准产品。

当前通常的流程：单个LLM对话处理所有事情。

背景：LLM作为伪人类

大型语言模型在大量人类文本知识库上训练。这使得它们在解决问题时“行为”很像人类：误解任务、迷失在细节中、走捷径等。

幸运的是，我们作为人类已经解决了这些问题。这被称为软件开发团队。多个人共同解决一个问题。

例如，即使审阅者与编码者具有大致相同的专业知识，代码审查也能很好地工作，这并不奇怪——我们只是人类，我们会犯错误，另一双眼睛通常能发现这些错误。既然我们已经创造了反映我们思维方式的机器，是时候让它们以类似的方式解决问题了。其中一些可以直接在代理级别处理，但大多数时候，一双新的LLM眼睛更有效。（这可能在未来改变，我预计已经有很多研究专注于解决这个问题。我谈论的是开发者今天可以做的事情，以更好地利用编码代理。）

一些现有论文

以下是一些最近发表的论文，都介绍了强大的客户端提示技术方法：

Self-Refine: Iterative Refinement with Self-Feedback (2023)
提出了Self-Refine，一种LLM首先生成答案，然后批评自己的输出并迭代改进的方法。同一个模型在多个回合中既产生反馈又产生修订答案。这种方法不需要额外的训练或数据，只需在推理时使用模型本身。在七个任务（从对话到数学）中，Self-Refine平均将解决方案质量提高了约20%，甚至提升了GPT-4的性能。
Self-Consistency Improves Chain-of-Thought Reasoning (2023)
提出了一种称为自一致性的解码策略。模型不是依赖单个思维链，而是采样多个推理路径并选择最一致的答案。这种思维集成方法显著提高了数学和常识任务的推理准确性（例如，在GSM8K上+17.9%）。
Tree of Thoughts: Deliberate Problem Solving with LLMs (2023)
引入了思维树（ToT），一个将思维链提示推广到树搜索的框架。LLM探索多个推理分支，自我评估它们，并可以根据需要回溯或前瞻。这种深思熟虑的搜索策略显著提高了需要规划的任务的性能（例如，解决了74%的“24点游戏”谜题，而标准CoT只有4%）。

还有更多与LLM和问题解决相关的研究；这些只是冰山一角。但正如你所见，它们都有一个反复出现的主题：使用多个LLM，让它们像团队一样工作，并寻求共识。这可以在不同级别和以不同方式实现，但结果似乎总是相同的：更多的LLM（和更多的计算）带来更高质量的输出。

一些使用上述技术的现有工具

SWE-Agent
这是这里要提到的唯一一个用于解决编程任务的开源框架，但如果你查看SWE-bench上的顶级竞争者，你会发现更多。这些框架使用了许多先前提到的客户端提示技术——甚至添加了更多——以在编程相关任务中获得最佳可能结果。毫不奇怪，LLM本身在这些基准测试中并不占据顶级位置。几乎所有顶级性能系统都严重依赖框架以及代理来以最佳方式完成任务。
Refact.ai
Refact.ai最近在SWE-bench上占据了榜首，并且还提供了VSCode和其他IDE的插件。它很棒！这正是那种显示LLM在由结构化框架引导时能有多有效的工具。不仅仅是要求模型编码；而是编排整个工作流程：规划、编辑、审查和迭代。这才是真正性能提升的来源。

嗯…所以呢？

尽管它们被证明有效，但令人惊讶的是，很少有开发者或公司积极将这些客户端提示技术集成到他们的工作流程中。一个可能的原因是，大型科技公司 heavily focus on pushing easy-to-use tools broadly into every developer’s hands，通常优先考虑可访问性而不是最优性能。此外，这些高级提示方法通常需要额外的API调用，如果按使用计费，会显著增加执行时间和成本。

我们已经确定，使用客户端提示技术 definitely improves the quality of LLMs in programming tasks。要使用这些技术，必须设置单独的开源工具，这需要时间和精力，更不用说通过API使用LLM进行这些更昂贵计算的额外成本。

我做了所有这些，然后意识到我 simply enjoy IDE-based workflows more。Cursor的固定月费——以及我是个吝啬鬼——也激励我仅使用我的IDE获得更好的编程结果。所以我基于先前提到的、广泛采用的技术，想出了一个更简单的工作流程。这种方法可以轻松适应多个代码库、IDE或LLM代理，并且 overall just much simpler to use。

改进的流程：每个步骤都是单独的LLM对话。

三个步骤

1. 规划

你是一个拥有数十年经验的世界级软件工程师。你被赋予一个与当前项目相关的任务。它要么是一个需要修复的错误，要么是一个需要实现的新功能。你的工作是提出一个逐步计划，当实施时，将完全解决任务。

然后为实施任务解决方案提出一个逐步计划。该计划将发送给另一个代理，因此它应包含成功实施的所有必要信息。通常，计划应以解决方案的简短描述以及它如何与代码库相关开始，然后应遵循逐步计划，描述必须进行哪些更改以实施解决方案。

在响应末尾的代码块中以格式化markdown文档的形式输出计划。不要实施任何更改。另一个代理将从那里接管。

这是需要解决的任务：{{在此添加你的任务描述。}}

这一步反映了人类软件开发工作流程。即使我们没有意识地意识到，我们通常在开始编码之前有一个解决方案的想法或制定一个计划。这一步使其明确；它允许人类开发者早期干预，如果代理的计划似乎完全错误。如果你经常遇到计划完全错误的问题，我建议给AI代理更多关于代码库的上下文。参见文章末尾的部分。

无论如何，代理制定的计划在大多数情况下应该足够好，通过让代理在开始编码之前思考这一点，我们确保它不会早期迷失在细节中——这是糟糕解决方案的常见来源。

2. 编码

你是一个拥有数十年经验的世界级软件工程师。你被赋予一个与当前项目相关的任务，它要么是一个需要修复的错误，要么是一个需要实现的新功能。你还被给予了由该领域另一位专家创建的逐步计划，该计划详细描述了任务的解决方案。你的工作是使用逐步计划为手头任务提供全面解决方案。

然后通过遵循那里描述的步骤来实施逐步计划。确保实施计划中描述的所有必要更改以解决原始问题。在认为工作完成之前，确保任务实际上完全、彻底地解决，没有任何错误或问题。不要将你的更改提交到git。另一个代理将从这里接管。

这是需要解决的任务：{{在此添加你的任务描述。}} 这是专家提供的逐步计划：{{在此添加上一步的输出。}}

这是一个直接的步骤，也是代理 mostly expected 的步骤。确保此提示在与上一步不同的对话中使用，因为 earlier step 的思考内容会影响计划的实施。如果思考步骤中出现问题，可能导致输出问题。对话中更多的令牌通常也使LLM表现更差。

3. 审查

你是一个拥有数十年经验的世界级软件工程师。你被赋予一个与当前项目相关的任务，它要么是一个需要修复的错误，要么是一个需要实现的新功能。代码库还包含由其他专家创建的未提交代码更改，这些更改应该解决手头任务。你的工作是审查未提交的代码，修复所有问题，并确保它准备好合并。

然后对代码库中的未提交更改进行代码审查。要无情并提出所有担忧。然后修复你提出的所有担忧以完成任务的实施。在认为工作完成之前，确保任务实际上完全、彻底地解决，没有任何错误或问题。

当你完成更改时，创建一个简短列表，总结你发现的问题以及你对代码添加的修复。

这是需要解决的任务：{{在此添加你的任务描述。}}

有趣的是，这一步 often turns out to be surprisingly beneficial。大多数时候，它会发现问题，有时只是与边缘情况相关的次要问题，但偶尔是需要解决的真实错误。确保这也是一个新的LLM对话，一双新的眼睛有助于确保实施和思考步骤不影响代码审查。

这种方法起初可能看起来有点 pedestrian

在某种程度上，它是。你基本上只是在不同聊天窗口之间复制粘贴输出，并在问题出现时修复它们。

但它有效。 surprisingly well。如果你使用具有固定月费的IDE，它也超级经济。

现在是做这个的完美时机

AI代理 vary wildly；一些已经自动化了部分这个过程，甚至获得更好的结果，但那些通常运行在基于API的定价上，这很快变得昂贵。今天大多数人使用的工具提供固定价格的无限交互。因此，对于这些用户，将这些简单步骤添加到工作流程中可以 seriously boost the Agent’s performance without costing anything extra。

最终，我确信这些技术将被直接内置到大型平台中。但现在，重点似乎在于使这些工具广泛可访问，而不一定是高性能的。这就是为什么这个三步工作流程是一个坚实的升级——它简单、有效，并让你尝到AI编码工具未来的方向。

+1 提示

通过用本文档锚定代理的理解，你为一个 far more reliable planning, implementation, and review stages 创建了基础。它还 dramatically reduces the risk of hallucination and improves the agent’s ability to follow implicit team norms that aren’t otherwise visible in the code alone。将其视为给你的初级开发人员他们的入职包——只是这个说JSON。

希望这是一个有趣的阅读，你设法改进了你的LLM代理，或者至少在这个过程中学到了新东西。如果我在这里或GitHub代码库中遗漏了什么，请告诉我，并随意为这篇文章鼓掌或给代码库加星，以帮助算法传播消息。

编码快乐！