1
00:00:00,100 --> 00:00:06,432
本内容改编自小山学堂《学 AI 产品，从入门到精通》，为二次演绎配音版。

2
00:00:06,382 --> 00:00:16,057
这一集讲一个很容易被忽略的真相，用户只发了一句话，底层可能跑了十轮以上的循环，产生几十条接口消息。

3
00:00:16,057 --> 00:00:18,966
等你打开账单，可能会吓一跳。

4
00:00:18,966 --> 00:00:21,346
先说本集解决什么问题。

5
00:00:21,346 --> 00:00:30,949
做人工智能产品的人，大多把注意力放在模型聪不聪明、回答好不好上，很少有人算过一次对话到底花多少钱。

6
00:00:30,949 --> 00:00:39,903
而成本的结构和你想的不一样，它不是按用户说了几句话算的，是按底层跑了多少轮、每轮带了多少内容算的。

7
00:00:39,903 --> 00:00:48,365
这一集把这笔账拆开，再给你三套可以直接用的设计框架，上下文怎么压、记忆怎么管、提示词怎么分层。

8
00:00:48,365 --> 00:00:51,201
再说为什么产品经理要关心。

9
00:00:51,201 --> 00:00:54,831
因为这三件事全是取舍，没有标准答案。

10
00:00:54,831 --> 00:00:58,497
哪些内容能删、哪些必须留，你得定。

11
00:00:58,497 --> 00:01:01,947
什么值得记住、什么要忘掉，你得定。

12
00:01:01,947 --> 00:01:07,091
系统提示词怎么分层、工具描述要不要全给，还是你定。

13
00:01:07,091 --> 00:01:15,709
这些决定最后都会体现在账单和体验上，而且一旦定错了，改起来的代价比一开始想清楚要高得多。

14
00:01:15,709 --> 00:01:18,100
还有一层更现实的考虑。

15
00:01:18,100 --> 00:01:23,197
上下文管理不是性能优化，它是基本功，没有可选的余地。

16
00:01:23,197 --> 00:01:32,343
放任不管的产品，跑着跑着就会变得又贵又笨，而用户只会觉得这个东西越来越不好用，说不出为什么。

17
00:01:32,500 --> 00:01:34,433
先看成本结构。

18
00:01:34,383 --> 00:01:40,537
用户发一句话，底层可能跑十轮以上循环、产生几十条接口消息。

19
00:01:40,537 --> 00:01:43,037
成本的大头有三个来源。

20
00:01:43,037 --> 00:01:49,503
第一个是系统提示词，它每一轮都要重复发送，轮次越多，重复消耗越大。

21
00:01:49,503 --> 00:01:58,085
第二个是工具结果，工具返回的文本通常很长，一整个文件的内容、一整页搜索结果，全都算钱。

22
00:01:58,085 --> 00:02:04,443
第三个是上下文累积，后面的轮次要带上前面所有消息，滚雪球式增长。

23
00:02:04,443 --> 00:02:14,250
所以结论很直接，智能体的成本随轮次指数增长，远超线性，因为每一轮都要把之前所有内容重新发给模型。

24
00:02:14,250 --> 00:02:18,914
你的用户每说一句话，你的账单上可能就多了十美分。

25
00:02:18,914 --> 00:02:21,775
再说说为什么对话越长越笨。

26
00:02:21,775 --> 00:02:23,097
三个理由。

27
00:02:23,097 --> 00:02:28,061
越长越贵，每轮重发全部历史，费用像滚雪球。

28
00:02:28,061 --> 00:02:36,847
越长越笨，模型的注意力是两头热、中间冷，开头和结尾的信息容易被记住，中间的最容易被忽略。

29
00:02:36,847 --> 00:02:44,563
越长越危险，上下文窗口有上限，满了之后最早的信息被直接丢弃，连个招呼都不打。

30
00:02:44,563 --> 00:02:50,645
还有一点值得提醒，成本随任务复杂度是指数增长的，不是线性。

31
00:02:50,645 --> 00:02:57,508
任务越复杂，循环轮次越多，而每一轮都要把之前所有内容重新发送一遍。

32
00:02:57,508 --> 00:03:05,717
所以你在设计功能的时候，多一个工具调用、多一轮自动重试，账单上都不是加一点，而是乘一截。

33
00:03:05,717 --> 00:03:10,657
这三个问题决定了同一件事，上下文不能放任不管。

34
00:03:10,800 --> 00:03:13,117
上下文太长了怎么办。

35
00:03:13,067 --> 00:03:17,719
全删不对，全留也不对，真正的答案是分三类处理。

36
00:03:17,719 --> 00:03:19,233
第一类可以删。

37
00:03:19,233 --> 00:03:24,978
旧的工具调用结果、已经处理完的中间步骤、重复的确认消息。

38
00:03:24,978 --> 00:03:29,053
这些东西处理完就没用了，留着只是占地方。

39
00:03:29,053 --> 00:03:30,844
第二类可以压缩。

40
00:03:30,844 --> 00:03:36,913
人工智能的长篇回复、多轮讨论的结论、搜索和查询的详细结果。

41
00:03:36,913 --> 00:03:41,757
它们有信息量，但不需要保留原文，用摘要替代就行。

42
00:03:41,757 --> 00:03:43,704
第三类绝不能动。

43
00:03:43,704 --> 00:03:48,404
用户的原始消息、系统提示词、关键的偏好设定。

44
00:03:48,404 --> 00:03:57,262
这个分类框架的价值在于，它把「要不要压缩」这个模糊的问题，变成了「这条属于哪一类」这个可以逐条判断的问题。

45
00:03:57,262 --> 00:04:04,377
好的压缩策略像一个有经验的编辑，知道什么是废话可以砍，什么是用户的原话必须留。

46
00:04:04,377 --> 00:04:06,457
看一个具体的例子。

47
00:04:06,457 --> 00:04:14,257
用户让助手查北京到上海的高铁，就这么一句话，背后跑了十轮、用掉四千二百词元。

48
00:04:14,257 --> 00:04:24,846
里面都有什么呢，一次车次查询返回十五条结果、八百字；一次座位查询返回一段五百字的数据；一次酒店搜索又回来六百字。

49
00:04:24,846 --> 00:04:28,632
可用户在意的其实只是最后那一句推荐。

50
00:04:28,632 --> 00:04:36,000
前面那八百字的车次列表，查完就再也不会看了，这就是最典型的可以直接删掉的部分。

51
00:04:36,000 --> 00:04:47,575
顺便说一句，压缩的优先级从高到低是，先删工具输出，再压缩人工智能的回复，最后才是用户消息，而用户消息基本永不触碰。

52
00:04:47,710 --> 00:04:51,662
用户说的话能不能删，这个问题值得单独讲。

53
00:04:51,612 --> 00:04:58,439
人工智能的输出可以摘要，工具结果可以截断，但用户的原话删了就回不来了。

54
00:04:58,439 --> 00:05:04,569
而且用户一定会发现，会直接问你，我明明说了这句话，你怎么忘了。

55
00:05:04,569 --> 00:05:06,215
原因很简单。

56
00:05:06,215 --> 00:05:11,227
用户输入的每一句话都承载着需求、偏好和上下文。

57
00:05:11,227 --> 00:05:15,686
一旦删除，丢的不只是信息，更是用户的信任。

58
00:05:15,686 --> 00:05:21,636
一句「连我说的话都记不住，这东西有什么用」，就足以让一个产品被放弃。

59
00:05:21,636 --> 00:05:28,499
所以原则很朴素，宁可删掉人工智能自己说的一千字，也别动用户说的十个字。

60
00:05:28,499 --> 00:05:31,444
再看压缩的两条技术路线。

61
00:05:31,444 --> 00:05:41,912
一条是本地压缩，用规则匹配、字符截断、模板替换，优点是零成本、延迟低于一毫秒，缺点是粗糙，可能丢关键信息。

62
00:05:41,912 --> 00:05:50,025
另一条是让模型读一遍写摘要，优点是精准，能保留核心语义，缺点是花钱，而且要一到五秒。

63
00:05:50,025 --> 00:05:54,088
答案不是二选一，是都用，但有严格顺序。

64
00:05:54,088 --> 00:05:56,203
推荐流程是三步。

65
00:05:56,203 --> 00:06:00,843
第一步本地截断，删掉工具输出、截断超长数据。

66
00:06:00,843 --> 00:06:05,013
第二步模板替换，把重复结构换成占位符。

67
00:06:05,013 --> 00:06:11,191
第三步检查还超不超窗口，还超，才进入花钱请模型做摘要的环节。

68
00:06:11,191 --> 00:06:19,076
先用免费的方法尽量压，实在压不下去了再花钱，这个顺序不能反，反了就是白白多花一笔钱。

69
00:06:19,220 --> 00:06:22,679
接下来是很多人会混淆的一对概念。

70
00:06:22,629 --> 00:06:28,507
上下文窗口像一块白板，写满了就写不下，对话结束就擦干净。

71
00:06:28,507 --> 00:06:35,333
长期记忆像一个笔记本，这次写下的，下次打开还在，可以翻页，也可以搜索。

72
00:06:35,333 --> 00:06:37,521
为什么需要两套系统。

73
00:06:37,521 --> 00:06:43,519
上下文窗口随时可用、读写极快，但容量有限，对话结束就消失。

74
00:06:43,519 --> 00:06:51,331
长期记忆跨会话保留、容量可以扩展，代价是写入需要做决策，检索需要额外的步骤。

75
00:06:51,331 --> 00:06:52,617
打个比方。

76
00:06:52,617 --> 00:06:59,913
上下文窗口就像开会时的白板，大家讨论时随手写写画画，会议结束就擦了。

77
00:06:59,913 --> 00:07:07,665
长期记忆就像会议纪要，有人负责整理关键结论，写进文档里，下次开会时翻出来参考。

78
00:07:07,665 --> 00:07:15,033
所以一个好的产品需要两套系统协作，上下文负责当场记住，记忆负责长远记住。

79
00:07:15,033 --> 00:07:19,660
把这两件事混在一起做，是很多产品记不住的根源。

80
00:07:19,660 --> 00:07:25,874
这里还有个常见误解，以为把上下文窗口开得足够大，就等于有了记忆。

81
00:07:25,874 --> 00:07:27,076
不是的。

82
00:07:27,076 --> 00:07:32,857
窗口再大也是一次性的，对话结束就清空，下次打开什么都不剩。

83
00:07:32,857 --> 00:07:40,502
真正的跨会话能力必须靠外部存储加检索，这是两套独立的系统，谁也替代不了谁。

84
00:07:40,650 --> 00:07:45,660
记忆系统最关键的不是能记多少，而是知道什么不该记。

85
00:07:45,610 --> 00:07:54,937
用户每天聊几十上百条消息，嗯、好的、哈哈这类语气词占了大半，真正有价值的偏好和事实可能只有几条。

86
00:07:54,937 --> 00:07:57,929
所以记忆系统需要一个守门员。

87
00:07:57,929 --> 00:08:00,706
守门员的判断标准很清楚。

88
00:08:00,706 --> 00:08:07,425
值得记的是用户的偏好、重要事实、长期习惯、明确表达的需求模式。

89
00:08:07,425 --> 00:08:13,951
不值得记的是语气词、一次性问题、没有信息量的闲聊、已经过时的临时信息。

90
00:08:13,951 --> 00:08:17,461
如果什么都记，记忆库很快变成垃圾场。

91
00:08:17,461 --> 00:08:19,973
守门员比记忆力更重要。

92
00:08:19,973 --> 00:08:22,388
感受一下守门员的工作量。

93
00:08:22,388 --> 00:08:36,812
十条消息里，可能有六条是嗯、好的、哈哈，两条是一次性的提问，比如今天天气怎么样，剩下真正值得记的也许只有两条，一条是他对某个品牌的偏好，一条是他现在用的设备。

94
00:08:36,812 --> 00:08:41,775
把这两条挑出来存好，比把十条全存进去有用得多。

95
00:08:41,775 --> 00:08:44,852
人会改主意，所以还要处理冲突。

96
00:08:44,852 --> 00:08:50,333
上个月说喜欢咖啡，这个月说改喝茶了，两条记忆打架，怎么办。

97
00:08:50,333 --> 00:08:51,800
四种策略。

98
00:08:51,800 --> 00:08:55,429
信息有明确新旧关系时，覆盖更新。

99
00:08:55,429 --> 00:08:58,675
新旧信息互补时，合并扩展。

100
00:08:58,675 --> 00:09:03,626
无法确定谁对时，标记冲突，两条都留着等用户确认。

101
00:09:03,626 --> 00:09:06,968
信息不够确定时，直接跳过不存。

102
00:09:06,968 --> 00:09:09,071
最后是注入的成本。

103
00:09:09,071 --> 00:09:16,619
记了一千条，每次全塞进系统提示词，简单但贵，而且噪声多，模型反而找不到重点。

104
00:09:16,619 --> 00:09:22,016
推荐做法是按需检索，每次只把最相关的三到十条注入。

105
00:09:22,016 --> 00:09:28,158
记忆的价值在于每次能拿出最相关的几条，记了多少条并不重要。

106
00:09:28,158 --> 00:09:37,521
好的记忆系统像一个称职的秘书，不会把整个档案柜搬到会议室，只会提前把今天需要的三份文件放在桌上。

107
00:09:37,521 --> 00:09:40,285
注入那一侧的差距也很直观。

108
00:09:40,285 --> 00:09:52,196
十条记忆全量塞进去还行，一百条开始就又贵又吵，一千条、一万条则完全不可行，因为绝大部分内容跟当前对话毫无关系，反而干扰判断。

109
00:09:52,196 --> 00:09:57,665
所以按需检索不是一项优化，它是唯一能扩展下去的方案。

110
00:09:57,810 --> 00:10:00,392
最后讲提示词的工程化。

111
00:10:00,342 --> 00:10:06,952
生产级的系统提示词不是想到什么写什么，它是分层管理的，四层各管各的。

112
00:10:06,952 --> 00:10:12,217
身份层回答我是谁，性格、角色、基本人设，几乎不变。

113
00:10:12,217 --> 00:10:21,988
环境层回答现在什么情况，用户基本信息、系统状态、会话上下文，每次会话可能不同，但同一会话内相对稳定。

114
00:10:21,988 --> 00:10:27,914
工具层回答能用什么，注册可调用的工具、参数格式、使用限制。

115
00:10:27,914 --> 00:10:35,101
行为层回答怎么行动，回答风格、决策优先级、安全护栏，这是迭代最频繁的一层。

116
00:10:35,101 --> 00:10:37,493
先看一坨文本长什么样。

117
00:10:37,493 --> 00:10:52,229
名字叫什么、可以搜索能读写文件、现在是二零二六年、用户在中国、搜索时用什么工具、回答要思考再答、性格温暖友善、文件操作用什么工具、语言偏好中文、不确定就直说。

118
00:10:52,229 --> 00:10:56,496
身份、环境、工具、行为全搅在一起。

119
00:10:56,496 --> 00:11:03,839
改一处可能影响全部，而且谁也说不清哪一段影响了哪个行为，出了问题只能靠猜。

120
00:11:03,839 --> 00:11:12,830
改一层不影响其他层，加个新工具只改工具层，调整回答风格只动行为层，不会牵一发而动全身。

121
00:11:12,830 --> 00:11:21,195
多人协作不冲突，产品改行为、工程师加工具、运营调人设，各改各的文件，合并的时候不打架。

122
00:11:21,195 --> 00:11:28,659
对照测试更精准，想试不同的回答策略，只替换行为层，其他三层不变，变量单一。

123
00:11:28,659 --> 00:11:38,767
排查问题也更容易，行为异常的时候按层检查，到底是身份搞错了、环境信息过时、工具描述有误，还是规则之间冲突。

124
00:11:38,767 --> 00:11:41,315
顺带说清技能这一层。

125
00:11:41,315 --> 00:11:48,827
系统提示词管我是谁，工具管我能做什么，技能管的是遇到某件事怎么一步一步做好。

126
00:11:48,827 --> 00:12:04,841
一份技能包含四部分，触发条件，也就是什么情况下启用；允许的工具列表，用白名单控制风险；执行流程，从头到尾先做什么再做什么；输出格式要求，规定最终产出的格式、长度和风格。

127
00:12:04,841 --> 00:12:07,773
为什么不直接写进系统提示词。

128
00:12:07,773 --> 00:12:17,653
因为系统提示词是全局的，改一处影响所有场景；而技能是按需加载的，只在匹配时注入，不会污染其他任务的行为。

129
00:12:17,653 --> 00:12:25,129
而且技能是独立文件，可以单独做版本管理，谁改了什么、什么时候改的，一目了然。

130
00:12:25,129 --> 00:12:30,670
文件即配置，改了就生效，像管理代码一样管理行为指引。

131
00:12:30,670 --> 00:12:33,194
第二个原则是按需加载。

132
00:12:33,194 --> 00:12:44,108
如果你有一百个工具，把全部描述塞进系统提示词，光工具描述就要占掉大约三万四千词元；按需加载只需要大约两千八百。

133
00:12:44,108 --> 00:12:50,718
做法三步，首轮只给名字列表，用到时再展开完整描述，用完就收回。

134
00:12:50,718 --> 00:12:56,523
就像公司通讯录，你不需要每个人的完整简历，只需要名字和职位。

135
00:12:56,523 --> 00:13:00,550
第三个原则和缓存有关，也是最容易被忽视的。

136
00:13:00,550 --> 00:13:06,764
缓存的规则极其简单，前缀一模一样就命中，差一个字就全部重算。

137
00:13:06,764 --> 00:13:13,398
所以往系统提示词里插入任何动态内容，都可能让缓存永远打不中。

138
00:13:13,398 --> 00:13:20,297
最典型的是时间戳，每一秒指纹都不同，缓存永远落空，成本直接翻倍。

139
00:13:20,297 --> 00:13:28,038
不只是时间，技能内容、用户标识、会话标记，任何会变的东西都不该出现在前缀里。

140
00:13:28,038 --> 00:13:30,334
技能也有同样的讲究。

141
00:13:30,334 --> 00:13:43,254
把技能插进系统提示词里，切换技能时前缀就变了，缓存失效；把技能作为独立消息追加在系统提示词之后，系统部分永远不变，前缀缓存始终命中。

142
00:13:43,254 --> 00:13:50,442
结论一句话，把所有可能变化的内容放到系统提示词之后，让前缀永远稳定。

143
00:13:50,590 --> 00:13:54,866
最后给你一份可以马上用的判断清单，一共五条。

144
00:13:54,816 --> 00:13:58,026
第一条，重新理解一次对话的成本。

145
00:13:58,026 --> 00:14:04,877
它不是按用户说了几句话算的，而是按底层跑了多少轮、每轮带了多少内容算的。

146
00:14:04,877 --> 00:14:12,941
成本大头有三个，系统提示词的重复发送、工具返回的超长结果、以及滚雪球的上下文累积。

147
00:14:12,941 --> 00:14:16,151
成本随轮次指数增长，不是线性。

148
00:14:16,151 --> 00:14:21,499
第二条，把上下文压缩当成一项基本功，而不是优化项。

149
00:14:21,499 --> 00:14:32,172
判断框架是三类，工具输出可以直接删，模型回复和搜索结果可以压成摘要，用户原话、系统提示词和关键偏好绝不能动。

150
00:14:32,172 --> 00:14:38,362
记住那句话，宁可删掉模型自己说的一千字，也别动用户说的十个字。

151
00:14:38,362 --> 00:14:42,160
第三条，压缩的顺序是先免费后花钱。

152
00:14:42,160 --> 00:14:48,566
先用本地规则截断、删除和模板替换，压不下去了再调用模型做摘要。

153
00:14:48,566 --> 00:14:52,641
这两者是流水线上的先后环节，不是二选一。

154
00:14:52,641 --> 00:14:56,836
第四条，把上下文和记忆当成两套系统。

155
00:14:56,836 --> 00:15:00,742
白板负责当场记住，笔记本负责长远记住。

156
00:15:00,742 --> 00:15:15,417
记忆系统要有守门员，只记偏好、事实、习惯和需求模式，不记语气词和闲聊；冲突时有覆盖、合并、标记、跳过四种策略；注入时按需检索三到十条，不要全量塞进去。

157
00:15:15,417 --> 00:15:20,021
第五条，系统提示词必须分层，且前缀必须稳定。

158
00:15:20,021 --> 00:15:25,778
身份、环境、工具、行为四层各管各的，迭代时互不影响。

159
00:15:25,778 --> 00:15:29,420
工具描述按需加载，用得到再展开。

160
00:15:29,420 --> 00:15:37,581
最重要的是，所有会变的内容都放在系统提示词之后，让前缀永远不变，缓存才能持续命中。

161
00:15:37,581 --> 00:15:44,288
这五条的共同点是，它们都在回答同一个问题，怎么让一次对话既便宜又可靠。

162
00:15:44,288 --> 00:15:49,901
答案不在模型里，在你对上下文、记忆和提示词的设计里。