让 GPT-4 修改文件，真的太难了！( 三 ) _GPT-4

最终我们的解决方案是分别生成 S 和 R(S) 。首先让 GPT-4 生成 S'，然后通过模糊匹配，在代码中用 S' 搜索 S 。然后要求 GPT-4 在 S 上执行相应的变换，这样就生成了 R(S) 。
具体而言，新算法执行以下操作：
1、生成一系列的小段代码：S'1, S'2, ..., S'n，供GPT-4编辑，然后使用模糊匹配算法，找到正确的行：S1, S2, ..., Sn 。
a.如果模糊匹配对于某个 S'i 产生的相似度分数过低（< 50%），则抛弃。未来也可以向 GPT-4 重新提示该问题。
2、然后将真正的代码片段发给 GPT-4 进行编辑。
因此，我们会要求 GPT-4 生成类似于以下内容：
此时生成省略号(...)是允许的，因为我们的匹配算法通常可以正确匹配代码片段。然后，我们会在代码库中找到真正的代码片段，并呈现给 GPT-4 进行编辑，如下所示：
然后，我们会回复以下内容，要求 GPT-4 进行编辑：
这样可以确保不会出现意外编辑，比如将变量从 create_task 重命名为 start_task 。
其他障碍
以下是我们遇到的其他不太重要的障碍：

格式错误：我们设置了一个退避系统，可以再次提示 GPT-4 以更高的准确度以正确的格式提供响应。
缩进：GPT-4 往往会取消缩进代码，这会使 Python/ target=_blank class=infotextkey>Python 代码无法解析。我们通过匹配原始缩进来修复这个问题，根据 ORIGINAL 代码块和原始文件的匹配部分之间的缩进差异来进行匹配。

尽管我们解决了大部分问题，但仍然存在一些文件太长的问题。我们自己的代码库中就有多个超过 1000 行的文件。

每次流式传输 400 行只是一个权宜之计，但并不能完全解决问题，因为它会分割代码的语义。此外，模型有时不会修改代码的任何部分，有时会修改代码的多个部分。在没有文件其余部分的上下文的情况下，修改文件的一部分非常困难。
对于 Python，我们建立了基于实体的编辑。最近，我们建立了一个用于更好地理解 Python 代码的库级别的调用图系统。我们在规划阶段使用它，让 LLM 决定要编辑文件的哪个类或函数。

结论
让 GPT-4 正确修改代码是一场艰苦的战斗，很容易出现各种错误。自发布以来，我们一直在与这些错误作斗争，但只能缓解常见的错误。
原文链接：https://docs.sweep.dev/blogs/gpt-4-modification

【让 GPT-4 修改文件，真的太难了！】