深入探讨Al prompt engineering: A deep dive

深入探讨Al prompt engineering: A deep dive 深入探讨Al prompt engineering: A deep dive Modified November 26, 2025 https://www.youtube.com/watch?v=T9aRN5JkmL8 Amanda： 人们经常忘记在提示中给模型留有余地。例如，在遇到边缘情况时，模型会尽力遵循你的指示，但如果你没有告诉它该怎么做，它可能会给出错误的答案。你可以告诉模型“如果发生了一些奇怪的事情，你不确定该怎么做，就在标签中输出‘不确定’”。这样可以帮助你发现模型没有处理好的情况，提高数据质量。 Amanda： 我会把提示给其他人看，就像我自己做评估一样。 David： Karpathy 也会自己做 ImageNet 测试集。 如何从模型的回复中获取有效信息 (36:46 40:46) Alex： 如何从模型的回复中获取有效信息？这不仅仅是一个数字，你可以从中了解模型的思考过程。这是否适用于思维链？ David： 我认为过分强调“推理”的人格化比喻是有害的。重要的是，思维链确实有效，可以提高模型性能。结构化的推理可以进一步提升效果。 Amanda： 如果去掉模型得出正确答案的推理过程，换成看似合理但导向错误答案的推理，看看模型是否会得出错误的结论。 Zack： 让模型在完成任务前写一个故事，效果不如思维链好。 Alex： 这说明推理过程确实对结果产生了影响。 Amanda： 我见过推理步骤不一致但最终得出正确答案的情况。 关于提示中是否需要注意语法和标点符号 (40:47 45:19) Alex： 提示中是否需要注意语法和标点符号？ Zack： 我会注意这些细节，因为这很有趣，但这并不是必须的。重要的是，你应该具备这种关注细节的态度。 Amanda： 我的提示中经常会出现拼写错误，但我更关注概念的清晰表达。 David： 这与预训练模型和 RLHF 模型有关。预训练模型中，拼写错误的条件概率更高。将预训练模型的直觉应用于生产环境中的模型并不总是有效。 Alex： 与模型对话在一定程度上可以看作是一种模仿。 David： 模型会根据你的输入调整其行为。 企业提示、研究提示和普通聊天的区别 (45:20 50:53) Alex： 企业提示、研究提示和普通聊天的区别是什么？ Zack： 研究型提示更注重多样性和探索模型的可能性，因此示例较少或没有，以避免模型过度依赖示例。而企业级提示更注重可靠性和格式一致性，因此会使用大量示例。 Amanda： 我使用的示例通常与模型将要处理的数据不同，目的是为了说明概念，而不是让模型死记硬背。对于认知任务，我希望模型能够真正理解每个样本中的正确答案。 David： 在 Claude.ai 上，我只需要让模型正确完成一次任务即可。但在企业应用中，提示需要能够应对各种情况和输入数据。 提升提示工程技能的建议 (50:54 53:57) Alex： 提升提示工程技能的建议？ Zack： 阅读优秀的提示和模型输出，分析其原理并进行实验，多与模型对话。 Amanda： 将你的提示给其他人看，特别是那些不了解你工作的人。不断练习，并以“初学者”的视角审视自己的提示。 David： 尝试让模型做一些你认为它做不到的事情。 关于越狱 (53:58 56:54) Alex： 当人们编写越狱提示时，模型内部发生了什么？ Amanda： 一种可能是越狱提示使模型偏离了训练数据的分布。 Zack： 越狱有时像是黑客攻击和社会工程的结合。 提示工程的演变 (56:55 64:33) Alex： 过去三年里，提示工程发生了怎样的变化？ Zack： 我们会将有效的提示工程技巧融入到模型训练中，因此最好的技巧通常是短暂的。 David： 我逐渐学会了尊重模型的能力，给予它们更多的信息和上下文。 Amanda： 我会把论文直接给模型，让它自己学习提示技巧。 David： 人们经常会低估模型的能力，试图将问题简化到“Claude 的水平”。 Amanda： 我会尝试进入模型的“思维空间”，这会影响我编写提示的方式。 Zack： 我更容易进入预训练模型的思维空间。 Amanda： 阅读互联网上的内容可能比读书更有助于理解模型。 提示工程的未来 (64:34 结束) Alex： 提示工程的未来是什么？我们都会成为提示工程师吗？ David： 指定模型的目标始终是必要的，清晰地表达目标很重要。工具和方法会不断发展，模型可以帮助我们更好地编写提示。 Zack： 我们将更多地使用模型来辅助提示工程，例如生成示例。 Amanda： 我目前主要编写元提示，让模型生成我想要的输出。未来，模型可能会像设计师一样，与我们进行交互，引导我们说出真正的需求。 David： 我会让 Claude 对我进行“采访”，以提取信息。 Amanda： 现在，我们需要将头脑中的概念传达给模型，未来，模型可能会主动引导我们说出这些概念。哲学训练有助于我清晰地表达复杂概念。 Alex： 从用户那里提取信息将变得更加重要。 Zack： 提示工程就像教学，需要“共情”学生。而未来，我们需要“自省”，让模型理解我们。 Amanda： 我经常定义新概念，以清晰地表达我的想法。 Alex： Amanda 的总结非常到位：将你的思想外化给一个受过教育的外行。 总结： 本次圆桌讨论围绕提示工程展开，涵盖了其定义、优秀提示工程师的素质、与模型的交互方式、企业级应用、研究应用、以及未来的发展方向等多个方面。核心观点包括： You don't have permission to access this synced block. Please log in and try again. Log In https://www.youtube.com/watch?v=T9aRN5JkmL8 Amanda： 人们经常忘记在提示中给模型留有余地。例如，在遇到边缘情况时，模型会尽力遵循你的指示，但如果你没有告诉它该怎么做，它可能会给出错误的答案。你可以告诉模型“如果发生了一些奇怪的事情，你不确定该怎么做，就在标签中输出‘不确定’”。这样可以帮助你发现模型没有处理好的情况，提高数据质量。 Amanda： 我会把提示给其他人看，就像我自己做评估一样。 David： Karpathy 也会自己做 ImageNet 测试集。 如何从模型的回复中获取有效信息 (36:46 40:46) Alex： 如何从模型的回复中获取有效信息？这不仅仅是一个数字，你可以从中了解模型的思考过程。这是否适用于思维链？ David： 我认为过分强调“推理”的人格化比喻是有害的。重要的是，思维链确实有效，可以提高模型性能。结构化的推理可以进一步提升效果。 Amanda： 如果去掉模型得出正确答案的推理过程，换成看似合理但导向错误答案的推理，看看模型是否会得出错误的结论。 Zack： 让模型在完成任务前写一个故事，效果不如思维链好。 Alex： 这说明推理过程确实对结果产生了影响。 Amanda： 我见过推理步骤不一致但最终得出正确答案的情况。 关于提示中是否需要注意语法和标点符号 (40:47 45:19) Alex： 提示中是否需要注意语法和标点符号？ Zack： 我会注意这些细节，因为这很有趣，但这并不是必须的。重要的是，你应该具备这种关注细节的态度。 Amanda： 我的提示中经常会出现拼写错误，但我更关注概念的清晰表达。 David： 这与预训练模型和 RLHF 模型有关。预训练模型中，拼写错误的条件概率更高。将预训练模型的直觉应用于生产环境中的模型并不总是有效。 Alex： 与模型对话在一定程度上可以看作是一种模仿。 David： 模型会根据你的输入调整其行为。 企业提示、研究提示和普通聊天的区别 (45:20 50:53) Alex： 企业提示、研究提示和普通聊天的区别是什么？ Zack： 研究型提示更注重多样性和探索模型的可能性，因此示例较少或没有，以避免模型过度依赖示例。而企业级提示更注重可靠性和格式一致性，因此会使用大量示例。 Amanda： 我使用的示例通常与模型将要处理的数据不同，目的是为了说明概念，而不是让模型死记硬背。对于认知任务，我希望模型能够真正理解每个样本中的正确答案。 David： 在 Claude.ai 上，我只需要让模型正确完成一次任务即可。但在企业应用中，提示需要能够应对各种情况和输入数据。 提升提示工程技能的建议 (50:54 53:57) Alex： 提升提示工程技能的建议？ Zack： 阅读优秀的提示和模型输出，分析其原理并进行实验，多与模型对话。 Amanda： 将你的提示给其他人看，特别是那些不了解你工作的人。不断练习，并以“初学者”的视角审视自己的提示。 David： 尝试让模型做一些你认为它做不到的事情。 关于越狱 (53:58 56:54) Alex： 当人们编写越狱提示时，模型内部发生了什么？ Amanda： 一种可能是越狱提示使模型偏离了训练数据的分布。 Zack： 越狱有时像是黑客攻击和社会工程的结合。 提示工程的演变 (56:55 64:33) Alex： 过去三年里，提示工程发生了怎样的变化？ Zack： 我们会将有效的提示工程技巧融入到模型训练中，因此最好的技巧通常是短暂的。 David： 我逐渐学会了尊重模型的能力，给予它们更多的信息和上下文。 Amanda： 我会把论文直接给模型，让它自己学习提示技巧。 David： 人们经常会低估模型的能力，试图将问题简化到“Claude 的水平”。 Amanda： 我会尝试进入模型的“思维空间”，这会影响我编写提示的方式。 Zack： 我更容易进入预训练模型的思维空间。 Amanda： 阅读互联网上的内容可能比读书更有助于理解模型。 提示工程的未来 (64:34 结束) Alex： 提示工程的未来是什么？我们都会成为提示工程师吗？ David： 指定模型的目标始终是必要的，清晰地表达目标很重要。工具和方法会不断发展，模型可以帮助我们更好地编写提示。 Zack： 我们将更多地使用模型来辅助提示工程，例如生成示例。 Amanda： 我目前主要编写元提示，让模型生成我想要的输出。未来，模型可能会像设计师一样，与我们进行交互，引导我们说出真正的需求。 David： 我会让 Claude 对我进行“采访”，以提取信息。 Amanda： 现在，我们需要将头脑中的概念传达给模型，未来，模型可能会主动引导我们说出这些概念。哲学训练有助于我清晰地表达复杂概念。 Alex： 从用户那里提取信息将变得更加重要。 Zack： 提示工程就像教学，需要“共情”学生。而未来，我们需要“自省”，让模型理解我们。 Amanda： 我经常定义新概念，以清晰地表达我的想法。 Alex： Amanda 的总结非常到位：将你的思想外化给一个受过教育的外行。 总结： 本次圆桌讨论围绕提示工程展开，涵盖了其定义、优秀提示工程师的素质、与模型的交互方式、企业级应用、研究应用、以及未来的发展方向等多个方面。核心观点包括： You don't have permission to access this synced block. Please log in and try again. Log In 提示工程的核心在于清晰的沟通和对模型能力的理解。 优秀的提示工程师需要具备清晰的表达能力、迭代能力、预见错误的能力以及系统性思维。 随着模型能力的提升，提示工程将更多地关注于如何从用户那里提取信息，而不是单向地向模型发出指令。 未来的提示工程可能会像设计师与客户之间的交互，模型将扮演更主动的角色，引导用户表达需求。 哲学训练有助于提升提示工程能力，因为哲学强调清晰、准确地表达复杂概念。 中英对照 credit to 群友 @洺熙 No access 中英双语播客全文.md No access 中英双语播客全文.md 关联阅读 提示词写作框架：提示词写作框架 提示词写作框架 🎁 迄今为止看到的关于Prompt Engineering最佳的讨论播客内容。 迄今为止看到的关于Prompt Engineering最佳的讨论播客内容。 播客地址 AI总结 概述 AI 提示工程 的深入探讨，通过一个圆桌会议的形式，多位来自 Anthropic 的专家从研究、消费和企业等不同角度分享了他们对提示工程的理解和实践经验。 文章详细阐述了提示工程的定义、重要性、以及如何成为一名优秀的提示工程师。 核心观点认为，提示工程不仅仅是简单的文字输入，而是一个需要不断迭代、实验、并深入理解模型心理的过程。 它涉及到如何有效地与 AI 模型沟通，并将其整合到更大的系统中。 此外，还探讨了提示工程与编程的相似之处，以及在不同应用场景下（如研究、企业和日常对话）的不同侧重点。 强调了 清晰沟通、迭代能力和对模型输出的细致观察 是提示工程的关键。 专家们还讨论了在实际应用中遇到的各种挑战，并分享了宝贵的经验和技巧，例如如何处理边缘情况、如何利用模型自身的反馈来改进提示，以及如何区分不同类型模型之间的差异。 总而言之，本文为读者提供了全面而深刻的提示工程指导，并对未来的发展方向进行了展望。 关键要点 ◦ 提示工程是一种通过与模型清晰沟通，并不断迭代来发挥模型最大潜能的过程。 ◦ 工程的核心在于实验和试错，能够回溯和从头开始尝试不同的方法。 ◦ 提示不只是文字，而是整合到整个系统中的一种编程方式，需要考虑数据来源、延迟和系统设计。 ◦ 优秀的提示工程师需要具备清晰的沟通能力、迭代能力，以及对模型输出的深入分析能力。 ◦ 对模型“心智”的理解至关重要，需要考虑到模型如何解读指令。 ◦ 提示工程是一种通过与模型清晰沟通，并不断迭代来发挥模型最大潜能的过程。 ◦ 工程的核心在于实验和试错，能够回溯和从头开始尝试不同的方法。 ◦ 提示不只是文字，而是整合到整个系统中的一种编程方式，需要考虑数据来源、延迟和系统设计。 ◦ 优秀的提示工程师需要具备清晰的沟通能力、迭代能力，以及对模型输出的深入分析能力。 ◦ 对模型“心智”的理解至关重要，需要考虑到模型如何解读指令。 创新见解 ◦ 将书面文字视为代码，认为写一篇好的文章和写代码一样重要。 ◦ 强调阅读模型输出的重要性，类似于机器学习中“查看数据”。 ◦ 提出使用模型来帮助优化提示，甚至让模型指出其自身错误。 ◦ 认为直接向模型解释任务，而不是假装一个角色，在很多时候更为有效。 ◦ 提示工程的未来将更加注重从用户那里获取信息，模型将扮演引导者的角色。 ◦ 将书面文字视为代码，认为写一篇好的文章和写代码一样重要。 ◦ 强调阅读模型输出的重要性，类似于机器学习中“查看数据”。 ◦ 提出使用模型来帮助优化提示，甚至让模型指出其自身错误。 ◦ 认为直接向模型解释任务，而不是假装一个角色，在很多时候更为有效。 ◦ 提示工程的未来将更加注重从用户那里获取信息，模型将扮演引导者的角色。 重要引用与翻译 原文1：I think the engineering part comes from the trial and error. Okay. So one really nice thing about talking to a model that's not like talking to a person, is you have this restart button. This giant go back to square zero where you just start from the beginning.（第5段） 原文1：I think the engineering part comes from the trial and error. Okay. So one really nice thing about talking to a model that's not like talking to a person, is you have this restart button. This giant go back to square zero where you just start from the beginning.（第5段） 翻译： 我认为“工程”的部分来自于试错。好的，与模型对话和与人对话的一个非常不同的地方在于，你有一个重启按钮。这个巨大的按钮让你回到原点，从头开始。 引用理由： 这段话精辟地指出了提示工程中“工程”的含义，强调了通过不断尝试和迭代来改进提示的重要性，这是提示工程区别于其他形式沟通的关键。 原文2：I think of prompts as the way that you program models a little bit, that makes it too complicated. 'Cause I think Zack is generally right that it's just talking clearly is the most important thing. But if you think about it a little bit as programming a model, you have to think about where data comes from, what data you have access to.（第7段） 原文2：I think of prompts as the way that you program models a little bit, that makes it too complicated. 'Cause I think Zack is generally right that it's just talking clearly is the most important thing. But if you think about it a little bit as programming a model, you have to think about where data comes from, what data you have access to.（第7段） 翻译： 我认为提示有点像是对模型进行编程的方式，虽然这么说有点复杂。因为我认为 Zack 说得对，清晰地沟通才是最重要的。但是，如果你把提示看作是对模型编程，你就必须考虑数据从哪里来，你能访问哪些数据。 引用理由： 这段话将提示与编程联系起来，强调了提示不仅仅是语言，而是需要系统性思考，包括数据、延迟和系统集成等因素。 原文3：So I think that I can trust the model if I look at 100 outputs of it and it's really consistent. And I know that I've constructed those to basically figure out all of the edge cases and all of the weird things that the model might do, strange inputs, et cetera. I trust that probably more than a much more loosely constructed set of several thousand. （第23段） 原文3：So I think that I can trust the model if I look at 100 outputs of it and it's really consistent. And I know that I've constructed those to basically figure out all of the edge cases and all of the weird things that the model might do, strange inputs, et cetera. I trust that probably more than a much more loosely constructed set of several thousand. （第23段） 翻译： 因此，如果我查看模型的 100 个输出，并且它们非常一致，并且我知道我已经构造了这些输出来找出所有的边缘情况和模型可能做的奇怪的事情，以及奇怪的输入等等，我就会相信这个模型，可能比一个构造松散的数千个输出更值得信赖。 引用理由： 这段话强调了高质量的小数据集比低质量的大数据集更有价值。在提示工程中，重点应该放在对边缘情况的充分考虑，而不是盲目追求大量的样本。 阅读笔记 【提示工程的本质】：迭代和实验 • 提示工程是通过试错和迭代来优化模型输出的过程。 • 它强调像编程一样管理和跟踪实验。 • 清晰的沟通是提示工程的基础。 promptengineering iteration experimentation 【提示工程师的素质】：理解和观察 • 需要清晰的沟通技巧和迭代的意愿。 • 需深入理解模型，并能从模型输出中学习。 • 需要考虑到实际使用场景和用户输入的多样性。 communication understanding observation 【模型交互】：信任和质疑 • 不应盲目信任模型，需不断测试和验证其可靠性。 • 可利用模型自我诊断错误，并提出改进建议。 • 模型可以帮助用户更好地理解任务并进行提示。 trust feedback collaboration • 提示工程过程： 类似于一个循环过程，不断改进提示以达到理想的输出。 • 模型评估： • 三个关键维度，一致性、边缘情况覆盖和输入多样性都越高越好。 提示工程的未来 • 未来提示工程中，模型将更加主动地参与到用户需求理解和提示优化的流程中。 核心问题问答 1. 什么是提示工程？ 提示工程（Prompt Engineering） 是一种通过设计和优化提示（Prompts）来引导大型语言模型（LLMs）执行特定任务的技术。它旨在通过清晰、精确的沟通，使模型能够产生期望的输出。以下是关于提示工程的详细解释： 提示的定义 • 指令：提示是用户提供给模型的指令，目的是让模型执行特定任务。它可以是一个简单的句子，也可以是包含多个步骤的复杂描述。 • 程序：提示也可以被视为一种程序，用自然语言编写的，用来指导模型执行任务。 • 沟通方式：本质上，提示是一种与模型沟通的方式，类似于与人交流，需要清晰和明确。 提示工程的核心要素 • 清晰的沟通：提示工程强调清晰的沟通，使用户能够准确地表达自己的需求，并让模型能够理解任务的具体要求。 • 迭代过程：提示工程是一个迭代的过程，涉及不断尝试、修改和优化提示，以改进模型的性能。这类似于软件工程中的开发和调试过程。 ◦ 实验：通过尝试不同的提示，观察模型的反应，并根据结果调整提示。 ◦ 反馈：分析模型的输出，找出错误，并进行相应的修正。 ◦ 循环：反复进行实验和反馈，直到达到期望的结果。 ◦ 实验：通过尝试不同的提示，观察模型的反应，并根据结果调整提示。 ◦ 反馈：分析模型的输出，找出错误，并进行相应的修正。 ◦ 循环：反复进行实验和反馈，直到达到期望的结果。 • 系统性思维：提示工程不仅仅是编写单个提示，还包括考虑如何将提示集成到整个系统中。这需要考虑数据来源、数据处理方式以及模型在系统中的作用。 • 理解模型：提示工程师需要理解模型的工作原理和局限性，以便更好地设计提示。这包括理解模型如何处理不同类型的输入，以及如何引导模型的推理过程。 • 问题解决能力：提示工程师需要像解决工程问题一样，系统地考虑各种可能出现的情况，并为之提供解决方案。 ◦ 预测错误： 预测模型可能如何出错，并设计相应的提示来处理这些错误。 ◦ 处理边缘情况：考虑模型在遇到不寻常的输入或错误时的反应。 ◦ 预测错误： 预测模型可能如何出错，并设计相应的提示来处理这些错误。 ◦ 处理边缘情况：考虑模型在遇到不寻常的输入或错误时的反应。 • 版本控制：像对待代码一样对待提示，包括版本控制，跟踪实验等。 • 阅读模型输出：仔细阅读模型的输出，理解其推理过程，而不仅仅是看结果是否正确。 • 理论思维： 在理解模型时，需要从理论层面考虑模型可能如何理解你的指示，而不仅仅是根据自己的理解来写。 提示工程的目的 • 发挥模型潜力：提示工程的目的是充分利用模型的潜力，使模型能够完成超出其原始设计能力的任务。 • 优化模型性能：通过精心设计的提示，提高模型在特定任务上的性能。 • 指导模型行为：通过提示来引导模型的行为，使模型能够产生期望的输出，并避免产生不期望的输出. 提示工程的挑战 • 难以明确表达： 很难用文字准确描述一个任务，并去除所有的假设。 • 模型不提问：模型不像人类一样会提出澄清问题，因此提示工程师需要自己预测模型可能存在的疑问，并在提示中给出相应的答案。 • 找到完美提示的困难：寻找完美的提示是一项具有挑战性的工作，因为总有可能存在更好的提示。 提示工程的应用 • 各种场景：提示工程可以应用于各种场景，包括研究、企业应用和消费者应用。 • 不同类型的任务：提示工程可用于不同类型的任务，包括文本生成、信息提取、问题回答和代码生成. • 整合到系统：提示工程不仅仅是编写单个提示，还包括将提示整合到整个系统中. 提示工程的未来 • 模型辅助提示：在未来，模型将能够帮助用户编写更好的提示，包括提出问题、提供建议和自动生成提示。 • 人机协作：未来提示工程可能会转变为一种人机协作模式，模型会根据用户的目标提出问题，并引导用户编写更有效的提示。 • 从指导到咨询：随着模型变得更加智能，提示工程可能会从指导模型转变为咨询模型，模型会根据用户目标来反向提示用户。 提示工程是一种需要创造性、逻辑思维和系统性思维的技术。它不仅仅是关于写好一个提示，更是关于理解模型、设计实验、迭代优化和解决问题的过程。提示工程师需要像工程师一样，不断尝试和学习，才能充分发挥模型的潜力。 2. 优秀提示工程师的素质？ • 清晰的沟通能力：优秀的提示工程师能够清晰地表达想法，明确理解任务，并准确地描述概念。这包括能够以一种易于模型理解的方式构建指令。 • 迭代能力：他们愿意不断地迭代和调整提示，并思考模型可能误解的地方。这种迭代过程包括对模型的响应进行分析，找出错误，并进行修正。 • 测试边缘案例：他们会主动思考提示在哪些不常见的情况下可能出错，例如输入为空或不符合预期格式。这包括测试各种异常情况，以确保模型在不同情况下都能正常工作。 • 理解模型输出：优秀的提示工程师会密切关注模型的输出，而不仅仅是结果。他们会深入研究模型的思考过程，并尝试理解其推理方式。 • 理论思维：他们能够从自身的理解中抽离出来，并系统地分解完成任务所需的全部信息。他们能够以一种模型能够理解的方式，清晰地传达必要的信息。 • 同理心：他们能够站在模型的角度思考问题，理解模型如何看待他们的指令。他们也需要考虑到用户的需求，并理解用户如何与模型互动。 • 实验心态：他们通过不断地实验和尝试，来发现模型的边界。他们不怕失败，并从失败中学习，通过挑战模型的能力极限来加深对模型的理解. • 利用模型进行改进：他们不仅通过自身的努力，也会利用模型本身来改进提示。例如，他们会要求模型指出指令中的不清晰之处，或者请模型提供修改建议。他们会尝试让模型解释其错误并改进指令。 • 信任但验证：他们对模型的能力持谨慎态度，并通过反复测试来确保模型的可靠性。他们会通过大量的测试来验证模型的输出，而不是盲目地信任模型。 • 细致的观察：他们会仔细阅读提示和模型的输出，分析其中的细节。他们会通过分析模型输出的细节来学习模型的思维方式。 • 不执着于完美：他们不追求完美的提示，而是不断尝试并从错误中学习。他们会认识到提示是一个迭代过程，而不是一次性的任务. • 将文字视为代码: 他们可以理解文本作为代码的含义，并理解提示也需要版本控制和实验跟踪等。 • 能够从不同角度思考：好的提示工程师可以从不同的角度考虑问题，例如，既能设身处地地为模型着想，也能考虑到实际用户的需求。 • 能够创造新概念：他们会根据需要定义新的概念，并通过与模型合作来明确这些概念。 • 能够将思想外化: 他们可以清晰地表达自己的想法，并能将大脑中的复杂概念转化为模型能够理解的指令。 优秀的提示工程师不仅要有清晰的沟通能力和迭代能力，还要有同理心，能够站在模型的角度思考，并能够不断地实验和学习，通过测试边缘案例来发现模型的边界。他们还会利用模型本身来改进提示，并从模型输出的细节中学习。他们需要理解到提示的过程是迭代的，而不是追求完美，他们也需要理解文本与代码的相似之处。他们需要从不同角度思考，既包括用户体验，也包括模型本身的认知方式。最重要的是，他们需要能够清晰地表达自己的想法并将大脑中的概念外化。 3. 如何有效地与模型互动？ 3.1 清晰的沟通是核心 • 准确表达需求： 就像与人交流一样，你需要清晰地表达你的需求，让模型准确理解你的目标。避免模糊不清的指令，尽量具体描述你期望模型完成的任务。 • 明确任务细节： 你需要剥离你所有的假设，并详细说明模型需要了解的所有信息。不要假设模型知道任何你没有明确告诉它的事情。 3.2 将提示视为程序 • 自然语言代码： 可以将提示视为一种用自然语言编写的程序，用来指导模型完成任务。 • 系统思维： 要像对待代码一样对待提示，包括版本控制，跟踪实验等。需要考虑提示如何融入整个系统，包括数据来源、数据处理和模型在系统中的作用。 3.3 拥抱迭代和实验 • 试错是常态： 提示工程是一个试错的过程，需要不断尝试不同的提示，并根据模型的反馈进行调整。 • 重启按钮： 模型有一个“重启按钮”，你可以随时回到起点，从头开始尝试不同的方法，而不会受到之前实验的干扰。 • 频繁迭代： 有效的提示工程需要频繁地与模型进行互动，进行多次的来回迭代，而不是期望一次就能得到完美的结果。 3.4 理解模型的心智 • 模型视角： 尝试从模型的角度思考你的指令，理解模型可能如何理解你的要求。这需要你扮演模型的角色，模拟它的思维方式。 • 阅读模型输出： 仔细阅读模型的输出，不仅要关注结果是否正确，还要理解模型的推理过程。从输出中学习，了解模型是如何理解你的指令的。 • 探究模型错误： 不要忽视模型犯的错误，询问模型为什么会犯错，并尝试理解错误的原因，甚至可以请模型修改指令。模型有时能够指出指令中不清晰的地方，并给出改进建议。 3.5 处理边缘情况 • 预测错误： 预想模型可能出错的情况，并设计相应的提示来处理这些错误。考虑模型在遇到不寻常的输入或错误时的反应，例如： ◦ 提供备选方案： 如果模型不确定如何处理某些输入，给它一个“出口”，例如让它输出“不确定”的标签。 ◦ 测试极端情况： 尝试用各种极端情况（例如空字符串、不符合预期的输入）来测试你的提示，以确保模型在各种情况下都能正常工作。 ◦ 提供备选方案： 如果模型不确定如何处理某些输入，给它一个“出口”，例如让它输出“不确定”的标签。 ◦ 测试极端情况： 尝试用各种极端情况（例如空字符串、不符合预期的输入）来测试你的提示，以确保模型在各种情况下都能正常工作。 3.6 尊重模型的能力 • 不要低估模型： 不要认为模型很笨，而需要“哄骗”它才能工作。要尊重模型的能力，给它足够的上下文和信息，让它能够理解你的目标。 • 直接给出信息： 当你想让模型学习一种新的技术时，可以直接给它相关的论文或文档，而不是尝试用自己的语言来描述。 • 避免过度简化： 不要刻意简化你的指令，要相信模型能够处理复杂的任务。 3.7 利用模型辅助 • 模型生成示例： 使用模型生成例子，然后你再进行修改，可以更快的生成高质量的提示。 • 模型进行访谈： 让模型采访你，提取你脑海中的信息，并将这些信息转化为提示。 3.8 不要迷信完美提示 • 没有完美： 不要陷入“寻找完美提示”的陷阱，要明白总有进步的空间。 • 持续学习： 每次与模型的互动都是一次学习的机会，每次尝试都能让你更好地理解模型。 • 专注边界探索： 尝试让模型做一些你认为它做不到的事情，通过探索模型的边界来学习。 3.9 区分不同场景 • 研究与企业： 在研究环境中，你可能更注重多样性和探索性，而在企业环境中，你可能更注重可靠性和一致性。 • 人机对话与系统应用： 在人机对话中，你可能会进行多次迭代，但在系统应用中，你需要一次性编写出能够处理各种情况的提示。 3.10 使用元提示 (Meta Prompts) • 生成提示的提示： 可以使用“元提示”来让模型生成你需要的输出或查询。你可以直接给模型一篇关于提示技巧的论文，然后让它生成一个元提示，来让其他模型执行该技巧。 总之，与模型进行有效互动需要清晰的沟通，系统的思维，持续的实验，深刻的理解以及对模型能力的尊重。同时，有效地利用模型的辅助，可以帮助你更快的迭代和优化你的提示。记住，没有完美的提示，只有不断的学习和改进。 4. 关于 Prompt 的常见误解 4.1 提示仅仅是简单的指令： • 误解： 人们常常认为提示只是给模型的简单指令，就像在搜索引擎中输入关键词一样。他们可能会认为只需要输入一些关键词就可以让模型完成任务，而忽略了清晰和精确沟通的重要性。 • 事实： 实际上，提示是一种复杂的编程方式，需要像对待代码一样对待，包括版本控制和跟踪实验。好的提示需要经过精心的设计和迭代，以确保模型能够准确理解任务并产生期望的输出。 4.2 提示是静态的，一次编写即可： • 误解： 有些人认为编写提示就像写一篇文章一样，写完就完成了，不需要再做修改。 • 事实： 提示工程是一个迭代过程，需要不断地尝试、修改和优化。你需要与模型进行多次的来回互动，并通过阅读模型输出和分析错误来改进你的提示。有效的提示工程需要拥抱实验和反馈，而不是期望一步到位。 4.3 提示需要完美的语法和标点： • 误解： 人们常常认为为了让模型理解，提示必须使用完美的语法和标点符号。 • 事实： 虽然注意细节是重要的，但模型通常能够理解包含拼写错误或语法不完美的提示。重要的是概念的清晰度，而不是语法的完美。虽然在最终的提示中修正错误是好的，但在迭代过程中不完美也是可以接受的。 4.4 模型需要被“哄骗”才能工作： • 误解： 一些人认为模型很笨，需要使用一些技巧或“谎言”来引导它完成任务，例如给模型赋予一个虚假的身份或角色。 • 事实： 模型具有很强的理解能力，你不需要“哄骗”它。你应该尊重模型，并直接给它提供清晰、准确的信息，让它理解你的目标。直接描述你的任务，而不是使用比喻或相似的任务来引导模型。 4.5 提示工程的核心在于编写完美的指令： • 误解： 有人认为提示工程的重点在于找到完美的指令，并花费大量时间琢磨每个词语。 • 事实： 虽然精确的指令很重要，但更重要的是理解模型的工作原理，并通过阅读模型的输出来学习。理解模型的思维方式，以及它如何处理不同的输入，比追求完美的指令更重要。好的提示工程师应该能够从模型的输出中提取信号，并理解其推理过程，而不仅仅是看结果是否正确。 4.6 提示工程仅仅是写作： • 误解： 一些人认为，提示工程的核心能力在于写作技巧，认为好的作家自然会成为好的提示工程师。 • 事实： 虽然良好的写作能力是必要的，但它不是提示工程的核心能力。好的提示工程师需要具备实验精神、系统思维、问题解决能力以及理解模型心智的能力。迭代和测试比单纯的写作技巧更重要。 4.7 应该避免给模型提供太多信息： • 误解： 一些人担心给模型提供太多信息会让它感到困惑，因此试图简化指令并隐藏复杂性。 • 事实： 随着模型能力的提升，它们能够处理更多的信息和上下文。你应该信任模型，给它足够的信息，让它能够更好地理解你的任务。 4.8 多示例提示总是更好： • 误解： 人们可能认为提供大量的示例是提高模