今年（2018 年）下半年，和团队协作时我反复感到：大家的“理解路径”并不一致。
我更习惯先把系统抽象出来，明确假设、约束与不变量，再沿着逻辑链条推导出可复用的结论；而不少同事更喜欢先跑一个具体场景，把输入在系统里的流动过程走一遍，从输出与现象中获得直觉。

这篇短文把这两条路分别叫做：推理论证（形式化推导） 与 实例走查（案例走查）。名字一换，很多含混之处会自动消失。

推理论证（Reasoning / Derivation）

这里说的不是“数学意义上严格的证明”，而是工程语境里更常见的：从模型与前提出发的推导与论证。

做法通常是：

  • 先立前提：把系统的“假设/约束/边界条件”（assumptions / constraints）写清楚。它们在这里扮演“公理”的角色。
  • 再做推导：在这些前提下，沿着逻辑一步步推出结论，得到系统的性质/不变量/保证（properties / invariants / guarantees）。
  • 最后可复用：结论最好是“对一类输入、一类配置都成立”，而不是“只对某个样例成立”。

推理论证的迷人之处在于：你最终得到的不只是一个“答案”，而是一套“可迁移的理解”。新旧结论互相咬合，久而久之会形成对系统的整体把握——这大概就是“融会贯通”的工程版。

实例走查（Trace / Case Walkthrough）

实例走查指的是：选定一个具体输入（或一个具体 case），跟踪它在系统中的流动路径、状态转换、关键分支与最终输出。
它非常像调试：你盯着一条“执行轨迹”（trace），让系统自己把内部结构“演出来”。

实例走查的优势也很直接：

  • 快：几分钟就能建立直觉，尤其适合陌生系统或新同学上手。
  • 真：它天然贴近实现细节，能把文档里不存在的分支、边界、脏数据直接暴露出来。
  • 好沟通：故事比定理更容易被记住（这是事实，不是抱怨）。

二者的关系

如果把“理解系统”当作目标，那么两者关系更像：

  • 推理论证给你“地图”：哪些结论在什么前提下成立，你能依赖什么，不该依赖什么。
  • 实例走查给你“路感”：现实路况长什么样，坑在哪儿，转弯有多急。

问题往往出在走偏：

  • 只做推理论证：容易写出漂亮但不落地的结论——因为前提偷偷被现实打碎了（比如“时钟可靠”“网络稳定”“数据干净”“调用方守规矩”）。
  • 只做实例走查：容易落入“轶事式例证”（anecdotal evidence）——拿一个样例就开始下结论，把“我见过”误当作“我证明了”。

把实例提升到“能支撑论证”的层次，常见有三种做法（按严谨程度递增）：

  • 归纳推断：用一组有代表性的样本归纳出规律与边界，但要明确它是推断而非必然。
  • 穷举验证：在可控的小空间内覆盖“所有情况”，更像验证而不是证明（工程里这很常见）。
  • 反例：当你想推翻一个看似正确的命题时，最便宜的方式往往是给出一个反例（比长篇大论有效）。

我现在更愿意这样说：研究时要尽量追求推理论证的“可复用结论”，表达时要善用实例走查的“可共享直觉”。你要说服别人，通常先讲故事；你要说服自己，最后得回到前提与推导。

一个小例子：乘法

推理论证的写法会更像“定义 + 性质”：

  • 定义（模型）：乘法可以定义为加法的重复。
    一个常见表述是：(a \times b) 等于把 (a) 重复加 (b) 次。
  • 形式化表达：
    \(a \times b=\sum_{1}^{b}{a} = \underbrace{a + a + a + \cdots + a}_{b}\)
  • 可复用结论：只要你接受“加法”的规则，很多乘法性质都能被推出来（交换律、分配律等——当然在不同代数结构里要先检查前提）。

实例走查的写法会更像“挑一条轨迹走一遍”：

  • 选一个 case：(2 \times 4)
    你会看到：(4 + 4 = 8)（或者 (2+2+2+2=8)，取决于你选的约定）
  • 再选一个 case：(3 \times 5)
    你会看到：(5 + 5 + 5 = 15)

如果走查者只停在“看到了输出”，那么他获得的是几段现象；如果走查者愿意追问“为什么每一步这样走”，他就会开始反向逼近那个定义与结构。
换句话说：实例走查可以是推理论证的入口，也可以是推理论证的替代品——区别在于你有没有在关键处停下来，把“现象”提炼成“规则”。

方法、人、文化

这一节仍然要胡言乱语，但我试图胡得更准确一点。

我越来越怀疑：偏好哪条路，未必是“勤奋/懒惰”的差别，更像是记忆与思维的默认压缩算法不同。
我对事件细节的记忆非常差，看完电影常常复述不了情节；但我容易记住结构与抽象关系（于是更偏好模型与推导）。也有人反过来：细节栩栩如生，抽象一旦离开具体场景就会飘（于是更偏好走查与故事）。

文化层面也许有一点影子：一边更崇尚“把道理说清楚”，一边更擅长“把东西做出来”。前者容易在推理论证里上瘾，后者容易在实例走查里上瘾。两边都有各自的病：一种病叫“正确但没用”，另一种病叫“有用但说不清为什么”。

曾经和大师聊工作风格，我说我总想把东西讲成一套体系。大师说这像武侠：有人剑宗，有人气宗。
我听完挺高兴——直到意识到商业世界多数时候只问一句：你这套内功，能不能把 KPI 打穿？