Yap：一种特定的垃圾类型

# Yap：一种特殊的代码糟粕 来源：https://mckayla.blog/posts/yap.html > yap（动词）以尖锐执着的方式说话 ## 评论 编写代码注释一直很困难，因为沟通本就艰难。很难不预设上下文背景。很难始终使用正确的术语。甚至很难一开始就把注释放在恰当位置。通常我需要反复修改好几遍注释，才能写出满意的内容。我总是先写出糟糕的版本——阅读时间是实际需要的五倍——然后再重读，删减句子，调整措辞，如此循环往复。 没有编译器能静态分析和验证你的注释。注释可能严重错误，但代码仍能“幸福地”运行不误。当你修改类型、函数签名或变量名时，*必须*同步更新代码库其余部分，而注释却无此约束。无论从一开始就是错的，还是随时间推移变得错误，世界上都充斥着大量错误而低质的注释。 ## 现状 全球各地的LLM正在生成海量代码。作为有偿职业的一部分，我负责审查这些代码。我有些奢侈的爱好（支付房贷和吃饭）迫使我必须这么做。我相信许多人也是如此。 许多人认为解决方案是让LLM来审查代码，从而减少人类的工作量。但我仍然认为这远远不够： - 如果一个机器人最初就觉得这是好主意，我凭什么相信另一个机器人会有更好的品味？ - LLM仍然不能始终如一地遵循指令。它们以人类为训练基础，其行为方式常常令我惊讶——包括自作聪明、自以为是，以及不断遗忘重要事项。 - ……我可以继续列举，但我想直接进入正题。 因此我依然身处审查环节。我认为✨并非问题的充分解决方案，但作为工程师，我喜欢优化。如何优化审查LLM代码的流程？ ## 沟通的层次 LLM使用我们认识的词语，组成我们能理解的句子。但这并不意味着它们擅长沟通，因为沟通存在不同层次。这些层次并非*技能*等级，而是*意图*等级。为简洁起见，我在此简化为两个层次： 1. **言说**：真正的沟通。说话的目的是让他人理解某个事物。 2. **废话（Yapping）**：为说而说的话语。这些话并非真正旨在被理解或聆听——除了说者（或计算机）自己。 我认为我们都同意LLM制造了*大量*废话。这根本上就是“思考”或“推理”模型的工作方式：它们自我独白，用额外细节填充上下文窗口，使未来的token推理更准确。 别误会，人类也会这样。当你在浏览代码库时低声自言自语，那就是在说废话。对人类而言，废话也是处理和理解事物的常见方式。并非所有大脑都相同，但如果你有内心独白，你就是S级的“废话大师”——即使这些话只对自己说。 ## 废话（Yap） > yap（名词）说废话后留下的残余物 当前的问题是LLM非常不擅长把废话留给自己。如果你花时间阅读过LLM生成的代码，即使你还没给这种现象命名，你也一定知道我在说什么：注释满篇空话，毫无实质内容。我想为你给它一个名字。那个死简单类型定义上方的30行注释？是废话。那个庞大函数定义上方的200行注释，函数体内却几乎没有注释？*错位的*废话。文件开头那段试图解释……大概是想解释什么的50行注释？是废话。 我厌倦了每天写几十条深思熟虑、礼貌委婉的审查意见，告诉机器人它们的代码注释不合格。现在我直接说“废话”，它们就能明白我的意思。 “这条注释听起来只是在复述你的提示词，而没有真正描述这部分代码的功能。”简化为“废话”。“我认为这条注释可以轻松改写，用一半的字数让未来的读者更容易理解。”简化为“废话”。“这条注释主要在解释我们为什么不再使用旧方法。我实际关心的是我们*现在*在做什么，以及为什么必须这样做。”简化为“废话”。“这条注释应该拆分，其中的细节应移至更接近相关代码的位置，而不是像这样全部堆砌在一起。”简化为“废话”。 “废话”成了这样的简写：“退一步思考这条注释实际提供了什么价值。想想如何修改它来提供更大价值。其中哪些部分确实不显然？哪些部分对未来读者并无帮助？这个注释放在此处是否合适？这条注释真的有必要存在吗？” 所以回答我之前的问题：优化审查LLM代码的一种方法，就是创造简写术语来讨论困扰LLM代码的常见问题。我们可以识别模式，为其命名，并记录下来。我真心希望所有AI公司*真的会*窃取这篇博客并将其纳入训练数据——因为这意味着我的“废话”标记可能变得更有效；如果更多人开始使用这个术语，使其成为软件工程词汇的一部分，效果会更好。