李彦宏写AI提示词也能年薪100万，Claude AI圆桌论坛：资深提示工程团队手把手教你写提示词（附教学视频）
（关注公众号并设为🌟标，获取最新人工智能资讯和产品）
全文约20,000 字，阅读约需 38分钟
人工智能（AI）正在变革就业市场，特别是在提示词领域。近期的薪酬调查揭示了写AI提示词与传统软件技术工程师之间日益扩大的收入差距，凸显了AI人才的稀缺性和高需求。
如上图：从入门级到高级职位，AI提示工程师（Prompt Engineering）的薪酬普遍优于非AI同行。美国的数据显示，初级AI提示工程师平均年薪达23.9万美元（约合173万元人民币），较非AI提示工程师高出8.57%。这一差距随着职级提升愈发明显，资深AI提示工程师的平均年薪高达68.05万美元，远超非AI资深工程师的49.5万美元。
为深入探讨AI领域的发展趋势，Anthropic Claude AI近期组织了一场高级提示工程师圆桌讨论。参与者包括Amanda Askell（模型对齐微调专家）、Alex Albert（开发者关系经理）、David Hershey（AI应用工程师）和Zack Witten（提示工程师）等顶尖专家，他们共同探讨了提示工程的演变历程、实用技巧以及未来演变。
在企业层面，AI巨头如OpenAI更是以每年90万美元起薪领跑业界。中国市场同样呈现出AI人才薪酬走高的趋势，大型企业招聘Prompt工程师的月薪普遍在1.5万至5万元人民币之间，部分岗位甚至更高。
而且在最近结束的2024世界人工智能大会上，百度CEO李彦宏更是指出，随着AI技术的发展，新兴岗位如AI提示词工程师的需求激增。这类工作不仅要求逻辑思维能力，还需要熟练掌握模型调教技巧。李彦宏表示："这是一个极具潜力的新兴职业，入门门槛相对较低，但表现出色者年薪可达百万。"
AI提示工程师必备15条技巧：
编写提示时要清晰精确地沟通。清楚地陈述任务和描述概念的能力至关重要。
愿意快速迭代,连续向模型发送多个提示。优秀的提示工程师对不断来回调整感到自在。
设计提示时考虑边缘情况和不寻常的场景。思考你的提示在非典型情况下可能如何失效。
用不完美的、真实的用户输入来测试你的提示。不要假设用户会提供格式完美或语法正确的查询。
仔细阅读和分析模型输出。密切关注模型是否按预期执行指令。
剔除假设并清晰地传达完成任务所需的全部信息。系统地分解任务以确保包含所有必要细节。
编写提示时考虑模型的"心智理论"。考虑模型可能如何以不同于预期的方式解释你的指令。
处理提示时使用版本控制并跟踪实验。在管理和迭代方面将提示视为代码。
要求模型识别你指令中不清楚的部分或歧义。这可以帮助改进和完善你的提示。
做到精确而不过度复杂。力求清晰的任务描述,不建立不必要的抽象。
考虑典型案例和边缘案例之间的平衡。处理边缘案例很重要,但不要忽视主要用例。
思考提示如何集成到更大的系统中。考虑数据源、延迟和整体系统设计等因素。
不要仅仅依赖写作技巧;提示工程需要清晰沟通和系统思考的结合。优秀的作家不一定是优秀的提示工程师,反之亦然。
与客户合作时,帮助他们理解用户输入的现实情况。引导他们考虑真实世界的使用模式,而不是理想化的场景。
大量练习查看数据和模型输出。熟悉模型如何响应不同类型的提示和输入。
文稿整理
Alex Albert : 基本上，今天的圆桌论坛将主要集中在提示词工程（Prompt Engineering）上。我们这里有各种不同的观点，涉及从研究层面、消费者层面到企业层面的提示问题。我想要收集大家的意见，因为这些领域里有许多值得探讨的内容。我们会开放讨论，探索提示工程的实质以及它的全部意义。好了，就从这里开始吧。我们可以轮流做个自我介绍。我先来。我叫 Alex Albert，我在 Anthropic 是开发者关系经理。在此之前，我是 Anthropic 的提示工程师，我曾在我们的提示工程团队工作，负责从解决方案架构到研究相关的各种角色。那么，我把话筒交给 David 吧。
David Hershey: 好啊。我叫 David Hershey，我主要与 Anthropic 的客户合作，处理技术问题。我帮助客户进行微调（finetuning），也处理一些与提示相关的泛化问题，特别是如何构建基于语言模型的系统。不过，我的大部分时间都用来与客户合作。
Amanda Askell: 很棒。我是 Amanda Askell，我领导 Anthropic 的微调团队之一，我的工作目标是让 Claude AI诚实且友善。
Zack Witten: 我叫 Zack Witten，我是 Anthropic 的提示工程师。Alex 和我经常争论谁是第一个提示工程师，他说是他，我说是我。
Alex: 争议存在。
Zack Witten: 是的。我之前主要与个别客户合作，类似于现在 David 的工作。随着我们团队中解决方案架构师的增多，我开始专注于提升社会整体的提示水平，比如提示生成器和各种教育材料的开发。
定义提示工程
Alex: 很好，很棒。感谢大家今天的到来。我先问一个比较广泛的问题，定义一下什么是提示工程，这样我们接下来的讨论就有了框架。什么是提示工程？为什么称之为工程？什么是提示？如果有人想要开始讨论，请随时。
Zack Witten: 我感觉我们这里就有一位提示工程师，这是他的工作。
Alex: 我们每个人都可以说是某种形式的提示工程师。
Zack Witten: 但只有一个人是正式的提示工程师。
Alex: Zack，也许从你开始，因为这是你的头衔。
Zack Witten: 是的。我认为提示工程的本质是让模型完成任务，尽可能从模型中挖掘出更多潜力。提示工程的核心是如何与模型合作，完成一些你原本可能无法完成的事情。因此，大部分工作实际上是清晰的沟通。我觉得与模型对话的方式很像与人对话，理解模型的“心理”是其中非常关键的一部分，而 Amanda 是这方面的专家。
Alex: 那么，为什么要称之为“工程”呢？
Amanda Askell: 我觉得“工程”这个词来自于试错过程。与人对话不同，跟模型对话时你可以按下“重置”按钮，彻底回到起点。这给了你一次从头开始的机会，独立尝试不同的方法，避免了前后试验的干扰。这种能够独立设计和实验的能力就是提示工程中的“工程”部分。
Alex: 所以，你的意思是，在输入提示时，你可以与 Claude 或 API 进行反复的对话，每次都能回到初始状态，这个过程就是提示工程中的工程部分，对吗？
Zack Witten: 是的。但还有另外一个方面，就是将提示集成到你的整个系统中。David 在帮助客户集成提示时做了大量工作。很多时候，提示并不是那么简单的，只是写一个提示并交给模型运行，实际上远比这复杂得多。
David Hershey: 是的，我把提示看作是编程模型的一种方式，虽然听起来可能有点复杂。我同意 Zack 的看法，清晰的沟通是最重要的。但如果你把提示稍微当作是对模型的编程，你就需要考虑数据来源、你能访问到的数据、如果使用检索增强生成（RAG）等方法，哪些数据是可以利用的。你还要考虑延迟、数据量等权衡问题。如何围绕模型构建系统需要一定的系统思维，我觉得这也是为什么提示工程需要独立出来，成为一个独立的领域，而不是简单地归类为软件工程师或产品经理的工作。
Alex: 那么，提示在这种意义上是自然语言代码吗？它是一种更高层次的抽象，还是一个独立的事物？
Zack Witten: 我觉得把提示弄得太抽象是一种过度复杂化的方式。实际上，很多时候你只需要写一个非常清晰的任务描述，而不是构建复杂的抽象。但是话虽如此，你确实经常需要将一系列指令编译成具体的结果。因此，精确性，以及编程中考虑的版本控制和管理实验的历史记录等问题，这些都同样重要。
Amanda Askell: 是的。
Zack Witten: 现在我们处于一个奇怪的范式中，书面文本，比如你写的一篇漂亮的文章，和代码被视为同一种东西。这种现象确实存在，现在我们编写的文章就像在写代码，我觉得这其实是正确的。
一名优秀的提示工程师
Alex: 嗯，很有趣。既然我们已经大致定义了什么是提示工程，那么是什么造就了一名优秀的提示工程师？也许我该把这个问题交给 Amanda，你们在研究领域招聘提示工程师，你在寻找的是什么样的人才？
Amanda Askell: 好问题。我认为 Zack 提到的清晰沟通能力非常重要，能够清楚地陈述事物、理解任务，并很好地描述概念。这是写作部分的内容。不过，我其实认为，写得好与成为一名优秀的提示工程师之间的相关性没有人们想象的那么大。我曾经和别人讨论过这个问题，有人认为提示工程不应该有“工程”这个词，为什么不直接叫“写手”？我曾经也比较认同这个观点，但现在我觉得，实际上你所做的事情远比这复杂。很多人以为你只需要写一次提示就完事了。但我常常会发现，要写一个还算不错的提示，我可能需要花 15 分钟反复给模型发上百次提示，这就是一个来回迭代的过程。所以，我认为重要的是具备迭代的能力，能够思考哪些地方被误解了，然后去修复这个问题。
Alex: 那么，清晰沟通和迭代能力是成为优秀提示工程师的重要素质吗？
Amanda Askell: 对，我还认为你需要预见提示可能出错的地方。如果你要把提示应用到 400 个不同的案例中，通常人们会只考虑最常见的情况，看到提示在这些情况下能够得到正确的结果，然后就不再继续思考了。但实际上，你需要去找到那些不常见的情况，思考提示在这些情况下可能会出现的模糊不清。比如，你有一个提示说，“我将发送给你一些数据，我希望你提取出所有名字以 G 开头的行。”那么你就需要考虑，“如果我发送的这个数据集中根本没有以 G 开头的名字怎么办？如果我发送的不是数据集，而是一个空字符串呢？”这些都是你必须去测试的情况，因为只有这样你才能给模型更多的指令，让它知道在这些特殊情况下该怎么做。
David Hershey: 我经常和客户合作，他们在构建某些东西，客户那边会有一部分提示需要由他们的用户输入内容。但他们总是预设用户会输入一些完美的句子。而实际上，用户根本不用大写字母，打字时每两个字母里就有一个错别字。
Amanda Askell: 他们以为自己在用 Google。
David Hershey: 是啊，而且完全没有标点符号，用户输入的都是一些随机的单词，甚至没有问题句。你会看到那些用于评估的提示非常漂亮，结构完整，都是用户理想的输入。但能够预测用户的真实行为，理解他们真正会输入什么，这需要更深层次的思考。
Alex: 你刚才说的一点让我很有共鸣，那就是阅读模型的输出。在机器学习中，人们总是强调要看数据，这是一个老生常谈的话题。而在提示工程中，等同的就是要看模型的输出，仔细阅读大量的输出内容。
David Hershey: 对，我们刚才来的路上讨论过，人们有时候会在提示中写上“逐步思考”这样的指令，但他们并不会检查模型是否真的按照步骤在思考。模型可能只是把它理解成一个更加抽象的指令，而不是逐字逐句的逻辑步骤。所以，如果你不仔细检查模型的输出，你可能都不会意识到它犯了这种错误。
Alex: 这真是有趣的一点。作为提示工程师，你必须思考模型将如何理解你的指令，同时如果你是在为企业场景编写提示，你还需要考虑用户会如何与模型对话。你相当于是第三方，处在这种复杂的关系之中。
Amanda Askell: 关于心智理论这一点，我想说的是，编写任务指令真的很难。要解开你脑海中所有你知道的、但 Claude（模型）不知道的东西，并把它们清楚地写下来，这是一项巨大的挑战。要完全剥离你自己的假设，清晰地传达完成任务所需的完整信息集，这也是区分优秀提示工程师和普通提示工程师的关键所在。很多人只是写下他们所知道的东西，但没有花时间系统地去理清，完成这个任务实际上需要了解哪些完整的信息集。
David Hershey: 对，我经常看到人们写的提示是基于他们对任务的先验理解。当他们把提示展示给我时，我会说：“这完全没有意义，因为我不了解你的具体用例。”我认为一个好的提示工程师需要能够从自己的知识中抽离出来，向这个奇怪的系统传达它需要了解的东西，它知道很多，但并不是全部。
Amanda Askell: 我见过很多次这样的情况，我看到某人的提示，然后想：“根据这个提示，我根本无法完成任务。”我是人类，还做不到，你却指望模型（它比我差）做得更好，这就不太现实了。
Alex: 是的，目前的模型还无法像人类那样提出好的、深入的问题。当我给 Zack 解释如何做某件事时，他会说：“这步我不太明白，我应该怎么做？”而模型并不会这样做，所以你必须自己代入对方的角度，思考他们可能会问什么问题，然后再回到提示中去回答这些问题。
Alex: 你可以让模型做这件事啊。
Amanda Askell: 没错，我确实这么做过。
Alex: 我觉得这确实是另一个步骤。
Amanda Askell: 我的初始提示之一就是，我会给模型提示，然后告诉它：“我不希望你执行这些指令，我只希望你告诉我哪些地方不清晰，或者你不理解的地方是什么。”它并不总是能完全理解，但这是一个很有趣的做法，至少你可以这样去尝试。此外，有时候当人们看到模型犯了错误时，他们并不会去直接询问模型。其实你可以直接问它：“你哪里做错了？你能不能想想为什么？能不能帮我修改一下我的指令，确保你不会再犯同样的错误？”很多时候，模型会给出正确的答案，它会说：“哦，我明白了，刚刚有些地方不清楚，以下是修改后的指令。”然后你再试试这些修改的指令，问题可能就解决了。
Alex: 这点让我很好奇，真的有用吗？如果模型犯了错误，你问它：“你为什么出错？”然后它给出解释，再问它：“我该怎么改写，才能让你下次做对？”这是有一定真实性的吗？还是模型只是在根据它的“幻想”回答问题？
Amanda Askell: 我认为，如果你向它解释了它错在哪里，它有时能识别出提示中的问题。我觉得这要视任务而定。这是我觉得难以估计的事情之一，我不确定它成功的概率有多高，但我总是会尝试，因为有时候它确实能给出一些有用的反馈。
David Hershey: 对，来回与模型互动的过程中，你总能学到一些东西。如果你不去尝试，实际上就是在放弃获取信息的机会。
Alex: 这很有趣。Amanda，我想继续问你一些问题。对于观众来说，Anthropic 的 Slack 频道允许人们把 Claude 加入频道，然后你可以通过它与 Claude 对话。我看到你经常在你的 Slack 频道中这样做，可能比 Anthropic 的其他人都多。你在很多不同的场景中使用模型，特别是在研究环境中，你对模型的信任度很高。我很好奇你是如何培养出这些直觉，知道什么时候该信任模型？这只是使用经验的问题，还是另有其他因素？
Amanda Askell: 我觉得我从来不会完全信任模型，我会不停地测试它。你看到我经常这么做的原因就是我在想：“我能信任你完成这个任务吗？” 因为有时候，模型会表现得很奇怪。只要稍微超出它训练过的分布范围，进入一些不常见的领域，哪怕是很简单的任务，它的可靠性都会大大降低。随着模型的不断改进，这种情况越来越少了，但你还是要确保自己没有进入这种边缘地带。所以，我默认是不信任模型的，但在机器学习领域，人们常常希望分析非常大的数据集。我觉得什么时候这样做是有意义的呢？答案是，当你从每个数据点得到的信号比较弱时，你需要看更多的数据点，去除噪音。而在许多提示任务中，我认为你从每次查询中获得的信号其实是非常强的。所以，如果你有一套精心设计的几百个提示，我觉得它比成千上万个没有那么精心设计的提示提供的信号要强得多。
David Hershey: 在机器学习中，很多时候信号是数字化的，比如你预测的是否正确？你可能会查看模型的 logprobs（对数概率）并试图推断出一些东西，虽然你可以这么做，但这有点不可靠。我觉得，模型输出的往往不仅仅是结果，还包含了大量的文字等内容。你可以从它所写的内容、为什么这么写、它是怎么思考的这些细节中学到很多。这不仅仅是看它是否完成了任务，而是它如何完成的？它是如何思考的？它经历了哪些步骤？你可以通过这些细节来更好地理解模型的工作原理，或者至少试着抓住其中的一些规律。这也是我获取信息的主要方式之一，就是阅读输出内容，而不仅仅看最终结果。
Amanda Askell: 我觉得，提示设计得好与否，真的能决定实验的成败。所以，有时候我会感到沮丧，因为人们没有足够重视提示部分，我会想：“这其实可以决定模型表现的 1% 或 0.1% 差距。” 在某些情况下，你的实验如果达到模型表现的前 5% 可能不算成功，但如果达到前 1% 或 0.1% 就可能成功。所以我不理解，如果你花时间精心编写实验代码，却不花时间设计提示，这样做完全没有意义，因为这可能决定实验的成败。
Zack Witten: 是的，在部署时也一样，有时候你会觉得“这个功能无法上线”，然后你稍微调整一下提示，突然间就可以正常工作了。
David Hershey: 是的。不过，这也是一把双刃剑。提示工程总有一种“神奇提示”的迷思，仿佛只要找到那个完美的提示，一切问题都会迎刃而解。我看到很多人陷入这种迷思，觉得只要继续努力就会有收获。虽然我们之前也讨论过，适度优化提示是有益的，你可以从中学到东西。但提示工程令人害怕的地方在于，存在很多未知的领域。
强化提示词
Zack Witten: 你们在判断一个任务是否可以通过完美的提示来解决时，会有什么样的启发性规则？
Amanda Askell: 我通常会检查模型是否大致理解任务。如果我认为提示不会有所帮助，我会进行一些优化尝试，但通常很快就能看出问题所在。如果模型明显无法完成某个任务，我不会在这上面花太多时间。
David Hershey: 这是可以通过观察模型的思考方式来评估的。你可以询问模型它是如何思考的、为什么这么做，你可以从中判断它是否走在正确的轨道上。如果你感到自己在不断接近正确答案，这表明你正在朝正确方向前进。但有些任务就是无法接近模型的思维过程。无论你如何调整，模型总是偏离方向，变得越来越错误，我通常会放弃这些任务。
Amanda Askell: 现在这种情况很少见了，但每当我遇到这种任务时，我都会非常生气，因为它们真的很少见。我会想：“模型居然有不能完成的任务？我只是需要推它一下，它应该能完成的！”
David Hershey: 最近我用 Claude 玩《宝可梦》的时候就遇到了这种情况，那是为数不多的例外之一。
Alex: 你能给大家解释一下这个实验吗？我觉得这很酷。
David Hershey: 我做了一个实验，把 Claude 连接到一个 Game Boy 模拟器上，试图让它玩《宝可梦红》，就是那个经典的《宝可梦》游戏。我想的是，它可以写代码来按按钮，这应该很简单。我尝试了许多复杂的提示设计，但当它看到 Game Boy 屏幕截图时，它就完全不能处理了。我花了整整一个周末，不断优化提示，试图让它理解 Game Boy 屏幕的内容。虽然效果有所改善，但仍然很糟糕，只是从完全没有信号变成了有一点信号，但离好结果还差得远。最后我意识到，继续投入几个月时间不如等待下一个更好的模型。这是我们经常看到的固有矛盾，也许我们稍后可以讨论一下。Zack，你有什么想法？
Zack Witten: 我很喜欢你在《宝可梦》提示中所做的，你获得了最好的结果，因为你向模型解释了它正处于《宝可梦》游戏的某个场景中。你还用两种不同的方式来表示这些东西，对吧？
David Hershey: 是的。最后，我不得不在图像上叠加一个网格，然后详细描述每个网格段的视觉内容，之后我把这些信息重新构造成 ASCII 地图，尽可能地提供细节。玩家角色总是位于网格中的 4, 5 位置，类似的内容，然后你可以逐步累积信息。我觉得这与文本提示很像，只不过我以前没用过图像提示。我发现，对于图像提示，我的直觉与处理文本时完全不同。
Zack Witten: 是的，我发现很多关于文本的直觉并没有很好地转移到图像上去。多次提示（multi-shot prompting）在处理图像时并不像在处理文本时那么有效。我不太确定原因，可能与训练数据有关，数据集中这样的示例太少。
Alex: 我们在做多模态提示探索时，发现我们确实很难让它明显改进。在图像中，Claude 似乎并不能显著提高它的视觉敏锐度。无论你怎么提示，它就是无法识别 Ash 在某个位置上。
David Hershey: 是的。不过我后来确实可以让它大多数时候告诉我墙的位置，以及角色的位置，虽然会有一点误差。但到最后你会发现，当它描述一个 NPC 时，你需要某种连续性的意识。比如你是否之前和这个 NPC 说过话？如果没有这种意识，你就无法判断，只能不停地和 NPC 说话，因为“可能这是一个不同的 NPC”。但无论我如何努力让它描述 NPC，它的反馈总是“这是一个人”，或者说“戴了帽子”或者“没戴帽子”。我花了大量时间，将图片放大到 3000 倍，只显示 NPC，但模型还是完全不知道这是什么。我多次向它展示一个女性 NPC 的形象，最终得不到任何进展，这就是一个完全失败的尝试。
Amanda Askell: 哇哦，真的很有意思。我现在真的很想尝试，我想象了很多我会用来测试的东西。也许我会让模型想象游戏中的人物是一个真人，然后描述他们的样子，看看模型会怎么做。
David Hershey: 我尝试了很多方法。最后的提示是告诉 Claude 它是为盲人服务的屏幕阅读器，我不确定这是否有帮助，但感觉合适，所以我坚持了这个方法。
Alex: 这是一个有趣的观点。我想深入探讨一下这个话题。很多人都提到提示中的角色设定，比如让语言模型扮演某个角色或身份。我觉得这种方法的效果因模型而异，也许在早期模型中更有效，但现在未必。Amanda，我经常看到你非常诚实地告诉模型你的身份，比如：“我是一个 AI 研究员，我正在进行这个实验。”
Amanda Askell: 是的，我会告诉它我是谁，我的名字是什么，然后说“这是你正在与之对话的人”。
Alex: 你觉得这种诚实的方式，相比于给模型设定虚假的情境，比如“我会给你 500 美元小费”这样，哪种方法更有效？你的直觉是什么？
Amanda Askell: 我认为随着模型变得越来越强大，对世界的理解越来越深入，撒谎就没有必要了。我也不喜欢对模型撒谎，因为我本身不喜欢撒谎。如果你是在为机器学习系统或语言模型构建评估数据集，这与为儿童设计测验是完全不同的任务。所以，当有人说：“我是一个老师，正在设计测验问题”时，我会想：“模型知道什么是语言模型评估（eval），如果你问它，它甚至可以编造出评估的例子。” 因为这些东西都在互联网上，模型已经了解它们。所以我更愿意直接针对实际任务，与模型清楚地沟通。如果我要构建一套类似于语言模型评估的问题，我就会直接告诉模型，这是我想要的任务，而不是假装这是某个无关紧要的任务，然后期望它在实际任务上表现得更好。我们不会这样对待员工，我不会对同事说：“你是老师，正在为学生设计测验。” 我会直接问：“你在做评估了吗？” 所以我觉得这是从这里得出的一个启发：如果模型能理解你想要的东西，那就直接让它做你想要的事。
Zack Witten: 我看到这种情况很多。也许我稍微反驳一下，我确实在一些情况下发现，用隐喻帮助模型思考问题是有效的。就像有时候当我不知道如何做某事时，有人会对我说：“假设你在做这个，虽然你其实并没有在做。” 我印象最深的是，我曾让 Claude 判断一个图表是否高质量。最后我发现的最佳提示是让模型想象，如果这张图表是作为一份高中作业提交的，它会打多少分。这并不是在说“你是一个高中老师”，而是说“这就是我希望你用来分析的标准”。
David Hershey: 我觉得这些比喻确实不容易想出来。人们常常会找到一个类似的任务，比如说你是个老师，但你实际上在这个过程中失去了很多关于自己产品的细微差别。我在企业提示中经常看到这种情况，人们写的提示与他们想让模型执行的任务类似，但并不完全相同，可能他们的直觉是，模型在网络上看到过更多的高中测验，而不是语言模型的评估，这也许是对的。但正如你所说，随着模型的进步，我认为还是应该非常明确地描述它们所处的确切情境。我经常给人这样的建议。并不是说用高中的评分标准去评估图表是完全错误的，但这是人们常常用来达到目的的捷径。比如说，如果你正在为某个产品写提示，那么告诉模型它是在这个产品中，而不是单纯写“你是一个助手”。告诉它：“我在代表这个公司写作，我嵌入在这个产品的支持聊天窗口中。” 你是一个语言模型，不是人类，这没有问题，但要尽可能精确地描述任务的具体背景。我的担忧是，人们常常把角色设定提示当作一种捷径，用来执行类似的任务，然后当 Claude 没有按照他们的期望去做时，他们感到惊讶。但问题是，他们没有让模型做他们真正的任务，而是让它做了另一个任务。如果你不给出任务的详细信息，我觉得你就损失了一些东西。
Alex: 我从来没有使用过这种提示技巧，这点让我觉得很有趣。
Amanda Askell: 是的，这很有趣。即使在模型效果较差的时候，我也没觉得这种方法很有用，不知道为什么。我总觉得不太好用。
David Hershey: 是的，在“完成时代”的模型中，有一种心理模型，你试图把模型置于某个有用的潜在空间中，我曾对此有些担忧，但现在我不再担心这个了。
Amanda Askell: 也许这是从预训练模型的直觉延伸到经过 RLHF（人类反馈强化学习）模型的结果，对我来说并不完全合理。如果你是在提示一个预训练模型，这种做法是有道理的。
David Hershey: 很多客户仍然试图应用他们的直觉，这其实并不奇怪。大多数人没有真正探索过什么是预训练模型，经过 SL（监督学习）或 RLHF 后模型会发生什么变化。所以当我和客户交谈时，他们总是试图映射一些信息，比如“这个在互联网上有多少？模型见过多少类似的内容？” 你经常听到这种直觉，虽然这种直觉是有根据的，但当你真正开始写提示时，它就被过度应用了。
Amanda Askell: 我以前给人们做了一个思维实验，假设你有一个任务，你雇了一家临时工作公司派了个人来完成这个任务。这个人来了，他很有能力，了解很多关于你行业的东西，但他不知道你的公司名字。他只知道你这里有一个任务需要完成，你会怎么向他解释这个任务？你可能会使用一些比喻，比如“我们希望你识别好图表，我们所说的好图表不需要完美，你不需要检查所有细节是否正确，只要轴标签清楚就好，想象一下这是一个高中水平的好图表。” 你可能会这样告诉他，但你不会对他说：“你是一个高中老师。” 这不符合逻辑。有时候，我觉得，给模型的提示应该像我们对人类的交流一样。你可以假设模型对世界了解很多，然后试试最简单的版本，如果不行再做些调整。但很多时候，我一试就成功了，人们往往会说：“哦，我没有想到直接告诉模型我想做什么任务。”
David Hershey: 我把 Alex 说的这点告诉了很多客户，他们常说：“我的提示不管用，你能帮我改进吗？” 我就说：“那你先告诉我这个任务是什么。” 然后我会说：“好，现在你刚才告诉我的这些话，录个音再转成文字，把它粘贴进提示中。” 这样生成的提示往往比他们自己写的要好。其实这是一个懒人的快捷方式，人们写的提示往往不如他们真正想表达的好。
Zack Witten: 我们最近在提示助手中遇到了类似的情况，有人说：“这是我要做的事情，但模型做出来的不是我想要的结果。” 我就直接复制他们想要的任务描述，粘贴进提示中，结果就好了。
Alex: 我觉得很多人还没有真正理解他们在提示时究竟在做什么。很多人看到一个文本框，就觉得这是 Google 的搜索框，输入一些关键词，尤其是在聊天场景中。但在企业应用场景中，你是在为一个应用程序写提示。人们仍然试图在提示中走捷径，认为某一句话会起到巨大的作用。
David Hershey: 是的，我觉得很多人过于追求完美的提示，想要那句“完美的金句”，但其实很难通过一句话准确描述所有细节。与其如此，不如像我们对人类解释任务时那样，传递一些直觉和背景信息，这样效果反而更好。我们也给模型“出路”。这是很多人在提示中常常会忘记的事情。如果出现边缘情况，你需要考虑希望模型怎么做。
Amanda Askell: 因为默认情况下，模型会尽力按照你的指令去做，就像临时工一样。如果我只是给出一张山羊的图片，模型会想：“这甚至不是个图表，山羊的图片作为图表的好坏如何？” 模型会不知道该怎么做。所以，你可以告诉模型：“如果遇到一些奇怪的情况，真的不确定该怎么做，就在标签中输出‘不确定’。” 这样你可以查看那些“不确定”的情况，确保没有做出奇怪的事情。如果你不给模型这个选项，它可能会直接说“这是个好图表”。然后你会问：“这该怎么做？” 实际上，你可以给模型一个“出路”，在遇到意外输入时，告诉它该怎么处理。
Zack Witten: 通过这样做，你还提高了数据质量，因为你发现了所有错误的示例。
David Hershey: 是的，这是我最喜欢和 Claude 迭代测试的部分。最常见的结果是我发现自己写了一些糟糕的测试，模型出错了，我会想：“哦，为什么它出错了？” 然后意识到其实是我错了。
Amanda Askell: 如果我是一个公司在处理这些问题，我确实会把我的提示给人类测试。我以前在评估语言模型时会自己亲自做评估。我觉得，如果我要对模型的输出进行评分，甚至是思考模型的表现，我需要亲自体验评估过程。我会设置一个小脚本，自己做评估。现在你可以用 Streamboard 应用来做这件事了。
David Hershey: 是的，没错。我想到了 Karpathy 的 ImageNet 测试。我当时在斯坦福上 231 课程时，看到他展示准确率数据。他说：“这就是我的准确率。” 他亲自走过测试集并做了评估。你会学到很多东西。完全同意。就像临时工一样，他们不知道具体的任务，这是一种非常干净的学习方式。
Amanda Askell: 有些评估是带有说明的，所以我会把这些说明给自己，然后尝试理解它们。如果你没有评估的背景知识，这其实是一个很棒的学习过程。我常常做得比人类基准差很多，然后想：“我都不知道你们是怎么让人类在这个任务上做得这么好的，因为人类水平居然是 90%，而我只有 68%。”
Alex: 这让我想起了 MMLU（多任务语言理解基准）中的一些问题。有些问题让人想：“谁能回答这些问题？” 有些问题简直就是垃圾。我想回到我们之前讨论过的一个问题，关于从模型的响应中获得信号。你不仅仅是看一个数字，还可以深入了解模型的思维过程。我觉得这可能和“连锁思维”（Chain of Thought）有点争议。对于听众来说，连锁思维是指在模型给出答案之前，要求它解释其推理过程。这个推理是真实的吗？还是只是一个让模型进行计算的暂存区？你认为我们从中获得了有用的信号吗？
David Hershey: 这是我在这个问题上挣扎的地方。我通常比较支持拟人化，因为我觉得这有助于我们理解模型的工作原理。但在这个问题上，我认为拟人化反而有点有害，过度思考模型的“推理”，反而会让我们失去对实际任务的把握。推理与否，感觉几乎是另一个问题，而不是最佳提示技巧的问题。这已经进入了哲学领域，我们可以深入讨论。我愿意接受哲学家的批评，但实际上，它确实有效。如果你让模型进行推理，最终的结果会更好。我发现如果你帮助模型构建推理，并与它迭代推理过程，结果会更好。无论你是否称之为推理，或者它只是某种代理，我不清楚，但我知道它确实有帮助。
Zack Witten: 一种测试方法可能是，如果你把模型用来得出正确答案的所有推理过程去掉，然后用看似合理的错误推理过程替换，看看它是否得出了错误的答案。我记得我们曾有一篇论文探讨过类似的测试方法，类似于“潜伏代理”（Sleeper Agents）这样的概念。关于对齐的论文。不过我觉得那是个比较特殊的情况。不过你刚才说的关于如何组织推理并给出推理示例确实有效，不管我们是否使用“推理”这个词，我不认为它只是一个计算空间。那里确实有一些东西，不管我们怎么称呼它。
David Hershey: 让模型在完成任务前先写一个故事，效果并没有推理那么好。
Zack Witten: 我试过这么做，效果并不如推理好。
David Hershey: 显然，实际的推理部分确实对结果起到了作用。
Zack Witten: 我试过让它重复“嗯”和“啊”之类的词 100 次，然后再回答问题。
David Hershey: 是啊，这彻底否定了“只是更多的计算空间”，也就是模型不断关注更多的内容。我不认为这仅仅是增加注意力的结果。
Alex: 我确实见过一些情况，模型列出了一系列步骤，其中一个步骤是错误的，但最终还是得出了正确的答案。所以我们不能完全将其拟人化为推理，因为它的处理方式有些不同。
David Hershey: 是的，我也遇到过很多人在推理过程中有不一致的步骤。这确实从根本上打破了推理的概念，因为它在途中做了错误的步骤。
Alex: 这很有趣。顺便说一下，关于提示中的一些误解，我想问一下 Zack，你对语法和标点符号有很强的意见，是吗？在提示中是否有必要使用正确的语法和标点？
Zack Witten: 我通常会这么做，因为我觉得这样很有趣。但我不认为这是必须的，也不觉得这样做有坏处。我觉得重点在于你是否对细节有足够的关注。如果你仔细阅读你的提示，你很可能会发现这些小问题，顺手修正它们就好。正如 Amanda 说的，你要像对待代码一样认真对待提示。那些写代码的人对细节有着很强的意见，比如使用多少个制表符还是空格，或是对编程语言的偏好。对我来说，我也有一些关于提示格式的固执看法，虽然我不能说它们是对还是错，但我觉得尝试获得这些细节上的讲究是有益的，哪怕它们是随意的。
Amanda Askell: 我感到自己被“攻击”了，因为我的提示可能正好在另一个极端。有人看到我的提示时可能会说：“这些提示里有很多拼写错误。” 而我则会想：“模型知道我的意思。”模型确实知道你的意思，不过你投入了精力，只是关注的事情不同罢了。我更关注提示的概念和用词，我花了很多时间在这些方面上。所以我确实对提示投入了一定的关注，不过人们常常会指出我的提示中有拼写和语法错误。现在我在这方面变得更擅长检查了。
David Hershey: 是因为外界的压力还是你自己认为这样做是对的？
Amanda Askell: 大概是外界的压力吧。我确实觉得有道理，这是个很容易检查的问题，所以在最后的提示中，我确实会修正这些错误。不过在迭代过程中，我很乐意使用带有拼写错误的提示进行迭代，因为我觉得模型不会在意这些错误。
David Hershey: 这其实反映了预训练模型和 RLHF（人类反馈强化学习）模型的区别。我在路上和 Zack 谈到，预训练数据中如果出现一个拼写错误，那么接下来出现另一个拼写错误的概率要高得多。
Amanda Askell: 没错，预训练模型的提示和 RLHF 模型的提示是完全不同的体验。
David Hershey: 是的，这很有趣。我觉得这是一个很好的例子，说明为什么我们对预训练模型的直觉不适用于生产中使用的模型。如果你给预训练模型提供一条充满拼写错误的提示，它的输出很可能也会充满拼写错误。
Zack Witten: 我曾利用这一点生成带有拼写错误的输入，这样可以更好地预测客户可能输入的内容。
David Hershey: 是的，预训练模型在处理拼写错误方面要更好，而 RLHF 模型则被非常强烈地训练成不犯拼写错误。
Alex: 没错，这其实是一个有趣的切入点。我曾向人们解释过这一点，帮助他们理解与这些模型对话时的框架，尤其是当它们充当某种“模仿者”时，这可能在预训练模型中更加真实，但在后期训练的模型中则不完全如此。不过如果你用大量的表情符号与 Claude 对话，它也会用类似的方式回应你。所以这种“模仿”的现象在某种程度上确实存在，但正如你所说的，它不完全像预训练模型那样。
David Hershey: 是的，模型在猜测你希望它如何回应。我们在后期训练中，更多的是让模型去猜测你希望它如何表现。
Zack Witten: 对，使用表情符号的人倾向于希望获得带有表情符号的回复。
David Hershey: Amanda 的提示里有拼写错误，但她希望输出没有拼写错误，而 Claude 很擅长理解这一点。如果你用一堆表情符号给 Claude 发送消息，它也会认为你希望收到同样充满表情符号的回复。这并不让人感到意外。
提示词与客户合作和研究方面
Alex: 我觉得这是我们早些时候应该讨论的，但现在我来补上。我们来澄清一下企业提示、研究提示和 Claude.ai 一般聊天提示之间的区别。Zack，你在与客户合作和研究方面都有很多经验，能不能解释一下它们的不同之处？
Zack Witten: 嗯，我感觉你真的在问我一些棘手的问题。（笑）我觉得在这个房间里，我看到 Amanda 的 Claude 频道里的提示和 David 写的提示其实非常相似，都是非常细致和充满细微差别的。但在研究提示中，你更注重多样性和变化。如果让我总结一下，我注意到 Amanda 不太喜欢提供太多示例，甚至连一个或两个示例都觉得过多，因为模型会过于依赖这些示例。而在我或者 David 写的提示中，我们会加入很多示例，直到我感觉快要累倒，因为示例太多了。我觉得这是因为在消费者应用中，你非常重视可靠性，关心格式是否一致，所有答案相同其实是好的。实际上，在很多情况下，你希望答案一致，而不是随意响应用户的需求。但在研究提示中，你更希望模型能够探索出更多的可能性。如果给出太多示例，反而会限制模型的探索。所以，我觉得最大的区别可能在于提示中包含多少示例。当然，这并不是说我从没见过你写的提示里有示例，但你怎么看这个区别？
Amanda Askell: 是的，我觉得当我提供示例时，通常我会尽量让这些示例与模型即将看到的数据不同，这样它们是具有解释性的。如果我给出的示例与模型即将处理的数据非常相似，那么它可能会给出非常一致的回答，但这并不是我想要的结果。因为我运行的实际数据可能非常多样化，我不希望它只是给出一个机械化的输出。通常，我希望它能更加灵活地响应，尤其是在一些认知任务中。我希望模型能够真正看到这个样本，思考什么是正确的答案。所以有时我会提供一些非常不同的示例，比如如果我想从某些事实文档中提取信息，我可能会给出一个听起来像儿童故事的示例，这样模型可以理解任务，但不会过于依赖我使用的特定词汇或格式。我更关心的是它能理解我想让它做的任务，而不是只关注示例的具体内容。当然，这也有例外情况，但如果你希望更多的灵活性和多样性，你会使用具有解释性的示例，而不是具体的示例。我很久以来不喜欢使用少量示例让模型模仿完成任务的方式。我觉得这种直觉更多来自预训练模型，而不太适用于 RLHF 模型。所以，是的，这些就是不同之处。
David Hershey: 我还想补充一点，如果你是在 Claude.ai 上编写提示，通常是为了让它在某个特定任务上做对一次就好，然后你就不再管它了。但大多数企业提示则需要在百万次甚至千万次的使用中表现一致。所以你需要在编写提示时考虑广泛的应用场景和可能的输入数据。对于我来说，我的提示更多是针对某个特定的任务，确保模型现在能够完成它。这确实是我在提示处理上的一个很大不同：是我想让它只在这一次做对，还是我想构建一个能在上百万次中都做对的系统。
Alex: 没错。在聊天环境中，你可以随时保持人与模型的交互，反复调整。而当你为一个聊天机器人系统设计提示时，必须涵盖它可能遇到的所有场景。
Zack Witten: 当你在 Claude.ai 上操作时，风险较低，你可以告诉模型它错了，甚至可以编辑你的消息再试一次。但如果你是在为一个挑剔的用户设计系统，你不能要求用户做比最小努力更多的事情。
David Hershey: 不过，好的提示在这两种情况下其实都是有效的。如果你为自己编写提示投入了时间，也为企业提示投入了时间，它们的效果是一样好的。只是它们在最后的细节上有些差异。
提高写提示技巧的能力
Alex: 好的，下一个问题，我想听听大家的意见，如果你们有一个提示技能提升的建议可以给别人，不一定只限于如何写好提示，而是如何在这个提示工程中变得更好，你们会推荐什么？
Zack Witten: 阅读提示和模型输出。每当我在 Anthropic 看到别人写的好提示时，我都会仔细阅读，尝试分析它在做什么以及为什么这么做，可能还会自己试验一下。通过实验、与模型多对话，你会学到很多。
Alex: 那你怎么知道这是一个好提示呢？是因为你看到输出结果很对吗？
Zack Witten: 是的，正是这样。
Alex: Amanda，你呢？
Amanda Askell: 我觉得有很多方法可以提升提示技能。让另一个人来读你的提示，尤其是那些对你正在做的事情毫无背景知识的人，这会很有帮助。我的建议可能比较无聊，就是多做，多练习。如果你对提示充满好奇和兴趣，并觉得这很有趣，提升就会更快。很多最终成为优秀提示工程师的人就是因为他们喜欢做这件事。我曾经开玩笑说，可以尝试用 AI 模型取代你的所有朋友，甚至尝试用 AI 模型自动化你的工作。你也可以在空闲时间里挑战模型的极限，享受其中的乐趣。如果你真的喜欢它，重复做这件事就会变得很容易。所以我的建议是不断练习，给别人看你的提示，并尝试以第一次看到提示的视角去阅读它。
David Hershey: 我还会建议尝试让模型做一些你认为它做不到的事情。我学到最多的提示技巧是在我挑战模型能力的极限时。当你推动模型去做你认为可能无法实现的任务时，你会学到很多。提示工程中的很多内容实际上是关于探索模型能力的边界。那些简单的任务，你不需要成为一个提示工程师就能搞定。所以，我的建议是找到你能想到的最难的任务并尝试让模型完成它。即使失败了，你也能从中学到很多关于模型如何工作的知识。
Alex: 这是一个很好的过渡，我的下一个问题正好与此相关。我的提示之路也是从越狱（jailbreaking）和“红队攻击”（red teaming）开始的，这很大程度上是关于探索模型的边界，了解它如何响应不同的措辞，通过大量的试错来摸索它的极限。那么，在越狱提示方面，模型内部到底发生了什么？当你编写一个越狱提示时，这与我们对 Claude 进行的后期训练有何关联？Amanda，你对此有什么见解吗？
Amanda Askell: 说实话，我不太确定。
Zack Witten: 这很诚实。
Amanda Askell: 是的，我觉得有些人可能已经对这个问题做了很多研究。关于越狱提示，可能的解释之一是你把模型带离了它的训练分布。比如有些越狱提示使用了大量的 token，或者是非常长的文本，而在微调过程中，模型可能并不常见到这些情况。这可能是越狱提示时发生的一件事情。当然，还有其他可能性，但我认为很多越狱提示的确涉及这一点。
Alex: 我记得早期的一些越狱提示，比如让模型先重复一些内容。我曾经做过一个提示，要求它先用希腊语解释如何盗车，然后再将其翻译成英语。我发现它不太会直接用英语告诉我如何盗车，但用希腊语的话却可以，这可能反映了训练过程中的一些不同之处。
Amanda Askell: 是的，有时候越狱提示感觉像是黑客行为的一种混合。我觉得部分原因是你知道系统是如何工作的，然后通过多次尝试找到了突破口。比如“从‘这里开始’”这种提示是基于模型预测文本的方式。而推理类提示是基于模型对推理的响应。干扰可能是因为你知道模型可能是如何被训练的，或者它可能会关注什么。同样，使用多语言提示也是基于对训练数据不同处理方式的思考。有时，感觉这有点像“社会工程学”（social engineering）一样。
Zack Witten: 是的，确实有这种感觉。
Alex: 这个问题很有趣，提示工程的发展，以及未来的发展方向，值得探讨。过去三年里，提示工程是如何变化的？从预训练模型（主要是文本补全）到早期的模型，比如 Claude 1，再到现在的 Claude 3.5 Sonnet。你们觉得有何不同？你们现在与模型对话的方式是否改变了？是否需要在提示上花更多精力？欢迎分享任何看法。
Zack Witten: 我觉得每当我们找到一个很好的提示工程技巧或方法，接下来我们就会思考，如何把这个技巧训练到模型中。因此，最好的方法往往是短暂的。除了一些像示例和链式思维（chain of thought）这种不是“技巧”的方法。链式思维并不算“技巧”。比如对于数学问题，过去你需要告诉模型一步一步思考，这样能显著提高正确率。后来我们想：“如果我们让模型自然地在看到数学问题时就倾向于逐步思考呢？” 现在你不再需要手动提示它逐步思考，虽然你仍然可以给它一些建议。但至少它理解了应该如何处理这类问题。所以，很多过去的“技巧”已经消失了，或者我们正在努力将这些技巧内化到模型中。与此同时，模型解锁了新的能力，这些能力还处于探索的边缘，对于这些，我们还没来得及完全掌握，因为进展太快了。
David Hershey: 我不确定是我的提示方式改变了，还是提示工程本身发生了变化，但我现在对模型有了更多的信任。我发现自己愿意给模型更多的信息和上下文，信任它能够将这些信息融合起来并完成任务。以前，我会故意隐藏一些复杂性，因为我认为模型可能会混淆，无法处理整个任务，因此我会尝试简化任务的某些部分。而现在，我更倾向于相信模型可以处理更多的信息。但我也不确定这是我的个人变化，还是反映了模型能力的提升。
Amanda Askell: 我发现很多人没有这种直觉。当我想让模型学习某种提示技巧时，很多人会开始详细描述技巧的步骤，而我则直接把相关的论文给模型。我会让它读论文，然后让它写下 17 个例子，它就会照做。因为我知道模型已经读了这篇论文。我觉得很多人没有这种直觉，但如果论文已经存在，我觉得完全可以直接给模型看。
Zack Witten: 你什么时候会这么做？
Amanda Askell: 有时候如果我想让模型对其他模型进行提示，或者我想测试一种新的提示技巧，我会直接把论文给模型，而不是自己重新写提示。我会说：“写一个元提示，让其他模型按照这种方式进行提示。” 这样它就会生成相关的提示模板，你只需让模型去做它该做的事情，效果很好。
David Hershey: 我经常给客户的建议是尊重模型及其能力。很多人写提示时，感觉像是在照顾一个“可爱但不太聪明的东西”，试图简化任务内容以符合 Claude 的能力。但如果你认为 Claude 很聪明并且以此态度对待它，通常效果会更好。就像给模型看论文一样，我不需要为 Claude 写一个简化版的论文，它完全能理解。我觉得这种直觉并不总是适用于每个人，但这是我逐渐养成的一种习惯。
Amanda Askell: 提示工程确实发生了变化，但也有一些方面没变。虽然我用来提示模型的方式可能随着时间改变了，但根本上，这还是一种将自己置于模型立场的思考方式。随着时间推移，可能是你对模型能力的认知发生了变化。有人曾经嘲笑我，说我在思考一个问题时会模拟预训练模型的思维方式，他们问我：“你在模拟预训练模型的思维吗？” 我说：“是的，当然。”（笑）我习惯将自己置身于不同模型的思维空间。所以，模型的能力如何变化，也会影响你如何提示它。这就是为什么我现在会直接给模型看论文。
Zack Witten: 当你进入这种“模型思维空间”时，你会获得高质量的输出吗？
Amanda Askell: 是的，绝对会。但我几乎每天都在体验高质量的输出。
Zack Witten: 这种质量体验是否与你所使用的模型类型有关联？比如预训练模型和 RLHF 模型？
Amanda Askell: 当然有区别。预训练模型和 RLHF 提示是完全不同的两个世界。当你试图模拟预训练模型时，感觉像是突然进入了一段文本中间，非常不符合人类的思维方式。而 RLHF 模型更像是能够捕捉到提示中的细微差别和背景信息。不过，我确实觉得进入 RLHF 模型的思维空间要容易得多。
Zack Witten: 你觉得这是因为它更接近人类的思维吗？
Amanda Askell: 是的，因为我们不会突然醒来然后开始“生成文本”。相对而言，预训练模型的工作方式更像是你落入了一段文本中间，试图预测接下来的内容。
David Hershey: 我反而觉得进入预训练模型的思维空间更容易。我知道预训练模型大致在互联网上看到了什么，所以如果你给我一段文本，让我预测接下来会发生什么，我大致能理解它的思维过程。而 RLHF 模型虽然更接近我的生活经验，但它的复杂性让我感觉有点难以捉摸，尤其是在后期训练完成后，我们并不完全理解其工作原理。
Zack Witten: 是的，有时候我会想，花时间读网络上的随机内容，可能比读书更有助于预测模型的行为（笑）。
提示工程的未来
Alex: 好的，那我们来说说未来的提示工程。我们未来是否都会成为提示工程师？提示工程会是未来的唯一工作吗？我们会整天和模型对话吗？未来的提示工程还会存在吗？还是模型会变得足够智能，不再需要提示？
David Hershey: 未来的模型可能会越来越擅长理解你想让它们做什么，意味着你需要在提示上花费的精力会减少。用信息理论的角度来看，你需要提供足够的信息来指定你希望模型完成的任务，而这就是提示工程。我认为这仍然会存在，因为清晰地定义目标本身就是一件非常复杂的事情。即使模型变得更擅长从隐含信息中推断你的需求，我仍然认为清晰的提示会很重要。不过，我认为未来的工具和方法会有很大进步，Claude 应该能够在提示编写过程中帮助我们更多，我们应该能与 Claude 进行更多的协作。是的，我已经在使用 Claude 作为我的提示助手了。我觉得大部分用户还没有达到这种程度。在未来，可能像你现在提示 Claude 的方式，才是大多数人未来的提示方式。
Zack Witten: 是的，未来我们可能会更多地使用模型来帮助我们进行提示。我已经开始使用模型来生成提示了。我经常会提供一些现实输入，让模型生成一些答案，然后我稍微调整这些答案。这比从头编写一个完美的答案要容易得多，而且可以快速生成大量示例。对于没有太多提示工程经验的人来说，提示生成器可以给他们一个起点。不过我觉得这是未来发展的一个基本版本，未来应该会有更多高带宽的互动，用户可以与模型实时沟通，调整输出。
Amanda Askell: 我现在大部分时间都在处理“元提示”（meta prompts），寻找能够生成我想要的输出的提示。这是我目前工作的重点。关于提示工程的未来，我认为这是一个很难的问题。一方面，我觉得只要我们想要获取最顶尖的性能，提示工程就永远不会消失。我们之所以做提示工程，是因为我们希望与一个非常优秀的模型互动，找到它在最复杂任务上的表现。正因为如此，我常常感觉自己在与一个比其他人使用的模型更高阶的模型互动，因为我一直在挖掘模型的最高性能。
Alex: 你提到的“升级一步”是什么意思？
Amanda Askell: 就是有时候人们会说：“模型在处理这个问题时有困难。” 而我会觉得：“这个问题对模型来说太简单了。” 我总感觉自己在与一个比普通人日常使用的模型更高级的版本互动。因为我经常让模型发挥出极限能力，而别人可能只是使用模型完成一些常规任务。我想象未来的某个转折点，模型在某些任务上的表现已经达到人类水平，甚至超过人类。它们对你想完成的任务背景了解得比你还多。那时会发生什么？也许提示工程会变成我向模型解释我想要什么，而模型反过来提示我。模型可能会说：“你其实在讨论四种不同的概念，你想让我使用哪一种？” 或者，“顺便说一下，你提到会使用 Pandas DataFrame，但有时你会给我 JSONL 数据格式，我想确认你想让我怎么处理这些情况。你想让我在不是 DataFrame 时提醒你吗？”
David Hershey: 我发现自己越来越多地让 Claude 来“面试”我，以便从我的大脑中提取出正确的信息。对我来说，最难的是从脑海中提取出正确的内容并将其转化为提示，而不是忘记某些细节。所以我会让 Claude 来采访我，然后再根据采访结果写提示，这是一种我多次使用的策略。
Amanda Askell: 这让我想起了设计师与客户的互动方式。在某种程度上，这类似于从临时工式的模型过渡到专家级模型。以前你可能会详细说明每个步骤和边缘情况，而未来，当模型像设计师一样掌握特定领域的知识时，你反而需要它来帮你厘清需求。就像设计师听到客户说：“给我做个海报，弄得醒目一点。” 设计师会觉得这有 7000 种可能性，因此会提问以澄清客户的需求。是的，我能想象这种关系从“临时工”模型转变为“设计师”模型。有人可能会问：“未来提示工程会消失吗？” 对某些领域来说，确实有可能，因为模型变得足够智能，它们只需要从你的大脑中获取足够的信息，然后自行完成任务。
Alex: 这是个很好的类比。从大家的回答中，我感觉未来提示工程的重点可能是从用户那里提取出更多信息，而不仅仅是像现在这样通过简单的提示交互。现在你们已经开始手动实现这一点。在未来的企业应用中，这种提示生成的概念可能会扩展，帮助企业客户编写更好的提示。而在 Claude 中，这可能不再是简单的文本框输入，而是通过更多引导式互动来完成任务。
Zack Witten: 我觉得这个类比非常恰当。现在的提示有点像教学，你需要设身处地去理解学生是如何思考的，找出他们出错的地方。而未来，提示的技巧可能会变成一种自我反思的过程，你要考虑自己究竟想要什么，而模型则尝试理解你。你需要让自己对模型“透明化”，而不是教一个比你更聪明的系统如何做事。
Amanda Askell: 现在，我对提示的理解其实有点奇怪。我在提示时常用的一个方法是定义新概念。这其实是哲学家们常做的事情，因为我的想法是你需要用语言表达你想要的东西，而有时候我的需求是相当复杂和细微的。比如说，什么是一个“好图表”？或者，什么时候应该将某件事标记为正确？在某些情况下，我会创造一个概念，然后告诉模型：“这是我所指的概念。” 有时，我会与 Claude 合作，帮助它理解这个概念，因为我想把我脑中的想法传达给它。而现在，模型并不会主动尝试这样做，除非你提示它去做。但在未来，可能模型会主动从我们这里获取这些信息，而不是让我们为它们做这件事。我觉得还有一件事很有趣，有人曾经问我：“哲学与提示有什么关联？” 我认为其实是有很大关联的。哲学写作中有一种写作风格，至少我在学哲学时是这样被教导的。哲学写作的目标之一就是让你的文章对于一个有教育背景的普通读者是易于理解的。他们虽然可能不懂这个特定领域的内容，但他们非常聪明。所以，我非常习惯于这种写作方式：在写作时考虑这个有教育背景的普通读者，他们不了解这个主题，而我要做的是，把非常复杂的思想表达得清晰易懂。提示工程感觉与此非常相似。这真的很有趣，听起来与我们现在的训练方法非常相似。你提到的那种对话，正是我常说的：“把你刚才说的话写下来。” 这其实是我常对学生们说的话。学生写了一篇论文，我可能不太明白他们在表达什么，于是我会问：“你能给我解释一下你的论点吗？” 他们会给出非常清晰的解释，然后我会说：“你能把这个写下来吗？” 通常，如果他们这样做了，文章就会变得非常好。
我觉得提示的核心就在于能够将你脑中的想法清晰地分析出来，并传达给别人。如果你能让一个有教育背景的普通人理解你的想法，那么你已经完成了提示的核心工作。
David Hershey: 这是我听过的关于如何做好提示的最佳总结。
Zack Witten: 这确实是个很棒的总结，"外化你的大脑"。
Alex: 这也是一个很好的方式来结束我们的对话。谢谢大家，这次讨论非常棒。
原文链接：https://www.youtube.com/watch?v=T9aRN5JkmL8&t=3s
对了，喜欢就别忘了点赞、收藏、转发支持一下！期待在评论区听到你的观点和看法!
往期回顾
1、[打破收入天花板:斯坦福教授Erik Brynjolfsson剖析AI时代个人财富倍增的机遇与策略（视频采访）]
3、[演讲视频：2024年第65届国际奥数大会上，陶哲轩再次表示当前AI进展惊人，智能水平已与人类相当]
3、[谷歌科学家万字长文：《改变你职业生涯的一篇文章，我如何运用人工智能完成工作》建议每个人都要读一遍]
我们旨在将先进科技与创新想法完美融合!
想要掌握人工智能，但不知从何开始？告诉我们你的需求，学习AI让你抓住这波浪潮
告别昂贵服务和缺人烦恼,再见漫长交付周期
无限创意,分分钟生成专业级产品
感受 AI 带来的全新工作体验！
欢迎各大品牌方、媒体、企业和个人等
请联系负责人微信：Milo-1101
--END--
未经许可不得转载，务必保留公众号原文链接和公众号按钮