生成式AI已经革命性地改变了编程方式。Jon Udell根据自己的经验，总结出了如何与大语言模型助手进行高效合作的方法。
译自 7 Guiding Principles for Working with LLMs，作者 Jon Udell。
在《以网站的方式思考的七种方法》中，我归纳总结了一套模式，这些模式来源于我作为优先面向网络的作家和软件开发人员的经验。其思想是(并且仍然是)，网络架构 —— 被Roy Fielding描述为一个互联网规模的分布式超媒体系统 —— 展示出你想要保持一致的粒度。你不需要对TCP/IP或HTTP的底层有充分的理解就可以与网络的方向保持一致，但是你确实需要对更高层次的构造形成直觉: 超链接、结构化和非结构化的数据、可重用的组件与服务以及发布-订阅的通信模式。
同样，你不需要对构成大型语言模型核心的神经网络的底层理解，才能与该架构的方向保持一致。虽然我无法解释LLM是如何工作的—可以说没有人能够解释—但我能够有效地使用它们，并开始整理一套指导原则。以下是我的清单:
- 大声思考
- 不要盲信，要求证实
- 使用助理团队
- 要求合唱式解释
- 外包模式识别
- 自动化转换
- 边做边学
在《当橡皮鸭说话时》一文中，我描述了使用LLM的最佳方式之一: 只要与它们对话@“橡皮鸭”一词来自软件工程:
橡皮鸭调试(或橡皮鸭法)是通过用口头或书面自然语言阐述问题来调试代码的一种方法。这个名称来源于《程序员实用主义》一书中的一个故事，其中一个程序员会随身携带一个橡皮鸭，并通过强迫自己一行一行地向鸭子解释代码来调试代码。 — Wikipedia
当编程时，我会与LLM讨论代码惯用法、库和配置策略。例如，今天我在帮助一个在容器中运行Steampipe有困难的人。这成为我学习Docker中绑定装载和卷装载的机会，这是一个我之前并不清楚的话题。经过一番研究后，我认为对于我可能想在容器运行时更改的配置文件使用绑定装载更合理，而对于数据库文件使用卷装载更合理(因为对于你不会编辑的文件来说，这更高效)。
在LLM时代之前，这些想法会留在我的内心，因为尽管讲述你的工作总是有价值的，但自言自语感觉很尴尬。为什么不只跟同事聊天呢？当然，你可以而且应该这样做，但是你需要注意何时以及多频繁地打断他们的工作流程。现在我可以将想法反弹给我的LLM助理团队。即使他们只是哑巴橡皮鸭，这也是有用的，但他们不是哑巴: 他们以帮助我验证、否定或澄清想法的方式响应。
这个原则不仅适用于技术主题。当我写散文时，我现在经常与LLM对话。例如，当我写这篇文章的引言时，我在“粒度”这个隐喻上挣扎。它感觉正确，但也许有点陈词滥调。我没有只是这样想，而是对ChatGPT和Claude都说了出来。他们都没有觉得有问题，也没有提出一个更有说服力的替代方案，所以我决定坚持这个隐喻。即使LLM没有说任何有用的话，它们也鼓励你大声思考。
这个规则在技术领域最容易应用。现在我使用LLM编写许多小的方便脚本，以简化或自动化任务。例如，我最近在制作屏幕录像时，需要一点JavaScript来平滑滚动我要演示的网页上的长项目标单。在“过去的时代”，这会牵扯到一个权衡:编写代码的收益是否值得付出的努力？现在我只需要请求代码，它通常可以直接使用或经过小的调整就可以工作，但结果很容易验证:它要么起作用，要么不起作用。
当然，有一种更严格的方法来验证软件:编写测试，以证明它做你期望的事情。我肯定不是唯一一个以前偷工减料测试的人。现在，我更有可能将测试用作验证LLM编写的代码的一种方式 —— 这是一个很好的激励!在某些情况下，你甚至可以将LLM置于自主的自我导向循环中，并观察它迭代以通过测试解决方案，这既令人难以置信又非常有趣。
在其他领域，形式化验证LLM输出就比较困难。当我写文章时，我经常要求我的AI助手为我的标题和副标题提出变化，但没有正确或错误的答案——这是对什么更好或更差的主观判断。
我从未依赖LLM提供事实信息，但如果你这样做，显然你应该核实你的事实。有些可能正确或错误，其他的则存在解释的空间。无论哪种情况，都没有任何替代人类判断的方法。而且，敦促LLM引用它们的来源从未有害。从历史上看，它们无法这样做，但随着它们获得通过实时网络搜索增强训练数据的能力，根据你可以检查的来源支撑其响应变得更加可行。
我经常使用ChatGPT和Claude，以及依赖这些引擎中的一种或另一种的编码助手。哪个更好？这取决于情况!在给定的情况下，我的任何助手都可能是解决技术问题或激发有价值见解的那一个。并且常常比较结果很有用。当我想评估两种替代解决技术问题方案的权衡时，我邀请我的整个助手团队对利弊进行评价。出现的共识并不具有约束力，而我最终决定推翻它，但是存在共识的事实——有几种互补的理由支撑——帮助我使思考更清晰，并为我的决定辩护。
在非技术方面，我最近给我的助手一个我喜欢的书籍的长列表，要求他们给出建议。以下是提示:
- 不要包括已经在列表中的作者的书，我可能已经读过它们，或者知道它们并决定不包括它们。
- 不要应用“更多这样的”规则，我正在寻找书籍、流派或主题，这些会让我感兴趣，但与此列表中的书籍明显无关。
- 用令人愉快和周到的书籍给我惊喜，这些书籍我会喜欢的。
我很欣赏各种反馈。这里也有共识: ChatGPT和Claude都建议Sy Montgomery的《章鱼的灵魂（The Soul of an Octopus）》。事实上，我已经读过这本书(尽管现在我倾向于重新读一遍)，而且不应该建议它，因为我的列表中包含另一本Sy Montgomery的书籍。参见规则2: 不要盲信，要求证实!
在合唱式解释中，Mike Caulfield描述了StackExchange和Quora等网站的问答过程为读者提供了一系列答案，读者可以从中综合出对主题的理解。如果你遵循规则2(使用助手团队)，你可以在任何主题上要求合唱式解释。在这个例子中，我想更多地了解web服务器返回的HTTP头。当我向Sourcegraph Cody、GitHub Copilot Chat和ChatGPT提出头信息，并请求进行概述和解释时，每个都以略有不同的方式回答。差异——就他们选择概述的项目，以及如何解释它们——具有指导意义，并比任何单一解释都能给我更好地掌握术语、概念和关系。
你也可以通过使用Wired的5个层次公式，要求单个LLM提供合唱式解释。
在5个层次中，专家科学家以5个不同的复杂度层次向不同对象解释一个高层主题——首先向儿童，然后向青少年，然后向主修同一学科的本科生，研究生，最后向同行。
这不仅适用于技术主题，也适用于更广泛的主题。例如:
我的理财计划师建议我将一些资金转移到年金中。请按以下对象解释利弊:
- 九年级学生
- 大学四年级生
- 中期职业专业人士
- 后期职业专业人士
- 理财计划师
长期以来，从各种来源组合解释一直是可能的，但从未如此轻松或具有如此精细的对解释级别的控制。在遵守规则2(不要盲信，要求证实)的前提下，你可以从要求一个或多个LLM提供合唱式解释中获得很多收益。
人类和LLM都是强大的模式识别器，以互补的方式。我们可以轻松检测到支撑叙事弧线、抽象类比和情感智力的模式。但我们在识别LLM可以轻松发现的数据模式方面遇到困难。与LLM合作是弥补这种人类弱点的有力方式。
在一种情况下，我和一个同事因无法将CSV文件加载到Steampipe表中而感到困惑。没有CSV验证器发现数据存在任何语法问题，但ChatGPT注意到一个异常: 有两列具有相同的名称。Excel不介意这一点，但Postgres介意。我们最终会弄明白的，但对我们不明显的重复列模式对LLM来说显而易见。
在另一种情况下，社区的一个成员在容器中运行Steampipe时遇到麻烦。问题的原因是在docker run命令中错误使用了--mount参数。有两种风味: 绑定装载(使用主机路径)和卷装载(使用逻辑名称)。由于不熟悉这些选项，混淆主机路径和逻辑名对我来说一开始并不明显。但ChatGPT马上就看出来了。
这里是一个非技术示例。我给每个助手提供了我用来提示书籍建议的书单，要求他们按类别对书籍进行分组。然后，我要求他们在每个类别中推荐书籍。这个任务并不需要非人的能力去注意数据中的低级细节，但确实受益于非人的能力，可以更快速和全面地检测到我本可以通过付出更多努力才能推断出的模式。
我们的信息饮食中包含许多结构化的、半结构化的和非结构化的数据。判断这些数据的意义仍然是我们的工作。做到这一点需要识别数据中的各种模式，对此LLM是一个强大的盟友。
我们所说的知识工作中有大量令人苦恼的内容只涉及从一种格式到另一种格式的重复转换:HTML文档需要变成Markdown(或反之亦然)，JSON格式需要转换为CSV(或反之亦然)。当人们花费数小时在编辑器中推移字符以实现这些转换时，这是死于一千剐的过程。LLM的模式识别超能力延伸到基于模式的转换，并可以让我们更有成效地使用这些小时来从事对这些转换只是入门要求的高阶智力任务。
在一种情况下，我需要将谷歌文档中提供的一个复杂表格转换为在网页上呈现表格所需的相应JSON结构。在“过去的时代”，这将需要大量乏味的手动编辑。ChatGPT无法在一次通过中完成整个转换，但当我给它表格的各个部分时(每个部分展示一个不同的模式)它是成功的。与往常一样，我遵循规则2(不要盲信，要求证实)来检查结果，然后进行细微更正。但与手动转换所需的工作量相比，这只是微不足道的努力。
在另一种情况下，我使用LLM将测试脚本的原始日志转换为去重和分类日志中的事件的摘要。完全验证该结果将是冗长乏味的，但对我的目的来说这并非真正必要——我只需要对每个类别中的事件分类和数量有一个粗略的了解。
这些是LLM的平凡用途，这正是重点。我们在这些平凡的任务上花费了太多时间和精力。让我们外包这些苦差事，并更好地利用这时间和精力。
一个朋友最近说: “我认为ChatGPT是我遇到的最好的老师。我有一个涉及常微分方程的个人项目。那些在大学里可怕极了。我从未上过那门课。现在我可以提出问题，迭代答案，探索联系。没有判断，没有不及格，没有成绩。”
LLM的反馈是实时学习的绝佳方式。在项目中，你可以在面向具体任务的可教授时刻获得知识，所以学习是立即的、具体的，而不是展望性的。这里展示了LLM如何让我仅学习关于一个JavaScript框架的足够知识，以推进一个项目。
在应用显性学习时，你也可能会隐性地获得相关知识。这里引用了LLM教我一些自己原本不知道需要了解的工具和技术的例子，这种隐性学习很理想，通常出现在我们从无意中提供隐性和显性指导的人那里学习时。但我们需要合理规划对他人时间和注意力的占用。有了始终提供的LLM副驾驶员监控我们的知识工作并做出反应，我们可以在工作中高效学习，并牢记实时获得的与任务相关的知识。
我们才进入LLM时代一年，正在发现AI助手的能力和如何最好地使用它们。随着功能和能力的不断涌现，我们需要制定守则指导我们度过这个具有历史意义的变革。本文的七条守则不会是这个主题的最后言，但至今对我很有用，也许可以帮助你在我们常规与AI助手合作的世界中导航。