本文是《执行缝隙》The Execution Gap的作者手记。 它不是书籍正文的摘要或重写而是围绕本章问题、工程背景与写作之后的进一步思考。做事故复盘时人很容易希望最后得到一个干净的答案。数据库问题、权限问题、流程问题、配置问题、操作问题或者某一种已经定义好的根因。最好只能选一个这样可以统计可以分派责任也方便进入后续整改。组织规模越大这种需求越强因为如果每一次事故都只能用一段长叙述保存下来时间一久几乎没有办法比较也很难形成统一的经验。所以我并不反对分类。真正让我开始警惕的是另一件事当记录系统只允许一个答案时我们很容易慢慢相信现实本身也一定存在一个唯一答案。表格只是为了方便管理但久而久之表格的结构会反过来影响我们理解事故的方式。第五章把 Path 和 Boundary 分开以后这个问题已经变得无法回避。一次失败可以不存在路径偏离却存在执行边界失效也可以同时出现路径和边界问题。到了第四章留下的五类直接机制这种重叠更加明显。如果我们仍然坚持每次事故都必须找到一个“它真正属于的类别”那么后面的分析很容易变成一场分类竞争到底应该算绑定问题还是边界问题状态与结果是不是才是最核心的问题证据这一层是不是只是后果但现实中的失败并没有义务替我们选一个。分类工具很容易偷偷变成因果模型第六章开头用了一个很普通的场景事故复盘表里有一栏“根因分类”必须填写而且只能选择一个值。这个设计在管理上非常合理。可它实际上已经预设了两件事。第一所有候选类别彼此可以被清楚分开。第二每一次事故最终都存在唯一归属。只要这两个前提没有被单独证明一个方便统计的字段就可能悄悄变成一套关于现实的因果模型。这件事并不少见。我们每天使用的监控、工单、事故平台和风险系统都需要结构化字段。严重程度、影响范围、责任团队、故障类型、恢复时间几乎都必须标准化。结构化本身没有问题但只要一个字段开始替代真实分析它就会制造一种非常强的认知惯性。人会开始寻找那个系统允许填写的答案。而不是继续问现实究竟发生了什么。写这一章的时候我越来越觉得《执行缝隙》如果最后也只是提供一套新的根因分类表那么前面几章所做的很多拆解其实都会重新被收回去。我们先花了很大力气说明一次执行偏差未必来自某个单一坏掉的组件。如果最后又要求每个事故只能落到五类机制中的一个格子里那只不过是把“组件唯一归因”换成了“机制唯一归因”。表格变了思维方式没有变。十七个案例真正让我放弃的是“唯一归属”这一章里有一个很简单的算术我觉得比很多理论解释都更直接。十七个已经完成事实核验的案例中决定与绑定关系有十七个 Strong状态与结果关系也有十七个 Strong边界有十一个 Strong证据还有十三个 Strong。如果五类机制真的是五个互斥的桶一个案例只能进去一个那么光这几项 Strong 加起来就已经远远超过十七。问题不在统计方法。而在于同一个案例本来就可能同时让多个问题成立。这件事情对我来说很重要因为它迫使我接受一个并不那么“整齐”的结论可以被清楚区分的是问题不一定能够被唯一分配的是事故。这是两回事。我们完全可以准确地区分 Path 和 Boundary因为它们问的是不同的问题可以区分判断与绑定、状态与结果、Evidence 与 Proof因为每个分析对象都有自己的进入条件和边界。可这并不意味着现实事故必须从中挑一个作为“真正归属”。一个复杂失败很可能同时包含多个机制而且这些机制不是互相竞争的解释而是在同一条因果过程中分别承担不同作用。这个区别一旦接受下来很多以前让我觉得“分类不够好”的重叠反而不再需要被消除。重叠不一定说明理论还没分细面对重叠最自然的反应是继续细分。如果两个类别经常同时出现那是不是说明它们里面其实还混着更细的东西只要继续拆总有一天可以得到彼此互斥的一组最小类别。这种思维在软件设计里很熟悉我们总希望把对象边界划得清楚一点。但现实失败不一定适合这样处理。例如一份 Evidence 在上一轮执行中形成后来又进入下一轮判断影响新的授权、边界和动作。它看起来像一种很新的失败形式可拆开以后会发现里面仍然是原来的 Evidence、Decision / Binding、Boundary 等机制只是它们跨越多个回合重新组合起来。跨组织资格继承也是类似的情况。一份资格从一个系统进入另一个系统在新的域里继续取得作用能力看起来好像需要再创造一个“跨域机制”。但继续拆开后真正承担作用的仍然是已有的资格关系、绑定关系和边界只是作用范围跨越了组织。这让我慢慢接受了一个很重要的原则新的组合不一定意味着出现了新的一级机制。否则理论会进入一种不断膨胀的状态。每发现一种新的案例组合就增加一个名字每出现一种过去没有见过的叙述就增加一个类别。最后得到的不是更好的解释而是一张越来越长、越来越难使用的词汇表。理论真正需要新增结构的时候应该是出现一个已有机制无法吸收的新对象、新因果位置而且这种结构还能够在不同案例里重复出现。否则现实复杂本身并不是增加一级概念的理由。我后来越来越不愿意问“这个事故属于哪一类”写到这里以后我觉得事故分析最先应该改变的可能不是工具而是问法。“这是什么类型的事故”这个问题很方便但它太容易要求一个名词作为答案。一旦答案变成名词分析往往就开始收缩这是边界问题这是状态问题这是证据问题。名词一出现我们很容易产生一种已经解释完毕的感觉。所以第六章最后没有继续增加分类规则而是换成了三个问题。第一个问题是什么变了这个问题非常朴素。先不讨论谁对谁错也不急着决定机制只去看事故发生前后究竟什么东西发生了变化。对象变了参数变了状态变了Policy 变了路径变了Evidence 变了还是一个词的实际含义发生了变化。“变化”在这里不负责解释原因。它只是帮助分析重新抓住事实。因为事故叙述一旦写长很容易出现一种情况所有东西听起来都不对但真正和原来不同的是什么反而没有被明确指出。如果连变化的对象都没有找到后面的所有理论判断都很容易悬在空中。第二个问题才是哪个关系断了这一步开始从对象转向对象之间。一个 Approval 仍然存在但它是不是仍然绑定当前 Payload一个状态仍然有效但它是不是仍然代表当前现实一份 Evidence 仍然真实存在但它是不是仍然具有参与下一次动作的资格这里真正需要寻找的是两个对象之间原本必须成立、后来却没有继续成立的对应。第三个问题是断在哪里落在哪一层机制上到了这里五类直接机制才真正开始发挥作用。它们不是给事故贴标签的五个桶而是帮助我们说明这一段断裂最终通过什么位置获得了继续进入现实的条件。这样使用以后五类的角色就完全不同了。它们不是在回答“这是什么事故”而是在回答“这次偏差在这里是怎么继续向现实推进的”。三个问题也不能再被做成“三步法”这一章里我还刻意保留了一个限制不要把这三个问题重新包装成新的框架。这件事听起来有些反常。既然已经有三个问题为什么不把它画成三步流程第一步找变化第二步找关系第三步定位机制看起来非常自然而且特别适合做图。但这会再次引入一个我们之前一直在避免的东西结构本身开始暗示现实必须按照这个顺序存在。三个问题确实存在分析上的先后关系因为只有知道什么发生变化通常才更容易继续检查关系可这种分析顺序并不意味着现实事故也是三个阶段。事故不会先发生 Change再发生 Relation Failure然后最后进入 Mechanism。它们只是三个观察问题。如果把它们做成三个阶段读者很快就会开始问“这个事故现在走到第二层了吗”然后我们又得到了一套新的固定结构。所以我反而希望它们一直保持问句的形式。问题的好处就在于它不会轻易替事实决定答案。“什么变了”要求你把变化指出来。“哪个关系断了”要求你说明两个对象之间原来应该保持什么。“断在哪里”要求你把机制位置说清楚。它们都逼着分析重新回到可核对的东西而不是选择一个听起来最合适的术语。放弃唯一分类不等于接受“系统太复杂”这里还有一个必须守住的反面。如果说一个案例可以同时涉及多个机制有人很容易走到另一边既然都可以重叠那就不用精确定位了反正现实系统很复杂什么地方都有问题。这同样不是我想要的结果。“非互斥”不能成为模糊分析的借口。如果一次复盘最后只能写成“多个环节存在问题”“系统整体复杂”“很多因素共同造成”实际上和强行选一个唯一根因一样都没有真正解释偏差为什么进入现实。一次分析完全可以得出多个同时成立的机制判断但至少应该明确指出其中一条直接机制并说明它是怎样让偏差继续下去的。这也是我很喜欢第六章里那句话的原因放弃唯一归类不等于放弃定位。这句话看起来只是方法上的提醒实际上关系到整套 Execution Gap 能不能真正用于工程分析。如果只有分类没有关系我们会过早结束分析。如果只有复杂性没有定位我们又会失去工程可操作性。真正需要保留的是中间那个位置允许一个失败拥有多条同时成立的解释但每一条解释都必须能够回到具体对象、具体关系和具体机制。“什么变了”很重要但还不是原因第六章最后还有一个我觉得很值得留下的问题。在当前十七个案例里Change 这一维全部都能找到 Strong 支持。也就是说每一个案例里都能明确找到某种东西发生了变化。这个结果非常诱人。既然所有案例都有变化我们很容易进一步说变化就是执行缝隙产生的原因。但这个推论仍然太快。几乎任何现实事件都包含变化。系统从一种状态进入另一种状态本身就是执行的意义之一。如果只要有变化就构成 Execution Gap那么这个概念最后会覆盖几乎所有执行行为。所以 Change 覆盖得广只能说明它是一个很好的分析入口。它让我们知道从哪里开始观察。但“什么变了”和“为什么偏差能够进入现实”仍然不是同一个问题。这也是为什么第六章最后没有因为找到三个问题就宣布定位方法已经完成。它反而把问题继续往下推了一步如果变化几乎处处存在那么真正有意义的区分就不是“有没有变化”。而是什么样的变化才会改变原来已经成立的关系并最终形成 Execution Gap到这里分类的问题暂时放下了。接下来需要处理的是变化本身。关于《执行缝隙》《执行缝隙》The Execution Gap是Execution Engineering Trilogy第一卷。本书讨论一个基础而关键的问题从人的意图到机器最终改变现实世界中间究竟发生了什么在线阅读繁體中文版 執行縫隙 | Havenlon ResearchEnglish Edition https://havenlon.com/research/books/the-execution-gap/Amazon Kindle Amazon.com: The Execution Gap: The Structural Discontinuity Between Intent and Action (Execution Engineering Trilogy Book 1) eBook : Wang, Lin, Wu, Mengting, Zhang, Yong, Deng, Jiang: Kindle StoreAmazon Paperback The Execution Gap: The Structural Discontinuity Between Intent and Action (Execution Engineering Trilogy): Wang, Lin, Wu, Mengting, Zhang, Yong, Deng, Jiang: 9798177903347: Amazon.com: Books© 2026 Lin Wang / Havenlon.本文为作者手记与《执行缝隙》正式书籍正文相互独立。 未经授权请勿全文转载或用于商业再出版。 引用请注明作者及出处。