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

2
00:00:06,382 --> 00:00:15,084
这一集讲规则，也就是你怎么把和人工智能协作中一次次翻车的教训，变成它每次都能稳定执行的指令。

3
00:00:15,084 --> 00:00:17,463
先说本集解决什么问题。

4
00:00:17,463 --> 00:00:26,009
很多人和人工智能协作，反复遇到同一类问题，每次都靠临场叮嘱解决，聊完就忘，下次再犯。

5
00:00:26,009 --> 00:00:37,355
这一集给你一套把教训沉淀成规则的方法，包括环境事实怎么写、破坏性操作怎么设闸、长对话怎么对抗遗忘、以及文案怎么摆脱机器腔。

6
00:00:37,355 --> 00:00:40,192
再说为什么产品经理要关心。

7
00:00:40,192 --> 00:00:43,750
因为这套东西的本质是产品化的思维。

8
00:00:43,750 --> 00:00:49,591
注意质量这四个字执行不了，删除代码前必须显式声明才执行得了。

9
00:00:49,591 --> 00:00:58,858
把模糊期望翻译成具体动作，本来就是产品经理的核心能力，只不过这一次的交付对象不是人，是一段规则。

10
00:00:58,858 --> 00:01:01,346
顺带说清这一集的结构。

11
00:01:01,346 --> 00:01:12,367
前两节讲环境事实和三个具体的坑，中间两节讲破坏性操作的闸门和长对话锚定，最后两节讲写作规范和四步协作流程。

12
00:01:12,367 --> 00:01:16,310
你可以按自己项目当前最疼的那个问题挑着听。

13
00:01:16,310 --> 00:01:18,701
还有一层更现实的考虑。

14
00:01:18,701 --> 00:01:24,567
这一课的来源只有一个，每发现一次它反复犯的错误，就加一条规则。

15
00:01:24,567 --> 00:01:30,276
所以规则的价值不在于多，而在于每条背后都对应一次真实的翻车。

16
00:01:30,276 --> 00:01:33,449
照搬十四章，不如精选五章。

17
00:01:33,449 --> 00:01:37,211
规则和代码一样，没人维护就会腐烂。

18
00:01:37,370 --> 00:01:39,543
先看一个高频场景。

19
00:01:39,493 --> 00:01:46,092
每次新开对话，它都不知道该调哪个模型、超时设多少、项目用什么框架。

20
00:01:46,092 --> 00:01:49,301
你把这些环境事实写在哪里最稳。

21
00:01:49,301 --> 00:01:53,820
第一个选项是写进环境变量配置文件，让它自己读。

22
00:01:53,820 --> 00:01:56,741
问题是它不一定每次都主动去读。

23
00:01:56,741 --> 00:02:01,765
第二个选项是写在对话里，可对话一长就被截断遗忘。

24
00:02:01,765 --> 00:02:10,130
第三个选项是写进规则文件，规则在每轮对话开始之前就被加载进上下文，这是最稳的注入方式。

25
00:02:10,130 --> 00:02:13,784
一份环境配置章节应该包含哪些事实。

26
00:02:13,784 --> 00:02:19,048
第一是模型配置和接口服务商，一次写死，轮轮生效。

27
00:02:19,048 --> 00:02:33,772
第二是超时，比如图像生成至少要一百二十到一百八十秒，而很多网络客户端默认三十秒超时就会失败，它还会反复尝试同一个错误配置，所以要把超时值写进规则一次解决。

28
00:02:33,772 --> 00:02:43,303
第三是代理回退，网络请求失败时必须先尝试代理重试，仍然失败才向用户报告，禁止跳过代理直接报错。

29
00:02:43,303 --> 00:02:51,332
第四是流式，前端可见的所有大模型响应必须流式返回，只有后端内部调用才允许非流式。

30
00:02:51,332 --> 00:02:53,255
还有技术栈锁定。

31
00:02:53,255 --> 00:03:06,464
后端用什么框架、前端用什么框架和样式方案、数据库用什么、向量库用什么，一旦定了就不再讨论替代方案，它的职责是在确定的技术栈里把代码写好。

32
00:03:06,464 --> 00:03:10,647
选型是人的决策，不是它每次重新讨论的议题。

33
00:03:10,647 --> 00:03:18,447
端口也要写清规则，比如避开五千，从八千到九千随机分配，这样多个项目同时开也不冲突。

34
00:03:18,447 --> 00:03:23,604
为什么这件事值得单独做成规则，而不是每次口头交代。

35
00:03:23,604 --> 00:03:27,125
因为环境事实有个特点，它们几乎不变。

36
00:03:27,125 --> 00:03:34,505
几乎不变的东西就应该一次性写死，然后每一轮自动带入，而不是靠对话重新传递。

37
00:03:34,505 --> 00:03:41,560
这和你把数据库连接串写进配置文件是同一个道理，只不过这里的对象是模型。

38
00:03:41,710 --> 00:03:44,280
第一个坑是中文输入法。

39
00:03:44,230 --> 00:03:53,941
用中文输入法确认候选词时会触发回车，只判断按键是回车就发送的输入框，会把半段内容直接发出去。

40
00:03:53,941 --> 00:04:07,511
正确做法是同时检查输入法组合状态的标记，组合中为真是正在选词，回车只确认候选词，不触发发送；组合中为假才是普通键盘输入，回车正常发送。

41
00:04:07,511 --> 00:04:12,811
这个标记在训练数据里覆盖率不高，不写进规则，它一定会忘。

42
00:04:12,811 --> 00:04:15,672
第二个坑是数据格式的选择。

43
00:04:15,672 --> 00:04:20,768
这里有个三分法，三种格式各管一个领域，互不混用。

44
00:04:20,768 --> 00:04:26,730
为什么工具调用推荐用标签格式而不是键值格式，看一个对比就明白了。

45
00:04:26,730 --> 00:04:38,869
同样一个发消息的工具调用，键值版本要在字符串里再套一层键值，每层嵌套翻一倍反斜杠，模型逐词生成的时候极易配错括号和引号。

46
00:04:38,869 --> 00:04:43,196
而标签版本标签闭合直观，出错率明显更低。

47
00:04:43,196 --> 00:04:52,763
当然也有例外，如果你的项目只用某一个系列的模型，可以把工具调用改回键值格式，因为它的函数调用原生就是键值。

48
00:04:52,763 --> 00:04:58,545
所谓智能体用标签格式，是多模型混用场景下的最大公约数选择。

49
00:04:58,545 --> 00:05:01,838
第三个坑是图标这类细节规范。

50
00:05:01,838 --> 00:05:16,525
比如禁止用表情符号当按钮图标，图标必须用矢量图形；按产品调性选图标集，企业服务类用线性风格，温暖调性用另一种；图标要下载到本地使用，不依赖公共网络。

51
00:05:16,525 --> 00:05:21,069
这些看起来琐碎，但每一条都对应一次真实的返工。

52
00:05:21,069 --> 00:05:27,499
还有一个细节，这类环境规则要写到数值和路径，而不是描述性语言。

53
00:05:27,499 --> 00:05:33,112
写超时设长一点没有用，写图像生成超时设一百二十秒才有用。

54
00:05:33,112 --> 00:05:39,518
写记得用代理没有用，写失败时先尝试本地代理端口重试才有用。

55
00:05:39,670 --> 00:05:50,064
发版的时候以为只改了某个功能，实际改动里混进了上周调试另一个功能的临时改动，半成品代码就这么进了生产环境。

56
00:05:50,014 --> 00:05:55,519
数据库、配置、部署这些不可逆操作，必须在执行之前设闸。

57
00:05:55,519 --> 00:05:57,274
第一道闸是备份。

58
00:05:57,274 --> 00:06:03,692
数据库改动先备份，备份放在项目根目录的备份文件夹下，命名带上时间戳。

59
00:06:03,692 --> 00:06:08,981
没有备份，不得执行任何迁移、删除、改结构的操作。

60
00:06:08,981 --> 00:06:12,442
成本是一行命令，赌的是整库数据。

61
00:06:12,442 --> 00:06:14,557
第二道闸是回退方案。

62
00:06:14,557 --> 00:06:25,050
不可逆操作之前，必须先说出回退方案，而且要回答三件事，怎么恢复到操作前的状态，需要哪些备份文件，预计恢复耗时。

63
00:06:25,050 --> 00:06:28,957
说不出这三件事，说明这个操作还没想清楚。

64
00:06:28,957 --> 00:06:30,940
第三道闸是审查。

65
00:06:30,940 --> 00:06:37,130
发版前做改动差异审查，把你以为我改了什么和我实际改了什么拆开比对。

66
00:06:37,130 --> 00:06:43,776
可以让一个子智能体独立分析改动与发布说明之间的偏差，有风险就暂停发版。

67
00:06:43,776 --> 00:06:46,036
这个设计意图很明确。

68
00:06:46,036 --> 00:06:52,670
发布说明描述的是预期改动，而实际提交里可能混入无关调整甚至误删。

69
00:06:52,670 --> 00:07:05,243
正规团队靠自动流水线和合并请求评审来拦这个问题，但独立开发者往往跳过评审直接推送，让子智能体充当评审者，就是用规则补上这个缺口。

70
00:07:05,243 --> 00:07:07,346
还有两条配套规则。

71
00:07:07,346 --> 00:07:22,526
发布通道方面，代码发布、版本发布、服务器部署必须通过代码仓库，紧急热修复可以例外但事后必须补提交同步，而且在用户明确确认之前，打标签、推送、部署全部禁止。

72
00:07:22,526 --> 00:07:36,360
凭据管理方面，所有凭据通过环境变量或独立的密钥文件管理，禁止硬编码在代码或配置文件里，因为密钥一旦进入版本库历史就等于永久泄露，只能作废重发。

73
00:07:36,360 --> 00:07:44,714
备份的命名也有讲究，统一格式是原文件名加年月日时分秒，放在项目根目录的备份文件夹下。

74
00:07:44,714 --> 00:07:51,072
别小看命名格式，真到要回滚的时候，你需要能一眼找到最近的那一份。

75
00:07:51,210 --> 00:08:01,376
对话开头说好用某种关系型数据库，聊到三十轮它突然建议换轻量数据库，因为早期的约定已经被上下文窗口挤掉了。

76
00:08:01,326 --> 00:08:03,237
这就是认知漂移。

77
00:08:03,237 --> 00:08:04,775
成因有两条。

78
00:08:04,775 --> 00:08:17,396
一是上下文窗口截断，早期内容直接掉出窗口；二是长文本尾部的注意力衰减，即使是二十万词元的模型，注意力在长文本尾部的衰减也真实存在。

79
00:08:17,396 --> 00:08:19,138
对策是设锚点。

80
00:08:19,138 --> 00:08:27,203
超过十轮之后，在关键操作之前强制复述当前目标和关键约束，用周期性锚点对抗遗忘。

81
00:08:27,203 --> 00:08:34,992
复述要有固定格式，比如一行当前目标加一行关键约束，格式固定才便于扫一眼确认。

82
00:08:34,992 --> 00:08:36,915
这里有三个要点。

83
00:08:36,915 --> 00:08:44,379
第一，复述的时机是修改代码、修改配置、部署之前，也就是动手之前的那个断点。

84
00:08:44,379 --> 00:08:54,872
第二，目标以最新一次为准，用户在对话中改了目标，复述就要以最新一次为准，并明确标注变更，避免新旧目标混在一起。

85
00:08:54,872 --> 00:08:58,778
第三，并行编辑前必须先重读文件。

86
00:08:58,778 --> 00:09:09,932
多个子智能体或者多次编辑涉及同一个文件时，后续修改必须先重新读取文件当前状态，禁止基于缓存或记忆里的旧内容去编辑。

87
00:09:09,932 --> 00:09:12,732
这是多智能体时代的乐观锁。

88
00:09:12,732 --> 00:09:15,893
顺便说一句，为什么是十轮这个数。

89
00:09:15,893 --> 00:09:19,487
因为它是一个经验阈值，不是硬性规则。

90
00:09:19,487 --> 00:09:30,617
真正的判断标准是，当你发现它开始出现和早期约定不符的建议时，就说明漂移已经发生了，此时无论多少轮都该立刻设锚点。

91
00:09:30,760 --> 00:09:34,423
再讲怎么让它写出的中文摆脱机器腔。

92
00:09:34,373 --> 00:09:38,857
核心结论是，一句请用自然流畅的中文没有用。

93
00:09:38,857 --> 00:09:48,147
它认为的自然和你认为的自然可能完全不同，必须给出具体的违禁词和违禁句式列表，它才能精确执行。

94
00:09:48,147 --> 00:09:49,854
流程是这样的。

95
00:09:49,854 --> 00:09:58,160
先准备一份可搜索的违禁模式清单，交付前逐条搜索，发现一处改一处，完成后注明已完成自查。

96
00:09:58,160 --> 00:10:05,179
注意系统提示词里的违禁句式同样要改，否则它一边改文案一边继续用那套句式。

97
00:10:05,179 --> 00:10:07,583
还有个设计细节值得学。

98
00:10:07,583 --> 00:10:18,809
写作规范应该独立成文件，并且把全局生效的开关设成假，只在写文案或者写提示词的时候手动引用，避免污染编码对话的上下文。

99
00:10:18,809 --> 00:10:25,083
这件事背后的原则是，规则也要按需加载，不是所有规则都适合每轮都带。

100
00:10:25,083 --> 00:10:28,268
这一节和上一节其实是一体两面。

101
00:10:28,268 --> 00:10:31,393
锚定对抗遗忘，清单对抗含糊。

102
00:10:31,393 --> 00:10:38,220
长对话里靠周期性复述保住约定，写作上靠可搜索的违禁模式保住风格。

103
00:10:38,220 --> 00:10:42,823
两者的共同点，都是把模糊期望变成可执行动作。

104
00:10:42,823 --> 00:10:44,758
看一个具体例子。

105
00:10:44,758 --> 00:10:51,994
有一段文案读起来处处透着机器腔，用自查表逐条扫描，能命中七类违禁模式。

106
00:10:51,994 --> 00:11:00,708
逐条改完之后，同样的内容会从彻底重构、推倒重来、判断是这样的腔调，变成一段平实的表述。

107
00:11:00,708 --> 00:11:05,335
差别不在文采，在于把那些空泛的套话删掉了。

108
00:11:05,490 --> 00:11:07,423
先看规则怎么用。

109
00:11:07,373 --> 00:11:08,490
三步。

110
00:11:08,490 --> 00:11:14,933
第一步放入规则目录，把规则文件放进项目里对应的目录，编辑器会自动识别。

111
00:11:14,933 --> 00:11:25,041
第二步配置生效方式，文件头里的全局生效开关设成真就全局生效，设成假则需要手动引用，写作规范适合后者。

112
00:11:25,041 --> 00:11:35,510
第三步替换环境事实，把模型配置、技术栈、端口规则换成你自己的选型，密钥文件填占位符并排除出版本库。

113
00:11:35,510 --> 00:11:43,971
这套规则一共十四章，归入五大板块，共同底层只有一句，把模糊期望变成可执行的具体动作。

114
00:11:43,971 --> 00:12:01,583
结课作业也不是读完就完事，而是产出你自己的第一版规则，按删、换、调、补四个动作改出来，在一个真实项目里用满一周，记录哪些规则被触发、哪些从没生效，删掉从没生效的，把新踩的坑写成新规则。

115
00:12:01,583 --> 00:12:03,134
然后是适配。

116
00:12:03,134 --> 00:12:10,670
这套规则并非拿来即用的模板，正确姿势是按删、换、调、补四个动作改造。

117
00:12:10,670 --> 00:12:17,965
删掉你用不上的章节，换成你自己的环境事实，调整规则的严格程度，补上你踩过的坑。

118
00:12:17,965 --> 00:12:25,826
别整套照搬，规则的价值在于每条背后都有一次真实翻车，你没翻过的车，规则贴上去也守不住。

119
00:12:25,826 --> 00:12:28,242
最后是四步协作流程。

120
00:12:28,242 --> 00:12:34,504
第一步让它复述需求，用它自己的话讲一遍要做什么，理解歪了当场就能看见。

121
00:12:34,504 --> 00:12:40,129
第二步写需求文档，方案、边界、不做什么，白纸黑字落下来。

122
00:12:40,129 --> 00:12:44,624
第三步等你确认，这是人工闸门，不点头就不动手。

123
00:12:44,624 --> 00:12:49,708
第四步才开始编码，此时写出来的就是确认过的那个东西。

124
00:12:49,708 --> 00:12:52,665
为什么断点必须设在动手之前。

125
00:12:52,665 --> 00:12:58,855
因为一句话丢过去直接开写，第一步理解就歪了，你要到验收时才发现。

126
00:12:58,855 --> 00:13:03,254
它写得越快、越勤奋，你要拆的违章建筑越大。

127
00:13:03,254 --> 00:13:06,884
这就是所谓它写得快反而容易搞砸的机制。

128
00:13:06,884 --> 00:13:12,809
断点设在动手之前，返工才会消失；动手之后的纠正都叫返工。

129
00:13:12,809 --> 00:13:16,259
这一格是整条实战主线的最后一格。

130
00:13:16,259 --> 00:13:21,824
前五格你做出了一个能干活的东西，但所有判断都还在你脑子里。

131
00:13:21,824 --> 00:13:24,143
这一格把它们写成规矩。

132
00:13:24,143 --> 00:13:32,172
立住之后，换个人、换个项目、换个模型，这套东西照样跑，这才叫工程，不叫手艺。

133
00:13:32,172 --> 00:13:39,360
验收标准也很朴素，把你的规范发给一个同事，看他能不能照着做出一个类似的东西。

134
00:13:39,360 --> 00:13:46,571
能提出具体问题的，说明他真读懂了；只回一句写得挺好的，多半没读。

135
00:13:46,720 --> 00:13:50,996
最后给你一份可以马上用的判断清单，一共五条。

136
00:13:50,946 --> 00:13:56,235
第一条，环境事实写进规则，而不是配置文件或对话里。

137
00:13:56,235 --> 00:14:01,583
包含四类，模型与服务商、超时、代理回退、是否流式。

138
00:14:01,583 --> 00:14:08,086
再补上技术栈锁定和端口规则，选型是人的决策，一旦定了就不再讨论。

139
00:14:08,086 --> 00:14:11,848
第二条，把踩过的坑写成明确的禁令。

140
00:14:11,848 --> 00:14:22,557
中文输入法要检查组合状态标记，工具调用优先用标签格式而不是嵌套的键值格式，图标用矢量图形且不依赖公共网络。

141
00:14:22,557 --> 00:14:26,872
这些琐碎的细节，每一条都对应一次真实的返工。

142
00:14:26,872 --> 00:14:32,329
第三条，不可逆操作必须设三道闸，且都设在执行之前。

143
00:14:32,329 --> 00:14:38,110
备份拦数据损失，回退方案拦无法恢复，改动审查拦带病发版。

144
00:14:38,110 --> 00:14:43,158
另外发布必须走代码仓库通道，凭据禁止硬编码。

145
00:14:43,158 --> 00:14:46,475
第四条，长对话靠锚定对抗遗忘。

146
00:14:46,475 --> 00:14:58,663
超过十轮，在修改代码、修改配置、部署之前强制复述目标与约束，格式固定；目标以最新一次为准；并行编辑前必须先重读文件。

147
00:14:58,663 --> 00:15:02,990
第五条，把协作流程改成四步，断点前移。

148
00:15:02,990 --> 00:15:07,076
复述、写需求文档、等你确认、再编码。

149
00:15:07,076 --> 00:15:12,978
同时把规则按删、换、调、补改造成你自己的版本，别整套照搬。

150
00:15:12,978 --> 00:15:16,091
最后补一个判断规则好坏的标准。

151
00:15:16,091 --> 00:15:21,595
把这条规则放进新对话的开头，看那个坑是不是真的不再出现。

152
00:15:21,595 --> 00:15:26,103
规则写了却不生效，说明你写的是愿望，不是指令。

153
00:15:26,103 --> 00:15:32,160
这五条的共同点是同一句话，把模糊期望变成可执行的具体动作。

154
00:15:32,160 --> 00:15:34,624
它负责快，规则负责稳。

155
00:15:34,624 --> 00:15:39,540
规则的价值不在于多，而在于每条都解决一个真实问题。