Michael Polanyi 说过一句话:We know more than we can tell. 人知道的,比能说出来的多。
骑自行车你知道怎么保持平衡,但写不出一份让人照着骑就能学会的说明书。认人你一眼就知道是不是熟人,但说不清你到底看了哪些特征。代码 review 你一看就知道这段不对,但要你说出具体违反了哪条规则,不一定说得出来。
这就是默会知识(tacit knowledge)—你已经在用,但还没说清的判断。
Subsidiary Clues 和 Focal Whole
Polanyi 的框架里,默会知识有两个层次。
你感知到的零散线索是 subsidiary clues。骑车时身体的倾斜、车把的微调、路面的反馈—这些都是线索。你没有逐一分析它们,但它们共同指向一个 focal whole—平衡。
写代码也一样。变量命名、函数长度、抽象层级、错误处理方式—这些是线索。你看代码时不会逐条检查,而是整体感受”这段代码干净”或”这段代码有问题”。判断来自整体,不是单条规则。
为什么规则总是不够
你给新人写过代码规范吧?命名用 camelCase,函数不超过 50 行,每个函数只做一件事。然后他交上来的代码每条规则都符合,但你就是觉得不对。
因为真正的判断不全在规则里。比例、节奏、重点压在哪里、哪些该抽象哪些不该—这些依赖案例记忆和训练过的感知,很难写成条文。
这也是为什么 style guide 总是越写越长但永远写不完。每发现一个不对的地方就加一条规则,规则越来越多,但核心判断还是在那几条规则之间的空隙里。
和 LLM 的关系
理解默会知识,能让你和 LLM 沟通时少走很多弯路。
很多人给 LLM 写 prompt 的方式是列规则:你必须这样做,你不能那样做,格式要求是这些。这和给新人写代码规范一样—规则覆盖不到的地方,LLM 会用默认行为填,而默认行为不一定是你想要的。
更有用的方式是给 subsidiary clues。
给例子,不给定义。 与其说”写作风格要简洁”,不如给三段你觉得简洁的文本,让 LLM 自己提取 pattern。例子比定义更早接近 tacit judgment。
给反例。 “这段太啰嗦”比”要简洁”更具体。告诉 LLM 你不要什么,比告诉它你要什么更容易传递隐含标准。
给比喻。 “像老朋友聊天”比”语气亲切自然”更接近你真正想要的感觉。比喻绕过了形式化的困难,直接传递整体氛围。
给上下文。 你是谁,你在做什么,你为什么需要这个—这些信息看起来和任务无关,但它们是 subsidiary clues,帮助 LLM 拼出 focal whole。
承认说不清。 当你觉得不对但说不清哪里不对时,直接告诉 LLM:“这段有问题,但我说不清具体哪里,你看看。” 然后把你的判断线索拆出来—比例、节奏、重点、边界。不需要一步到位定义清楚,逐层桥接就够了。
实际应用
我在公司做过一件事:用 LLM 批量写产品宣传的视频脚本。听起来简单,但不同品牌、品类、型号的规则都不一样—有的要突出参数,有的要讲故事,有的语气要硬,有的要软。我一开始的思路是给每个场景写显性规则:prompt 里列一堆”必须包含 XX""不能出现 XX""格式要 XX”。结果 prompt 越写越长,效果还是不行。规则太多 LLM 反而抓不住重点,输出的东西每条规则都符合,但整体就是不对。
后来换了思路。不写规则了,直接给几个我觉得写得好的脚本当例子。LLM 自己从例子里提取 pattern—节奏、重点、语气、结构,这些本来就是很难用规则描述的默会知识。效果立刻好很多,prompt 也短了。
这次经历让我意识到:不是 LLM 笨,是我在用错误的方式和它沟通。我把隐性知识硬翻译成显性规则,翻译过程中信息大量丢失,剩下的规则既冗长又抓不住核心。直接给例子反而绕过了这个翻译损耗。
做代码 review 时,与其说”这段代码不好”,不如说”这段和上次那个 bug 的模式很像”。你传递的不是一条规则,而是一个 pattern 匹配的线索。
定需求时,与其写十页 PRD,不如给三个”好的例子”和三个”不好的例子”。例子承载的信息密度比规则高得多,尤其是那些你凭经验知道但还没形式化的部分。