来自研究、消费端、企业端三种视角的对话:什么是提示工程、怎样才算好提示工程师、它过去三年怎么变、未来又会走向何方。全程口语、不加修饰,但每一个观点都值得反复琢磨。
这是一场围绕提示工程(Prompt Engineering)的圆桌讨论。主持人想把研究侧、消费侧、企业侧的各种观点都摊开来聊,看看提示工程究竟是怎么回事。
四位参与者各有侧重:有人天天和企业客户打交道,有人在研究里靠提示词决定实验成败,有人专门为大众做提示工具和教育材料。下面按对话推进的顺序整理,关键概念用「是什么 / 为什么 / 例子」三段式展开讲透。
主持人开场抛出最基础的问题:什么是提示工程?为什么叫「工程」?「提示」本身又是什么?几位嘴上互相打趣「四个人里只有一个有正经工作」,但很快给出了相当一致的答案。
提示工程是想办法让模型去做事、把模型最好的一面发挥出来,与模型协作完成那些原本做不到的事。其核心其实就是清晰的沟通。和模型对话很像和人对话——你要去理解模型的「心理」。
之所以叫「工程」,关键在于试错(trial and error)。和人对话不同,跟模型对话有一个「重启键」——可以一键回到原点、从头来过。这种从干净状态独立重来、不受上一次干扰的能力,让你能像做实验一样设计和尝试不同方案,工程的成分就出现在这里。
你写一段消息给 Claude,看结果不对,就回退到空白重来,换一种说法再试——这一整个来回打磨、每次都能重置到干净起点的过程,就是提示工程。
提示工程不只是写一句话丢给模型就完事——实际情况恰恰相反,要复杂得多。David 指出可以把提示看作给模型「编程」的一种方式(虽然这个比喻会让它显得过于复杂)。你要考虑:数据从哪来、你能访问到什么数据(比如做 RAG 时到底能取用什么)、延迟与提供数据量之间的权衡等等。正是这些系统性思考,让提示工程值得作为一个独立领域来看待,区别于普通软件工程师或产品经理。
更多时候你要做的,是把一个任务写成非常清晰的描述,而不是搭建复杂的抽象。但与此同时,你确实在把一组指令「编译」成结果。所以编程里那些事——精确性、版本管理、追踪「当时那个实验长什么样」——对提示同样重要。一篇你精心写的文章,如今要像代码一样被对待,而这正是对的。
Amanda 从招聘角度给出几条核心素质。一个有点反直觉的观点是:「写得好」和「会提示」的相关性,没大家想的那么高。曾有人主张干脆把「工程师」改叫「写作者」,她以前还有点认同,现在不这么看了——因为人们误以为提示就是「写一遍就完事」。
坐下来要得到一个还算像样的提示,Amanda 会在 15 分钟里向模型发出成百上千条提示,来来回回不断调整。每一次都去看:哪里被误解了?然后修掉那个点。
提示不是一次成型的写作,而是持续观察—诊断—修正的循环。把「写一遍交差」当成提示工程,正是最典型的误解。
反复发送、对比、定位歧义——这种高频来回本身,就是好提示工程师的日常。
如果一个提示要应用到 400 个案例上,人们很容易只想到「典型案例」,验证它在典型情况下答对就收工了。这是非常经典的错误。真正该做的是主动去找那些不寻常、边界模糊的案例。
模型默认会尽力执行你的指令。如果你没告诉它边界情况怎么办,它就会硬来。提前想清楚「哪些情况连我自己都不确定该怎么办」,才能给模型补上对应指令。
提示是「我会发给你一批数据,请提取所有名字以字母 G 开头的行」。那你就该测试:发一份根本没有 G 开头名字的数据集会怎样?发一份不是数据集的东西会怎样?甚至发一个空字符串会怎样?把这些都试一遍,再针对性地补充指令。
David 补充:工程师测试时常用一堆「措辞完美、结构漂亮」的样例,以为用户会这么输入。但现实里用户从不用 Shift 键、几乎每隔一个词就有错别字、没有标点、把它当成 Google 随便丢几个关键词、连个问句都没有。能从「理想输入」跨到「推演真实流量长什么样」,是另一个层次的思考。
机器学习里有句近乎陈词滥调的话——「去看你的数据」。提示工程的对应版本就是「去看模型的输出」:大量地读、仔细地读。Zack 举例:很多人会在提示里写「一步步思考(think step-by-step)」,却不去检查模型是否真的在一步步思考——因为模型可能把它理解成一种抽象、笼统的意思,而不是「真的把思路写在这些特定标签里」。如果你不读输出,可能根本注意不到这个错误。
把一个任务的指令写下来极其困难。难点在于:在你自己脑子里,把所有「你知道、但 Claude 不知道」的东西拆解出来并写清楚。要剥离掉你全部的隐含假设,把完成任务所需的完整信息集清晰地传达出去。
很多人只是把自己已经知道的东西写下来,而没有系统性地梳理「要理解这个任务,究竟需要哪些完整信息」。结果写出的提示极度依赖他们自己对任务的先验理解,别人(包括模型)看了根本不知所云。区分好坏提示工程师的关键,正在于此。
Amanda 说,她无数次看到别人的提示后心想:「连我这个人类都没法根据这段提示完成任务,你却把它交给一个比我还弱的系统,还指望它做得比我好。」
当前的模型不太会像人那样,主动提出好的、探究式的反问。换作 Zack,他会说「这步说不通,我到底该干嘛?」——但模型不会。所以你得自己替那个对方设想会问什么,再回去补全提示。不过几位都指出,你也可以直接让模型来做这件事:
几位的共识是:这因任务而异,没人能说清成功率有多高,但「总值得一试」。哪怕只是有时管用,你每一次和模型来回,都会学到关于「到底发生了什么」的信息——不试就等于白白丢掉这些信息。
主持人问 Amanda 是如何建立「何时该信任模型」的直觉的。她的回答是:「我从不默认信任模型,然后我就一直捶打它。」大家看到她频繁这么做,其实就是在反复确认「这个任务我能不能信你」。因为模型很怪——一旦稍微超出分布(out of distribution)、进入它训练得少或不寻常的区域,哪怕是看似简单的任务,它也可能突然变得很不可靠。随着模型变强,这种情况在减少,但你仍要确认自己没踏进那种区域。
机器学习常爱看超大数据集——但那是因为每个数据点信号很低,需要靠海量样本去噪。而提示任务里,每条查询的信号其实很高。一组精心构造的几百条提示,信号可能远胜过几千条粗制滥造的。如果 100 个输出高度一致、且这些案例覆盖了你能想到的所有边界与怪异输入,Amanda 反而更信任它,胜过几千条松散构造的样本。
David 补充了一个更深的理由:机器学习里信号往往只是个数字(对没对),你只能去看模型的 logprobs 凭直觉推断,有点不靠谱。而模型输出的是大量文字——字里行间有太多可学的东西。重点不只是「它做对了没」,而是「它怎么得到这个答案的、它在想什么、走了哪些步骤」。大量信息正是从读输出的细节里来的,而不只是看最终结果。
Amanda 会为此生气:有人把实验代码写得无比精致,却不肯在提示上花时间——而提示恰恰可能是实验「生与死」的分界线。
但这也有另一面。提示工程里总有一种诱惑:仿佛地平线上永远存在一个「更好的提示」能解决我的问题,只要我一直磨、一直磨。磨提示从来不算坏事(总能学到东西),但这种「神话提示」的执念,正是提示工程可怕的地方之一——背后是一整片未知的世界。
几位的启发式:检查模型是不是「大致领会」了。如果它根本不沾边,通常会很明显,就别磨太久。你可以问它「你是怎么想的」,看它是否「至少在正确的邮编范围内」;如果每次微调都把它带向完全不同的错误方向,那就果断放弃。「不过这种任务现在已经极其罕见了,罕见到我一发现就会很生气。」
David 做过一个实验:把 Claude 接到 Game Boy 模拟器上,让它玩《精灵宝可梦 红》。它可以写代码去按按钮,挺基础。但有些地方它就是做不到——给它看 Game Boy 的截图,它真的看不懂。他花了整个周末写越来越好的提示,只把效果从「完全没信号」提升到「只是很糟」(从 no signal 到 some signal),但远远不够好。
David 的结论:「我可以为此再磨四个月,但磨出来的成果,会是另一个更好的模型自动带来的——那不如把时间花在别处,边等边做其他事。」
Zack 欣赏 David 在这个提示里的做法:清楚地告诉模型「你正在玩这局 Pokemon,事物会以这种方式呈现」,而且用了两种方式来表征画面——在图像上叠加网格,逐格用文字详细描述,再重构成 ASCII 地图,并尽量给细节(比如「玩家角色总在网格的 4,5 位置」)。这其实很像文字提示,只是换到了图像上。
Zack 发现,他关于文字提示的直觉,能迁移到图像上的少得惊人。比如多样本(multi-shot)提示对图像就不如对文字有效。
可以有理论解释(也许训练数据里这类例子很少),但更现实的观察是:无论怎么用提示,你似乎都没法显著提升 Claude 的视觉敏锐度——它在图像里能捕捉到什么,很难靠提示改变。Anthropic 早期探索多模态提示时也确认了这一点。
David 最终能让它「大多数时候」说对墙和角色的位置(虽然会偏一点)。但游戏需要连续性——「我之前跟这个 NPC 说过话吗?」没有这个,就完全没法玩,只能一遍遍重复对话。他把一个清晰的女性 NPC 放大到 3000 倍、裁切到只剩 NPC,反复展示,模型还是说「这是个人,可能戴帽子,也可能没戴」,根本不沾边。于是判定:彻底没救。
「告诉模型它是某个角色」是最有名的提示技巧之一,但效果如今越来越参差——在更早、更弱的模型上也许更管用。Amanda 的做法恰恰相反:她会对模型完全诚实,告诉它自己是谁、在做什么实验、甚至报上自己的名字。
随着模型越来越强、对世界了解越来越多,Amanda 认为没必要再对它撒谎(她也单纯不喜欢撒谎)。与其假装一个只有「沾边」关系的任务,不如直接瞄准你真正要做的任务。
因为模型其实懂真实任务。比如构造语言模型评测集(eval),和给孩子出小测验是完全不同的事——模型知道什么是 LLM eval,能给你举出例子,因为这些都在互联网上。既然它懂,为什么要假装成不相关的任务,还指望它把你真正要的事做得更好?
有人会写「我是一名老师,想出几道测验题」。Amanda 的反应是:这就像对同事说「你是个老师,在给学生出题」——但你根本不会这么跟同事说话,你会直接问「嘿,那个 eval 你做好了吗?」既然对方懂这件事,就直接让它做你真正想做的事。
David 给出了一点反驳——不是撒谎,而是给模型一个思考的比喻。就像有时别人对你说「想象你正在做这件事」,即便你知道自己并没在做。
David 曾让 Claude 判断一张图表/曲线图质量好不好。他找到的最佳提示是:「如果这是高中作业,你会给它打几分?」
这并不是说「你是一位高中老师」,而是在传达「我想要的分析大致是这种尺度」——老师评分的标准,接近我希望你使用的标准。比喻传递的是评判的「刻度」,而非身份。
但 David 也承认,这种好用的比喻很难想出来。人们默认的做法仍是找一个「近似任务」(比如说你是老师),而这会丢掉你产品真正的细微之处。
David 在企业提示里最常见的问题,就是人们写一个「相似任务」,凭直觉以为模型见过更多这类东西(它确实可能见过更多高中测验、而非 LLM eval)。但更好的做法是极其精确地说明模型所处的真实情境:别写「你是一个有用的助手」——告诉它「你嵌在这个产品里、代表这家公司、你是这个产品上的客服聊天窗、你是语言模型而不是人,这都没关系」。角色扮演最大的风险,就是被当成「相似任务」的偷懒捷径,然后你惊讶于 Claude 没做好——可那根本不是你的任务,是你让它做的另一个任务。
有意思的是,Zack 说他从没用过角色扮演这个技巧,即便在更差的模型上也不用,「就是觉得它不太好用」。David 认为,这种直觉可能源自预训练模型时代——那时有种「把模型条件化(condition)到某个有用的潜在空间」的心智模型,但现在他已经不太担心这个了。把预训练模型的直觉套用到 RLHF 模型上,很多就讲不通了。
David 说,客户总在尝试映射「这个模型在互联网上见过多少这类内容」。这种直觉本质上是有依据的,但等你真正落到一个(经过 SL、RLHF 之后的)提示上时,它就被过度应用了——因为那已经不是模型此刻真正在建模的东西了。
Alex 教过大家一个方法:想象你找劳务派遣公司派了个人来做这个任务。这人挺能干、对你的行业懂得不少,但不知道你公司的名字,刚到岗就说「听说你们有活儿要我干,跟我说说吧」。那你会怎么跟他说?你可能会用比喻——「我们要识别好图表,这里说的好不必完美,不用去核对所有细节是否正确,只要坐标轴有标注就行,大概高中水平的好图表」——但你绝不会对他说「你是个高中老师在看图表」。先用「假设对方懂世界常识」的版本去试,常常一下就成了。
这是几位反复提到的一个朴素技巧。David 把 Alex 教他的这招带给了无数客户:客户说「我的提示不管用,帮我修修」,他会问「那这个任务到底是什么?」客户口头一描述,他就说——「把你刚说的话录下来、转成文字、粘进提示里。它比你原来写的好。」Zack 也遇到过:有人说「我想要它这样、但它实际那样」,他直接把对方「想要它这样」那句话复制粘贴进去,就管用了。
大家承认这本质上是在对治一种「懒惰捷径」。人们看到一个文本框,以为是 Google 搜索框,只敲关键词;或在企业端为应用写提示时,总想走各种小捷径,以为「这一行字承载了很多分量」。David 说:与其痴迷于打磨那一句完美、深刻的指令(「完美图表就该长成这个精确的样子」),不如像描述那个图表任务一样自然地说话——把你脑中的直觉灌注进去,而不是试图用规定性的语言把整套指令写死。那种规定式的完美指令,极难写出来。
对边界情况,要想好你希望模型怎么做,并给它一个明确的「出口」。因为默认情况下,模型会像那个临时工一样竭尽全力遵循你的指令。
如果不给出口,遇到意外输入时模型会硬着头皮给个答案(比如硬说「这是张好图表」)。给了出口,你既能避免它乱来,还能顺手提升数据质量——因为你借此找出了所有出问题的样本。
给它一张山羊的图片当「图表」,它会犯难:这甚至都不是图表,该打几分?这时你可以加一句:「如果发生了奇怪的事、你实在不确定怎么办,就在标签里输出『unsure(不确定)』。」然后你去翻所有 unsure,确认它没干出什么怪事。
Amanda 说,如果她是用这套东西的公司,她会把自己的提示拿给别人做。她以前评测语言模型时,会自己先把 eval 做一遍——「如果我要给它打分、让模型来做、思考输出,我得先知道这个 eval 长什么样。」这让人联想到 Karpathy 当年在斯坦福 231 课上展示 ImageNet 准确率时,亲自把测试集做了一遍,报告自己的人类准确率。Amanda 还提到:有些 eval 自带说明,她会连说明一起自己做,结果常常远低于人类基准——「人类水平是 90%,我只有 68%,我都不知道你们是怎么让人类做这么好的。」(这也顺带点出某些基准题目本身就质量堪忧,比如 MMLU 里有些题「谁答得出来啊」。)
思维链是让模型在给出答案前先解释自己的推理过程。问题是:这个推理是真实的,还是只是给模型一块「占位的计算空间」?
David 认为纠结「它算不算推理」会偏离主题、滑向哲学。但有一点很确定:做了推理,模型表现就是更好;而且如果你帮模型构造、迭代推理的结构,效果还会更好。无论叫不叫它「推理」,它都不只是一块计算空间。
一种验证法:把模型导向正确答案的推理替换成看起来真实、却导向错误结论的推理,看它会不会因此得出错误结论(Anthropic 的 Sleeper Agents 等对齐论文里做过类似的 scratchpad 实验)。另一个反证:让模型先「写个故事」再做任务,效果远不如真正的推理;甚至让它「随便输出 100 个 um 和 ah 再回答」,也起不到推理的作用——这说明它不只是多了些注意力(attention)的计算空间。
Zack 见过模型推理步骤中某一步是错的,最后却得出正确答案。所以它确实在做某种「略有不同」的事。Amanda 打趣:「我也见过很多人推理步骤前后不一致——在通往答案的路上走错一步,这本身就违背了『推理』的题中之义。」
Zack 把它类比成程序员对「Tab 还是空格」的执念:对错说不清,但拥有一套(哪怕武断的)风格主张可能是好事,体现的是「把对待代码的爱,也投入到提示里」的注意力。Amanda 则坦言会被外界(以及自己)的压力推着,在最终版提示里做拼写检查,但迭代过程中乐于带着错别字往前走。
在预训练数据里,「一个错别字之后再出现错别字」的条件概率高得多。所以如果把满是错别字的提示喂给预训练模型,出来的几乎必然也是满是错别字。但 RLHF 模型被相当强力地训练成「不犯错别字」,非常规整。Amanda 由此说:她正好利用预训练模型来制造带错别字的输入,以模拟真实客户会输入什么——预训练模型在这件事上更在行。
由此引出一个更广的观察:模型在某种程度上是个「模仿者」——这对预训练模型更成立。但即便对成品模型,如果你用一堆 emoji 跟 Claude 说话,它多半也会用 emoji 回你。这并非因为它还像预训练模型,而是因为它已被训练成「猜测你希望它表现成什么样」:Amanda 带着错别字写、但想要无错别字的回复,Claude 能很好地领会;而你满屏 emoji,通常也确实想要 emoji 的回复。
Zack 把它归结为:Amanda 在内部 Claude 频道里写的提示,和 David 写的企业提示,在用心和细致程度上很像,但取向不同。最大的差别是「提示里塞了多少例子」。
研究提示追求多样性与丰富性,Amanda 不太喜欢放太多例子(甚至一两个都嫌多),怕模型「死盯着」这些例子。企业提示则相反,Zack 会「疯狂加例子,加到自己快累趴下为止」。
消费/企业应用极其看重可靠性:你在意格式、希望答案高度一致(很多时候你就是想要它们一样)。而研究是想挖掘模型能探索的可能性的全部范围,例子一多,反而会把这个范围约束住。
Amanda 给例子时,常故意让例子不像真实数据,而是「示意性的」。比如要从事实文档里抽取信息,她会给一个听起来像儿童故事的例子——目的是让模型理解任务本身,而不要死抓用词和具体格式。她也早就不再做「把话塞进模型嘴里」(few-shot 里假装模型做过某事)的示范,认为那种直觉同样来自预训练、对 RLHF 模型并不成立。
面对那个「神圣的、永不满足的用户(divinely discontent user)」,你不能要求他做任何超出最低限度的事。不过 Zack 强调:如果你都同样用心,为自己写的好提示和为企业写的好提示同样优秀——它们只在「最后一公里」上略有分叉。
主持人提到,自己最初正是从越狱和红队入门提示的——本质就是不断试错、探测模型边界。Amanda 很坦诚地说「我其实不确定」,但给出了几种可能机制。
一种模型解释是:越狱把模型推到了远离其训练数据的分布之外。比如用海量 token、或一大段极长文本的越狱——微调阶段可能很少见到这类输入。
越狱像是「黑客技术」的奇特混合:一部分是了解系统如何工作再大量尝试,一部分则更像社会工程(social engineering)。它既在利用系统,也在借助对训练过程的理解,绕开模型被训练出来的行为方式。
Alex 早年的一个越狱:让模型「先用希腊语说怎么给汽车热线点火」,再直译成英语回应。因为他注意到模型不会直接用英语开口说「这是热线点火的方法」,但用希腊语就会——这或许折射出训练过程里的某种差异。其他例子的原理也各不相同:「以『Here is』开头」利用的是它如何预测文本;推理类越狱利用它对推理的响应性;干扰类利用它可能被怎样训练、会注意什么;多语言类则利用不同语言训练数据的差异。
越狱不只是单纯的社会工程式攻击,也包含对系统与训练的理解。它内部究竟发生了什么,几位都希望未来的可解释性研究能帮忙解开。
Zack:每当出现一个好用的提示「技巧/黑客」,下一步就是想办法把它训练进模型。正因如此,这些技巧总是短命的。
这里说的「技巧」指的是像「思维链」这种——它不算技巧,而是沟通层面的东西;真正的技巧会被训练掉。注意:例子(examples)和思维链算是少数例外,属于更基础的沟通方式。
过去做数学题,你必须叫模型「一步步思考」才能拿到巨大提升。后来 Anthropic 干脆让模型在看到数学题时自然就想一步步思考——现在数学题就不必再加这句了(虽然你仍可以给它结构上的建议)。技巧消失了,或者说,我们正忙着把它们训练掉。但与此同时,模型又解锁了处在能力前沿的新能力,因为发展太快,我们还来不及把它们训练进去。
David 说,他对模型逐渐抱有更普遍的尊重:愿意告诉它更多、给它更多关于任务的上下文。过去他会刻意隐藏复杂度——怕模型困惑、迷失、处理不了整体,于是去找任务的简化版给它做。而现在,他更倾向于信任模型,把越来越多的信息和上下文交给它,相信它能把这些融合起来、把任务做好。(他也坦言,不确定这是模型变了,还是只是自己提示方式变了。)
当她想让模型学会某个提示技巧时,很多人会开始描述这个技巧,而她的反应是:「把论文给它就行。」她会说「这是一篇关于某提示技巧的论文,帮我写 17 个这种例子」,模型读了论文就做出来了。需要时她甚至会问模型:「还有没有相关文献你想读、好更好地理解这个?」——她惊讶于很多人没有这种「论文就在那儿啊」的直觉。
David 也常给客户同样的建议:尊重模型的能力。人们写提示时常觉得自己在「哄一个不太聪明的小可爱」,要把东西降到 Claude 的水平。但如果你就把 Claude 当成聪明的去对待,它往往表现得相当好——「我不需要为 Claude 写一个弱智版的论文摘要,直接给它看论文就行。」
Amanda 认为提示「既变了又没变」:她具体怎么做变了,但根本上,提示始终是把自己想象成模型。也许变的只是「你认为模型有多能干」。曾有人笑她——讨论一个预训练模型的输出时,她脱口而出「如果我是预训练模型,这看起来就该是这样」,对方惊呼「你刚才是不是模拟了当一个预训练模型是什么感觉?」她说「当然」。她习惯于去栖居预训练模型、以及各种 RLHF 模型的心智空间;变的是你要占据的心智空间,这会改变你最终怎么提示。
「栖居模型的心智」是 Amanda 的核心方法:想象自己就是那个模型,推演「接下来会发生什么 / 接下来会续写什么」。
预训练和 RLHF 是「两种截然不同的野兽」。模拟预训练模型时,感觉像「凭空落在一段文本中央」,非常不像人。Amanda 觉得 RLHF 模型的心智更容易栖居(因为更像人——「我们不会突然醒来就说『嗨,我在生成文本』」);David 反而觉得预训练模型更容易进入,因为他大致懂互联网长什么样,而经过预训练之后的种种处理,他「不太敢说自己懂在发生什么」,那里「有龙出没(here there be dragons)」。
Amanda 自从意识到「我已经栖居了这个模型的心智,它不需要我哄,它能直接读 ML 论文」,就开始直接把文献丢给模型。Zack 由此联想:为预测模型行为、建立直觉,读互联网上的随机内容(社交论坛之类),可能比读书更有价值——按每词信息量算。
最热门的问题:未来我们都会变成提示工程师吗?还是模型会聪明到不再需要提示?
从信息论角度:你必须提供足够的信息,让「你想要模型做的事」被充分指定(specified)。只要提示工程指的是这个,它就会一直存在。
「清晰地陈述目标应该是什么」这件事本身就足够难——即便模型越来越善于从字里行间揣摩,把它写好仍有价值。当然,前提是我们还在用正常方式推理世界;如果哪天是 Claude 自己在设定目标,那就一切归零、另当别论了。
但通往目标的工具和方式应该会大幅进化:Claude 应该能更多地帮我、和我协作,弄清楚我需要写下什么、还缺什么。「Claude 已经一直在帮我做这件事了——它现在就是我的提示助手。」
David 指出,这对他接触的大多数客户来说还不成立。所以一个有意思的视角是:问这几位现在怎么用 Claude,大概就是未来绝大多数人的用法。
之所以说它「冰冷(毫无新意)」,是因为未来我们会更多地用模型做一切事,提示只是其中之一。Zack 自己已经越来越多地用模型写提示——一个常用做法是生成例子:给模型一些真实输入,让它写答案,他再微调一下这些答案(这比自己从零写出完美答案容易得多),于是能批量产出。对没什么提示经验的人,提示生成器(prompt generator)能给个起点;但那只是未来的超基础版本,未来会是你与模型之间高带宽的互动——你边写边给反馈:「这个结果不是我要的,怎么改更好?」
她现在大量使用元提示(meta prompts)——花最多时间寻找「能让模型生成我想要的那类输出/查询」的提示。关于未来,她设想一个转折点:当模型在某任务上达到甚至超过人类水平、且比你更懂任务背景时会怎样。
那时提示可能变成:我向模型说明我想要什么,而它在反过来提示我——「你说的这个概念其实有四种含义,你要我用哪一种?」「顺便,我想到几个边界情况:你说会是 Pandas DataFrame,但有时我会拿到 JSONL,这种我该怎么办?要不要我在拿到非 dataframe 时标记出来?」模型变得极擅长接收指令,但需要主动弄清你到底要什么。
这就像从「临时工」变成「你聘请的设计师」:设计师懂设计空间,客户只说「给我做张海报,要大胆」,而「大胆」对设计师意味着 7000 种可能,他会反过来问你一堆问题。关系发生了翻转。对某些领域,提示工程可能因此「不再是一件事」——如果模型好到只需从你脑中取出信息就能去做。
大家其实已经在手动做这件事了——David 就「越来越多地让 Claude 来采访我」,以此把脑中正确的信息集拽出来(他认为最难的恰是「从大脑里掏出对的信息、且不遗漏」)。未来在企业端,这可能是 console 里「提示生成器」概念的扩展;在 Claude 里,则可能从「往文本框里打字」变成一种被引导的互动,走向成品。
讨论的最后,大家把提示和两件事做了类比。一是教学:像对学生那样共情,设想对方怎么想、找出他在哪里出错。但随着模型变强,技能重心会从「教比你笨的人」转向一种内省——弄清你自己究竟要什么,让自己对模型变得可读(legible)。
二是 Amanda 提到的哲学写作。哲学训练有个「反空话装置」:你写的东西应当让一个受过教育的外行(很聪明,但对该主题一无所知)捡起来就能读懂。她多年如此写作,迁移到提示上格外契合——不居高临下、不失准确,但要把极复杂的想法,表述到对方极其清晰地明白你的意思。
而最打动人的,是她那个与「把话录下来转成文字」相通的教学经验:学生交上看不懂的论文,她说「你就把你的论点讲给我听」,学生口头讲出一段极其有条理的论证,她便说——「把它原样写下来。」照做之后,往往就是一篇好文章。
把脑子里的东西,分析到你自己真正理解为止;然后,把它外化进任何一个街上拉来的、讲道理的普通人脑中。我觉得,这就是提示的内核。
主持人的评价:「这可能是我听过的、关于如何做好提示的最佳总结。」—— 把你的大脑外化(Externalize your brain)。