隐性知识与显性知识
认知知识管理
We know more than we can tell.
— Michael Polanyi
核心概念
隐性知识（Tacit Knowledge）：无法完全用语言表达的知识，包括直觉、模式识别、审美判断、身体记忆。
显性知识（Explicit Knowledge）：可以用语言、文字、公式明确表达的知识。
Polanyi 的洞察
波兰尼在《个人知识》（Personal Knowledge, 1958）和《隐性维度》（The Tacit Dimension, 1966）中指出：
我们知道的远多于我们能表达出来的。
经典例子
- 骑自行车：你会骑，但无法完全用语言教会别人平衡感
- 识别人脸：你认得某人，但无法完全描述“为什么这是他”
- 品酒：专家能分辨细微差别，但无法完全言传
在编程中的体现
优秀工程师的隐性知识
- 代码审美 — 看一眼代码就知道“这里不对劲”，但说不清具体哪里不对
- 架构直觉 — 感觉“这个设计会出问题”，但无法完全形式化推理过程
- Bug 嗅觉 — 凭经验判断“问题可能在这个模块”，跳过大量无关代码
- 取舍判断 — 在没有完整信息的情况下，依靠直觉做出“足够好”的决策
为什么无法完全显性化？
编程中的隐性知识来自：
- 模式识别：大脑在大量案例中形成的模式，无法完全意识到
- 上下文感知：对项目历史、团队风格、业务约束的整体把握
- 审美偏好：对“好代码”的感觉，部分是文化、部分是个人经验
隐性知识的传递
不能靠“讲”，只能靠“示范 + 观察 + 实践”
| 传递方式 | 效果 | 为什么 |
|---|---|---|
| 读文档 | ❌ 低效 | 文档只能传递显性知识 |
| 听讲座 | △ 有限 | 可以传递部分模式，但无法覆盖所有上下文 |
| Code Review | ✅ 高效 | Junior 观察 Senior 的修改建议，习得判断力 |
| Pair Programming | ✅ 高效 | 实时观察思考过程和决策路径 |
| 踩坑 + 反思 | ✅ 最高效 | 亲身经历形成的隐性知识最牢固 |
Code Review 的隐藏价值
Code Review 的价值不只是发现 bug，更是传递隐性知识：
- Senior 说“这里应该抽象”，Junior 看到了抽象的时机
- Senior 说“这个命名不够清晰”，Junior 习得了命名的审美
- Senior 说“这里可能有并发问题”，Junior 建立了并发的直觉
对“说不清楚是因为想不清楚”的补充
第 9 条编程哲学说：说不清楚是因为想不清楚。
但隐性知识的存在表明：有时“说不清楚”不是因为“想不清楚”，而是因为这类知识本质上就无法完全言说。
两种“说不清楚”
- 思考不够深入 → 继续思考，写出清晰的技术方案
- 隐性知识无法言传 → 不要强求显性化，用“示范 + 实践”传递
如何区分？
如果你能做出正确决策（写出好代码、找到 bug、设计出好架构），但无法完全解释推理过程 → 这是隐性知识，不是思考不够。
对知识管理的启示
Wiki 的局限性
Wiki、文档、知识库只能捕获显性知识。大量的隐性知识（审美、直觉、上下文感知）无法写进文档。
混合策略
- 显性知识 → Wiki、文档、ADR
- 隐性知识 → Code Review、Pair Programming、案例分析、导师制
在 system-weaver 中的体现
sources/和wiki/捕获显性知识- 对话、code review、实际项目操作传递隐性知识
与结构思维的关系
结构思维强调“说清楚”，但也要承认有些结构是通过实践涌现的，而不是先规划后执行。
TDD 的例子
TDD 的“消除重复后自然涌现设计”就是隐性知识的体现：
- 你无法事先完全设计出最优结构
- 但通过红-绿-重构循环，好的结构会自然显现
- 这个过程部分依赖你的审美和直觉
实践建议
- 不要强求显性化一切 — 有些知识必须通过实践传递
- 重视 Code Review — 这是传递隐性知识的最佳场景
- 建立导师制 — Junior 跟着 Senior 工作，观察思考过程
- 记录决策而非过程 — ADR 记录“决定了什么”，不强求解释“为什么这样想”
- 鼓励踩坑 — 亲身经历形成的隐性知识最牢固
核心原则
智慧不可传授，唯有实践。 但隐性知识可以通过观察、模仿、反思逐步习得。