WEBVTT

1
00:00:00.000 --> 00:00:05.854
大家好，欢迎来到AI生活课第三课，AI怎样理
解你的话。

2
00:00:05.854 --> 00:00:10.623
前两课我们认识了模型，也分清训练与实际运行。

3
00:00:10.623 --> 00:00:15.826
今天回到每天都会遇到的事：怎样把一件事交代清
楚。

4
00:00:15.826 --> 00:00:21.246
购物清单上少写一个条件，买回来的东西就可能不
合适；

5
00:00:21.246 --> 00:00:26.233
奶茶点单中少了前一句，再加珍珠就变得没头没尾
。

6
00:00:26.233 --> 00:00:31.436
使用AI也一样，任务、材料和前后关系会影响回
答。

7
00:00:31.436 --> 00:00:39.240
本课用这些生活场景解释提示词、上下文和容量，
再说明应用记忆如何参与其中。

8
00:00:39.240 --> 00:00:47.912
你不需要找神奇口令，而是学会提供足够且相关的
信息，遇到答非所问时知道先检查哪里。

9
00:00:48.512 --> 00:00:56.798
这节课的目标有两个，第一是把任务、背景和格式
交代清楚，第二是分清眼前材料、一次能

10
00:00:56.798 --> 00:01:00.113
处理的容量，以及应用保存的信息。

11
00:01:00.113 --> 00:01:08.398
提示词告诉模型要做什么，上下文提供前后信息，
Token是处理信息时使用的单位，上

12
00:01:08.398 --> 00:01:10.677
下文窗口则有容量限制。

13
00:01:10.677 --> 00:01:18.963
记忆通常属于应用保存和取出信息的机制，系统提
示词提供整体指引，少样本提示则用几个

14
00:01:18.963 --> 00:01:20.413
例子说明做法。

15
00:01:20.413 --> 00:01:26.006
这些概念会一起影响回答，但不等于每次都在改变
模型参数。

16
00:01:26.006 --> 00:01:34.292
学习时可以一直追问，这条信息来自哪里，这一次
模型能不能看到，它究竟是一项要求，还

17
00:01:34.292 --> 00:01:36.156
是一份待处理材料。

18
00:01:36.756 --> 00:01:44.361
请家人买牛奶，只说买点牛奶，可能买回含糖的、
小盒的，或者超出预算的一款。

19
00:01:44.361 --> 00:01:51.544
改成两盒一升装的无糖纯牛奶，预算三十元以内，
对方就更容易知道要什么。

20
00:01:51.544 --> 00:01:57.037
这里不是句子越长越好，而是与任务有关的条件说
清楚了。

21
00:01:57.037 --> 00:02:03.375
把这个习惯用在AI上，写通知时就交代对象、内
容、时间和语气。

22
00:02:03.375 --> 00:02:09.712
没有确定的项目可以明确说待确认，不必为了让问
题完整而编一个。

23
00:02:09.712 --> 00:02:14.149
清晰要求减少猜测，但不保证对方永远不出错。

24
00:02:14.149 --> 00:02:19.219
下面我们把这类引导AI处理任务的输入叫作提示
词。

25
00:02:19.819 --> 00:02:26.650
提示词，是引导AI处理任务的输入内容，可以包
含要求、背景和示例。

26
00:02:26.650 --> 00:02:34.122
这页先交代目标与背景，再提供材料、限制和格式
，最后由AI根据输入回答。

27
00:02:34.122 --> 00:02:42.448
比如把一段活动资料改成给同事看的通知，保留时
间地点，控制在三段以内，语气平实。

28
00:02:42.448 --> 00:02:45.863
这比只说帮我写好一点更容易验收。

29
00:02:45.863 --> 00:02:51.627
理解检查：加上你是顶级专家，是否就能保证专业
结论可靠？

30
00:02:51.627 --> 00:02:57.818
不能，角色设定可能影响表达，却不会凭空增加可
靠的专业能力。

31
00:02:57.818 --> 00:03:02.728
提示写得清楚仍需检查结果，尤其要对照原始材料
。

32
00:03:02.728 --> 00:03:09.987
接下来要解决另一个问题，同一句话为什么在不同
对话里可能表达不同意思。

33
00:03:10.587 --> 00:03:15.909
在奶茶店，你先说要一杯奶茶，少糖，接着说再加
珍珠。

34
00:03:15.909 --> 00:03:22.083
店员知道是给刚才那杯加珍珠，因为前面的订单还
在当前对话里。

35
00:03:22.083 --> 00:03:27.192
换一家店，直接说再加珍珠，对方就不知道加到哪
里。

36
00:03:27.192 --> 00:03:34.005
请想想，理解后一句，依赖的是珍珠这个词本身，
还是前面的点单信息？

37
00:03:34.005 --> 00:03:38.475
两者都重要，前面的信息把省略的对象补全了。

38
00:03:38.475 --> 00:03:45.288
和AI聊天时，说再简短一点、按第二种方案修改
，也依赖此前的材料。

39
00:03:45.288 --> 00:03:49.971
如果换了新对话，更稳妥的是重新提供必要背景。

40
00:03:49.971 --> 00:03:56.358
即使没有换窗口，对话很长时也不能一概假定所有
旧信息都还可用。

41
00:03:56.958 --> 00:04:02.573
上下文，是模型在当前任务中可以参考的背景和前
后信息。

42
00:04:02.573 --> 00:04:06.460
奶茶例子里的前一句，帮助解释后一句；

43
00:04:06.460 --> 00:04:13.587
工作中，文件内容、先前要求和当前问题，也可能
一起构成可参考的信息。

44
00:04:13.587 --> 00:04:19.633
关键是模型这次实际收到什么，而不是界面上曾经
显示过什么。

45
00:04:19.633 --> 00:04:28.271
应用可能因为容量和处理策略，对历史记录进行截
断、总结或挑选，所以你还能向上翻到旧

46
00:04:28.271 --> 00:04:32.158
消息，并不能保证模型每次都看到了它。

47
00:04:32.158 --> 00:04:38.853
遇到回答忘记条件，可以先把关键材料和要求重新
说清，再检查结果。

48
00:04:38.853 --> 00:04:44.468
下一步我们看看，文字送入模型时怎样拆成可处理
的单位。

49
00:04:45.068 --> 00:04:49.318
做拼贴画，要把材料拆成小片，再组合起来。

50
00:04:49.318 --> 00:04:55.056
文字进入模型前，通常也会按特定规则切分，变成
许多片段。

51
00:04:55.056 --> 00:05:02.282
一个完整的词有时是一片，有时会拆成几片，不能
直接按眼睛看到的字数猜。

52
00:05:02.282 --> 00:05:08.232
这个故事里，最后能怎样组合，依赖前面怎样切分
和表示材料。

53
00:05:08.232 --> 00:05:15.883
不过，真正的文字切分由具体规则决定，并不是有
人拿着剪刀，凭意思随意裁开。

54
00:05:15.883 --> 00:05:23.959
请做个检查，一篇中文和一篇同样字数的英文，能
否直接断定占用一样多的处理单位？

55
00:05:23.959 --> 00:05:27.784
不能，语言和分词方式都可能影响数量。

56
00:05:28.384 --> 00:05:36.128
Token是模型把输入拆分后处理的基本信息单
位，文本Token不一定等于一个字，

57
00:05:36.128 --> 00:05:38.064
也不一定等于一个词。

58
00:05:38.064 --> 00:05:43.292
这页从一段文字开始，经过分词规则，形成多个T
oken。

59
00:05:43.292 --> 00:05:51.036
因此，不能统一规定一个中文字就是一个Toke
n，更不能拿固定比例套用所有模型和材

60
00:05:51.036 --> 00:05:51.424
料。

61
00:05:51.424 --> 00:05:55.877
不同语言、标点、数字和内容，都可能有不同切分
；

62
00:05:55.877 --> 00:05:59.362
图片与音频也有各自的表示和计量方式。

63
00:05:59.362 --> 00:06:05.364
只需知道产品标出的Token容量，不能直接当
成同样数量的汉字。

64
00:06:05.364 --> 00:06:09.817
若需要精确估算，应按对应模型与产品的计量方法
。

65
00:06:09.817 --> 00:06:15.044
接下来用桌面说明，这些信息单位为什么还会涉及
容量限制。

66
00:06:15.644 --> 00:06:21.352
想象你要核对一份合同，桌上摊着合同、会议笔记
和参考书。

67
00:06:21.352 --> 00:06:24.735
桌面大一些，可以同时摆更多材料；

68
00:06:24.735 --> 00:06:29.809
东西放不下，就需要收起一些，或把厚书整理成摘
要。

69
00:06:29.809 --> 00:06:36.151
这里的关键是眼前可用的材料，不等于书柜里曾经
存过的所有东西。

70
00:06:36.151 --> 00:06:41.437
请检查，桌子越大，是否就能保证你不会漏看任何
一句？

71
00:06:41.437 --> 00:06:45.665
不能，还要看材料怎样组织和实际怎样阅读。

72
00:06:45.665 --> 00:06:53.910
用在AI上也是如此，容量增加能提供更多空间，
却不能自动保证每个细节被正确使用。

73
00:06:53.910 --> 00:07:02.367
桌面的比喻帮助区分一次能容纳多少与能否准确处
理，下一页把这个容量范围叫作上下文窗

74
00:07:02.367 --> 00:07:02.790
口。

75
00:07:03.390 --> 00:07:11.752
上下文窗口，是模型在一次处理过程中可以容纳的
信息范围，通常用Token数量表示。

76
00:07:11.752 --> 00:07:16.770
问题、已有材料以及相关指引，都要考虑可用的容
量；

77
00:07:16.770 --> 00:07:21.370
具体输入输出怎样占用，还要看模型与产品规则。

78
00:07:21.370 --> 00:07:27.642
窗口大，不代表每个细节都会被准确使用，也不等
于拥有永久记忆。

79
00:07:27.642 --> 00:07:31.614
长材料中的信息仍可能被遗漏或理解错误。

80
00:07:31.614 --> 00:07:39.768
处理合同这类任务，可以明确指出要比较哪些条款
，让回答对应原文位置，再逐项核对。

81
00:07:39.768 --> 00:07:45.622
理解检查：把一整本材料成功放进去，是否就能省
掉结果检查？

82
00:07:45.622 --> 00:07:48.758
不能，放得下与用得对是两回事。

83
00:07:48.758 --> 00:07:54.194
下面再看应用怎样保存信息，并在后来的任务里重
新使用。

84
00:07:54.794 --> 00:07:59.959
一家常去的咖啡店在顾客资料里记下，你喜欢燕麦
奶。

85
00:07:59.959 --> 00:08:04.263
下次你来，店员查看记录，再给你相应建议。

86
00:08:04.263 --> 00:08:11.149
这里发生了保存记录和重新查看两个动作，不只是
延续眼前这一轮点单。

87
00:08:11.149 --> 00:08:18.466
请想想，如果记录存在系统里，但店员这次没有查
看，它是否必然影响推荐？

88
00:08:18.466 --> 00:08:24.061
不一定，信息要被取出并用于当前任务，才可能产
生作用。

89
00:08:24.061 --> 00:08:32.453
AI应用的记忆可以借这个故事理解：它可能保存
偏好或摘要，在之后重新提供给模型。

90
00:08:32.453 --> 00:08:37.188
不同店铺有不同管理方式，不同AI产品也一样。

91
00:08:37.188 --> 00:08:42.568
下一页会把记忆、当前上下文和训练之间的边界说
清楚。

92
00:08:43.168 --> 00:08:50.662
AI应用中的记忆，通常是保存信息，并在后续任
务中重新提供给模型的机制。

93
00:08:50.662 --> 00:08:56.444
流程是保存偏好或摘要，后续任务取出，再加入本
次上下文。

94
00:08:56.444 --> 00:09:02.868
所以记忆与上下文可以联系起来，保存的信息成为
这次回答的参考；

95
00:09:02.868 --> 00:09:05.866
它不等于训练时更新模型参数。

96
00:09:05.866 --> 00:09:14.431
也不能假定每个产品都有相同功能，保存什么、怎
样使用、能否查看和修改，都要以具体设

97
00:09:14.431 --> 00:09:15.930
置与说明为准。

98
00:09:15.930 --> 00:09:21.712
重要任务中，不要只靠它可能记得，应该再次明确
关键条件。

99
00:09:21.712 --> 00:09:27.708
比如这份通知面向新员工，必须保留某个日期，就
直接写出来。

100
00:09:27.708 --> 00:09:34.132
理解检查：能在新对话里提到你的偏好，是否证明
模型被你训练过？

101
00:09:34.132 --> 00:09:38.629
不能，应用保存再取出信息也能产生这种效果。

102
00:09:39.229 --> 00:09:46.232
商店服务台有一份工作说明，要求礼貌回应，先确
认订单，不随意承诺退款。

103
00:09:46.232 --> 00:09:52.205
顾客来问问题时，店员要结合具体订单，也要参照
整体工作要求。

104
00:09:52.205 --> 00:09:59.209
这个场景帮助理解，用户当前说的话之外，还可能
存在应用提供的行为指引。

105
00:09:59.209 --> 00:10:06.624
请想想，如果顾客直接要求不用核对订单就退款，
服务台是否应该只听最后一句？

106
00:10:06.624 --> 00:10:09.096
不能忽略适用的工作要求。

107
00:10:09.096 --> 00:10:16.305
不过，软件里的指引不是一位训练有素的员工主动
负责，模型仍可能执行错误。

108
00:10:16.305 --> 00:10:20.219
我们只是借这个故事认识不同输入的作用。

109
00:10:20.219 --> 00:10:22.896
下一页正式介绍系统提示词。

110
00:10:23.496 --> 00:10:29.591
系统提示词，是应用向模型提供整体角色和行为指
引的一类输入。

111
00:10:29.591 --> 00:10:37.996
应用的工作指引与用户的具体任务一起影响回答，
例如希望表达简洁、先确认必要信息等。

112
00:10:37.996 --> 00:10:43.250
它仍属于输入层面的引导，不能据此保证模型永远
正确。

113
00:10:43.250 --> 00:10:50.815
系统提示也不是绝对可靠的防护墙，模型可能理解
错要求，或受到其他输入影响。

114
00:10:50.815 --> 00:10:58.800
真正涉及权限与敏感操作，还需要应用层面的控制
，不能只写一句不要乱操作就放心。

115
00:10:58.800 --> 00:11:04.684
理解检查：在提示中声称永不出错，是否就能让应
用免于错误？

116
00:11:04.684 --> 00:11:08.467
不能，文字要求与实际机制不是一回事。

117
00:11:08.467 --> 00:11:12.249
用少量完成后的样板帮助模型理解任务。

118
00:11:12.849 --> 00:11:19.108
请同事整理活动报名信息，只说排整齐，每个人可
能有自己的理解。

119
00:11:19.108 --> 00:11:27.453
你给两条已经整理好的样板，用姓名、部门、是否
参加这三个字段，他更容易保持相同格式

120
00:11:27.453 --> 00:11:27.661
。

121
00:11:27.661 --> 00:11:33.294
样板提供了可以观察的标准，后面处理新的内容时
就有参照。

122
00:11:33.294 --> 00:11:41.639
请想一想，如果样板把部门写错了，或者每条都恰
好只包含同一个部门，会不会产生误导？

123
00:11:41.639 --> 00:11:44.768
可能，所以示例本身也需要检查。

124
00:11:44.768 --> 00:11:52.696
给AI提供样板，可以同时展示输入和希望得到的
输出，而不是只放一段结果让它猜。

125
00:11:52.696 --> 00:11:59.998
例子要贴近真实任务，也要说明哪些是固定格式，
哪些只是这条记录里的内容。

126
00:12:00.598 --> 00:12:07.822
少样本提示，是在提示中给出少量任务示例，帮助
模型按类似方式完成任务。

127
00:12:07.822 --> 00:12:13.772
先写任务说明，再给输入输出样例，最后提供新的
待处理内容。

128
00:12:13.772 --> 00:12:22.271
比如原文说张敏来自财务部，参加活动，样例就整
理成张敏、财务部、参加三个对应字段。

129
00:12:22.271 --> 00:12:28.646
新记录缺少部门时，可以明确要求填未提供，避免
它照着样例乱补。

130
00:12:28.646 --> 00:12:35.658
示例中的错误也可能被模仿，例子太单一，还可能
让偶然细节被当成规则。

131
00:12:35.658 --> 00:12:40.120
因此要检查示例是否准确，并覆盖必要的差别。

132
00:12:40.120 --> 00:12:46.495
这里样例进入当前上下文，通常没有调整模型参数
，所以不是微调。

133
00:12:46.495 --> 00:12:52.445
理解检查：想统一格式，给两个正确样例之后，还
需要验收吗？

134
00:12:52.445 --> 00:12:56.482
需要，示例提供引导，不是正确性的保证。

135
00:12:57.082 --> 00:13:05.164
现在看本课的问题，聊天界面里还看得到旧消息，
能否保证模型每次都参考全部历史？

136
00:13:05.164 --> 00:13:09.844
先想想刚才的奶茶订单和有限桌面，再给出答案。

137
00:13:09.844 --> 00:13:10.907
不能保证。

138
00:13:10.907 --> 00:13:15.374
界面保存和显示聊天记录，是产品的一种功能；

139
00:13:15.374 --> 00:13:19.628
这一次发送给模型哪些内容，是另一个环节。

140
00:13:19.628 --> 00:13:25.583
应用可能截断较早内容，也可能用摘要或挑选的信
息替代原文。

141
00:13:25.583 --> 00:13:29.625
模型即使收到较多材料，也可能遗漏细节。

142
00:13:29.625 --> 00:13:38.132
因此，如果旧消息中有关键日期、预算或格式要求
，当前任务里最好再明确一次，并在结果

143
00:13:38.132 --> 00:13:38.983
中核对。

144
00:13:38.983 --> 00:13:46.428
不要简单把忘记条件理解为不听话，更不要认为聊
天记录可见就等于永久记忆。

145
00:13:46.428 --> 00:13:54.085
你能区分可见记录、实际上下文和保存机制，就掌
握了这一课最实用的判断方法。

146
00:14:02.085 --> 00:14:09.699
这一课请记住，提示词交代任务、背景、材料和要
求，上下文帮助理解前后关系。

147
00:14:09.699 --> 00:14:14.351
Token是处理单位，不等于固定数量的汉字；

148
00:14:14.351 --> 00:14:19.004
上下文窗口有容量，放得下也不保证全部用得对。

149
00:14:19.004 --> 00:14:26.618
应用记忆通常通过保存信息、之后取出并加入上下
文来实现，具体能力要看产品。

150
00:14:26.618 --> 00:14:35.078
系统提示词提供整体行为指引，少样本提示通过几
个示例说明做法，两者都不能保证永不出

151
00:14:35.078 --> 00:14:35.501
错。

152
00:14:35.501 --> 00:14:43.961
现在你可以试一个小练习，把帮我写通知改成一条
能验收的要求，说清给谁看、用哪些材料

153
00:14:43.961 --> 00:14:46.287
、保留什么和怎样排版。

154
00:14:46.287 --> 00:14:49.037
再检查结果是否忠实于材料。

155
00:14:49.037 --> 00:14:57.497
下一课我们继续看文字、图片和声音怎样一起进入
AI，把今天对输入与信息范围的理解扩

156
00:14:57.497 --> 00:14:59.400
展到更多内容形式。