不可言说的知识：AI时代软件工程的核心传递问题
一、两类知识的本质区别
软件工程中存在两类截然不同的知识，理解它们的区别是构建高效知识传递体系的前提。
**显式知识（Explicit Knowledge）**是能够直接表达并在人群中分享的知识，比如数据结构的定义、设计模式的规则、编码规范等。这类知识可以写进文档、记录在 Wiki 里，任何人都能通过阅读获取。
**不可言说的知识（Tacit Knowledge）**则是那些无法用语言完整表达的知识，它依附于个人经验、直觉和技能，与具体场景紧密绑定。《庄子》里轮扁削车轮的故事是最好的注脚：榫头不宽不紧的那个"度"，轮扁能感知、能操作，却无法教给徒弟------因为这个"度"只能在实践中习得，无法通过语言传递。
还有一类容易混淆的隐式知识（Implicit Knowledge），它只是"尚未被记录的显式知识"。比如某个水池的深度没有文字记载，但只要测量一下就能记录，这是隐式知识而非不可言说知识。区分这三者的关键在于：隐式知识记录下来就变成显式知识；不可言说知识即使写下来也没有用，因为真正的理解必须通过经验获得。
英国哲学家赖尔将两者分别称为 "know-what"（知道是什么）和 "know-how"（知道怎么做）。软件开发中，数据结构的定义是 know-what，而在什么场景下选择哪种数据结构、如何在特定架构约束下实现功能，这些是 know-how，是不可言说知识。
二、为什么不可言说知识才是核心
显式知识只是冰山一角，不可言说知识才是冰山主体。这在软件开发中体现得尤为明显。
在团队协作层面，不可言说知识包括特定的编码实践、项目管理的非正式流程、代码审查的潜规则，甚至是如何与特定同事有效沟通的技巧。这些知识不在任何手册里，但对新成员快速融入团队至关重要。它回答的是"我们是如何做事的"这个问题，涵盖团队的价值观、信仰和期望。
在业务理解层面，判断一个功能是否真正满足业务价值、在模糊需求中识别隐含的业务规则，这些都是不可言说知识。它们无法通过需求文档完整传递，必须通过持续的业务反馈循环才能习得。
在技术实现层面，架构决策背后的权衡逻辑、在当前技术栈下解决特定问题的最优路径，同样是不可言说知识。这也是为什么很多架构文档写得再详细，落地时仍然会腐化------文档传递的是显式知识，而架构中真正重要的 know-how 没有对应的传递机制。
三、不可言说知识的传递机制
既然不可言说知识无法通过文档传递，那它如何传播？答案是社会化活动（Socialization）。
社会化活动的核心是共同活动，而非书面或口头指令。学徒与导师一起工作，通过观察、模仿和实践来学习------这是最古老也最有效的知识传递方式。关键在于：获取不可言说知识的核心是分享思维过程，而不是消费最终结果。
社会化活动最常见的形式是启动-反馈循环（Kickoff-Feedback Cycle）：在启动阶段传递知识，在反馈阶段检查知识是否被吸收并转化为实际产出。反馈必须包含对思维过程的检验，而不只是检查最终成品的对错。
以削车轮为例：如果反馈只是检查成品是否宽紧合适，学徒学不到真正的技艺。但如果轮扁在学徒拿到材料后询问其制作思路，并根据自己的经验给出反馈，那么通过思维过程的分享，知识才能真正传递。
另一种形式是训练法（Training Method）：将不可言说知识转化为一系列有结构的练习，通过持续的启动-反馈循环完成传递。一个健身教练无法把肌肉卖给你，但能给你一套训练法------通过这套训练法，你增长的是自己的肌肉。对于不可言说知识，我们能从别人那里获得的最好的东西，就是一套训练法。
这个视角揭示了软件架构实践中一个常见的失误：架构师通常只提供架构文档，说明当前架构的现状，却很少提供"在不同场景下如何应用架构概念解决问题"的训练法。缺乏训练法，架构中的不可言说知识就无法持续稳定地传播，这是很多架构腐化或无法落地的根本原因。
四、将工作转化为知识过程
**知识过程（Knowledge Process）**是从知识管理角度理解工作的框架：将工作看作产生、传递、应用、消费知识的过程，核心任务是识别其中关键的不可言说知识，并围绕其传递构造流程。
以迭代式软件开发为例，从知识管理视角可以识别出三个层次的不可言说知识及其对应的社会化活动：
在交付层，不可言说知识是"软件功能是否满足业务价值"，对应的社会化活动是迭代计划（IPM）与迭代展示（Showcase）------业务方根据迭代进展给予反馈。
在需求层，不可言说知识是"如何实现某个功能需求的 ROI 最高"，对应的社会化活动是启动（Kickoff）与桌面检查（Desk Check）------业务分析师根据代码进展提供反馈。
在实现层，不可言说知识是"在当前架构和最佳实践下如何实现功能"，对应的社会化活动是围绕任务列表的结对编程（Ping-Pong Pairing）或代码审查（Code Review）。
这个框架的价值在于：它让我们不再把软件开发流程看作任务的流转，而是看作知识的创造、传递和消费。当某个环节出现问题时，可以追问：这里关键的不可言说知识是什么？它的传递机制是否有效？
五、对 AI 辅助软件工程的启示
理解不可言说知识的传递机制，对于如何有效使用 LLM 辅助软件开发有直接的指导意义。
LLM 擅长处理显式知识------它能生成符合规范的代码、解释技术概念、完成有明确规则的任务。但不可言说知识的传递依赖社会化活动，依赖思维过程的分享和反馈循环。这意味着 LLM 在软件工程中的有效应用，不是简单地"让 AI 写代码"，而是如何将 LLM 嵌入到知识传递的社会化活动中，成为启动-反馈循环的参与者。
这也是为什么"提示词工程"本质上是一种知识工程：好的提示词不只是指令，而是将不可言说知识转化为 LLM 可以理解和应用的形式------这本身就是一种知识传递的训练法。