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

2
00:00:06,382 --> 00:00:09,543
这一集是工程可行性这一章的收官。

3
00:00:09,543 --> 00:00:28,801
前面几集我们分别讲了工具设计、长运行、安全这些主题，这一集要做两件事，一是把整章的知识地图合起来，二是把几个还没落地的动手环节补齐，包括怎么搭第一个评测集，怎么给智能体立规矩，怎么用流程控制把返工拦在动手之前。

4
00:00:28,801 --> 00:00:31,181
先说本集解决什么问题。

5
00:00:31,181 --> 00:00:41,362
学到这里，你手里已经攒了一堆概念，设计模式、上下文工程、工具设计、评测、长运行、安全、检索增强。

6
00:00:41,362 --> 00:00:45,051
但概念是散的，散的知识点没法用。

7
00:00:45,051 --> 00:00:51,398
这一集把它们串成一张地图，并且给你三条能压住整张地图的底层原则。

8
00:00:51,398 --> 00:00:54,234
再说为什么产品经理要关心。

9
00:00:54,234 --> 00:01:03,056
因为这一章真正的分水岭，不是你会不会用某个工具，而是你能不能判断什么时候该加复杂度、什么时候该砍掉它。

10
00:01:03,056 --> 00:01:08,369
这个判断力，决定你带的项目是越做越轻，还是越做越重。

11
00:01:08,369 --> 00:01:10,196
顺便交代结构。

12
00:01:10,196 --> 00:01:24,270
前半段是回顾和原则，把七大主题和三条原则讲清楚；中段讲两件最容易被跳过的事，评测和规则；后半段讲流程控制和组件调试，最后给你一份可以带走的判断清单。

13
00:01:24,270 --> 00:01:27,239
我还想说一句关于这一集的定位。

14
00:01:27,239 --> 00:01:31,217
收官集最容易写成流水账，我尽量不这么干。

15
00:01:31,217 --> 00:01:35,652
每一块我都会给一个具体动作，你听完就能做。

16
00:01:35,788 --> 00:01:46,182
设计模式这块，五种工作流模式加自主智能体，分别是提示词链、路由、并行、编排者与执行者、评估者与优化者。

17
00:01:46,132 --> 00:01:52,034
核心原则是先简单后复杂，从最简方案起步，不够了再升级。

18
00:01:52,034 --> 00:01:56,661
上下文工程这块，是从提示词工程进化过来的。

19
00:01:56,661 --> 00:02:02,370
上下文窗口是稀缺资源，每个词元都有成本，注意力预算有限。

20
00:02:02,370 --> 00:02:06,517
信息的筛选和组织，比信息量本身更重要。

21
00:02:06,517 --> 00:02:12,563
工具设计这块，智能体和计算机之间的接口，是智能体和世界的契约。

22
00:02:12,563 --> 00:02:19,197
四条原则，给思考空间、贴近训练数据、减少格式开销、防呆设计。

23
00:02:19,197 --> 00:02:23,740
而且工具设计这件事，可以用智能体自己来优化。

24
00:02:23,740 --> 00:02:33,656
评测这块，三种评判模式，用代码判、用模型判、用人判，对应三个核心陷阱，噪音、作弊、退化。

25
00:02:33,656 --> 00:02:38,055
没有评测就没有优化，但评测本身也需要被评测。

26
00:02:38,055 --> 00:02:42,635
长运行这块，双角色的外壳架构，脑和手分开。

27
00:02:42,635 --> 00:02:48,236
会话不等于上下文，上下文会超窗口、会过期、会漂移。

28
00:02:48,236 --> 00:02:52,695
结构化日志和检查点，是长跑可靠性的关键。

29
00:02:52,695 --> 00:03:00,507
安全这块，三类风险，滥用、失控、外部攻击；双层防线，模型层加环境层。

30
00:03:00,507 --> 00:03:05,736
结构性凭证隔离，生成的代码和密钥永远不在同一个地方。

31
00:03:05,736 --> 00:03:14,281
检索增强这块，带上下文的检索解决了传统检索的老问题，片段一旦脱离上下文，信息就丢了。

32
00:03:14,281 --> 00:03:19,882
给每个片段加一段上下文前缀，检索失败率降低百分之六十七。

33
00:03:19,882 --> 00:03:23,704
这七块合起来，再看三条压舱石原则。

34
00:03:23,704 --> 00:03:27,454
第一，做最简单的、能跑的东西。

35
00:03:27,454 --> 00:03:37,010
大多数问题不需要智能体，甚至不需要工作流，先用一个好提示词试试，不够再加复杂度，每一层复杂度都是成本。

36
00:03:37,010 --> 00:03:39,774
第二，上下文是稀缺资源。

37
00:03:39,774 --> 00:03:47,322
把上下文窗口当无限垃圾桶，不但费钱，还会稀释注意力，降低输出质量，少即是多。

38
00:03:47,322 --> 00:03:51,048
第三，结构性安全大于提示词安全。

39
00:03:51,048 --> 00:03:58,103
不要指望在提示词里写一句别做坏事，要靠架构让危险操作在结构上不可能发生。

40
00:03:58,103 --> 00:04:06,036
这三条原则有个共同点，都在回答同一个问题，怎么用最小的代价，拿到最大的确定性。

41
00:04:06,172 --> 00:04:11,530
这一节讲从公开源码里读出来的三条教训，每一条都反直觉。

42
00:04:11,480 --> 00:04:15,903
第一条，智能体的核心是状态管理，不是智能。

43
00:04:15,903 --> 00:04:24,257
所有工程化问题最后都归结成同一个问题，什么信息在什么时候、以什么形式出现在上下文窗口里。

44
00:04:24,257 --> 00:04:32,706
模型的智能是预训练给的，你控制不了；但上下文的构建、裁剪、排列，是工程师能决定的。

45
00:04:32,706 --> 00:04:45,975
所以你会发现，成熟产品的大部分工程复杂度，都花在精心管理上下文上，什么该放进去、什么该拿出来、什么时候压缩、什么时候重置，让模型变聪明反倒是次要的。

46
00:04:45,975 --> 00:04:50,555
第二条，外壳代码编码的是假设，而假设会过时。

47
00:04:50,555 --> 00:04:55,843
你今天写的每一行脚手架，都隐含着对当前模型能力的假设。

48
00:04:55,843 --> 00:04:59,701
当模型升级，这些假设可能全部失效。

49
00:04:59,701 --> 00:05:02,358
素材里有个很具体的例子。

50
00:05:02,358 --> 00:05:11,949
某一代模型存在上下文焦虑，对话一长表现就明显下降，团队为此加了上下文重置机制，定期压缩上下文。

51
00:05:11,949 --> 00:05:18,572
后来模型换代，焦虑现象消失了，那个重置机制反而成了降低效率的累赘。

52
00:05:18,572 --> 00:05:23,271
启示很直接，你今天写的脚手架，明天可能就得扔掉。

53
00:05:23,271 --> 00:05:27,514
第三条，模型在变强，你的工程在变简单。

54
00:05:27,514 --> 00:05:34,930
重试、纠错、格式化、上下文压缩这些辅助逻辑，会随着模型能力提升变得不必要。

55
00:05:34,930 --> 00:05:40,110
所以最好的工程决策是，今天不写明天可能不需要的代码。

56
00:05:40,110 --> 00:05:42,249
但这不是说不做工程。

57
00:05:42,249 --> 00:05:52,009
恰恰相反，真正稀缺的能力是判断力，判断哪些逻辑会随模型进步而过时，哪些是真正持久的架构决策。

58
00:05:52,009 --> 00:06:02,177
沙箱隔离、权限分层、评测体系不会过时；而特定的提示词技巧、特定模型的绕道方案，半年后可能就不需要了。

59
00:06:02,177 --> 00:06:06,180
这条判断力，其实也是给产品经理的一个提醒。

60
00:06:06,180 --> 00:06:09,978
别把一时的手段，当成长期的资产。

61
00:06:10,132 --> 00:06:13,002
这一节解决一个非常具体的问题。

62
00:06:12,952 --> 00:06:17,219
前面几格你都是靠眼睛验收的，量小还行。

63
00:06:17,219 --> 00:06:25,428
但你马上会遇到那个经典困境，改了一版提示词，这三个用例变好了，那两个悄悄变差了，你没发现。

64
00:06:25,428 --> 00:06:29,503
没有评测集，变差的那两个你永远看不见。

65
00:06:29,503 --> 00:06:35,368
评测集本身不神秘，就是一堆固定的输入，各配一条什么算过的标准。

66
00:06:35,368 --> 00:06:41,943
神奇的地方在跑分那一刻，你以为的全面提升，往往是三条升、两条降。

67
00:06:41,943 --> 00:06:48,950
素材里有个演示，同一套五条用例，跑一版提示词，结果是五条过了三条。

68
00:06:48,950 --> 00:06:57,856
带数字的月报过了，超长文档漏掉了后半段的关键结论，挂了；信息缺失时编了一个数字，也挂了。

69
00:06:57,856 --> 00:07:02,219
这个三条是基线，它是后面所有改动的参照物。

70
00:07:02,219 --> 00:07:05,007
评测有三个坑，必须记住。

71
00:07:05,007 --> 00:07:07,748
第一，跑分时顺手改用例。

72
00:07:07,748 --> 00:07:10,873
用例一改，前后分数就没法比。

73
00:07:10,873 --> 00:07:14,815
加用例可以，改用例就得全量重跑基线。

74
00:07:14,815 --> 00:07:16,931
第二，只看总分。

75
00:07:16,931 --> 00:07:23,084
五条里过四条，一定比过三条好吗，先看挂的那条是不是原来能过的。

76
00:07:23,084 --> 00:07:26,077
第三，标准写成回答质量高。

77
00:07:26,077 --> 00:07:33,866
这种标准没法判定，要写成包含下周计划、数字与原文一致这种一眼能裁决的句子。

78
00:07:33,866 --> 00:07:37,964
判不了的，才轮到用模型当裁判出场。

79
00:07:37,964 --> 00:07:39,575
动手分三档。

80
00:07:39,575 --> 00:07:43,745
第一档，攒十条真实用例，十五分钟就能做。

81
00:07:43,745 --> 00:07:49,046
从你真实用过的输入里挑，配比是七条日常、三条刁钻。

82
00:07:49,046 --> 00:07:54,010
刁钻的从翻车记录里捞，那些让它翻过车的输入最值钱。

83
00:07:54,010 --> 00:07:59,899
做完的标志是，十条都是真实输入，其中至少两条是它翻过车的。

84
00:07:59,899 --> 00:08:04,947
第二档，给每条写通过标准，跑出基线分，大概一小时。

85
00:08:04,947 --> 00:08:13,036
标准必须一眼能裁决，比如输出恰好三段、结论里包含某个词、没有编造原文以外的数字。

86
00:08:13,036 --> 00:08:16,257
写完全跑一遍，记下第一个基线分。

87
00:08:16,257 --> 00:08:20,620
第三档，改一版提示词，用分数说话，半天。

88
00:08:20,620 --> 00:08:23,613
用例一条不动，全量重跑对比。

89
00:08:23,613 --> 00:08:28,950
重点盯两处，总分变了多少，有没有原来过的用例反而挂了。

90
00:08:28,950 --> 00:08:32,928
有退化不丢人，把退化那条和原因记下来。

91
00:08:32,928 --> 00:08:43,733
当你能说出这样一句话，这版改动让分数从六分到八分，代价是某条从过变挂，原因是新规则太保守，这一关就立住了。

92
00:08:43,876 --> 00:08:48,285
接下来换个场景，讲人和智能体一起写代码。

93
00:08:48,235 --> 00:08:59,833
靠自然语言让它直接产出代码，这种方式的问题出在质量上，没有规矩的智能体会返工、漏改、悄悄删代码、留下永久技术债。

94
00:08:59,833 --> 00:09:05,795
素材里归纳了四类典型事故，根源是同一件事，约束没有进入上下文。

95
00:09:05,795 --> 00:09:08,235
第一类，理解偏差返工。

96
00:09:08,235 --> 00:09:14,064
它拿到需求就开始写，写了二百行才发现理解有偏差，回滚重来。

97
00:09:14,064 --> 00:09:20,001
更糟的是改了七个文件之后才发现思路错了，逐个回退成本极高。

98
00:09:20,001 --> 00:09:22,105
第二类，选型漂移。

99
00:09:22,105 --> 00:09:31,312
不同对话里它会选不同框架，今天用这个后端框架，明天换另一个；数据库一会儿文档型、一会儿关系型。

100
00:09:31,312 --> 00:09:35,626
技术栈没有锁定，项目就在漂移中失去一致性。

101
00:09:35,626 --> 00:09:37,934
第三类，善意破坏。

102
00:09:37,934 --> 00:09:46,540
它重构时会清理自己认为多余的代码，事后才发现那段代码有用，善意的清理变成了破坏性操作。

103
00:09:46,540 --> 00:09:48,992
第四类，永久技术债。

104
00:09:48,992 --> 00:09:59,713
你让它做一个完整认证系统，它说先做简版登录，后续再加第三方登录，结果后续永远不会来，简版代码成了永久的技术债。

105
00:09:59,713 --> 00:10:02,189
那约束怎么注入才最稳。

106
00:10:02,189 --> 00:10:09,953
素材做了一个存活测试，同一条约束，数据库用关系型，在三个时点看它还生效不生效。

107
00:10:09,953 --> 00:10:15,723
结论是，写十遍务必，都比不过一个每轮自动加载的规则文件。

108
00:10:15,723 --> 00:10:22,489
规则文件里有几行开关，控制它是对所有对话自动生效，还是按需手动引用。

109
00:10:22,489 --> 00:10:30,386
全局编码规范适合自动生效，写作规范这类就该按需引用，避免污染编码对话的上下文。

110
00:10:30,386 --> 00:10:34,328
这里有个方法论，我觉得是整节最值钱的一句。

111
00:10:34,328 --> 00:10:38,475
规则的价值不在于多，每条都解决一个真实问题。

112
00:10:38,475 --> 00:10:42,117
它每反复犯一次错，就把它变成一条规则。

113
00:10:42,117 --> 00:10:45,963
这就是把踩过的坑，变成资产的方式。

114
00:10:46,108 --> 00:10:57,524
这一节把软件工程里的需求确认环节，搬进人机协作，核心是让它在动手之前，先复述需求、写出产品需求文档、拿到明确许可。

115
00:10:57,474 --> 00:10:59,770
为什么必须给具体步骤。

116
00:10:59,770 --> 00:11:07,330
因为请先确认理解后再编码这句话太模糊，它会自己判断我已经理解了，然后直接动手。

117
00:11:07,330 --> 00:11:13,508
写明写产品需求文档、等待许可这类具体动作，它才会真的停下来。

118
00:11:13,508 --> 00:11:25,166
实际使用中，简单的一行改动它会自己判断不需要文档，这套流程主要拦截多文件变更和新功能开发，也就是返工成本最高的那类任务。

119
00:11:25,166 --> 00:11:28,051
第二个机制是批量修改断点。

120
00:11:28,051 --> 00:11:35,106
规则原文是，修改超过三个文件时，必须先列出修改计划并等待确认后再动手。

121
00:11:35,106 --> 00:11:37,786
修改计划要写三样东西。

122
00:11:37,786 --> 00:11:48,772
第一，要改哪些文件，给出完整清单，人先看范围对不对、再看内容，清单本身就能暴露异常，比如这个需求为什么要动配置文件。

123
00:11:48,772 --> 00:11:56,705
第二，每个文件改什么，逐文件写清楚，避免它借着一次需求，顺手做无关的重构和清理。

124
00:11:56,705 --> 00:12:06,356
第三，改动之间的依赖关系，先改哪个、后改哪个，防止连续改一串文件后才发现思路有误，回滚成本过高。

125
00:12:06,356 --> 00:12:13,532
三个文件这个阈值是经验值，谨慎的项目可以调成一个，快速原型可以放宽到五个。

126
00:12:13,532 --> 00:12:16,849
第三个机制是新增功能前的查重。

127
00:12:16,849 --> 00:12:25,719
问题在于它不知道项目里已经有轮子，它的上下文只有当前对话，看不到三个月前另一个对话里写的工具函数。

128
00:12:25,719 --> 00:12:31,993
不加约束，同一个日期格式化函数会被写四遍，每遍行为还略有不同。

129
00:12:31,993 --> 00:12:45,238
所以规则要求，新增功能前必须先搜索项目中是否已有类似实现，搜索范围包括相关目录的函数名、类名、工具方法，找到已有实现时优先复用或扩展。

130
00:12:45,238 --> 00:12:49,830
这三道关卡有个共同点，断点都设在动手之前。

131
00:12:49,830 --> 00:12:59,794
复述和文档拦截理解偏差，修改计划拦截连锁错改，查重拦截重复造轮子，三道关卡都比事后回滚便宜。

132
00:12:59,932 --> 00:13:03,812
最后一节讲一个很小但很实用的工程习惯。

133
00:13:03,762 --> 00:13:10,649
界面功能直接写进页面，改一处影响一片，调一个按钮要把整个页面跑起来。

134
00:13:10,649 --> 00:13:18,690
解法是先做独立的组件试验场，每个界面元素有单独的演示，调好了再集成进正式页面。

135
00:13:18,690 --> 00:13:21,502
原理很简单，就是隔离调试。

136
00:13:21,502 --> 00:13:32,536
在试验场里怎么改，都不会影响页面上其他东西，样式和业务逻辑互不干扰，调好的参数直接抄进正式组件，集成时它已经是成品。

137
00:13:32,536 --> 00:13:50,052
对比一下直接写进页面，同样是调这个按钮，你得先把整个页面跑起来，登录、拉数据、切到目标状态，才能看到它一眼；而且样式和业务逻辑纠缠在一起，圆角改大了，可能挤歪旁边的布局，牵一发动全身。

138
00:13:50,052 --> 00:13:55,232
它和业界标准的组件展示工具思路一致，但成本不同。

139
00:13:55,232 --> 00:14:00,641
那个标准方案配置太重，对快速原型项目属于过度设计。

140
00:14:00,641 --> 00:14:07,684
试验场取它的思路，用一个静态页面把所有组件演示排在一起，成本几乎为零。

141
00:14:07,684 --> 00:14:09,956
三条维护规则要记住。

142
00:14:09,956 --> 00:14:19,078
第一，涉及页面动效时，必须先创建静态试验场，用于自由调整和测试组件，之后才允许写进正式页面。

143
00:14:19,078 --> 00:14:27,528
第二，需求变化后必须同步更新试验场，保证演示始终反映组件的最新形态，别让它变成过期的摆设。

144
00:14:27,528 --> 00:14:30,557
第三，演示只增改、不删除。

145
00:14:30,557 --> 00:14:38,730
功能需求取消了，对应演示也要留着，它是设计过程的历史存档，未来复活需求时直接捡回来用。

146
00:14:38,730 --> 00:14:42,720
如果项目涉及对话功能，还有两条额外要求。

147
00:14:42,720 --> 00:14:50,665
第一，试验场里必须实现一个简单的对话测试页面，脱离完整业务流程也能单独调一轮对话。

148
00:14:50,665 --> 00:14:54,727
第二，页面上必须列出项目用到的所有提示词。

149
00:14:54,727 --> 00:15:03,321
提示词是产品的核心资产，藏在代码字符串里没法调试，摊开在页面上才能快速对比和调整。

150
00:15:03,321 --> 00:15:08,093
一句话总结，组件先在试衣间里调好，再走上台。

151
00:15:08,093 --> 00:15:13,706
用一个静态页面的成本，换来组件与业务逻辑的双向隔离。

152
00:15:13,852 --> 00:15:18,128
最后给你一份可以马上用的判断清单，一共五条。

153
00:15:18,078 --> 00:15:23,223
第一条，先问自己，这是不是最简单的、能跑的东西。

154
00:15:23,223 --> 00:15:27,393
大多数问题不需要智能体，甚至不需要工作流。

155
00:15:27,393 --> 00:15:31,264
先用一个好提示词试试，不够再加复杂度。

156
00:15:31,264 --> 00:15:40,398
同时记住，判断哪些逻辑会随模型进步而过时、哪些是真正持久的架构决策，这是最稀缺的工程能力。

157
00:15:40,398 --> 00:15:43,860
第二条，把上下文当稀缺资源来管。

158
00:15:43,860 --> 00:15:47,357
每个词元都有成本，注意力预算有限。

159
00:15:47,357 --> 00:15:56,336
什么信息在什么时候、以什么形式出现在窗口里，这个问题的答案，比模型本身有多聪明，更影响最终结果。

160
00:15:56,336 --> 00:15:59,977
第三条，别用感觉验收，用评测集。

161
00:15:59,977 --> 00:16:06,528
攒十条真实用例，七条日常、三条刁钻，其中至少两条是它翻过车的。

162
00:16:06,528 --> 00:16:10,903
每条配一句一眼能裁决的通过标准，跑出基线分。

163
00:16:10,903 --> 00:16:15,566
改动用例不动，全量重跑，盯总分和退化这两处。

164
00:16:15,566 --> 00:16:21,348
第四条，给智能体立规矩，并且把约束做成自动加载的规则文件。

165
00:16:21,348 --> 00:16:25,002
每反复犯一次错，就把它变成一条规则。

166
00:16:25,002 --> 00:16:33,956
同时守住三道断点，动手前复述、写文档、等许可，超过三个文件先列计划，新增功能前先查重。

167
00:16:33,956 --> 00:16:38,427
第五条，界面组件先在试验场里调好再上台。

168
00:16:38,427 --> 00:16:43,727
涉及动效必须先建，需求变了同步更新，演示只增不删。

169
00:16:43,727 --> 00:16:50,266
涉及对话的项目，还要有独立的对话测试页，并且把所有提示词摊在页面上。

170
00:16:50,266 --> 00:16:53,018
这五条背后是同一个态度。

171
00:16:53,018 --> 00:17:01,612
工程的价值不在于你加了多少东西，而在于你砍掉了多少不必要的东西，同时把真正持久的判断留下来。

172
00:17:01,612 --> 00:17:05,915
这一章到这儿收官，下一章我们进入产品手感。