Meta Prompting正在成为一个人人都在使用的非常强大的工具。这感觉有点像在一九九五年那会儿写代码，工具还不完善，我们正处在一个全新的前沿领域。但对我个人而言，这也有点像在学习如何管理一个人，你需要思考，我到底该如何沟通，才能让对方掌握做出正确决策所需要的信息。欢迎回到新一期的《光锥之内》。今天，我们将揭开顶尖 AI 初创公司在提示工程方面的神秘面纱。我们调研了十几家公司，从构建这些技术的最前沿，为大家带来了他们的实战技巧。Jared，不如我们先从你所投的一家顶尖 AI 创业公司开始，给我们举个例子吧？

我从一家叫Para Help的公司拿到了一个例子。Para Help 是做 AI 客服的，虽然有很多公司都在做这个，但 Para Help 做得非常出色。他们现在正在为 Perplexity、Replit、Bolt 以及其他一些顶尖的 AI 公司提供客服支持。所以，如果你给 Perplexity 发一封客服邮件，实际回复你的很可能就是他们的 AI 代理。

最酷的是，Para Help 团队非常慷慨地同意向我们展示驱动这个代理的实际提示，并且在 YouTube 上向全世界公开。要拿到这些垂直领域 AI 代理的提示是相当困难的，因为它们可以说是这些公司知识产权中的皇冠明珠。所以，我们非常感谢 Para Help 团队同意开源这个提示。

Diana，你能带我们详细解读一下这个提示吗？它看起来超级有趣，能亲眼看到这样的东西机会实在难得。

这个提示最有趣的一点，首先是它非常长，非常详细，足足有六页。很多顶尖的提示，开头都会先设定大语言模型的角色。在这里，它被设定为一名客服代理的经理，然后用要点列出了它需要做的事情。接着，关键部分是告知任务，也就是批准或拒绝一个工具调用，因为它需要协调来自其他代理的调用。然后提示会给出一个高层次的计划，并将其分解成第一、二、三、四、五步。

提示还会给出一些需要牢记的要点，确保它不会随意调用其他不同类型的工具。它还规定了输出的结构，因为在多代理系统中，你需要让它们能互相集成，这就像粘合 API 调用一样。所以，明确指定它需要以特定格式输出接受或拒绝的指令，就变得非常重要。

这部分是高层次的概览，而优秀的提示通常会用这种 Markdown 的风格来排版，你看这里有标题，后面会更详细地介绍如何进行规划。在规划部分，有三个大块：如何规划、如何创建计划中的每一步，以及一个计划的高层范例。优秀的提示一个共通点是，它们会概述如何对任务进行推理。然后一个重点就是给你一个例子，这个提示就是这么做的。

有趣的是，它看起来更像是编程，而不是在写英文，因为它用了这种类似XML 标签的格式来指定计划。我们发现，这种方式能让大语言模型更容易遵循指令，因为很多模型在 RLHF 阶段就是用类似 XML 的输入进行训练的，事实证明这样能产生更好的结果。

是的。有一点让我很惊讶，这里面似乎没有包含某个具体场景的描述，以及针对该场景的输出范例，或许这只是他们公开的版本？

那个部分在整个流程的下一阶段。因为那是针对具体客户的。每个客户对于如何回应支持工单都有自己的一套风格。所以，对于很多做代理的公司来说，挑战在于，当每个客户都有稍微不同的工作流和偏好时，你该如何构建一个通用的产品。

我发现，做垂直领域 AI 代理的公司经常讨论一个很有趣的问题，那就是，如何在提供足够灵活性以实现特定逻辑的同时，避免自己变成一家为每个客户都构建新提示的咨询公司。我觉得，如何在不同客户间复用和合并提示，以及提示的哪些部分是客户特定的，哪些是公司通用的，这是一个世界才刚刚开始探索的有趣领域。

Jared，你说的这点很对。这里就引出了一个概念，就是将提示分为系统提示、开发者提示和用户提示。系统提示，基本上就像是为你公司的运作方式定义一个高层次的 API，Para Help 的例子就是一个非常典型的系统提示，里面没有任何关于具体客户的信息。然后，当他们需要调用这个 API 的具体实例时，就会把所有客户相关的信息塞进开发者提示里，这部分这里没有展示。比如，与 Perplexity 合作时，处理 RAG 问题的方式，就和与 Bolt 合作时截然不同。

至于用户提示，我不认为 Para Help 有，因为他们的产品不是由终端用户直接消费的。用户提示更像是 Replit 或 Cursor 那样，用户需要输入“帮我生成一个有这些按钮的网站”等等，这些都属于用户提示。这差不多就是目前正在形成的一种架构。

关于你提到的避免成为咨询公司这一点，我认为在围绕这些东西构建工具方面，存在着大量的创业机会。举个例子，任何做过提示工程的人都知道，范例和实际操作过的案例对于提升输出质量至关重要。那么以 Para Help 为例，他们非常需要针对每个公司的、优质的实际案例。你可以想象，随着他们规模的扩大，你几乎希望这个过程是自动化的。最理想的情况是，有一个代理能够自动从客户数据集中挑选出最好的例子，然后有套软件能直接将这些例子整合到工作流的相应位置，而不需要你手动去挑选和录入。

这正好可以作为一个很好的切入点，来谈谈我们想讨论的Meta Prompting。因为这是我们和 AI 创业公司交流时，一个反复出现的主题。

是的。Tr-peers 是我正在合作的本期 YC 项目中的一家初创公司，他们帮助像 YC 的 Ducky 这样的公司，对多阶段工作流中的提示和返回值进行深入的理解和调试。他们发现了一种叫做“提示折叠”（prompt folding）的方法。基本上，就是一个提示可以动态地生成自身的更好版本。一个很好的例子就是分类器提示，它能根据前一个查询生成一个更专业的提示。所以，你可以把你现有的提示，连同一些它可能失败或者没完全达到你预期的例子，直接喂给大语言模型，然后说：“帮我把这个提示变得更好。”因为模型对自己非常了解，说来也奇怪，Meta Prompting 正在成为一个每个人都在使用的非常、非常强大的工具。

在你完成“提示折叠”之后，如果任务非常复杂，下一步就是使用范例。我正在合作的一家公司 Jazz Berry 就是这么做的，他们旗下的 Dispatch 产品能够自动在代码中寻找 bug，这是一个难得多的任务。他们的方法是，喂给模型大量只有专家级程序员才能解决的难题范例。比如说，你想找出一个N+1 查询，这对今天即便是最顶尖的大语言模型来说都很难。他们的做法是，找到相关代码片段，然后把它们加入到提示中，并通过 Meta Prompting 的方式告诉模型：“嘿，这是一个 N+1 类型错误的例子。”然后模型就能解决它了。

我认为这种模式，就是当有些问题复杂到难以用文字描述时，干脆就给它一个例子，结果证明这非常有效。因为它能帮助大语言模型围绕复杂任务进行推理，并更好地引导它，因为你无法设定出非常精确的参数。这在某种意义上，就像是软件开发中的单元测试，可以说是大语言模型版本的测试驱动开发。

是的。Tr-peers 还提到了另一件事，就是模型非常想帮助你，以至于如果你只是告诉它“用这个特定格式给我返回输出”，即使它没有足够的信息，它也会告诉你它认为你想听到的东西。这其实就是一种幻觉。所以他们发现，你必须给大语言模型一个真正的“逃生通道”。你需要告诉它，如果你没有足够的信息来回答是或否，或者做出判断，不要凭空捏造，停下来问我。这是一种非常不同的思考方式。

这其实也是我们在 YC 内部开发代理时学到的一点。Jared 想出了一个非常有创意的方法来给大语言模型提供逃生通道。你想谈谈那个方法吗？

是的。Tr-peers 的方法是一种提供逃生通道的方式。我们想出了另一种，就是在返回的格式里，允许它的一部分回复，本质上是向你这位开发者“抱怨”，说你给的信息令人困惑或者不够明确，它不知道该怎么办。这样做的好处是，你只需要让你的大语言模型在生产环境中处理真实的用户数据，然后你就可以回过头去查看它在那个特定输出参数里给你的反馈。我们在内部称之为“调试信息”。所以我们有一个调试信息参数，它基本上就在向我们报告我们需要修复的问题。这最终就变成了一张你需要去完成的待办事项列表，作为代理的开发者，这真是令人大开眼界。

即便是对于业余爱好者或者有兴趣自己做着玩的人来说，一个非常简单的开始 Meta Prompting 的方法，就是遵循同样的提示结构：给它一个角色，让这个角色成为“一名专业的提示工程师，能对如何改进提示给出非常详细、出色的批评和建议”。然后把你想改进的提示给它，它就会给你返回一个经过扩展、更加优秀的版本。你可以一直重复这个循环，效果出奇地好。

我认为有一个常见的模式是，当公司需要从产品中的大语言模型那里更快地获得响应时，他们会先用一个更大、更强的模型进行 Meta Prompting。比如用拥有数千亿参数的模型，像是Claude 3 Opus或者GPT-4o来进行 Meta Prompting，得到一个非常好的版本后，再把它用到一个经过蒸馏的、更小的模型上，比如在 GPT-4o 上使用。结果证明效果相当不错，尤其对于做语音 AI 代理的公司来说。因为延迟对于通过图灵测试至关重要，如果代理在回应前停顿太久，人类就能察觉到不对劲。所以他们会用一个更快的模型，但配上一个由更大模型优化过的、更好的提示。这也是一种常见的模式。

另一个可能没那么复杂，但很有用的技巧是，当你的提示变得越来越长，像一份大型工作文档时，我发现一个有用的方法是，在你使用它的过程中，在一个谷歌文档里记下你看到的那些不符合预期的输出，或者你觉得可以改进的地方。你可以用笔记的形式写下来，然后把这些笔记和原始提示一起交给Gemini Pro，让它为你建议一系列修改，从而把这些改进融入进去。它做得相当不错。

另一个技巧是，在使用Gemini 1.5 Pro时，如果你观察它在进行评估时的思考轨迹，你也能从那些失误中学到很多。我们内部也这么做过。

这至关重要。因为如果你只是通过 API 使用 Gemini，直到最近你都无法获取思考轨迹。而思考轨迹是理解你的提示到底哪里出了问题的关键调试信息。他们最近刚把这个功能加入了 API，所以你现在终于可以把这些信息回传到你的开发工具和工作流中了。

是的，我认为 Gemini Pro 拥有超长上下文窗口一个被低估的好处是，你可以有效地把它当成一个交互式解释器来用。你可以一步一步地，把你的提示和一个范例放进去，然后实时观察它的推理轨迹，从而找出该如何引导它朝着你想要的方向发展。

Jared 和 YC 的软件团队实际上已经构建了各种形式的工作台，让我们能进行调试之类的工作。但正如你所说，有时候直接使用 gemini.google.com，然后拖拽 JSON 文件进去，效果反而更好。你不需要在某种特殊的容器里操作，它似乎直接在 ChatGPT 这样的聊天界面里就能工作。

是的，这些都是我们做的事情。这里我要特别感谢 YC 的数据负责人 Eric Bacon，他在 Meta Prompting 以及把 Gemini 1.5 Pro 当作交互式解释器来用这些方面，给了我们非常多的帮助。

那评估（evals）呢？我们讨论评估这个话题已经有一年多了。创始人们又有什么新的发现？

Garry，尽管我们说这个已经一年多了，但我认为情况依然如此：评估数据集才是所有这些公司真正的皇冠明珠。Para Help 之所以愿意开源他们的提示，一个原因就是他们告诉我，他们其实不认为提示是皇冠明珠，评估数据集才是。因为没有评估数据，你根本不知道这个提示当初为什么要这么写，也很难去改进它。

是的。从抽象层面来看，YC 投资了很多公司，尤其是在垂直领域的 AI 和 SaaS 公司。你不可能获得这些评估数据，除非你真的就坐在那些从事特定知识工作的员工旁边。你需要坐在内布拉斯加州的拖拉机销售区域经理旁边，去理解他关心什么，他如何获得晋升，那个人的激励机制是什么。然后，你所做的，就是把这些面对面的互动，这些坐在某人旁边的观察，带回到你的电脑前，将其编纂成非常具体的评估标准。比如，这个特定用户在收到这张发票后想要得到什么结果，我们必须决定是否要为这台拖拉机的保修负责。就拿这个例子来说，这才是真正的价值所在。

大家都非常担心，我们是不是只是在给大模型做个“包装”，初创公司的未来会怎样？我认为，这恰恰就是关键所在。如果你能深入到特定的场景中，比任何人都更了解那个用户，并且让你的软件真正为那些人服务，那才是你的护城河。

这简直完美地描绘了今天创始人所需要的核心能力。就是你刚才说的那件事，作为一家这样公司的创始人，你的工作就是要擅长那件事，并且对区域拖拉机销售经理工作流程的细节有着狂热的痴迷。

而疯狂的是，这事儿非常难做。比如，你去过内布拉斯加州吗？传统的观点认为，世界上最优秀的创始人，都是技术背景很强、非常聪明的工程师和技术专家。但同时，他们又必须理解世界上某个很少有人理解的领域。而这两者的交集，那一点点缝隙，就是一家数十亿美元初创公司创始人的诞生之地。我想到了 Flexport 的 Ryan Peterson，他是一个非常、非常优秀的人，懂得如何构建软件，但同时，我想他曾经有整整一年的时间，是美国第三大的医用热水浴缸进口商。所以，你见过的、其他技术人员没见过的世界越是奇特，机会就越大。

Garry，你之前用一种很有趣的方式描述过这一点，你说每个创始人都变成了“前线部署工程师”。这个词可以追溯到 Palantir。既然你曾在 Palantir 早期工作，或许可以跟我们聊聊，“前线部署工程师”这个角色在 Palantir 是如何产生的？以及创始人能从中借鉴些什么？

是的。我认为 Palantir 的整个核心理念在某种程度上是，如果你看看当时的 Meta（那时还叫 Facebook），或者 Google，以及当时大家熟知的任何顶尖软件公司，Palantir 的几位创始人有一个关键的认知：走进任何一家世界五百强公司，走进世界上任何一个政府机构，包括美国政府，你都找不到一个真正懂计算机科学和技术，并且达到最高水平的人。所以 Palantir 很早就发现了一个非常、非常大的机会，那就是那些地方所面临的问题，实际上是价值数十亿，有时甚至是数万亿美元的问题。

然而，那是在 AI 还没有成为热点之前，虽然人们会谈论机器学习，但当时他们称之为数据挖掘。世界被数据淹没，这些巨大的数据库里充满了人、物和交易，但我们不知道该拿它们怎么办。这就是 Palantir 过去、现在以及未来一直在做的事：你可以找到世界上最顶尖的技术专家，他们知道如何编写软件来理解这个世界。你有数 PB 的数据，却不知道如何在大海里捞针。而疯狂的是，大约二十到二十二年后的今天，这个趋势只增不减，我们拥有越来越多的数据，却越来越不理解到底发生了什么。所以，毫不奇怪，现在我们有了大语言模型，这个问题正变得越来越容易解决。

而“前线部署工程师”这个头衔，特指的就是，你如何能坐在正在调查国内恐怖主义的 FBI 探员旁边，就在他们真正的办公室里，看一个案件进来是什么样的，所有的步骤是什么，当你真的需要去找联邦检察官时，他们发送的是什么东西。有趣的是，那真的就是 Word 文档和 Excel 电子表格。作为一名前线部署工程师，你所做的就是把人们必须处理的这些“文件柜和传真机”式的工作，转化为非常简洁的软件。经典的看法是，在一个三字母机构里做调查，应该像在 Instagram 上拍张午餐照片发给所有朋友一样简单。这可以说是其中最有趣的部分了。所以，我认为今天，那些从 Palantir 的体系中成长起来的前线部署工程师，正在成为 YC 最优秀的创始人，这绝非偶然。

是的，Palantir 确实培养出了数量惊人的创业创始人。因为成为一名前线部署工程师的训练，正是现在创办这类公司所需要的训练。关于 Palantir 另一个有趣的地方是，其他公司可能会派一个销售人员去和 FBI 探员坐在一起，而 Palantir 派的是工程师去做这件事。我认为 Palantir 可能是第一家真正将这个流程制度化并规模化的公司。

是的。我认为之所以他们能如此稳定地拿到那些七位数、八位数甚至现在九位数的合同，原因在于，他们派去的不是那种衣着光鲜、口若悬河的人，去牛排馆里靠关系应酬。那种模式下，你可能开一次会，对方很喜欢那个销售，然后你试图通过纯粹的个人魅力让他们给你一份七位数的合同。这个过程的时间跨度可能是六周、十周、十二周，甚至五年，谁也说不准。而且软件最后往往也用不起来。

但如果你派一个工程师过去，给他一套 Palantir Foundry，也就是他们现在称之为核心数据可视化和数据挖掘套件的东西，那么下一次会议，你们讨论的就不是五十页的销售文档、合同或者技术规格书，而直接是：“好了，我们做出来了。” 你在几天之内就能得到真实的、实时的反馈。老实说，这正是初创公司最大的机会。如果创始人能做到这一点，而这正是前线部署工程师习惯做的事情，那你就能击败像 Salesforce 或 Oracle，或 Booz Allen，或任何拥有豪华办公室和强大握手的销售团队的大公司。一个握手没什么力道但非常优秀的工程师，怎么进去打败他们？答案就是，你给他们看一些他们前所未见的东西，让他们感到自己被真正倾听了。你必须对此有超强的同理心，你必须是一个出色的设计师和产品人，然后你回来就能用产品惊艳他们。软件本身的力量是如此强大，以至于当你看到某个让你感到被理解的东西时，你会想当场就买下来。

一个好的思考方式是，创始人应该把自己看作是自己公司的前线部署工程师。

绝对是。你绝对不能把这件事外包出去。创始人自己必须懂技术，必须是那个优秀的产品经理，必须是那个人类学家，必须是那个设计师。你希望在第二次会议上，对方看到你根据他们所说的内容做出的演示，然后说：“哇，我从没见过这样的东西，拿走我的钱。”

这个模式最不可思议的地方在于，这正是我们看到大量垂直领域 AI 代理能够迅速崛起的原因。因为他们可以直接与大型企业的最终购买者和内部支持者开会，获取那些上下文信息，然后基本上把它们塞进提示里，第二天开会时就能带着一个方案回来。在 Palantir 的时代，这可能需要一个工程师团队花更长的时间，而现在，可能只需要两个创始人，他们就能去敲定那些我们已经看到的、与大型企业签订的六位数、七位数的合同。这在以前是前所未有的。这种“前线部署工程师加 AI”的新模式，正在加速这一切的发生。

这让我想起了我之前在播客里提到过的一家公司 Giga ML，他们也做客服，尤其是大量的语音支持。这是一个典型的例子，两个非常有才华的软件工程师，不是天生的销售，但他们强迫自己成为事实上的前线部署工程师，最终和 Zeep 签下了一笔大单，还有几家其他公司他们还不能公布。

他们会像 Palantir 的模式那样，亲自去现场吗？

是的，他们会。他们签下合同后，就会去客户现场，和所有的客服人员坐在一起，研究如何持续调整，让软件或者说大语言模型工作得更好。但在此之前，为了赢得合同，他们发现，只要拥有最令人印象深刻的演示就能赢。在他们的案例中，他们在RAG 流程上做了一些创新，使得他们的语音回复既准确，延迟又非常低。这在技术上是很有挑战性的。我只是觉得，在当前大语言模型崛起之前，你可能无法在销售的演示阶段，通过一个稍好一点的、用户界面更佳的 CRM 来击败现有巨头。但现在，因为技术发展得太快，要做好最后那百分之五到十变得非常困难，如果你是一名“前线部署工程师”，你就可以在第一次会议后，针对那个客户进行调整，让产品为他们运转得非常好，然后在下一次带着演示回去，就能获得那种“哇，我们从没见过别人能做到这个”的惊叹，从而签下大单。

这和 Happy Robot 的情况完全一样，他们已经向世界前三大物流经纪商销售了七位数的合同，为他们构建 AI 语音代理。他们就是采用这种前线部署工程师的模式，直接和这些公司的首席信息官对话，然后非常、非常快地交付大量产品，周转速度极快。看到这一切在现在发生，真是令人难以置信。他们从六位数的合同开始，几个月后就已经在签七位数的合同了，这太疯狂了。

这就是通过极其智能的提示工程可以做到的事情。话说回来，关于每个模型，一个有趣的地方是，它们似乎都有自己的个性。创始人们正在真正意识到，对于不同的事情，你会去找不同的人（模型）来做。

大家都知道的一点是，Claude是一个更“快乐”、更容易被人类引导的模型。而另一个，Llama 4，则需要更多的引导，感觉就像在和一个开发者对话。这部分原因可能是它上面做的 RLHF 没那么多，所以用起来有点“糙”，但如果你真的擅长做提示，甚至自己做一些类似 RLHF 的工作，你其实可以把它引导得很好。

是的。我们在内部使用大语言模型的一个场景，就是帮助创始人判断应该从哪些投资人那里拿钱。在这种情况下，你有时需要一个非常直接的评分标准，从零到一百分，零分代表“绝对不要拿他们的钱”，一百分代表“立刻就拿”，因为他们能给你的帮助大到不拿就是傻。Harj，我们一直在用提示来研究这方面的评分标准，我们学到了些什么？

给大语言模型一个评分标准，确实是最佳实践，特别是当你想得到一个数值分数作为输出时，你需要给它一个标准来帮助它理解，八十分和九十分的区别是什么。但这些评分标准从来都不是完美的，总会有例外情况。

你用Claude 3 Opus和Gemini 1.5 Pro都试过，发现了差异。

是的，这是我们发现非常有趣的地方。你可以把同一个评分标准给两个不同的模型。在我们的具体案例中，我们发现 Claude 3 Opus 非常死板，它会严格遵守评分标准，对于任何不符合你给的标准的情况，它都会严厉扣分。相比之下，Gemini 1.5 Pro 在灵活性方面表现得相当出色，它会应用这个标准，但同时也能推理出为什么某个案例可能是个例外，或者为什么你可能需要比标准建议的更积极或更消极地评价。

我觉得这很有趣，因为这就像你在培训一个员工，你给他一个标准，你希望他把标准当作指南来用，但总会有一些边缘情况，需要你更深入地思考。而不同模型处理这种情况的方式也不同，这本身就说明它们有不同的“个性”。Claude 3 Opus 感觉更像一个士兵，就是“好的，收到，检查，检查，检查”，而 Gemini 1.5 Pro 更像一个高自主性的员工，会说：“嗯，好的，这个标准我明白了，但在这种情况下，这可能是一个例外。”看到这种差异真的很有趣。

是的，看到这个应用在投资人身上很有趣。有些投资人，比如 Benchmark 或者 Thrive，他们的流程无可挑剔，从不失联，回邮件比大多数创始人都快，非常令人佩服。而另一个例子可能是，有很多投资人虽然业绩记录证明他们很优秀，但他们总是应接不暇，时间管理可能不太好。所以他们回复很慢，看起来总是很忙，可能还会无意中失联。这恰恰就是大语言模型能发挥作用的地方。看某些案例的调试信息就很有趣，比如为什么是九十一分，而不是八十九分。

我们会持续观察。我想，对我来说，一件非常令人惊讶的事情是，随着我们自己不断地尝试，并且花了大概百分之八十到九十的时间和那些走在最前沿的创始人在一起，我发现一方面，我们用来讨论这件事的类比是，它有点像编程，感觉就像在一九九五年那会儿写代码，工具还不完善，有很多东西没有明确规定，我们正处在一个全新的前沿领域。

但对我个人而言，这也有点像在学习如何管理一个人。你需要思考，我到底该如何沟通，才能让对方掌握做出正确决策所需要的信息？我如何确保他们知道，我将如何评估和给他们打分？不仅如此，这里还有一种“改善”（Kaizen）的意味，就是那种在九十年代为日本创造出非常优秀汽车的制造技术。那个原则的核心就是，最擅长改进流程的人，就是那些亲身在做这件事的人。这正是日本汽车在九十年代变得如此出色的原因。对我来说，这就是 Meta Prompting。

所以，我不知道，这是一个美丽新世界，我们正处在一个全新的时刻。时间差不多了，但我们非常期待看到大家能想出什么样的提示。我们下次再见。