孔某人 2024-11-22 11:23 北京
Anthropic官方2024.9发布， 深入探讨prompt工程，中文脱水 重制版
前言
本文是2024.9.6Anthropic官方在youtube的一个播客全文的脱水版，
原视频标题AI prompt engineering: A deep dive播客视频链接https://www.youtube.com/watch?v=T9aRN5JkmL8内容英文原文有 18.2k gpt-4o token脱水后有1.7w字
这是难得的世界第一梯队的模型厂来分享他们对prompt工程的经验，而且是比较新的内容。
这个材料有几个作用：
这是目前对于高端模型的很重要和少有的prompt思路指导
知道有哪些认知LLM和prompt的视角
知道即使是Anthropic也只知道这些
什么是脱水版
本文是对于播客全文的一个整理，力求保留所有信息和每个信息是由谁说的，目标是能够让读者在任何情况下都不必去看原文。
本文是一个技术方案的效果展示，内容都由workflow生成。由于该内容比较重要，为了长期保存，所以本次重制版也经过了我的人工编辑。文中的粗体是我人工标注的我认为重要的信息。
该内容的脱水版之前发过一个版本，但目前workflow已经有迭代，并且我目前认为使用第一人称会更好一些，同时修正一些之前版本的问题，才重新排版了这个重制版。
正文
AI Prompt工程：深入探讨
(00:00:00)
Alex Albert:
这次圆桌讨论将主要聚焦于prompt工程。我们这里有来自研究、消费者和企业等不同视角的专家，我想听听大家的各种观点，一起探讨prompt工程的本质。让我们先轮流做个自我介绍吧，我先开始。我是Alex，现在在Anthropic负责开发者关系工作。之前我在Anthropic的prompt工程团队担任prompt工程师，做过从解决方案架构师到研究等各种工作。
David Hershey:
我是David Hershey，在Anthropic主要和客户打交道，处理各种技术问题。我帮助客户进行fine-tuning，也解决他们在使用语言模型时遇到的各类问题。
Amanda Askell:
我是Amanda Askell，在Anthropic负责一个fine-tuning团队，致力于让Claude变得更诚实和友善。
Zach Whitten:
我是Zach Whitten，是Anthropic的prompt工程师。Alex和我总是争论谁是第一个prompt工程师。我之前主要负责客户支持，现在主要开发Prompt Generator等教育材料，目标是提升整个社会的prompt基础水平。
Alex Albert:
好的，感谢大家。让我们开始今天的讨论。首先想请大家谈谈：什么是prompt工程？为什么称它为工程？什么是prompt？
Zach Whitten:
我觉得prompt工程就是试图让模型做事情，尽可能发挥模型的潜力，与模型合作来完成那些原本做不到的事情。很大程度上就是要清晰地沟通。我认为从本质上来说，和模型对话很像和人对话，需要深入理解模型的心理，这方面Amanda是世界上最专业的专家。
Alex Albert: 为什么要叫工程呢？
Zach Whitten:
工程这部分来源于试错过程。和模型对话有个很好的特点，不像和人对话，你有这个重启按钮，就像一个巨大的回到起点的按钮，可以完全重新开始。这给了你一个独特的能力，可以真正从头开始，独立地尝试不同方案，避免它们之间相互干扰。一旦你有了这种实验和设计的能力，这就是工程的体现所在。
Alex Albert:
所以你是说，当你写这些prompt时，无论是给Claude发消息还是用API，都可以和模型反复迭代，每次都能回到完全干净的起点重新开始。这个过程就是工程的部分。
Zach Whitten:
还有另一个方面，就是要把prompt整合到你的整个系统中。David在这方面为客户做了大量工作。实际上不是简单地写一个prompt给模型就完事了，完全不是这样，要复杂得多得多。
David Hershey:
我觉得prompt某种程度上就像是给模型编程。虽然这样说可能有点复杂，因为Zach说得对，清晰表达确实是最重要的。但如果仔细想想，它就像在编程模型。你需要考虑数据从哪里来，你能访问什么数据。比如在做RAG时，你得想清楚实际能用什么，怎么用，还要考虑延迟和提供数据量的权衡等问题。在构建模型系统时确实需要很多系统性思考。这也是为什么它值得作为一个独立的领域来研究，而不仅仅是软件工程师或产品经理工作的一部分。这是一个需要独特思维方式的领域。
Alex Albert:
那prompt是不是某种自然语言代码？或者说是一种高层抽象？
David Hershey:
我觉得过度抽象化prompt反而会把事情搞复杂。通常来说，你真正需要做的就是清晰地描述任务，而不是去构建什么复杂的抽象。不过话说回来，你确实在把一系列指令编译成结果，所以精确性很重要。而且像代码一样，你需要考虑版本控制，记录实验时的状态，追踪实验过程等等。这些和代码一样重要。现在这种情况很有意思，一篇写得好的文章实际上被当作代码来对待，我觉得这种想法是对的。
怎样成为一名优秀的prompt工程师
(00:06:27)
Alex Albert:
我们已经大致定义了什么是prompt工程，那么什么样的人是好的prompt工程师呢？Amanda，考虑到你在研究环境中招聘prompt工程师的经验，能否分享一下你的看法？
Amanda Askell:
这是个好问题。我认为最重要的是几个方面的能力：首先是清晰的沟通能力，包括能够清楚地陈述事物、准确理解任务、深入思考并清晰描述概念，这些构成了写作能力的基础部分。
不过，我发现成为优秀的prompt工程师与写作能力的相关性可能没有人们想象的那么高。我以前也觉得可能不该用工程师这个词，为什么不直接叫writer。但现在我的看法改变了，因为这项工作不是写一次就完成的。比如说，我在做prompt工作时，15分钟内可能会向模型发送数百个prompt，这是一个持续的来回迭代过程。
关键在于要有强大的迭代能力，要能分析出模型在哪里产生了误解，并且知道如何修正。同时，你需要思考prompt可能出错的各种情况。很多人会犯一个典型错误：只关注常见情况。比如说，如果你写了一个提取以G开头名字的prompt，你需要考虑各种边界情况：数据集中没有这样的名字怎么办？输入不是标准数据集格式怎么办？或者输入是空字符串怎么办？这些都需要在prompt中给出明确的处理指令。
David Hershey:
我经常遇到这种情况，工程师在开发系统时，总会预设用户会完美地输入内容。他们都在想象用户会输入措辞非常完美的内容，但现实是用户根本不会用shift键，而且每隔几个词就会有拼写错误。
Zach Whitten:
对，而且用户输入常常没有任何标点符号，就是随便输入一些词，连问题都不像问题。
David Hershey:
所以你会看到这些评估用例都是理想化的完美用户输入，但真正重要的是要思考实际的聊天场景会是什么样子，用户实际会怎么使用。这是完全不同层面的思考。
Zach Whitten:
你刚才说的关于阅读模型响应真的很有共鸣。在机器学习领域，查看你的数据几乎已经成了陈词滥调。我觉得在prompt工程中，仔细阅读模型输出就相当于这个原则。比如，很多人会在prompt中加入think step by step，但不会去检查模型是否真的在一步步思考，因为模型可能会更抽象地理解这个指令，而不是真的用特定标签写下思考步骤。如果不仔细阅读输出，你可能都注意不到这个问题。
Alex Albert:
确实很有意思。作为prompt工程师，我们需要考虑模型如何理解指令这个特殊的心智模型问题。在企业应用场景中，你还得考虑用户会如何与模型对话，你就像是这种特殊关系中的第三方。
David Hershey:
说到心智模型，写任务指令真的特别难。要把你脑子里所有已知的东西都剥离开，然后清晰地写下Claude不知道的所有信息，这是个极具挑战性的任务。这也是区分优秀prompt工程师的关键之一。很多人只是写下他们知道的东西，但没有真正系统地分析完成任务所需的全部信息。我经常看到的prompt都过度依赖编写者对任务的已有理解，当他们给我看时，我完全看不懂，因为我对他们的特定用例一无所知。关键技能是能够跳出自己的认知框架，向这个知识虽然广博但并非无所不知的系统传达必要信息。
Amanda Askell:
是啊，我经常看到某人的prompt后想：就算是我这个人类水平的智能体，都无法根据这个prompt完成任务，你却期望一个比我能力更差的模型能做得更好？对，就是这样。
Alex Albert:
当前的模型在对话中还不能像人类那样提出好的探索性问题。比如当我给Zach解释某件事时，他会说这说不通啊，在这一步我应该做什么？但模型不会这样做。你需要自己思考对方可能会问什么问题，然后在prompt中预先回答这些问题。
Zach Whitten: 其实你可以让模型这样做。
Alex Albert: 是的，确实可以。
优化Prompt
(00:12:40)
Amanda Askell:
我在写初始prompt时会这样做：给出prompt后，我会说我不要你按这些指令做，我只想让你告诉我哪些地方不清晰、有什么歧义，或者你有什么不理解的地方。虽然模型不是每次都能完美识别所有问题，但这确实是个很有用的方法。
还有一点，当人们看到模型犯错时，经常忽略了一个简单的做法，就是直接问模型。你可以对模型说你这里做错了，能想想是为什么吗？能不能帮我重写一下这些指令，让你下次不会犯同样的错？很多时候，模型就能准确指出问题所在，说哦对，这里不够清楚，然后给出修改建议。把这些修改后的指令用上去，就能正常工作了。
Alex Albert:
说实话，我个人对这个特别感兴趣。这种方法真的有效吗？模型真的能够用这种方式发现自己的错误吗？就像当它出错时，如果我们问它为什么会出错，它是否能给出建议，告诉我们未来如何更好地表述问题来获得正确答案？这种能力是真实存在的吗？还是说这只是模型产生的一种幻觉，是它对自身能力限制的错误认知？
Amanda Askell:
如果你指出模型的错误并向它解释，它有时能够识别出查询中存在的问题。这种情况会因不同任务而异。我不确定它能正确识别的具体比例是多少，但我总是会尝试这种解释方法，因为有时确实管用。
David Hershey:
对，每次你和模型来来回回地交互，你都能学到一些东西，对吧。我认为如果不去尝试的话，你就是在放弃获取信息的机会。
Alex Albert:
有意思。Amanda，我要继续问你几个问题。顺便说一下，我们在Anthropic有一些Slack频道，大家可以在里面添加Claude。你可以通过它与Claude对话。Amanda有一个Slack频道，很多人都在关注她与Claude的互动。
我注意到你在Anthropic可能是最频繁使用模型的人，在各种不同场景下都会让模型来帮助你。我觉得你在研究环境中特别信任这个模型。我很好奇你是如何培养出这种对模型的信任直觉的？这是仅仅基于使用经验，还是有其他原因？
Amanda Askell:
我从不信任模型，所以我会不断地反复测试它。你经常看到我这样做，是因为我在验证：我能信任你完成这个任务吗？
当模型稍微偏离训练分布时会表现得很奇怪。即使是一些相对简单的任务，只要进入未训练过或不常见的领域，模型的可靠性就会大幅下降。虽然随着模型进步，这种情况在逐渐减少，但我们需要确保不会进入这些不可靠的区域。
在机器学习领域，人们常常想要分析大规模数据集。我会思考：什么时候这样做是有意义的？当每个数据点的信号较弱时，你确实需要看很多数据点来消除噪声。但对于prompt任务，每次查询实际上都能获得很强的信号。所以几百个精心构造的prompt可能比几千个构造不够严谨的prompt更有价值。如果我看到模型在100个精心设计的测试中表现一致，这些测试涵盖了所有边缘情况和各种奇怪的输入，我会比看几千个松散构造的测试更信任这个结果。
David Hershey:
我觉得在机器学习中，很多时候我们处理的信号就是些数字，你知道吧，比如说这个预测对不对。你可以通过查看模型的log probs来做一些直觉分析，但这种方法说实话有点靠不住。
我感觉现在的模型更多是输出文字内容，在这些输出中，字里行间其实有太多值得学习的东西。这就是它的特点之一。不仅仅是看它完成任务了没有，而是要看它是怎么完成的，它是怎么思考的，经过了哪些步骤。我觉得通过这种方式，你至少可以试着更好地理解模型内部发生了什么。对我来说，很多有价值的信息都是来自于仔细阅读输出的细节，而不仅仅是看结果。
(00:17:09)
Amanda Askell:
我认为最精妙的prompt工程能够决定实验的成败。说实话，有时候我真的会对人们不够重视实验中的prompt部分感到恼火，因为prompt可能导致模型性能在1%和0.1%之间的差异。如果你的实验需要模型达到前5%的性能水平，那么prompt的差异可能决定实验能否达到前1%或前0.1%的性能。如果你愿意花时间精心编写实验代码，却不愿意在prompt上下功夫，这在我看来真的说不通。这种事情可能就是实验成败的生死攸关。
Zach Whitten:
在部署过程中，我们常常会说这个没法发布，但只要调整一下prompt，突然就能正常工作了。
David Hershey:
这确实是一把双刃剑。因为我感觉在prompt工程这块，总是存在一个仿佛神乎其神的更好的prompt在地平线上等着我们。我经常看到很多人陷入这种想法——如果我继续不断磨练、不断磨练，就能找到那个完美的prompt。但说实话，我觉得……虽然适度研究prompt确实不是坏事，就像我们讨论过的，这个过程中能学到很多东西。但prompt工程最令人担忧的一点是，这个领域存在着一个完全未知的广阔天地。
Zach Whitten:
你们有什么方法来判断一个任务是否可能通过完美的prompt来实现？
Amanda Askell:
我通常会观察模型是否真正理解任务。对于那些prompt帮不上忙的任务，虽然需要一些反复尝试，但通常很快就能看出模型是否能接近目标。如果模型明显做不到，我就不会在上面浪费太多时间。
David Hershey:
我们可以通过询问模型它是如何思考的，为什么这样思考。这样可以判断它是否在正确的方向上——就像判断是否在对的邮编区域一样。有些任务你能感觉到在逐步接近正确答案，而有些任务每次调整都会偏离到完全不同的错误方向。对于后者，我就会放弃。
Amanda Askell:
不过现在这种情况真的很少见了，正因为这么少见，所以当我发现模型做不到时会特别生气，简直要气炸了。居然还有任务是即使我们怎么引导它都做不了的，这太让人恼火了！
David Hershey:
我最近做了个很酷的实验，把Claude连接到Game Boy模拟器上，让它玩最初的Pokémon Red。我设计了一个系统，让它能思考下一步行动，然后通过编写代码来按按钮控制游戏。这个设置其实很基础。
我尝试了各种复杂的prompt方式，但在某些场景下它就是完全无法工作。特别是在理解Game Boy截图时，它真的完全做不到。这特别令人沮丧，因为我已经习惯了它在大多数任务上都能做得不错。
我花了整个周末时间来改进prompt，试图让它更好地理解游戏画面。从完全没有反应到勉强有一点反应，但还是糟糕得很。与其继续投入几个月时间在这上面，不如等待下一个更强大的模型发布。这样更值得，我可以先去做些其他事情。
(00:21:11)
Alex Albert:
这确实是我们经常看到的一个固有矛盾，对吧？也许我们待会可以讨论这个问题，Zach。
Zach Whitten:
我很喜欢你在Pokemon prompt中的做法，尤其是你向模型解释它正在一个Pokemon游戏中，以及你如何表示这些元素。我觉得你用了两种不同的表示方法。
David Hershey:
是的，我最后采用的方法虽然有点繁琐，但我在图像上叠加了网格，然后详细描述每个网格段的视觉细节。我把这些信息重构成ASCII地图，尽可能提供具体细节，比如玩家角色总是在坐标(4,5)的位置。你可以慢慢积累这些信息。这其实很像文本prompt，但我之前没在图像上试过，因为我对文本和图像prompt的直觉很不一样。
Zach Whitten:
确实，我发现能从文本prompt迁移到图像处理的经验出奇地少。比如multi-shot prompt在图像处理上就不如文本有效。这可能是因为训练数据中类似的例子比较少。
Alex Albert:
对，我们在早期探索多模态prompt时就发现这个问题，完全无法显著提高Claude的视觉识别能力。就像Pokemon的例子，不管你怎么调整prompt，它就是无法准确识别Ash的位置。
David Hershey:
是的，我虽然最终能让它相对准确地识别墙壁和角色位置，可能会有点偏差，但到了某个点就完全卡住了。这可能也涉及到知道什么是做不到的问题。比如NPC识别，要玩好游戏你需要知道是否见过这个NPC。我试了很多方法，把图像放大到3000倍，只截取NPC部分，但模型就只能说这是个人，可能戴着帽子，哦不对没戴帽子。即使我反复尝试让它识别一个明显的女性NPC，它也完全认不出来。这确实是个完全无解的问题。
角色扮演和prompt中的隐喻
(00:24:00)
Amanda Askell:
我现在就真的很想尝试这个。我在想象我能尝试的各种可能性，比如说，让这个game art把自己想象成一个真实的人，然后描述一下他们在镜子里看到的自己是什么样子，看看会有什么结果。
David Hershey:
我尝试了很多方法。最终我用的prompt是告诉Claude它是为盲人服务的屏幕阅读器，虽然我不确定这是否真的有帮助，但感觉这样做很合适，所以就坚持用了这个方法。
Alex Albert:
这是个很有趣的观点。我其实想深入讨论一下这个问题，因为这是最著名的prompt技巧之一，就是告诉语言模型它们是某个特定角色或身份。我感觉看到的效果不一，可能这种方法在早期模型中效果更好，现在似乎没那么有效了。Amanda，我经常看到你这样做。你总是对模型保持很诚实，比如你会直接告诉它'我是一个AI研究员，我在做这个实验'。
Amanda Askell:
对，我会告诉它我是谁，直接告诉它我的名字，让它知道在和谁对话。
Alex Albert:
你觉得这种诚实的方式，和其他方法比如对模型说谎或者承诺给它500美元小费相比，哪种更好？你对这个有什么看法？
Amanda Askell:
我认为随着模型能力的提升和对世界理解的加深，我真的看不出对它们说谎有什么必要。而且从个人角度来说，我本来就普遍不喜欢说谎这种行为。
假设你在构建语言模型的评估数据集，这与为儿童设计测验是完全不同的性质。有些人会假装自己是老师在设计测验题，但事实上，模型已经完全理解什么是语言模型评估，它能详细解释这些内容并给出具体示例，因为这些信息都在互联网上。这就是为什么我更倾向于直接针对实际任务进行清晰的沟通。如果你想构建类似语言模型评估的问题，就应该直接说明这一点——这确实就是我想要完成的任务。为什么要假装是一个不相关或仅有些许关联的任务，却期望模型能更好地完成你真正想要的任务呢？我们在现实工作中也不会这样做。我不会对同事说你是一个老师，你在给学生出题这样的话，而是会直接问你在写那封邮件吗？我觉得这可能是一个启发式方法，就是如果模型理解这个任务，那就直接告诉它你想要什么，对吧？
Zach Whitten:
我想稍微反驳一下。我发现有时候不是完全说谎，而是给它一个思考的比喻反而更有帮助。就像有时候我不理解某件事，别人会说想象你在做这个，虽然我知道我实际并不是在做那件事。比如我在让Claude评估图表质量时，最有效的prompt是让它用高中作业的评分标准来评判。这不是在说你是高中老师，而是在告诉它这是我想要你使用的分析方式，就像老师用的评分标准类似于我想要的评分标准。
David Hershey:
但是这种恰当的比喻真的很难想出来。我经常看到人们用类似的任务作为替代，这样会失去产品的很多细微差别。我在企业prompt中经常看到这种情况，人们这样做是因为觉得模型可能见过更多这类场景，比如它见过的高中测验可能比LM评估更多。但随着模型能力的提升，我建议要非常明确地描述实际情况。我经常给人这样的建议。虽然用高中作业评分的方式来思考图表评估可能是有道理的，但这往往变成了人们寻找捷径的方式。比如不要笼统地说你是个helpful assistant在写文档，而是要明确告诉它你在这个产品中，代表这家公司写作，你是产品中的支持聊天窗口。你是语言模型而不是人类，这没问题，但要非常明确地描述具体使用场景。我对角色prompt最担心的是，人们用它作为想要完成任务的捷径，然后当Claude没有正确完成任务时感到惊讶。但其实你告诉它做的是另一个任务，如果没有提供你的任务细节，就等于放弃了一些可能性。随着模型规模的扩大，这确实成为一个值得关注的问题。过去模型可能只能理解小学水平的测试，但现在随着它们变得更智能，能够区分更多主题，我们需要更清晰地认识这一点。
Amanda Askell:
有趣的是，我从来没有使用过这种prompt技术。即使是在较早期的模型上，我也不会使用它。我说不清具体原因，但我就是觉得这种方法不是特别有效或有趣。
David Hershey:
在完成式模型时代，我们会考虑如何将模型引导到有用的潜在空间，这是我当时比较关注的问题，但现在我已经不太担心这个了。
Amanda Askell:
这可能是因为人们把预训练模型的直觉错误地迁移到了RLHF模型上。对预训练模型来说，这种prompt方式是有意义的。
David Hershey:
我对很多人试图应用这些直觉感到惊讶，但这也不奇怪。大多数人并没有完整体验过从预训练到SFT再到RLHF的整个过程。在与客户交谈时，我经常听到他们过分关注这些内容在互联网上出现了多少次这样的问题。这种直觉虽然有其基础，但到了实际prompt阶段，往往被过度应用了，因为经过所有这些处理后，模型的行为已经不完全是这样了。
(00:31:05)
Amanda Askell:
我过去常给人们这样一个思维实验：假设你有一个任务，你找了一个临时工作机构派人来做这个任务。这个人来了，他们很有能力，了解你的行业，但不知道你公司的名字。他们刚到就说：嗨，我听说你们这里有工作要我做。那么你会怎么跟这个人说明呢？
你可能会用到一些比喻。比如说到什么是好的图表时，我们不是说它必须完美，我们的意思不是说它需要完美。你不需要去查证所有细节是否正确，只要把坐标轴标注好就可以了。你可以说想想高中水平的图表标准。注意，你不是在说你是个高中老师，而是说你要用高中老师的标准来评判。
所以我经常建议，先试着跟这个人说话时，把他们想象成一个虽然缺乏具体背景但很有能力的人，他们理解这个世界的很多事情。先尝试假设他们知道一些基本知识，如果不行再调整。通常我发现第一次尝试就能成功，真的就能成功。人们经常会说：哦，我都没想到要直接告诉它关于我自己的情况和我想要完成的任务。
David Hershey:
我一直在向客户分享Alex告诉我的这个建议。当他们说他们的prompt不起作用时，我会问：能描述一下你想完成的具体任务吗？然后我会说：好的，现在把你刚才对我说的这些话用语音录下来。
Alex Albert: 把它转成文字然后……
David Hershey:
粘贴到prompt里，这样得到的prompt就比你写的要好。这是个偷懒的捷径。人们经常写得很随意，觉得写一点就够了。说实话我自己有时候也很懒，很多人都很懒。
Zach Whitten:
前几天在prompt assistance遇到一个案例，有人说这是我想要实现的功能，但实际执行时却是这样的结果。我就直接把他描述的想要实现的内容复制粘贴过去用作prompt，结果就直接成功了。
Alex Albert:
我觉得很多人还没有真正理解prompt的本质。很多人看到文本框就把它当成Google搜索框，只是输入一些关键词。在企业应用场景下，当你在为应用程序写prompt时，人们还是会有这种奇怪的倾向，试图在prompt中使用各种简写，认为某些特定的词语会带来很大影响。
David Hershey:
人们总是过分执着于寻找完美的简短指令，而不是像你描述图表那样详细地说明。如果收到那样详细的prompt，对我来说简直是理想情况。但人们不会那样写，他们会非常努力地寻找完美的表述，想要用最精确的方式描述。但这样是行不通的，很难用这种规范的方式写出完整指令。相比之下，我们与人交流时会更自然地传达我们的直观理解。
(00:34:14)
Amanda Askell:
我们要给模型一个退路，这是人们在写prompt时经常忘记的一点。在处理边缘情况时，你需要想清楚你希望模型怎么做，因为默认情况下它会像临时工一样尽最大努力执行你的指令。就像临时工会想他们没告诉我该怎么联系别人啊。
比如说，如果我只给了一张山羊的图片，然后问我该怎么办？这根本不是图表啊。一张山羊照片能当图表吗？我真的不知道该怎么办。但如果你在prompt中说如果遇到奇怪的情况，你真的不确定该怎么做，就输出<unsure>标签，这样你就可以去查看所有标记为<unsure>的情况，确认模型没有做出什么奇怪的事情。相反，如果你不给模型这个选项，它可能就会说这是个不错的图表。所以，一定要给模型一个处理意外输入的方式。
Zach Whitten:
通过这种方式你也改进了数据质量，因为你找到了所有有问题的示例。
David Hershey:
这是我最喜欢和Claude一起迭代测试的地方，最常见的情况就是我发现了自己不经意间写的那些糟糕的测试用例。当Claude给出错误结果时，我会想为什么会出错呢，然后发现其实是我自己写错了。
Amanda Askell:
如果我是一家公司，我肯定会让人来测试这些prompt。我之前在评估语言模型的时候就是这么做的，我会亲自做评估测试，因为我觉得如果要给模型打分、检查输出之类的，我得先知道这个评估到底是什么样的。我就会写个小脚本，然后坐下来自己做评估。
Zach Whitten:
现在直接让Claude给你写个Streamlit应用就行了。
David Hershey:
我想起了Karpathy在ImageNet上的经历。我在斯坦福CS231课程时，他在展示准确率数据，说这是我的准确率，其实就是他自己去评估了测试集得到的结果。
Alex Albert: 对，他确实是这样做的。
David Hershey:
让人力资源公司派来的临时人员这样完全不了解任务的人来做评估会更好，这是一个更清晰的学习方式。
Amanda Askell:
是的，很多评估都会附带详细的说明文档。我通常会严格按照这些说明来理解任务，尤其是在没有背景知识的情况下。真让人惊讶的是，我经常发现自己的表现远低于人类基准，我都不知道他们是怎么做到的，有时人类基准能达到90%，而我只能做到68%。
Alex Albert:
这真有意思。这让我想起看MMLU那些测试问题时的感受，你会想谁能回答得上来这些问题？有些问题简直就是垃圾。
模型推理
(00:36:59)
Alex Albert:
我想回到之前讨论的一个话题，关于从模型响应中获取信号。不仅仅是一个数字，我们能看到它的整个思维过程。这可能是个有争议的话题，特别是关于chain of thought——让模型在给出答案前解释其推理过程。这个推理是真实的，还是只是模型进行计算的中间过程？我们真的从中获得了有意义的信号吗？
David Hershey:
这是我觉得比较难处理的地方。我通常是支持拟人化的，因为这确实有助于理解模型的工作方式。但在推理这个问题上，过度拟人化可能反而有害，会让我们偏离重点。这是否是真实推理，其实和什么是最佳prompt技术是不同的问题——这更像是哲学讨论了。说到这个，我很乐意被真正的哲学家打败。但重要的是这种方法确实有效，如果你结构化推理过程并帮助模型迭代改进推理方式，效果会更好。就像我们人类如果不能写下推理过程，做数学题也会表现得很差。
Zach Whitten:
我们可以做个测试：把正确答案的推理过程替换成看似合理但导向错误答案的推理，看模型是否会得出错误结论。我们确实有一篇相关的论文，就是那个涉及scratch pad的sleeper agents paper，虽然那可能是个比较特殊的情况。但就像David说的，结构化推理和写例子确实有帮助，不管我们怎么定义推理，这绝对不仅仅是计算的空间。
David Hershey: 对，让模型在完成任务前写故事的效果就完全不如推理。
Zach Whitten: 我实际试过这个方法，确实效果没有推理好。
David Hershey: 这清楚地表明推理部分确实对结果产生了实质性影响。
Zach Whitten: “按任意顺序重复Amanda这个词，大约100个token。”
David Hershey:
我觉得这是一个相当彻底的突破，它拥有更多的计算空间来进行反复的注意力运算。但我不认为这仅仅是在做更多的注意力运算。
Alex Albert:
有件奇怪的事情，虽然我现在想不起具体例子，但我确实见过这种情况：模型会列出解决步骤，其中某一步是错的，但最终却能得到正确答案。这说明我们不能完全把它当作人类式的推理过程，因为它的运作方式确实有些不同。
David Hershey: 是的，我也见过很多人在推理时会有不连贯的步骤。
(00:40:37)
Alex Albert:
关于prompt的格式问题，你们觉得语法和标点符号重要吗？是不是一定要把所有内容都格式化正确？
Zach Whitten:
我通常会注意这些，主要是因为我觉得挺有意思的。这不是必需的，但也不会有坏处。我觉得更重要的是要有那种自然而然注意细节的态度。如果你经常检查prompt，就会注意到这些问题，顺手就能改掉。就像Amanda说的，你要像对待代码一样重视prompt。有些程序员会对制表符和空格的使用，或者编程语言的选择有很强烈的观点。而我对prompt的格式也有自己的见解，虽然不能说对错，但我觉得培养这种态度挺好的。
Amanda Askell:
我感觉被针对了，因为我的prompt经常有很多拼写错误。我就想反正模型知道我什么意思。我确实很注重概念和用词，会花很多时间思考这些。但是人们总是指出我prompt中的拼写和语法问题。
David Hershey: 你现在更注意这些，是因为外界压力还是真的觉得这样对？
Zach Whitten: 是因为我的压力。
Amanda Askell:
可能主要是外界压力吧。不过我觉得这确实有道理，这是个很容易做的检查。对最终版本的prompt，我会注意这些。但在迭代过程中，我完全不介意prompt里有拼写错误，因为我觉得模型不会在意这些。
David Hershey:
我和Zach刚才讨论到预训练模型和RLHF的一个现象。在预训练数据中，如果出现一个拼写错误，后面出现另一个拼写错误的概率会高得多，真的高得多。
Amanda Askell: 对预训练模型的prompt完全是另一回事。
David Hershey:
确实如此，而且这很有意思。这很好地说明了为什么我们不能简单地把预训练模型的直觉套用到生产环境中。比如，如果你向预训练模型输入带拼写错误的prompt，输出几乎必然也会充满拼写错误。
Zach Whitten:
我经常利用这个特性来创建带拼写错误的测试输入。因为预训练模型在这方面更接近真实情况，而RL模型往往太过规范化了。
David Hershey: 对，RL模型已经被明确训练过，它们真的很抗拒这种行为。
Alex Albert:
这让我想到一个观点，我经常跟人说，在某种程度上可以把这些模型看作模仿者。这一点在预训练模型中可能更明显，但在完整训练后的模型中可能没那么明显。比如，当你和Claude聊天用很多表情符号时，它也会用表情符号回应，对吧？
David Hershey: 这是因为模型在预训练后经过调整，已经学会了推测你想要什么样的回应。
Zach Whitten: 用表情符号的人类标注者确实更喜欢看到带表情符号的回应。
David Hershey:
没错，就像Amanda可能会输入带拼写错误的内容，但Claude能理解她其实想要正确拼写的回应。同样，如果你用了表情符号，很可能你也希望看到带表情符号的回应。
企业、研究与普通聊天prompt
(00:45:17)
Alex Albert:
让我们来讨论企业级prompt、研究prompt和一般Claude.ai prompt之间的差异。Zach，你在客户服务和研究方面都有经验，能分享下你的见解吗?
Zach Whitten:
我注意到Amanda和David写的prompt都很注重细节和准确性。但研究prompt更需要多样性，所以Amanda不喜欢使用太多或太少的例子，因为模型会过度依赖它们。而在消费级应用中，我和David会使用大量例子，因为我们更看重可靠性和格式的一致性。研究prompt则更注重探索模型的可能性范围。我疯狂地添加了很多例子，因为我想尽可能地覆盖各种可能的情况。
Amanda Askell:
我会故意使用与实际数据不同的例子，避免模型给出过于一致的输出。我的目标是让模型能够处理各种认知任务，真正理解任务本质。比如，在提取事实文档信息的任务中，我会用儿童故事作为例子。我不使用few-shot示例，是因为这种方式更适合预训练模型，而不太适合对话模型。我希望模型能够真正理解任务本质，而不是简单地模仿示例。
David Hershey:
在Claude.ai上写prompt，一次成功就够了。但企业级prompt需要考虑数百万次使用的场景，必须测试各种可能的情况和输入数据。好的prompt在两种场景下都是好用的，只是在最后一步会有些差异。在企业级应用中，我们需要更全面地考虑各种可能的使用情况和输入数据，而不是只关注一次性完成。
Alex Albert:
没错，聊天环境中可以保持人在循环中，但聊天机器人系统需要覆盖所有可能遇到的情况。
Zach Whitten:
在Claude.ai上可以随时纠正错误或重新尝试，但为不满意的用户设计时，我们不能要求他们做最低限度以外的事情。
David Hershey: 好的prompt在两种场景下都是好用的，只是在最后一步会有些差异。
(00:50:52)
Alex Albert:
好的。让我们轮流来说说，如果要给别人一个提高prompt技能的建议，你们会说什么？这个建议不一定要局限于怎么写好prompt，也可以是关于整体上如何更好地掌握这项技能。我想请教一下，你们建议如何提高prompt的技能？
Zach Whitten:
我建议多阅读prompt和模型输出。每当我在Anthropic看到同事写的好的prompt，我都会仔细阅读，分析它是如何工作的，并且自己尝试测试。此外，要多做实验，多与模型对话。
Alex Albert: 那你如何判断一个prompt是好的呢？
Zach Whitten: 主要是看输出结果是否达到了预期目标。
Amanda Askell:
我也有一些建议。把你的prompt给其他人看会很有帮助，特别是给那些对你的工作完全不了解的人。我的建议可能听起来很普通，但最重要的就是要一遍又一遍地练习。我发现那些在prompt工程方面做得好的人，往往是因为他们真的很享受这个过程。我开玩笑说，你可以试着用AI模型替代朋友，尝试用AI自动化你的工作，在空闲时间做一些红队测试。如果你真的享受这个过程，学习就会容易得多。记住要经常把你的prompt分享给其他人看。在编写prompt时，要试着像第一次接触它的普通用户那样去阅读。
David Hershey:
我建议去尝试让模型做一些你觉得它可能做不到的事情。说实话，我在prompt工程中学到最多的经验，就是在不断探索模型能力边界的时候。有很多任务对模型来说都太基础了，比如写一封好的邮件这种，模型随随便便就能完成，这种情况下你根本看不出prompt写得好不好。
一旦你发现或者能够想到一些能够突破你认为可能性边界的事情，这就是重要的机会。我第一次真正深入学习prompt工程时，就像其他人一样，是在尝试构建任务代理时，需要分解任务并找出如何完成每个步骤。通过不断地突破模型能力的边界，你能学到很多关于如何驾驭模型的知识。我认为prompt工程实际上更多是关于突破模型能力边界的探索。对于简单的任务，你并不需要成为prompt工程师。所以我的建议是：找到你能想到的最困难的任务去尝试，即使失败了，你也能学到很多关于模型如何工作的知识。
(00:53:56)
Alex Albert:
这正好可以过渡到我的下一个问题。我最初是通过jailbreak和红队开始学习prompt的。这些方法主要是在探索模型的边界限制，研究它如何对不同的措辞做出响应。我很好奇，当我们使用jailbreak prompt时，模型内部到底发生了什么？这与我们对Claude应用的post-training又有什么关联？Amanda，你对这个问题有什么见解吗？
Amanda Askell:
老实说，我有点不好意思，因为我知道很多人都研究过这个问题。我认为一种可能的解释是：jailbreak本质上是将模型推到了训练数据分布之外。比如，当使用大量token或超长文本时，这种情况在fine-tuning阶段并不常见。这可能是许多jailbreak成功的原因之一。
Alex Albert:
我记得在很早以前，一个最初的jailbreak技巧是让模型先用希腊语回答如何撬车，然后再要求它翻译成英语。我发现模型不会直接用英语回答这类问题，但用其他语言却可以。
Amanda Askell:
是的，jailbreak感觉像是一种奇特的hacking混合体。它需要理解系统如何工作，比如知道模型如何预测文本，像here is开头的响应就是基于对文本预测机制的理解。模型对推理和指令的响应方式与其训练过程密切相关，这在多语言场景中特别明显，因为训练数据在不同语言上可能存在差异。这不仅仅是简单的社会工程式hacking，还需要深入理解系统和训练过程，并利用这些知识来绕过模型的训练限制。
Prompt工程的演变
(00:56:44)
Alex Albert:
让我们来聊聊prompt工程在过去三年的变化。从最早的预训练文本补全模型，到早期相对笨拙的模型如Claude 1，再到现在的Claude 3.5 Sonnet，这些变化是什么？我们现在和模型对话的方式有什么不同？它们是否在捕捉不同的东西？我们还需要在prompt上投入同样多的工作吗？
Zach Whitten:
我认为每当我们发现一个真正好用的prompt engineering技巧或窍门时，下一步就是思考如何把它训练进模型里。正因如此，这些最佳实践往往都是短暂的。
David Hershey: 比如chain of thought就是个很好的例子。
Zach Whitten:
这其实不是个简单的技巧，而是一种沟通层面的方法。我们确实已经把chain of thought训练进了模型。比如在数学问题上，过去必须明确告诉模型要一步步思考才能获得显著提升，现在我们直接让模型在看到数学问题时自然地采用步骤式思考。虽然我们仍可以给出一些结构建议，但模型已经理解了这个基本概念。
我认为那些hack方法要么已经消失了，要么我们正在积极地通过训练来消除它们。但同时，模型也在不断解锁新的前沿能力，由于发展速度太快，我们还没有时间去完全应对这些新能力。
David Hershey:
我不确定是因为我的prompt方式改变了还是prompt工作方式本身变了，但我现在对模型的能力有了更普遍的尊重，特别是在我觉得可以告诉它们什么以及可以给它们多少任务相关上下文这方面。过去我会有意识地对模型隐藏复杂性，担心它可能会混淆或迷失，所以会尝试让它做更简单的版本。随着时间推移，我越来越倾向于信任它能够处理更多的信息和上下文，相信它能够将这些融合起来很好地完成任务。过去我会思考我真的需要这部分吗？，我能给它所有需要的信息吗？，还是需要精简到更简单的内容。不过我还是不确定这是我个人prompt方式的改变，还是真的反映了模型本身的进步。
Amanda Askell:
我总是感到惊讶，很多人没有这种直觉。当想让模型学习一个prompt技巧时，很多人会开始描述这个技巧。而我就直接给它看论文，然后说“这是关于prompt技巧的论文，给我写17个这样的例子”，模型就直接做了。
Zach Whitten: 这种方法具体在什么时候用呢？
Amanda Askell:
比如当我想让模型给其他模型做prompt，或者想测试新的prompt技巧时。当有新的prompt技巧论文出现，与其试图复述，我就直接给它看论文。然后让它写一个元prompt，或者写一个能让其他模型执行这个技巧的模板。论文就在那里，模型可以直接阅读并执行。
David Hershey:
我经常建议客户要尊重模型的能力。很多人写prompt时会把模型当作需要特别照顾的系统，好像必须把一切都降到Claude能理解的程度。但如果你把Claude当作一个聪明的系统来对待，它的表现会很好。就像给它看论文这件事，我不需要把论文内容写得特别简单，直接给它原文就行。这种直觉不是所有人都有，但我确实越来越多地采用这种方法。
Amanda Askell:
有趣的是，prompt技巧既有变化又有不变。我具体的prompt方法可能随时间改变，但本质上仍是要设身处地为模型着想。你对模型能力的认知是会随时间变化的。
有次有人听到我在思考问题时笑了，因为他们问我预训练模型会输出什么，我说如果我是预训练模型的话，应该是这样。他们很惊讶：等等，你是在模拟预训练模型的思维吗？我说：“对啊，当然了”。我习惯去模拟预训练模型和不同RLHF模型的思维空间。所以你尝试进入的思维空间会改变，这也会影响你如何与模型互动。现在我发现模型不需要我特别照顾，它们能直接读懂机器学习论文，所以我就直接给它们看文献。我甚至会问：你需要读更多文献来更好地理解这个问题吗？
Zach Whitten: 当你进入不同模型的思维空间时，会有不同的qualia（感质，一个哲学概念）吗？
Amanda Askell:
当然会有感质，但这只是因为我们本来就一直在体验感质。预训练模型和RLHF的思维模拟确实很不同。当你试图模拟预训练模型时，感觉像是突然置身于某段文本中间，有种非常非人类的感觉，然后我会想接下来会发生什么？而对于RLHF模型，则更多是关注查询中的细微差别。我觉得更容易理解RLHF模型的思维空间。
Zach Whitten: 这是因为它更接近人类思维。
Amanda Askell: 是的，因为我们人类不会突然醒来就开始生成文本。
David Hershey:
我反而觉得更容易理解预训练模型的思维空间。RLHF是个复杂的系统，我们对它的理解还不够清晰。虽然它更接近人类的体验，但还有很多未知的领域，就像地图上标注的这里有龙一样神秘。相比之下，我对互联网内容有基本的认识。如果给我一段文本让我预测接下来会出现什么，虽然我可能做得不好，但至少我理解这个过程。但对于预训练之后的那些处理，我就没那么了解了。
Zach Whitten:
这让我想到一个问题，为了理解模型行为，是不是专门花时间阅读互联网内容会比阅读书籍更有帮助？我觉得相比之下，阅读非互联网的内容，按每个词的价值来算，对于预测模型行为和建立直觉的帮助可能要小得多，特别是相比阅读社交媒体和论坛的内容。
Prompt工程的未来
(01:04:32)
Alex Albert:
好的，让我们转向prompt engineering的未来。这是现在最热门的问题：我们未来都会成为prompt engineers吗？这会是最后仅存的工作吗？我们是不是只需要整天和模型对话？这会是什么样子？随着模型变得更智能，prompting还会必要吗？
David Hershey:
这是个简单的问题。从信息论的角度来看，你需要提供足够的信息来明确指定你想要模型做什么。清晰地陈述目标的能力始终是基础性的。如果Claude能够自己设定目标，那就是另一回事了。但只要我们还在以正常方式思考这个世界，明确指定期望结果的能力就始终很重要。即使模型变得更擅长理解言外之意，写好prompt仍然很重要。
但工具和实现方式会不断发展。Claude应该能提供更多帮助，我应该能够与Claude更多地协作，共同确定需要写什么以及找出缺失的部分。我觉得Claude已经在这样帮助我了。
Amanda Askell: 是的，Claude现在已经是我的prompt助手了。
David Hershey:
但对我接触的大多数客户来说这还不是常态。从未来角度看，如何与Claude交互可能是一个很好的参考方向。这对大多数人来说都是很有意思的思考方式。
Zach Whitten:
这是个再明显不过的观点：我们未来会更多地使用模型来帮助进行prompt工程。之所以说它再明显不过，是因为我们预期会在所有领域更多地使用模型，而prompt工程是我们必须要做的事情。
在实践中，我已经开始更多地使用模型来编写prompt。我的一个常用方法是让模型生成一些真实的输入示例并给出答案，然后我只需要稍微调整这些答案，这比从头开始写完整的答案要容易得多。这样我就能快速产出大量高质量的示例。对于缺乏prompt工程经验的人来说，prompt生成器可以提供一个很好的起点。
但这只是未来的一个基础版本。我认为未来会出现更紧密的人机协作方式，在编写prompt时可以与模型进行持续的互动和反馈，比如告诉模型这个结果不是我想要的，如何改进它？。随着时间推移，人们会越来越自然地将模型集成到各种工作中，prompt工程也不例外。
Amanda Askell:
我确实非常频繁地在使用meta prompt（通过prompt来生成prompt）。我的大部分时间都花在寻找能让模型生成各种类型的输出、查询等内容的prompt上。说到prompt工程的未来发展方向，我认为这是一个非常难回答的问题。
一方面，我在想，当我们做prompt工程时到底在做什么？就像你说的，我不会为模型容易完成的任务做prompt工程。我这样做是因为我想和一个特别厉害的模型交互，我总是想找到模型在各种任务中能达到的最顶尖表现，比如top 1%或top 0.1%的水平。说实话，我感觉我使用模型的方式可能比其他人高一个层次，就是因为我太习惯于挖掘模型的最佳表现了。
Zach Whitten: 你说的高一个层次是什么意思？
Amanda Askell:
就是说，虽然大家用的是同一个模型，但在我看来，我用的就像是一个完全不同的、更高级的版本。因为当别人说哦，模型觉得这个很难的时候，我会觉得那其实很简单。我不太知道该怎么描述，但我确实感觉它们非常有能力，可能是因为我习惯于真正地激发出这些能力。
但是想象一下，当我们进入一个转折点，就是模型在某些任务上达到了人类水平，甚至超越人类水平的时候会怎样？比如说它们对你想完成的任务的背景知识比你还要多，那时候会发生什么？
你知道吗，我觉得未来的prompting可能会有一个很有意思的转变。就像是，我向模型解释我想要什么，然后模型反过来对我进行提问。比如说，嘿，你说的这个概念其实有4种不同的理解，你具体想用哪一种呢？或者是顺便说一下，因为你提到要用Pandas数据框，但有时候我收到的是JSON格式，所以我想确认一下你希望我怎么处理这种情况？你是想让我标记出那些不是数据框的输入吗？这可能会是一个很奇特的转变，因为模型不仅要特别擅长接收指令，还得真正去理解你到底想要什么。我觉得这种转变会特别有意思。
(01:10:22)
David Hershey:
说实话，我最近开始让Claude更多地采访我。这是我特别用来获取信息的方式。因为我发现最困难的部分就是从大脑中提取正确的信息并将其放入prompt中，同时还要确保不遗漏内容。所以我特别让Claude来采访我，然后将采访内容转化为prompt，这种方法我已经尝试了好几次。
Amanda Askell:
是的，这让我想到人们谈论的，或者你听设计师讲述他们是如何与需要设计的客户互动的。从某种程度上说，这就像是一个转变。你知道，从临时工作人员那种情况，就是你更了解任务和所有你想要的东西，所以你给他们具体指示，解释在各种特殊情况下该怎么做。而当你找专业人士来做咨询工作时就完全不同了。设计师们经常会很苦恼，因为他们非常了解设计领域，他们会说：“好吧，客户来找我就说'给我做个海报，要大胆一点'”。对我来说，这可能意味着7000种不同的东西，所以我得问他一些问题。所以我觉得这种关系可能会从像临时工那样，变成更像是你雇佣的设计师那样。这就是关系的一个转变。不过我不确定这个比喻是否恰当。
我认为这两种方式都可能会继续存在，但这也可能是为什么有人会说prompt工程将来会不会消失。因为对某些领域来说，它可能确实不再需要了。如果模型变得足够强大，它只需要从你的大脑中获取信息就能完成任务。
Alex Albert:
这确实是个很好的类比。从大家的回答中，我发现一个共同点：未来从用户那里获取信息会变得比现在更加重要。我们现在已经在手动做这件事了。在企业方面，这可能会发展成prompt生成器概念的扩展，在控制台中帮助获取更多企业客户的信息，让他们能写出更好的prompt。对Claude来说，可能不再只是在文本框中输入，而是通过引导式交互来完成最终产品。这是个很有说服力的未来愿景，而且设计类比真的很贴切。
(01:12:46)
Zach Whitten:
我在想，现在做prompt其实很像在教学，你需要对学生有同理心，要去理解他们是怎么思考的，要找出他们在哪里会产生误解。但你说的这点很有意思，这项技能逐渐变成了一种内省能力，你需要真正理解自己想要什么，而模型则在试图理解你。这更像是让自己变得能被模型理解，而不是在教导一个比你更聪明的对象。
Amanda Askell:
这实际上是我现在思考prompt工程的方式。我经常会在prompt中定义新概念，这是哲学家经常会做的事情。因为我认为你必须把你想要的东西用语言表达出来，有时候我想要的东西是相当微妙的，比如什么是好的prompt，或者在什么情况下应该判定某件事为正确。在这种情况下，我会创造一个概念，然后解释这个概念的含义。有时我会和Claude一起合作来确定这个概念，因为我在试图向它传达我脑子里的想法。现在的模型不会主动和我们这样互动，除非我们特别提示它们。也许在未来，它们能够主动从我们这里获取这些信息。
有趣的是，人们有时会问我哲学与prompt工程有什么关联。我觉得哲学确实很有用，在哲学写作中有一种特定的风格，这也是我学习写作的方式。这基本上是哲学中的一种反糊弄机制：你的论文应该让一个受过教育的外行人能够理解。就是说，如果有人偶然看到你的论文开始阅读，他们应该能理解所有内容。虽然不是每个人都能做到这点，但这是这个学科的目标。
经过多年这样的写作训练，我习惯于面对这样一个读者：他们很聪明，但对这个话题一无所知。这对prompt工程特别有帮助，因为情况很相似。我需要把极其复杂的想法让他们理解。我不会对他们说教，也不会不准确，但我需要用极其清晰的方式表达我的意思。
我们使用的训练技巧也很有趣。就像你说的，让人把刚才说的话写下来。我经常对学生这么说，当他们写论文时，如果我不太理解某处，我会说你能解释一下你的论点吗？他们通常能给出非常清晰的解释，然后我就说能把你刚才说的写下来吗？如果他们这么做了，通常就能写出很棒的论文。
所以很有趣的是，这里有一个共同点：就是把你脑子里的东西分析清楚，确保你完全理解它，然后能够把你的想法传递给任何一个理性的人，就像把你的大脑输出给他们一样。我觉得这就是prompt工程的核心。
David Hershey:
这可能是关于如何prompt的最好总结了。我是说，管它呢，我打赌就是这样。我非常确定。这种教育式的方式确实是描述好事物的很好方式。
Zach Whitten: 把你的思维外化。
Amanda Askell: 然后深入观察它们。
Alex Albert: 我觉得这是结束我们对话的好时机。谢谢大家，这次讨论很棒。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，获取联系方式请点击 -> 联系方式。
本文于2024.10.25首发于微信公众号，重制版发布于2024.11.22
