COGNITION / J-SYSTEM15 SEP 2026
认知 70｜出了问题，先问它落在哪一层
上一篇《没有本体论的系统，会长成癌症》写完，小明哥看了说：你最后那一刀，是事件级别的，不是本体级别的。
问题出现在哪一层，不等于问题生在哪一层。修错了层，修得再好也是补丁。
本体 01 是什么、不是什么 |
系统 02 设计到部署 |
事件 03 出了什么事 |
他给了一个分层：本体层在最下面；上面是系统层，包括系统设计、软件架构、写代码和部署；最上面才是事件层。
他说得对。这一篇把这个分层讲清楚，顺便改正上一篇的错。
COGNITION / 01
一、三层各是什么
本体层： 这个系统是什么、不是什么，里面有哪些对象，每个对象叫什么、指什么、边界在哪。它还要说清这个系统为什么存在。
系统层： 在本体定下的前提上，怎么把对象连起来、让它们动起来。它自己也分几步，一步压着一步：先是系统设计，再是软件架构，然后是写代码，最后是部署上线。
事件层： 系统跑起来以后，每天发生的事：出了一个错、来了一个需求、某个报表对不上。
COGNITION / 02
二、箭头只能往上走
三层之间有一个方向：下层约束上层，上层不能反过来改下层。
本体说「客户就是签了合同的人」，系统设计就只能围着这个定义来建；代码就只能照着设计写；部署就只能部署这份代码。
举一个例子。一家公司的销售报表，每个月都和财务对不上。
如果在事件层看，这是个 bug，程序员改一下统计代码，这个月对上了。
下个月又对不上，再改。第三个月，换了个地方对不上。
往下追，才发现：销售部说的「客户」是所有来问过价的人，财务部说的「客户」是付过钱的人。同一个词，两个定义。 这是本体层的问题，代码改一百遍也改不好，因为两边的数从定义上就不该相等。
在事件层出现，在代码层修补，病根却在本体层——这就是系统越修越乱的原因。
COGNITION / 03
三、癌症到底是怎么长出来的
现在可以把上一篇说的「癌症系统」讲得更准一点。
癌症不是因为补丁多，而是因为补丁打错了层。本体上的问题，在代码上补；设计上的问题，在部署上补。每一个补丁都盖住了一个症状，病根还在，于是换个样子再长出来，再补，再长。
AI 让这件事更快，因为 AI 加速最多的，恰恰是写代码这一步。一句话就是一个补丁。补丁越便宜，越容易在错的层上补。
COGNITION / 04
四、改正上一篇
上一篇最后说：检验本体论有没有起作用，看它过去一个月拒绝了几样东西、删掉了几样东西。
这是一个事件层的读数。它数的是已经发生的动作，而且可以被凑出来——为了数字好看，随手删几样，本体并不会因此更清楚。
本体层的检验应该是结构性的，任何一刻都能做：
第一，系统里每一样东西，能不能指回一个对象、一个定义、一个主人。 指不回的，按定义就不该存在，不管它这个月有没有惹事。
第二，每一样东西，能不能连到这个系统存在的目的。 连不到的，哪怕它运转得很好，也是肿瘤。
「删了几样」可以拿来佐证本体在起作用，但它不是本体本身。
COGNITION / 05
五、怎么用：出了事，往下问三句
—这只是一个事件吗？ 偶然的、一次性的，修了就好。—它是系统设计的必然结果吗？ 同样的事会不会因为这个设计反复发生？是的话，改设计，不是改代码。—它说明我们对某个对象的定义错了吗？ 是的话，先改本体，再顺着往上，把设计、代码、部署一层层跟着改。
修在病根所在的那一层，然后往上传。 不在上层打补丁。
COGNITION / 06
六、这个判断也有它管不到的地方
—不是每件事都要追到本体。 大多数事件就是事件，修了就好。追到底是有成本的。一个简单的判据：同一类事第二次出现，才往下追一层。—本体自己也会错。 定义下错了，整个系统都会跟着歪。所以本体不是一次定死的，生意变了、对象变了，它也要改——只是改它要慎重，因为上面所有层都会跟着动。—什么情况下这个判断算错： 如果一个系统长期只在事件层和代码层修补，从不回头看定义和设计，却越来越稳定，那就说明这个三层模型漏掉了别的东西。
最后收成一句话：
好的修理工先问病根在哪一层，再动手；坏的修理工哪里冒烟就往哪里浇水。