… - LLMs 训练时使用了大量的源代码，这可能比自然语言的范围更小。根据我的经验，LLMs 在例如在两种编程语言之间翻译代码方面非常出色。但将我的提示翻译成代码却效果不佳，因为我的提示是自然语言，因此存在歧义。- 我想知道这是否是“自然语言与编程语言”的问题，还是“差代码与好代码”的问题。我完全可以想象，对差代码进行文档说明有助于 LLM（以及人类）理解意图，而对好代码进行文档说明反而会增加歧义。我学到的是，我们编写代码是为了让人阅读。好代码是能清晰表达意图的代码。如果需要到处添加注释，对我来说意味着代码可能没有达到应有的水平。当然，有人可能会说，代码质量每年都在下降，因此需要越来越多的文档来解释它，因为越来越难理解作者到底想做什么。
源讨论我们应该在代理时代重新审视文献编程原帖 251 条评论 · 导入时统计把你的经验，加入这段讨论。
我不会让我的LLMs生成可读的编程。我会让它讨论权衡。 我有大量被详细注释和解释过的例子，包括任何模式或文档的链接。当我让LLM使用这个作为模板时，结果很好，即其中并非所有内容都需要被使用，这大大减少了幻觉。
完整原文> 如果需要在代码中到处添加注释，对我来说意味着代码可能没有达到应有的水平:-) 如果好的代码本身足够，我们就会直接阅读源代码而不是文档。我相信好的软件的一部分是好的文档。可读源代码的叙述旨在用于文档，而不是对实现的逐行注释。
完整原文> 自然语言是模糊的。这就是为什么我们创造了编程语言。因此，代码周围的文档通常也是模糊的。更糟糕的是，它没有被执行，因此可能会过时（有时以微妙的方式）。 我讨厌这种观点。 我曾遇到过一些代码库，其中特定的规则禁止添加注释，就是出于这种态度。 是的，注释可能会有错误，没有保障确保它们与所描述的代码保持同步，但不添加注释要糟糕得多——我总是可以看到代码在做什么，这从来不是问题，问题在于为什么以这种方式做。 我会添加注释如“这段代码运行时间复杂度是O(n)，因为最多只有少量项目会被搜索——当有足够的项目需要O(log2 n)搜索时，请更新它” 这告诉未来的开发者，作者（我）知道这并不是最有效的方法…
完整原文"但将我的提示翻译成代码并不太有效，因为我的提示是自然语言，因此是模糊的。" 不仅如此，而且输入一大段文字到一个你无法控制其如何生成输出的东西中，而且即使输入相同，也无法重现输出，这非常烦人且令人极度不满。 我同意自然语言非常模糊，而且每天都在变得更加模糊，“'vibe'到底是什么意思？” 人们在60年前说话的方式非常明确，几乎没有解释的余地。今天则不能这么说。
完整原文编程语言也是自然且有歧义的，READ是什么意思？你必须去查才能看到类型。其力量来自于它是可审计的，但你不需要每次想写代码时都去审计它。你认为你写出了好代码吗？试着在编译器处理完之后证明这一点。 自然语言在思想上更丰富，从纯粹的自然描述到代码可能比从代码到代码更难实现，但你从仅仅翻译代码中获得的好处不多。一个是受你想象力的限制，另一个已经存在，你只需将其作为例程调用。 你之所以对好代码有感觉，是因为它是一种有惯例和共同意义的自然语言。如果编程的目标是让我们作为人类更好地交流，那么我们应该对抗歧义，而不是逃避它。100年后，没有人会...…
完整原文> 因为我的提示是用自然语言写的，因此有歧义。 法律术语专门发展出来是因为自然语言太有歧义了。对于提示，类似程度的明确性效果很好。 用代码来向计算机说明指令的一个问题是，你非常狭窄地描述了如何做某事。但有时候我并不总是知道最好的“如何”，我只知道我知道的。使用自然语言提示时，AI可以利用其训练知识，找到更好的方法。它仍然需要很多引导（通常如此），但很多时候你可以得到更好的结果。
完整原文文档和代码作为相互纠错的编码一起工作。没有冗余信息，你就无法获得错误检测和纠正的好处。
完整原文也许如果我们有一种真正简洁且无歧义的英语形式？每当有歧义时，我们插入括号和运算符，以真正明确我们的意思。我们可以用括号括起不同的句子，以确保逻辑条件的范围等等。哦，对了
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。