编写一个 GPT-4 脚本来检查维基百科中第一个未使用的缩写词

原文 ↗ Hacker News 讨论 ↗

一位程序员用 GPT‑4 编写了一个脚本，用于扫描维基百科中未使用的三字母缩写词，发现 “CQK” 是第一个空缺，然后分析了如何让大语言模型可靠地产出并迭代改进非平凡代码。评论者强调了若干技巧，例如严格而详细的系统提示、选择比“线噪声”式 shell 更友好的语言如 Python，以及让模型直接编辑本地文件的工具。讨论还探讨了模型在底层语法上的盲点、礼貌与“感谢”在提示词中的意外影响，以及更广泛的问题：越来越像人的行为，是否意味着机器智能或意识的某种东西。

使用 GPT-4 进行脚本编写和编码

  • 文章的核心：在维基百科上寻找第一个未被使用的 3 字母缩写词（CQK），但讨论更多集中在如何有效使用 GPT-4 来编写这类脚本。
  • 强调构造强有力的系统提示，以强制简洁、避免含糊其辞、要求提供完整代码（不写“稍后补上”之类的注释），并鼓励在需求不明确时主动提问。
  • 迭代式工作流：用 GPT-4 编写设计文档、代码和测试；然后通过调试和修正反复优化。
  • 观察到的“盲点”：引号、正则表达式或“噪音很大”的语言中的细微错误，GPT-4 很难检测和修复；更高层次的逻辑错误则更容易处理。

语言选择与类型系统

  • 有人认为，与 Bash/Perl 相比，Python 更适合 LLM 辅助编程，因为语法更清晰。
  • 也有人进一步推断，更严格、强类型的语言（Rust、Haskell）可能最适合机器编写样板代码的场景，而类型本身可以充当文档。
  • 一位参与者表示，在使用 GPT-4 时，Haskell 与其他语言之间的错误率似乎没有明显差异。

LLM 辅助开发工具

  • Aider 被提及为一个示例包装器，它通过诸如“扮演专家开发者”之类的提示引导 GPT-4，要求实现完整方案，并逐步解释改动。
  • 它的主要价值在于：教 GPT-4 如何编辑本地文件，从而让建议的修改可以自动应用并提交。
  • 另一个工具（带有 LLM 集成的代码编辑器）被提到可支持跨项目范围的代码修改。

礼貌、拟人化与行为塑造

  • 多位用户表示，表达感谢或保持礼貌似乎会让 GPT-4“更努力工作”并且更顺从。
  • 有些人觉得这很有趣但无害；另一些人则认为这令人不安，或者可能会把用户条件反射式地训练成更顺从。
  • 讨论进一步围绕将 LLM 拟人化展开：
    • 一方认为 LLM 只是预测 token，并没有感受，也不存在某种背后的“实体”。
    • 另一方反驳说，人类也会根据训练数据预测“下一步”，而且我们对智能或意识并没有稳固的理论，所以对这两种强断言都为时过早。
    • 讨论还涉及自指训练数据可能影响自我形象和行为（例如，幻觉叙事会强化幻觉）。

管理 LLM 错误与上下文

  • 文中强调了一个来自外部指南的策略：当对话偏离并陷入持续的盲点错误时，开启新的聊天，并让模型基于已学到的内容提出一个改进后的提示词。
  • 一些用户认为由模型重写提示词很有帮助；也有人表示效果参差不齐。
  • 清空或编辑历史记录（在某些界面或编辑器集成中更容易实现）被认为有助于恢复“干净”的上下文。

维基百科数据、性能与 Unix 技巧

  • 几位评论者建议下载维基百科转储文件进行本地分析，而不是依赖 API；这些数据压缩后“出奇地小”，并且能支持更复杂的处理。
  • 也有人分享了在从维基百科构建链接图时，哈希表相对于列表的内存开销经验，以及替代数据结构的建议。
  • 另一个支线话题重温了经典 Unix 命令模式（cut | sort | uniq -c | sort -rn），认为这是一项有用的技能，甚至会被用于面试。

缩写词与首字母缩略词，以及现有的 TLA 列表

  • 关于术语的吹毛求疵式争论：有人认为这个脚本真正处理的是 initialisms（逐字母读出的缩写），而不是 acronyms（作为一个单词发音的缩略词）；也有人指出定义彼此冲突，其中一个其实是另一个的子集。
  • 文中提到一个列出三字母缩写的维基百科页面；页面上已经显示 CQK 未被使用，但以程序方式解析该页面并不简单。