逻辑模型分为规范模型、描述模型和推理模型

很多人搜「逻辑模型分为规范模型、描述模型和推理模型」，其实是想确认自己手上的活儿该归到哪一类：是拿来定规则、描述现状，还是拿去推结论。分不清就容易把描述性材料当规范用，或者花大力气去建一个根本推不出结论的模型。这篇给三种分类的一句话定义、用途边界，以及一张按目的选类的对照表。

搜「逻辑模型分为规范模型、描述模型和推理模型」的人，多半不是想背定义，而是想确认手上这摊活到底该归到哪一类。是给团队定规则、把现状说清楚，还是拿一堆前提去推结论？分不清的话，最常见的后果就是把描述性材料当成规范依据用，或者花大力气搭了一个根本推不出结论的模型。

这篇就干三件事：给三种分类各一句人话定义，给一张按输出物选类的对照表，再给一份交付前的落地清单。概念本身不复杂，难的是落到具体文档和字段上的时候，还能判断自己站在哪一边。

三种分类各一句话，先对齐概念

先记住一个判断口径：这三类不是难度高低之分，而是用途不同。同一个业务问题，可能三种模型都要建一遍，只是它们各自回答的问题不一样，交付物也不一样。

规范模型

回答「应该怎样」，输出的是规则、约束、阈值和合规要求，落点是让执行方照做。

描述模型

回答「实际怎样」，输出的是对现状、结构或数据的刻画，落点是让读者看清事实。

推理模型

回答「由此能推出什么」，输入前提、输出结论，落点是支撑某个判断或决定。

• 规范模型的交付物通常长成条款、字段约束、校验规则、准入阈值这种形态
• 描述模型的交付物通常是现状图、字段关系表、分布描述、数据字典
• 推理模型的交付物通常是结论、判定结果、风险等级，外加一条能回溯的依据链
• 三者可以串联：描述模型固定事实，推理模型在其上推结论，规范模型再把结论固化成规则
• 反过来做会拧巴：先定规范再补描述，往往发现规则跟现实对不上

判断自己该用哪类：看输出物，不看方法

很多人用建模方法来判断类别，这是反的。同一个方法既可以用来写描述模型，也可以拿去做推理，关键看你最后交出去的是什么。所以判断顺序应该是：先想清楚这份东西要给谁、拿去干什么，再回头看方法和工具。

如果输出物既有现状刻画又有结论，别硬塞进一个模型。正确做法是拆成两步：第一步做描述部分，把事实和口径固定下来；第二步在它上面做推理。这样万一结论被质疑，还能退回去检查是前提错了还是推理错了。

最容易踩的三个坑

1. 把常见当成允许数据里频繁出现某个值，不代表制度上就认可它。要判断这个值能不能写进规范，得回到规范模型自己的依据，而不是拿描述模型的统计结果直接下结论。
2. 语气分不清建议和硬性要求规范模型如果用描述模型的语气写，执行方会当成参考意见，不会照做。写规则就用「必须」「不得超过」这类词，写现状就用「目前」「观察到」，别混。
3. 前提悬空推理模型的每条结论，都要能指回它依赖的那份描述材料。找不到来源的前提标成待补，别让它悄悄撑着一个看起来成立的结论。

有几种情况不适合套这套分类。探索阶段还没摸清现状时，先别急着定规范，容易定出一堆跟现实打架的条款。口径本身有争议时，推理结论只能当参考，不能当决定。还有一种是多方共用一份模型但目的不同，这种情况最好按使用方拆成两份输出，别指望一份文档同时满足定规则和说现状两个目标。

落地动作清单：从目的到交付

下面这份清单按顺序走一遍，基本能避免把三类模型混成一锅。每一条都能在交付前自查，不用等别人来挑问题。

分类不是为了给模型贴标签，是为了让每个结论都能找到它该站的位置。