01｜围绕不可言说知识构造知识过程

你好，我是徐昊，欢迎你和我一起学习AI时代的软件工程。

今天我们开始第一章的学习，掌握知识工程的整体框架。在开篇词我曾提到随着LLM的兴起，软件工程也会逐渐变成知识工程（Knowledge Engineering），即提取知识、组织知识为LLM易于理解的形式，再通过LLM将这些知识转化为可工作的软件。

不难发现，知识工程的关键是提升知识传递效率。为此我们需要先了解知识有哪些种类，以及知识是如何进行传递的。

不同种类的知识

实际上在我们的工作中存在两类知识：显式知识（explicit knowledge）、不可言说的知识（tacit knowledge）。

所谓显式知识就是能够直接表达且在人群中分享的知识。比如，地球的周长、水的密度、三角形面积公式等等。不可言说的知识是指那些不易用言语表达或形式化的知识，它通常是个人经验、直觉或技能的一部分，与个人的认知和学习过程紧密相关。

不可言说的知识需要从经验中获取，很难通过语言或其他的形式传播。而显式知识则没有这个要求。《庄子》上有一则故事，非常形象地描绘了什么是不可言说的知识。

齐桓公在堂上读书，轮扁在堂下砍削车轮。他问齐桓公在读什么书。齐桓公说是圣人的书。轮扁说，那全是古人的糟粕！齐桓公就很不高兴，非要让他说出个道理。
 
轮扁说：我所从事的工作是砍削车轮。榫头做得过于宽缓，就会松动而不牢固，而做得太紧了，又会涩滞而难以使用。不宽不紧才可以。这个道理是我从工作中学会的，虽然能讲出来，但是没有办法教给徒弟或儿子。于是这么大岁数了我也只能自己削车轮。不可言传的道理跟随圣人一起死了，所以您读的书只能是古人的糟粕。

轮扁讲出的道理需要他的徒弟或儿子亲身在工作中学习，通过经验的增长，才能学会。英国哲学家吉尔伯特·赖尔（Glibert Ryle）将这两种知识分别称作 “know-what” 和 “know-how”。显式知识是关于事实或规律的know-what，不可言说知识是特定场景下的know-how。

这其中的差别有点像求解计算题还是应用题。计算题只要根据计算法则，完成演算即可。而应用题有个额外的难点——我们先要从文字描述的场景里提取隐含的数学关系，然后才能选择正确的公式或算法求解问题。提取隐含的数学关系这个过程，就是不可言说知识在发挥作用。

不可言说知识还被称作经验知识（Experiental Knowledge）或部落知识（Tribal Knowledge）。经验知识指不可言说知识是通过经验获得的知识。部落知识则是说不可言说知识口口相传，不落文字。

不可言说知识不同于隐式知识（Implicit Knowledge），虽然在很多场合中我们也会使用隐式知识指代不可言说知识，但是二者还是存在很大的差别。隐式知识只是一种尚未被记录下来的显式知识，是没有记录下来的事实。要将隐式知识转化为显式知识，唯一需要做的步骤就是记录它。

比如我们在某个地方发现一个水池，对于水池的深度没有任何记载。但是水池的水深并不是不可言说知识，而是隐式知识。我们只需要测量并记录就好，并不需要再获取额外的经验。

不可言说知识是更重要的知识

显式知识只是我们技能里很小的一部分，不可言说知识才是冰山下的主体。

在许多专业领域，如医学、工程、软件开发和艺术，高级技能往往是通过实践和模仿，而非仅通过书本学习获得。这些技能的核心是不可言说知识，它们对于专业实践至关重要。

以软件开发为例，虽然像数据结构这样的基础编程概念可以通过书本学习，但想要真正掌握和精通却需要在实际编码过程中不断练习和应用。开发者需要在不同的项目和问题中使用这些数据结构，通过实际解决问题来深化理解。在这个过程中，他们不仅在学习如何使用这些结构，还在学习何时使用它们，以及如何在不同的编程环境和需求下调整用法。这些都是不可言说知识。

还记得不可言说知识也叫部落知识吗？任何团队、组织的环境与文化中都充斥着不可言说的知识，它包括团队特定的工作方式、非正式的规则、经验教训以及对组织文化的深刻理解。这些知识对于有效的团队协作和组织融合非常重要。

例如，在一个软件开发团队中，不可言说的知识可能包括特定的编码实践、项目管理的非正式流程、代码审查的潜规则，甚至是如何有效地与特定同事沟通的技巧。这些知识通常不在任何手册中，但对于新成员快速融入团队、提高工作效率和质量至关重要。

不可言说知识使得团队成员能够在没有明确指导的情况下高效协作。它帮助员工理解“我们是如何做事的”，这不仅仅是关于工作流程，更关乎于团队的价值观、信仰和期望。这种知识的共享和传播，促进了团队成员之间的信任和理解，加强了团队凝聚力。

在处理客户关系和提供服务时，不可言说知识也发挥着至关重要的作用。例如，可能凭借直觉判断客户的情绪和需求；能够读懂非言语的暗示，如客户的肢体语言和语调，从而更有效地响应客户未明确表达的需求。这种判断和理解通常基于过去在类似情境中的经历，是通过长期的人际交往和实际经验积累形成的不可言说知识。

我们还可以举出很多很多的例子，我们会发现无论在哪个领域，不可言说的知识才是真正有用且重要的知识。但正如我们在轮扁的故事中看到的，不可言说知识的传递是非常困难的。不可言说知识无法被转化为显式知识，因而无法靠文档和记录传递。

不可言说知识的传递

当代知识管理理论认为，社会化活动（Socialization）是传递不可言说知识的不二法门。

不可言说知识通过共同活动进行交流，而不是书面或口头指令。比如在同一工作环境中，通过个体之间的互动完成不可言说知识的交换。学徒与导师一起工作，通过观察、模仿和实践来学习手工艺。在职培训也采用同样的原则。获取不可言说知识的关键是分享思维的过程，而不单单是消费最终的结果。

社会化活动最常见的形式是启动-反馈循环（kickoff-feedback cycle）。在启动阶段（Kick off） 时传递知识，在反馈（feedback）时检查知识是否被吸收并且转化成为实际的产出物。反馈中还要包含针对思维过程的反馈，或是知识消费者对思维过程的自省。

以削车轮为例，如果反馈仅仅是停留在检查最终的成品是宽还是紧，那么学徒并不能真正学习到削车轮的关键。如果在轮扁询问学徒拿到材料和制式后的制作思路，并根据自己的经验提供反馈，那么借由思维过程的分享，最终应该还是能够教会学徒的。

另一种特殊的社会化活动是训练法。也就是将不可言说知识转化为教程、dojo、或者挑战练习等方式。通过一系列启动-反馈循环，持续且稳定地完成不可言说知识的传递。

我经常会用这样一个比喻，比如你看上了某个健身教练的肌肉，那么无论你想花多少钱，他都没办法把肌肉卖给你。他能带给你的是一套训练法。然而通过这套训练法，你增长的是自己的肌肉。对于不可言说的知识，很多时候我们能从别人那里获得的最好的东西，也就是一套训练法。而我们能给予别人最好的东西，也是提供对应的训练法。

比如对于软件架构，一个最常见的错误是，架构师通常只会提供架构文档，以说明当前架构的现状，但很少为架构提供教程或使用手册。也就缺乏针对在不同场景下，如何应用架构中的概念解决问题的指引。缺乏训练法，架构中的不可言说知识就无法持续稳定地传播。这是很多架构腐化或是无法落地的根因。

转化为知识过程

所谓知识过程，就是从知识管理的角度理解我们的工作，将我们的工作看作产生、传递、应用、消费知识的过程。由于不可言说知识的重要性，将任何工作转化为知识过程的关键，就是识别其中关键的不可言说知识，围绕不可言说知识的传递构造流程。

如上图所示是一个典型的迭代式软件开发流程。站在知识管理的角度，我们怎么看待这个流程呢？

首先，从软件交付的整体流程来看，不可言说知识是软件功能是否满足业务价值。为传递不可言说知识，对应的社会化活动是迭代计划（IPM）与迭代展示（Showcase）。即业务方根据迭代的进展，针对是否提供了足够的业务价值给予反馈。

其次，是在当前迭代中，不可言说知识是如何实现某个功能需求ROI最高。对应的社会化活动是启动（kickoff）与桌面检查（desk check）。业务分析师要根据代码的进展，提供反馈。

最后，在构造软件的时候，不可言说知识是在当前架构和最佳实践下要如何实现功能。对应的社会化活动是围绕任务列表的Ping-Pong结对编程。当然，如果不采取结对编程的话，也可以通过代码审查（code review）达到类似的效果。

这样我们就可以粗略地通过识别不可言说知识以及它们的传递，将软件开发看作一个知识过程了。

小结

今天我们介绍了显式知识、隐式知识和不可言说知识。显式知识是能够直接表达且在人群中分享的知识；隐式知识只是一种尚未被记录下来的显式知识，是没有记录下来的事实；不可言说知识，需要从经验中获取，很难通过语言或其他的形式传播。

这些知识中，不可言说知识最为重要。它的传递需要通过社会化活动来实现。最后我们介绍了如何将任何工作转化为知识过程，所谓知识过程就是把某种工作看作知识创造、传递和消费的过程，该过程中主要任务就是识别其中关键的不可言说知识。

那怎样围绕不可言说知识，让工作里的知识传递过程更高效呢？这就是我们下节课要讨论的内容。

思考题

请列举工作中的不可言说知识，以及它们是如何传递的？

获取不可言说知识的关键是分享思维的过程，希望你积极思考，在留言区分享你的想法。