详细摘要 摘要

生成:2025-06-10 13:27

摘要详情

音频文件
2024-08-17 | AI Engineer | Building with Anthropic Claude: Prompt Workshop with Zack Witten
摘要类型
详细摘要
LLM 提供商
openai
LLM 模型
gemini-2.5-pro-preview-06-05
温度
0.3
已创建
2025-06-10 13:27:42

概览/核心摘要 (Executive Summary)

本次内容为2024年8月17日由Anthropic工程师Zack Witten主持的Claude提示词(Prompt)工作坊。工作坊以现场实践为主,旨在通过实时编写、测试和编辑用户提交的提示词,提升其效果。Anthropic初创企业销售负责人Jamie Neuwirth首先介绍了Anthropic近期的重要发布,包括Claude 3.5 Sonnet模型和Artifacts功能,并强调Anthropic致力于支持初创企业成长。

Zack Witten随后详细阐述了提示词工程的核心原则与实用技巧。他反复强调两大核心理念:1. 优先使用代码解决确定性问题:当任务(如格式化、后处理)能通过代码可靠完成时,应优先于依赖不确定性较高的提示词。2. 高质量示例至关重要:提供少量、精心挑选的优质示例(Few-shot Examples),尤其是包含“思路链”(Chain-of-Thought)的示例,是提升模型表现和控制输出的关键。

具体技巧方面,Zack强调了清晰分隔提示词不同部分(推荐使用XML标签,因Claude训练数据包含海量XML)、将指令置于信息之后(尤其对于长文档)、以及使用目标语言编写多语言提示词(若条件允许,请母语者协助)。针对常见问题,他演示了多种策略:
1. JSON输出:通过“助手预填充(Assistant Prefill)”和API的“停止序列(Stop Sequences)”参数,可有效确保纯净的JSON输出。
2. 内容简洁性:明确指令长度(如“1-2句话,绝不超过3句”)比模糊的“简洁”更有效。
3. 角色扮演:通过明确指示和温和的负面提示改善。
4. 模型评分/评估:提供清晰的评分标准,并为每个评分等级提供带有“思路链”解释的正面和(或)负面示例,明确区分内容本身与评估对象。
5. 减少幻觉(总结任务):先让模型提取相关引文,再基于引文进行总结。
6. 处理复杂/格式不佳数据:将问题分解,逐步处理。
7. 图像理解:提供高质量、裁剪过的图像,可先让模型描述图像内容。

Zack还讨论了系统提示词的使用(个人倾向于仅放角色定义)、负面提示的“轻描淡写”原则、以及温度设为0(适用于知识型工作以减少幻觉)等。整个工作坊充满了实践操作和与观众的实时问答互动,强调迭代测试的重要性。

Anthropic近期发布与支持策略(Jamie Neuwirth发言)

Jamie Neuwirth,Anthropic初创企业销售负责人,在工作坊开始前进行了简要介绍。

  • 近期重要发布:
    • Claude 3.5 Sonnet: 一款新模型,已获得用户积极反馈。Zack Witten也已试用并将在工作坊中使用。
    • Artifacts: 一项与Claude Teams和Claude AI计划一同推出的新功能。
      • 功能:可将几行文本转化为代码(如制作视频游戏)、图表等。
      • 应用案例:商业图表制作、制药公司基因序列讨论的可视化分享、提示词食谱(Prompting Cookbooks)等。
    • Claude Teams 和 Projects: 为团队协作和项目管理提供的功能。
  • 对初创企业的支持:
    • 目标:赋能基于Claude构建的下一波AI公司。
    • 具体支持:
      • 提供更高的API调用速率限制(higher rate limits)。
      • 提供与Zack等专家的交流机会。
      • 提供早期产品访问权限(early access)。
    • 联系方式:sales@anthropic.com
    • Anthropic的DevRel负责人Alex也出席了活动。

Zack Witten的提示词工作坊:核心原则与实践

Zack Witten(被誉为“提示词医生”)主导了工作坊的核心部分,通过现场修改和测试参与者提交的提示词,分享了提升Claude模型表现的多种技巧。

工作坊形式与准备

  • 形式: 实时互动,参与者通过Slack频道(prompt-live-workshop-anthropic)提交有问题的提示词及其表现不佳的案例。Zack现场分析、修改并在Anthropic控制台(Console)中测试。
  • 提交内容建议:
    • 提示词模板(Prompt template),变量使用{{双大括号}}表示。
    • 具体表现不佳的示例。
  • 使用工具:
    • Anthropic Console(包括其评估“Evaluate”标签页,可能展示一些“秘密新功能”)。
    • Claude for Sheets(电子表格中调用Claude)。

通用提示词工程最佳实践

  • 高质量示例是核心: 提供少量、精心挑选的优质示例(Few-shot Examples)是提升模型表现和准确控制输出的最有效手段之一。示例应清晰展示期望的输入输出格式和内容。
  • 清晰度与结构:
    • XML标签: 强烈建议使用XML标签(如<information>...</information>, <instructions>...</instructions>)来分隔提示词的不同部分(如背景信息、指令、用户输入)。原因是Claude的训练数据中包含海量XML,因此它对这种格式的理解和遵循度通常更高,这比Markdown效果更好。核心在于“清晰地分离提示词的不同部分”。
    • 指令位置: 建议将信息(Information)置于指令(Instructions)之上。通常,“指令越靠近提示词底部,越容易被严格遵守”。
    • 语法与拼写: 保持提示词的语法正确和拼写无误。Zack提到“有轶事证据表明这有帮助”,并且“错别字确实会损害性能”。他个人对此非常注重,认为“这绝对没有坏处”。
  • 强调:
    • 使用大写字母、感叹号或明确说明“这一点极其重要”等方式,可以有效强调某些指令。
  • 简洁性与明确性:
    • 对于模型输出长度,给出具体数字范围(如“每条回复应为1-2句话,绝不超过3句”)比模糊的“简洁些”效果更好。
  • 多语言提示词:
    • 对于翻译或多语言输出任务,如果可能,尽量使用目标语言(Native Language)编写提示词。如果自己不擅长该语言,理想情况下应请母语者协助撰写和优化提示词。
  • 温度(Temperature):
    • 对于“知识型工作”,Zack通常将温度设置为0,他认为这样“可能会略微减少幻觉”。

针对特定问题的提示词优化技巧

1. 确保一致的JSON输出

  • 问题: 模型有时会在JSON输出前添加引导语(如“Here is the JSON:”)或在之后添加解释,或者不完全遵循JSON格式。
  • 核心解决方案:
    • 助手预填充 (Assistant Prefill): 这是Anthropic API的一个特性,允许用户预先设定模型回复的开头。
      • 方法1: 将不希望出现的引导语(如“Here is the JSON:”)放入预填充。模型会认为它“已经说过了”这部分。
      • 方法2: 预填充引导语和开头的JSON括号(如“Here is the JSON: {”)。这能更强力地引导模型进入JSON模式。注意: 后续处理时需要将这个预填充的括号加回到实际的JSON输出中。
    • 使用标签包裹JSON: 指示模型将JSON输出包裹在特定标签内(如<json_output>...</json_output>)。
    • 结合预填充与标签: 例如,预填充为“Here is the JSON: {”。
    • 停止序列 (Stop Sequences - API功能): 在API调用中,将JSON的结束标签(如</json_output>)或结束括号}设为停止序列。模型在输出该序列后会立即停止,避免了后续的解释性文字,也节省了token。
  • 原则: Zack反复强调:“能用代码解决的问题(如格式化、提取特定部分),就不要过度依赖提示词。” 代码更可靠且成本更低。

2. 处理格式不佳的电子表格/CSV数据提取

  • 问题: 从格式混乱、包含多个数据集的大型电子表格中准确提取信息到JSON时,模型容易产生幻ecuzione或遗漏。
  • 建议:
    • 分解问题:
      • 一次处理较少量的行或工作表。
      • 一次只关注必要的列。
      • 将大的提取任务分解为多个“小规模、一口大小(byte-sized)”的子问题。

3. 提升内容创作的质量(如生成推文)

  • 问题: 生成的推文可能不够吸引人或显得“尬”(cringe)。
  • 核心解决方案:
    • 高质量的“少样本示例” (Few-shot Examples): 这是提升效果的关键。
      • 提供1-2个“极好”的完整示例(包含输入文档和期望的推文输出),比提供多个截断或质量不高的示例效果更好。
      • 示例应能体现期望的语气、风格(如“不尬”、“吸引人”)。
      • 可以包含对比示例:一个“尬”的推文和一个“优秀”的推文,针对同一份文档,并排展示。
      • 在示例中解释为何某个输出是好的/坏的。
    • “思路链” (Chain-of-Thought - CoT) 融入示例: 在示例中展示模型“思考”过程,如先从文档中提取“关键点(key points)”,然后再基于这些关键点生成推文。并指示模型在处理新任务时也遵循此思考步骤。
      xml <example> <document_text>...</document_text> <key_points> <point>...</point> </key_points> <tweets>...</tweets> </example>
    • 迭代构建示例集: 从一个基础提示词开始,让模型生成内容,挑选好的,修改不好的,或自己撰写一些,逐步积累高质量的示例对。
  • 示例的组织: Zack个人倾向于将所有示例放在一个大的<examples>块中,而非模拟多轮对话格式,主要是因为前者操作更简便,且未发现性能上有显著差异。

4. 角色扮演与多角色管理

  • 问题: 模型在角色扮演时可能“出戏”(如回复“作为Sam,我会...”),或在多角色切换时管理复杂。
  • 建议:
    • 单角色扮演改进:
      • 明确指示模型在回复前加上当前角色名,并用括号括起来(如“[Sam] 我的流程是...”)。
      • 使用温和的负面提示,避免过度强调,如:“你不需要在回复中过多提及你的角色身份,只需保持角色即可。”
    • 多角色管理:
      • API层面: 为每个角色编写独立的提示词,通过外部代码逻辑根据用户输入判断并将请求路由到相应的角色提示词。这通常比在一个提示词中管理多个角色更简单有效(再次体现“代码优先”原则)。
  • 负面提示 (Negative Prompting):
    • 一般而言,正面表述(告诉模型做什么)优于负面表述(告诉模型不做什么)。
    • 若使用负面提示,应“轻描淡写(light touch)”,说一次即可,不要反复强调,否则可能触发模型的“逆反心理”(类似“别去想大象”效应)。

5. 图像理解与数据提取

  • 问题: 从图像(尤其是手写字迹)中准确提取文本信息。
  • 建议:
    • 图像质量: 提供尽可能高质量、清晰的图像。进行裁剪,只保留包含目标信息的关键区域,去除无关背景。Anthropic Claude会将图像下采样到1000x1000像素。
    • 初步描述: 可以先让模型“描述一下它在图像中看到的全部内容”。
    • 错误传播: 模型一旦在初期对图像的某部分产生错误解读,可能会为了保持“自我一致性”而将此错误延续到后续分析中。
    • Zack指出,特别难识别的手写内容,即使对人类也有挑战,除了优化图像质量外,没有立竿见影的提示词技巧。

6. 模型评分与评估(如翻译质量评估)

  • 问题: 让模型根据标准(rubric)对文本(如翻译稿)进行评分时,评分可能不准、不稳定,或混淆内容本身的好坏与评估对象(如翻译语法)的好坏。
  • 核心解决方案:
    • 明确区分: 在提示词中清晰指示模型区分“文本讨论的主题/情感色彩”与“评估对象本身的质量”。例如:“你的评分应仅反映翻译的质量(语法、流畅度、准确性),而非原文内容的性质。”
    • 高质量的“少样本示例”:
      • 为评分标准中的每一个等级提供至少一个示例。
      • 每个示例都应包含“输入文本”、“对应的分数”以及详细的“为什么得到这个分数”的解释(即思路链)
    • 指示模型进行“思路链”思考: 要求模型在给出最终评分前,先进行一步分析(如列出优点、缺点、符合/不符合哪些标准)。
    • 评分量表: 使用数字量表(如1-5分)是可行的,但不宜期望过高的粒度(如1-100分),模型可能无法很好地校准。5个等级通常是合理的。
  • Log Probs的使用:
    • 观众提问是否可以使用log probabilities来获取模型对不同分数的置信度。Zack认为,这需要先让模型完成“思路链”的思考,然后获取log probs。他个人感觉“思路链 + 离散分数输出”带来的准确性提升,可能大于单纯使用log probs获得的细微差别,因为“思路链”本身利用了更多的计算。

7. 减少总结任务中的幻觉

  • 问题: 模型在进行文本总结时可能编造不实信息。
  • 建议 (一个有效技巧):
    1. 第一步:指示模型首先从原文中提取所有相关的引言/引述 (relevant quotes)
    2. 第二步:指示模型仅基于这些提取出的引言/引述来撰写总结
    3. 可以使用助手预填充来引导这个两步过程,例如预填充“Relevant Quotes:”。

其他重要观点与问答

  • 系统提示词 (System Prompt) vs. 用户提示词 (User Prompt):
    • Zack个人习惯只在系统提示词中放入角色定义(如“你是一个乐于助人的助手”)。他发现Claude通常能更好地遵循用户提示词中的指令。
    • 他承认有些用户反馈,将复杂指令放入系统提示词有助于避免模型将其误认为是用户输入的一部分,从而减少幻觉。Zack对此的建议是,如果遇到此问题,可以在用户提示词中更明确地标记用户输入部分(如使用<user_input>...</user_input>)。
  • 代码与提示词的边界: 再次强调,对于可以通过代码确定性完成的任务(如格式检查、从特定标签提取内容、停止输出),应优先使用代码,而不是试图通过复杂的提示词来控制,后者往往不够稳定且成本更高。
  • 迭代与测试: 提示词工程是一个不断测试和迭代的过程。使用控制台的“评估”功能和构建测试用例集非常重要。
  • 对Traceback错误的处理: 有观众提到直接将完整的traceback错误信息粘贴给Claude,模型能很好地给出修复方案。Zack评论这更多体现了“模型能力的提升”,而非特定的提示词工程技巧。

结论

Zack Witten的提示词工作坊强调了通过结构化提示、高质量示例、以及结合API特性(如预填充和停止序列)来优化Claude模型输出的实用策略。核心思想是追求清晰、明确,并善于将复杂问题分解。至关重要的是,他反复倡导“代码优先”原则:在提示词的非确定性与代码的确定性之间,应优先选择后者来处理可以明确定义的任务,这不仅更可靠,也更经济。整个活动为AI工程师提供了宝贵的实践经验和可以直接应用的技巧,鼓励开发者通过迭代测试不断提升提示词效果。

评审反馈

总体评价

该总结质量非常高,准确、全面地提炼了演讲的核心内容和关键技术点,结构清晰,语言专业。对Zack Witten的提示词工程技巧总结得尤为详尽和到位。

具体问题及建议

  1. 轻微遗漏/可补充: 多语言提示词建议

    • 具体问题描述:记录文本中Zack Witten被问及“In general, for translations, our multilingual output, is it better to instruct our English or the native language?” 他回答 “I think it's better to instruct in the native language. If you speak the native language...ideally, I think for the ideal prompt, you would find a native speaker of the language and explain your use case to them and have them write the prompt.” 这一点在总结中未明确提及,虽然在“模型评分与评估(如翻译质量评估)”部分间接触及了日语翻译的例子,但通用性的多语言提示建议可以补充。
    • 修改建议:在“通用提示词工程最佳实践”或“其他重要观点与问答”部分,可以补充一点关于多语言提示词的建议,即如果可能,尽量使用目标语言编写提示词,或者请母语者协助编写。
  2. 细微表述优化: XML标签原因

    • 具体问题描述:总结中提到“原因是‘Claude的训练数据中包含大量XML,因此它更熟悉这种格式’”,这准确反映了Zack的解释。可以考虑更强调“大量”这个概念,以突出其重要性。
    • 修改建议:可微调为“原因是Claude的训练数据中包含海量XML,因此它对这种格式的理解和遵循度通常更高”。(当前总结已包含“大量”,此建议仅为强调,非必需修改)

优化方向

  1. 强化“代码优先”原则的贯穿性:总结中已在JSON输出部分和“其他重要观点”中提及“能用代码解决的问题,就不要过度依赖提示词”。鉴于这是Zack反复强调的核心原则之一,可以在总结的开篇或结论部分再次突出,使其成为贯穿全文的一个重要理念。
  2. 示例的层级与作用:总结中已很好地覆盖了“少样本示例”和“思路链”的重要性。可以考虑在“通用提示词工程最佳实践”中更早地引入“高质量示例是提升模型表现的核心手段之一”,并在后续具体技巧中体现其应用,使读者对示例的普遍重要性有更深印象。
  3. 保持当前详略得当的风格:当前总结在核心技术点的阐述上非常详细,对于一些辅助性讨论则相对简略,这种处理方式很好地抓住了重点。继续保持这种风格,确保核心价值信息突出。