怎么知道它真的变好了 — 评测,以及怎么读那些百分比
这一章讲三件事: 怎么把「我觉得这版更好」变成一个数; 一套最小评测由哪四件东西组成、一个下午怎么搭起来; 以及书里那一堆「效率提升 70%」的数字,为什么一个都不能引用。 这一章是第 05 章的还债: 那里说自动优化必须先有打分器,这里就是讲怎么做那个打分器。
1. 先看现象:你说「改好了」,同事问「好多少」
第 05 章开头那三个问题,这一章要回答了。
先看一个很常见的场景:
你把提示词改了一版,拿三个例子试了试,觉得明显更好,推给了团队。 一周后同事说:「我这边好像不如以前了。」
现在你们俩谁对?没人知道。因为你们各自试的例子不一样,而且都只有几个。
这不是态度问题。 你用三个例子做判断,而这条提示词一周要跑三百次—— 你看到的是它的 1%。
评测的全部意义,就是把「你看到的那 1%」扩大到一个够用的比例,并且固定下来。 固定下来才可比,可比才谈得上「好多少」。
2. 顶层全景:一套最小评测的四件东西
书通篇没有给出这套东西。 它只在两处甩了两个词就过去了—— 这两个词先当场讲明白,不然后面读不下去:
A/B 测试,就是同一件事准备两个版本(一个叫 A、一个叫 B),各跑一批, 看哪版结果更好。名字来自网站改版时的做法:一半用户看旧版、一半看新版,比数据。 说白了就是「对比着试」,没有别的意思。
A/B 测试要成立,还差一样东西:两版各跑一批之后,拿什么判断「哪版更好」。 书甩的第二个词管的就是这件事:
指标就是你拿来打分的那个数。「答对了几条」是一个指标, 「平均多长」「花了多少钱」也各是一个。说「用关键指标衡量」等于说「拿一个数来比」。
我们把这套东西补全:
┌────────────────────────────────────────────────────────────┐
│ ① 题集 20 到 50 条真实输入,其中必须包含你踩过的坑 │
│ ② 尺子 每条输出怎 么判对错(三档,能用高档就别用低档) │
│ ③ 基线 现在这一版的分数是多少 —— 没有基线就没有「更好」 │
│ ④ 记录 每次改动记一行:改了什么、分数从多少到多少 │
└────────────────────────────────────────────────────────────┘
图说:四件东西缺一不可,但都可以很简陋 ——
一个表格文件就能装下前三件,第四件就是那个文件的历史版本。
一个下午能搭起来的东西,能用一年。
这四件东西的顺序不能换。 很多人一上来就想「用什么工具」, 而工具是最后才需要考虑的——第 08 章会讲为什么工具最不重要。
这一章从头到尾只走一条提示词
下面四件东西,我们不各举各的例子,只拿同一条提示词从头走到尾。 这条提示词是书里给的,就是本章第 5 节那张表的第一行:
给放弃购物车的客户写一封跟进邮件,附 10% 折扣。
它就是这一章的那条线。 从捞题开始,到最后一次验收结束, 每一节都在这条线上往前走一步——每一步的数都是从上一步的数来的:
§3.1 捞 30 条真实输入 → §3.2 定出三个能用程序验的条件
→ §3.3 跑出基线 21/30 → §3.4 只改一处,26/30
→ §3.5 拿一直没看过的 20 条验收,17/20
图说:这五节是五步,不是五个例子。走完这一串,
「我觉得更好」就变成了「30 条里多对 5 条」。
提前声明:这条线上出现的每一个数,都是为演示编的,不是真实数值。 书里没有给过任何评测数字——它连「跑了多少条题」这一句都没写过。
3. 核心原理
3.1 题集:20 到 50 条,而且必须包含你踩过的坑
先还第 01 章的一笔账。 那一章末尾说过,GLUE、MMLU 这类公开考卷 「只能测出考试考得怎么样,测不出拿去干活好不好用」,并说这个落差留给这一章。
差在哪,现在能说清了:
| 公开考卷(GLUE、MMLU) | 你自己攒的这批题 | |
|---|---|---|
| 题从哪来 | 所有人共用的同一批 | 只有你会遇到的:你的客户、你的格式、你踩过的坑 |
| 这个分拿来干什么 | 给一个模型和另一个模型排名次 | 给这一版提示词比上一版好多少当尺子 |
| 谁和谁在比 | 模型 A 和模型 B | 第 17 版提示词和第 12 版 |
所以公开考卷的分再高,也代替不了下面这 30 条。 那个分回答的是「这台机器聪不聪明」,你要回答的是「我这条提示词在我这件事上好不好使」—— 这是两个问题,一个分答不了两个问题。
它解决什么问题: 用三个例子做判断,等于用运气做判断。
怎么做:
| 从哪捞题 | 说明 |
|---|---|
| 真实使用记录 | 最好的来源。哪类输入多、哪类少,比例和线上一模一样,不是你想象出来的 |
| 你踩过的每一个坑 | 这是最值钱的部分。 每次发现一个失败案例,就把它加进题集 |
| 边角情况 | 空输入、超长输入、非中文、含有奇怪符号的输入 |
20 到 50 条这个量级怎么来的: 太少了看不出差别, 太多了你就不会跑第二遍——而评测的价值全在于「你会反复跑它」。 能坚持跑的 30 条,胜过跑一次就束之高阁的 500 条。
一条实用规矩(我们的,不是书里的): 每修一个 bug,先把这个 bug 变成题集里的一条。 这样你的题集会随着时间自动长成「你这个任务上最容易出错的地方的合集」—— 而那正是最该反复测的东西。
主走查第一步:给那封跟进邮件捞题。
打开这半年的发信记录,捞出 50 条真实的客户状态,当成 50 道题; 先切走 20 条不看(为什么要切,§3.5 讲),手上剩 30 条:
| 这 30 条里 | 几条 | 长什么样 |
|---|---|---|
| 常规情况 | 26 条 | 「购物车 2 件,合计 480 元,3 天前放弃,订单号 #A20394」 |
| 踩过的坑 | 4 条 | 空购物车(0 件)、金额为 0(全用优惠券抵掉了)、收货地址在德国的外文客户、三周前刚退过款的客户 |
那 4 条坑是这批题里最值钱的部分。 26 条常规题谁跑都差不多, 分数拉开差距的地方全在那 4 条上——所以它们只占 30 条里的 4 条,却决定了后面每一步看到什么。
3.2 尺子:三档,能用高的就别用低的
第 05 章已经列过这三档,这里展开每一档怎么做。
第一档:对答案。
标准答案存在题集旁边,输出一字不差(或按你定的规则统一格式之后一致)才算对。
适用:分类(这条评论是好评还是差评)、抽字段(从合同里抽出金额和日期)、 格式转换。能用这一档是最幸福的情况:分数是客观的,零争议,一秒钟跑完。
第二档:用程序判。
不比对答案,而是检查输出满不满足一组可以用代码验的条件。
| 条件 | 怎么验 |
|---|---|
| 是不是合法的 JSON | 用程序读一遍,读不动就是不合格 |
| 有没有超过 100 字 | 数一下 |
| 有没有提到那三个必须提到的要点 | 查关键词 |
| 生成的代码跑不跑得通 | 执行它,或者跑一遍它的测试 |
| 有没有出现禁止出现的词 | 查一遍 |
这一档被严重低估。 很多看起来「没有标准答案」的任务, 其实有一半可以拆成能用程序验的条件。 一个输出如果连格式都不对,内容再好也没用——先把这一半自动化掉。
第三档:让模型当裁判。
拿另一次模型调用,给输出打分或者比较两个输出哪个好。
这一档能覆盖前两档覆盖不了的东西(写得好不好、总结全不全),但它有三个已知的偏差:
补充(不在书里): 2023 年一篇专门研究这件事的论文指出, 用模型当裁判会带上位置偏好(同样两个答案,换个先后顺序,判出来的赢家会变)、 长度偏好(倾向于给长的打高分)和自我偏好(倾向于给自己这个模型写的打高分); 同一篇论文也报告,强模型当裁判与人的判断一致率能超过 80%,和人与人之间的一致率相当1。
所以这一档能用,但要按下面这样用:
| 做法 | 为什么 |
|---|---|
| 给一份具体的评分标准,不要只说「打 1 到 5 分」 | 「1 到 5 分」它自己也不知道标准在哪 |
| 两个输出比较时,把顺序换过来再跑一遍 | 直接对冲位置偏好 |
| 别用同一个模型当选手又当裁判 | 对冲自我偏好 |
| 在评分标准里明确「长不等于好」 | 对冲长度偏好 |
| 人工抽查裁判本身 | 抽 20 条自己看一遍,裁判判对了没有 |
最后一条是这一档的门槛:你得先验一遍裁判。 裁判不准,后面全是白忙。
主走查第二步:给那封跟进邮件挑一档尺子。
「一封邮件写得好不好」听起来只能用第三档。但把它拆开,一多半能落到第二档:
| 可验条件 | 怎么验 |
|---|---|
| 正文里出现了这一单的订单号 | 查字符串:#A20394 在不在里面 |
| 正文里出现了折扣码 | 查字符串:SAVE10 在不在里面 |
| 正文不超过 120 字 | 数一下 |
三条全中才算这道题对,缺一条就算错。 剩下那一小半——「口气像不像我们家写的」——留给你自己抽查,不进分数。
这一步做完,「这封邮件好不好」就从一句感觉变成了一个能自动跑出来的数。 30 条题跑一遍不到一分钟,而你自己逐封读要花一个多小时—— 这个差别就是你后面愿不愿意反复跑它的全部原因。
3.3 基线:没有基线,「更好」这个词没有意义
这是最容易被跳过的一件事,也是最简单的一件。
基线,就是「你动手之前的那个分数」。 它是后面一切比较的出发点—— 「更好」永远是相对某个数说的,那个数就是基线。
做法只有一句话:在你改任何东西之前,先拿现在这一版跑一遍题集,把分数记下来。
没有这一步,你就永远只能说「我觉得」。
而且基线有一个额外的用处,第 05 章末尾提过:换模型的时候, 你只要拿题集跑一遍新模型,就知道值不值得换。 这件事没有基线就做不了。
主走查第三步:把现在这一版原样跑一遍。
现在手上那条提示词只有一句话,就是第 2 节那句:
给放弃购物车的客户写一封跟进 邮件,附 10% 折扣。
拿它跑那 30 条题,按上一步那三个条件判——对了 21 条。基线 21/30。
翻一眼错的那 9 条,错法很集中:
| 错在哪 | 几条 | 具体是什么样 |
|---|---|---|
| 超了 120 字 | 7 条 | 它爱先写两句「希望这封邮件找到您一切安好」 |
| 没写订单号 | 2 条 | 正是坑里的空购物车和已退款客户——它不知道这两种情况该怎么写,就绕开了 |
「21/30」这个数本身不说明任何事。 它的全部意义是: 从这一刻起,后面每一次改动都有了一个可以减的数。
3.4 A/B 测试:书讲了,但漏了最关键的一步
书专门有一节讲这件事,给的四步是:定目标、造两个略有差异的版本、 用关键指标衡量、分析结果并改进2。它给的例子是两条只是措辞不同的提示词3。
这四步没有错,但它漏了最关键的第五步——而漏掉它,前四步就白做了:
书给的: 定目标 → 造两版 → 衡量 → 分析
│
▼
漏掉的: 这个差别是真的,还是只是这批题碰巧?
图说:接着上一步那 21/30 说。假如你改了一版,30 题对了 22 条 ——
比 21 多 1 条,这一条之差说明不了任何事。
你需要的是「差多少才算真的差」,而不是「哪个数字大」。
(21 和 22 都是为演示编的,不是真实数值。)
先说一个这里绕不开的词,它在这儿不是指声音:
噪声指的是结果里那部分纯粹由运气造成的上下浮动。 同一版提示词跑两遍,分数也会差个一两条——那一两条就是噪声。 判断「真的变好了」,其实就是判断「这次的差别大过噪声了吗」。
给非 专业读者的一句话判据(我们的,不是书里的):
在 30 条题的规模上,差 1 到 2 条基本等于没差。 要么把差别做大到明显(比如从 21 条提到 26 条),要么把题加到几百条。 别为了 1 条的差别去改提示词,你会在噪声里追着自己转。
主走查第四步:只改一处,再跑一遍。
上一步已经看清楚了:错的 9 条里有 7 条是太长。 按第 02 章那张对照表,「太长、太啰嗦」对应的是⑤分寸没写。 所以 B 版只加一句,别的一个字不动:
给放弃购物车的客户写一封跟进邮件,附 10% 折扣。 120 字以内,不要开场白,第一句就点出他购物车里那件东西。
| A 版(基线) | B 版(只加了⑤分寸) | |
|---|---|---|
| 30 条里对了几条 | 21 | 26 |
| 其中超 120 字的 | 7 | 1 |
| 其中没写订单号的 | 2 | 2 |
26 比 21 多 5 条,而噪声只有 1 到 2 条——这个差别大过噪声,所以是真的。
同样值得看的是没修好的那两条:「没写订单号」一条都没少。 ⑤分寸修不了它们——那两条(空购物车、已退款客户)要的是②背景: 你得告诉它这两种情况该怎么写。那是下一轮的事,这一轮不碰, 因为一次只改一个部件。
书还有一处值得点出来的实践建议,在另一章: 用 A/B 测试比较提示词的效果,并且收集用户反馈来改进4—— 这一句加上「保留一份提示词库把有效的记下来」5, 其实已经很接近本章要讲的东西了,可惜书没有把它们连成一套流程。
3.5 留一批「调的时候不看」的题
这一条书完全没有,但它是评测里最容易犯的错。
问题是这样的: 接着上一步往下调。你拿那 30 条反复改,改了十几轮, 从 21 条一路调到 29 条——30 条里只错 1 条了。然后上线,实际效果并没有变好。
为什么: 你调的不是「这个任务」,你调的是「这 30 条题」。 调到最后,提示词里塞满了只对这 30 条有用的补丁—— 比如你为那个德国客户加了一句「收货地址在境外时用英文写」, 它只对这 30 条里的那 1 条有用,对第 31 条客户毫无意义。
这个现象有个正式名字,书在另一个语境下提过一次,叫「过度拟合」6: 为一种情况调得太好,换个情况就崩。
解法是:一开始就把题集切成两半。
| 哪一半 | 干什么用 | 规矩 |
|---|---|---|
| 调试集(比如 30 条) | 你反复跑、反复看、反复改 | 随便看 |
| 验收集(比如 20 条) | 只在你觉得改完了的时候跑一次 | 调的过程中绝对不看 |
这两个名字是我们起的,不是通行术语。 拿「验收集」去搜是搜不到的—— 这一行通行的叫法是开发集(dev set,对应我们的调试集)和 留出集(held-out set,对应我们的验收集)。 我们换了名字,是因为「开发」「留出」这两个词对没做过这行的人不说明任何事; 你要和别人讨论,就用通行的那两个。
如果两边分数接近,你的改进是真的;如果调试集九成、验收集只剩六成,你只是在给题目打补丁。
主走查第五步:拿一直没看过的那 20 条验收。
回到 §3.1——一开始捞的是 50 条,当场切走 20 条从没打开过。 前面四步看的全是那 30 条。现在把 B 版拿去跑一次那 20 条:
| 调试集 30 条 | 验收集 20 条 | |
|---|---|---|
| 对了几条 | 26 | 17 |
| 折算成比例 | 87% | 85% |
87% 和 85% 只差 2 个百分点,挨得很近——说明这一改改对的是任务,不是那 30 条题。 反过来,要是验收集只有 12/20(60%),和调试集的 87% 差出二十多个百分点, 那就该回去看看 B 版那句话是不是只对调试集里那批邮件管用。
走到这里,这条主走查就走完了。 一条一句话的提示词:捞 30 条题 → 定三个可验条件 → 基线 21/30 → 只加一句⑤分寸,26/30 → 20 条没见过的题上 17/20。 「我觉得更好」到这里才变成了「30 条里多对 5 条,而且换一批题也站得住」。
(这条 主走查里的每一个数——21、26、17、29、12、7、2、120, 以及
#A20394、SAVE10这两个字串——都是为演示编的,不是真实数值。 书里没有给过任何评测数字。)
3.6 上线之后:真正的题集在那里
评测不是上线前做一次的事。
上线之后,把真实的输入和输出记下来,定期翻一翻—— 你会看到一批你在办公室里永远想不出来的输入。 把它们加进题集,这就是 3.1 那条规矩在持续起作用。
书在这方面只有一句「用自动化监控跟踪表现」7,没有展开。 补三条最低限度的(我们的,不是书里的):
- 记下来: 每次调用都记一行——输入、输出、用了哪一版提示词、花了多少钱。 这样一份逐条流水账,行话叫日志(就是程序自己给自己记的账本);
- 看失败: 每周花十分钟翻一遍用户重问、放弃、或者点了「不满意」的那些;
- 别记不该记的: 第 06 章那件事——账本里也不该有客户的敏感信息。
4. 书里那些百分比:一个都不能引用
书的第 9 章给了两个案例和四个「真实用例」,每个都配了一串漂亮的百分比。
| 书里的说法 | 出处 |
|---|---|
| 内容生产效率提升 70%、互动率提升 40%、成本降低 50%8 | 无 |
| 自动解决率 80%、响应时间降低 60%、满意度提升 30%9 | 无 |
| 病历文档时间减少 40%、医学术语准确率 98%10 | 无 |
| 合同审阅快 75%、关键条款识别准确率 90%11 | 无 |
| 内容生产速度提升 200%、转化率提升 45%12 | 无 |
「出处:无」的意思是字面上的无: 没有公司名、没有时间、没有链接、没有脚注, 也没有下面这两样——而正是这两样才让一个百分比变得可信。先把它们说清楚:
样本量就是这个百分比是从多少条数据里算出来的。 「效率提升 70%」如果只统计了三篇稿子,那它就只是三篇稿子的事。
样本量够了也还不够。就算那 70% 是从三千篇稿子里算出来的,你仍然要问第二样:
对照组指的是一批不用 AI、其余条件都一样的人或事,专门留着当对比。 没有它,你分不清是 AI 起了作用,还是那段时间业务本来就在变好。
书里两样都没有,只有一个「某零售企业」「某地区医院网络」这样的化名。
书在第 5 章开头还提了一句,说这些洞见来自 麦肯锡、德勤这类领先机构13——但同样没有指明是哪份报告。
判断(我们的,不是书里的):这些数字一条都不能引用。 不是因为它们一定是假的,而是因为它们不可核对—— 你引用了,别人问「哪来的」,你答不上来。 一个数字的价值不在于它多好看,在于它能不能被追回去。 如果错,会错在: 如果这些数字确实出自作者自己的项目经验、只是没写出来, 那它们对作者本人是有意义的,对读者仍然没有——因为读者没法判断它适不适用于自己。
那这一章该怎么读?换一个读法:
别看结果那几行,看「实施」那几行。
以医疗文档那个用例为例10:结果那三行不能用, 但「实施」那三行(把口述转成结构化报告、为出院小结和病历建模板、加一道合规检查) 是一套可以照搬的做法——而且你会发现,它正好是第 02 章的③格式部件加上人在环。
这是读一切商业案例的通用姿势:结果是宣传,做法才是内容。
5. 书里真正有用的部分:一份按任务分的提示词清单
书的第 5 章和第 9 章,真正的价值不是案例,是散落其中的几十条现成提示词。 它们值得被整理成一张表——这是我们从书里挑出来、按任务重排的:
| 你要做什么 | 书里给的提示词大意 | 它示范了哪个部件 |
|---|---|---|
| 追回流失客户 | 「给放弃购物车的客户写一封跟进邮件,附 10% 折扣」14 | ②背景(客户处于什么状态)+ ③格式 |
| 客服标准答复 | 「为要求换货的客户写一份分步骤指引」15 | ①动作 + ③格式 |
| 数据分析 | 「分析过去三个月的销售数据,找出主要增长动因」16 | ①动作 + ②背景(时间范围) |
| 限定分析范围 | 「只关注上一财年的销售数字」17 | ②背景里的「不要什么」 |
| 出教学计划 | 「做一个四周的 Python 入门课,以动手练习为主」18 | ③格式(周数)+ ⑤分寸(难度) |
| 病历摘要 | 「总结这位病人最近三次就诊,突出关键症状与治疗」19 | ①动作 + ③格式(突出什么) |
| 合同起草 | 「按加州法律起草一份技术合作的保密协议」——保密协议就是约定双方不把对方的信息外传的那种合同20 | ②背景(适用法域) |
| 排日程 | 「排一份优先做高影响任务、并且留出休息时间的日程」21 | ②背景(排序原则) |
| 找异常交易 | 「分析这些交易,标出可疑活动」22 | ①动作 |
| 代码审查 | 「分析这段代码里可能的错误,并给出改进建议」23 | ①动作 |
| 写测试 | 「为某个网页应用的登录功能生成测试用例」24 | ①动作 + ②背景 |
| 找创意方向 | 「给出五个受 90 年代街头风启发的极简时装设计方向」25 | ①动作 + ②背景(灵感来源)+ ③格式(五个) |
第一行那条,就是本章从第 2 节一路走到 3.5 的那条主走查用的输入。 它在书里只是一句话的例子;在这一章里,它一共被跑了 80 次 (30 条调试题各跑 A、B 两版,再加验收集 20 条跑一次 B 版),换回来五个可以互相减的数。
这张表的用法不是照抄,是对照着看: 每一条好提示词,都能被拆回第 02 章那六个部件。 你自己写的时候,拿六个部件过一遍,就不需要背这张表。
最后一行来自书里单列的一节,值得多说两句。 书在第 5 章专门讲了「用 AI 帮着做创作」,给的三条做法是: 要求写得具体、并给上视觉参考;拿它的建议反复迭代;卡住的时候用它来探索方向26。
这三条没有一条是新东西——「写具体 + 给参考」就是第 02 章的②背景和④样例, 「反复迭代」就是第 02 章那个循环。 真正值得留下的是它给创作定的位置:用它找方向,不是用它交活。 这个定位在原书第 7 章还有一节专门讲,我们放在第 06 章 3.5 里说完了。
书还有一条建议在这里很实在: 在医疗、法律这类场合,AI 生成的东西必须逐条按法规复核27。 这一条和第 06 章的「人在环」是同一件事,而且这里说得更具体。
6. 作者的判断与证据
| 说法 | 性质 |
|---|---|
| A/B 测试那四步 | 对,但不完整——漏了「差多少才算真的差」 |
| 用关键指标衡量效果 | 对,但书没说指标怎么定 |
| 收集用户反馈、保留提示词库 | 对,而且很实在 |
| 案例里的所有百分比 | 不可核对,不能引用 |
| 「洞见来自麦肯锡、德勤」 | 没有指明具体报告,等于没说 |
| 各行业的提示词例子 | 真正有用的部分,但书没有把它们和写作方法连起来 |
全章零引用。
7. 边界与局限
| 缺什么 | 说明 |
|---|---|
| 整套评测流程 | 书只有零散的「用 A/B 测试」和「用指标」,没有一套可执行的东西 |
| 留一批不看的题 | 完全没有,而这是最容易犯的错 |
| 让模型当裁判怎么做 | 完全没有,而这是今天最常用的一档尺子 |
| 成本也是一个指标 | 一版提示词准确率高 3%、但贵三倍,该不该换?书没有触及 |
| 延迟(从你按下回车到它答完之间的等待时间)也是一个指标 | 用户等三秒和等三十秒是两个产品 |
| 多人协作 | 提示词改了怎么留底、谁来把关、怎么发布,书只说了「统一模板」 |
关于最后一条补一句(我们的,不是书里的):
提示词是产品的一部分,应该像代码一样被对待:进版本库(存代码的地方, 它会记住每一次改动是谁在什么时候做的)、有人评审、改动要能追溯。 它现在最常见的存放地点是某个人的聊天记录里, 这就是为什么团队里每个人的结果都不一样。
8. 可带走的
- 「我觉得更好」和「好多少」之间,隔着一套评测;
- 四件东西:题集、尺子、基线、记录——都可以很简陋,一个下午能搭起来;
- 题集 20 到 50 条;能坚持跑的 30 条,胜过跑一次就不再跑的 500 条;
- 每修一个 bug,先把它变成题集里的一条;
- 尺子三档:对答案 > 用程序判 > 让模型判;第二档被严重低估;
- 让模型当裁判有三个已知偏差:位置、长度、自我;换顺序跑一遍、别自己判自己、先验裁判;
- 改之前先记下基线,否则「更好」这个词没有意义;
- 30 条题上差 1 到 2 条等于没差,别追着噪声改;
- 一开始就留一批「调的时候不看」的题,否则你调的是题目不是任务;
- 上线之后的真实输入,才是最好的题集来源;
- 书里那些百分比一个都不能引用——不可核对的数字没有价值;
- 读商业案例只看「实施」那几行,结果那几行是宣传;
- 提示词该像代码一样进版本库,不是躺在某个人的聊天记录里;
- 这一章那条线可以照搬: 捞 50 条切成 30 + 20 → 定三个能用程序验的条件 → 跑出基线 21/30 → 只加一句⑤分寸得 26/30 → 用没看过的 20 条验收 17/20。 (这些数是为演示编的。)
9. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| A/B 测试四步 | Chapter 9: Exercises and Case Studies for Prompt Engineering | text/10-ch09-chapter-9-exercises-and-case-studies-for-prompt-.txt:211(搜「compare different prompt versions」) · text/10-ch09-chapter-9-exercises-and-case-studies-for-prompt-.txt:219(搜「key performance indicators」) |
| 用 A/B 测试、收集反馈、留提示词库 | Chapter 7: Common Pitfalls and Things to Keep in Mind | text/08-ch07-chapter-7-common-pitfalls-and-things-to-keep-in-.txt:208(搜「A/B testing to compare prompt effectiveness」) · text/08-ch07-chapter-7-common-pitfalls-and-things-to-keep-in-.txt:216(搜「Keep a prompt library」) |
| 过度拟合到特定问法 | Chapter 7: Common Pitfalls and Things to Keep in Mind | text/08-ch07-chapter-7-common-pitfalls-and-things-to-keep-in-.txt:44(搜「Over-optimizing a prompt for one task」) |
| 两个案例的百分比 | Chapter 9: Exercises and Case Studies for Prompt Engineering | text/10-ch09-chapter-9-exercises-and-case-studies-for-prompt-.txt:89(搜「70% increase in content production efficiency」) · text/10-ch09-chapter-9-exercises-and-case-studies-for-prompt-.txt:115(搜「80% automated resolution rate」) |
| 四个用例的百分比 | Chapter 9: Exercises and Case Studies for Prompt Engineering | text/10-ch09-chapter-9-exercises-and-case-studies-for-prompt-.txt:142(搜「98% accuracy in medical terminology」) · text/10-ch09-chapter-9-exercises-and-case-studies-for-prompt-.txt:161(搜「75% faster contract review」) · text/10-ch09-chapter-9-exercises-and-case-studies-for-prompt-.txt:182(搜「200% increase in content production speed」) |
| 麦肯锡与德勤 | Chapter 5: Real-World Applications of Prompt Engineering | text/06-ch05-chapter-5-real-world-applications-of-prompt-engi.txt:5(搜「McKinsey & Company and Deloitte」) |
| 各行业的提示词例子 | Chapter 5: Real-World Applications of Prompt Engineering | text/06-ch05-chapter-5-real-world-applications-of-prompt-engi.txt:15(搜「abandoned their shopping cart」) · text/06-ch05-chapter-5-real-world-applications-of-prompt-engi.txt:51(搜「key growth drivers」) · text/06-ch05-chapter-5-real-world-applications-of-prompt-engi.txt:101(搜「NDA for a technology partnership」) · text/06-ch05-chapter-5-real-world-applications-of-prompt-engi.txt:163(搜「test cases for the login feature」) |
| 用 AI 帮着做创作 | Chapter 5: Real-World Applications of Prompt Engineering | text/06-ch05-chapter-5-real-world-applications-of-prompt-engi.txt:129(搜「push the boundaries of creativity」) · text/06-ch05-chapter-5-real-world-applications-of-prompt-engi.txt:133(搜「minimalist fashion design ideas」) · text/06-ch05-chapter-5-real-world-applications-of-prompt-engi.txt:141(搜「creative blocks and idea exploration」) |
| 医疗法律必须逐条复核 | Chapter 5: Real-World Applications of Prompt Engineering | text/06-ch05-chapter-5-real-world-applications-of-prompt-engi.txt:107(搜「compliance with regulations」) |