夜雨聆风
先看一个场景。
某一天，公司管理层发布了一项新要求：从下个月起，所有涉及金额超过五百万的采购申请，在部门总监审批之后，必须增加一道财务总监会签。
这是管理上非常常见的一条规定。一句话，一个新增的评审节点。
业务部门的反应是：行，那流程图上加一格，制度文档里加一段，下个月执行。
IT部门的反应是：又一个需求。
这句话落到IT，变成了一份需求工单。IT产品经理开始盘算：这个"会签"加在哪里？是OA的审批流里加一个审批人，还是要改ERP的采购订单流程？新增的财务总监会签，需不需要在财务系统里同步一条审批记录？如果金额超五百万的采购单跨越了预算系统、合同系统、付款系统，这个新增节点要不要在每一个系统里都加一遍？
评估的结果是：这个需求，最快也要四周。
业务部门不理解：我就是加一个人签字，为什么要四周？
IT部门也无奈：因为"加一个人签字"这件事，不是改一个配置，而是要动到多个系统里的流程定义、审批引擎、权限配置，甚至可能涉及代码改动。
而这样的变更，在每一家企业里，每天都在发生。
我想了很久：为什么一个看似简单的流程变更，会这么难？
答案，指向一个我们一直没有意识到的环节——业务逻辑，从来没有被真正数字化过。
二
在前面的章节中，我们看到了企业数字化转型的三个阶段：信息化解决"记录"，数字化解决"连接"，智能化解决"决断"。
我们也看到了数字化的成就与边界：我们花了二十年，把企业里的"名词"——客户、产品、物料、组织、人员——统一成了数字资产。业务对象数字化完成了。
但"动词"——那些"当……时，做……"的规则和流程——还散落在两个互不兼容的世界里。
这一章，我想把"缺失的一环"说得更清楚：它到底是什么，为什么缺失，缺失的代价是什么。
先给一个定义。
业务逻辑数字化，是把企业的业务流程、业务规则和决策逻辑，从不可执行的文档或不可解释的代码，转化为结构化、可审计、可被AI理解的数字化声明。
这个定义里有三个关键词：结构化、可审计、可被AI理解。
"结构化"意味着，业务逻辑不再是一段散落在代码里的"if/else"，也不是一张挂在墙上的流程图，而是有明确边界的、可引用的逻辑单元。
"可审计"意味着，一条规则为什么存在、谁定义的、什么时候生效、改过几次，都可以追溯。还记得"0改1再改回0"吗？那段代码之所以恐怖，不是因为它复杂，而是因为它是不可审计的——没有人知道它为什么存在。
"可被AI理解"意味着，机器不再需要人肉翻译就能读取和执行业务逻辑。这是整个定义里最关键的部分，也是后面几章的核心。
打个比方。名词数字化，相当于给企业编了一本统一的《词典》——每个词是什么含义，全公司用同一套定义。而业务逻辑数字化，相当于把企业的《规章制度》变成了一本机器能直接执行的制度汇编——不再是一堆放在文件柜里的红头文件，而是每一条都能被系统直接理解和执行。
词典，我们编好了。制度汇编，还没有。
三
为什么业务逻辑数字化这么难？为什么我们能把名词管好，却始终碰不动动词？
我做过二十多年产品经理，在公司的架构设计中有"数据Owner"和"流程Owner"的设置。所以我要先纠正一个常见的误解：不是说动词没有主人。
数据有数据Owner，各级业务管理部门对业务对象负责；流程也有流程Owner，各级业务部门主管就是各自流程的Owner。制度上，每一个流程、每一条规则，都有明确的责任人。
那问题出在哪里？
问题在于：Owner管的是"文档"里的流程，管不到"代码"里的流程。
一个流程Owner，他手中最权威的东西，是一份流程文档——Word写的，Visio画的。他审批流程变更、组织流程评审、发布新的制度，都是在这份文档的层面上进行的。他以为，流程就是这样运转的。
但实际上，流程的"执行体"在代码里（也不是所有流程都在系统中跑，都体现在代码中）。在OA的审批引擎里，在ERP的ABAP里，在CRM的定时任务里。那是另一个世界——一个他看不见、摸不着、改不了的世界。
于是出现了这一幕：流程的"法律文本"（文档）和流程的"实际运行"（代码）是两份互不相同的存在，而且没有任何机制保证它们完全一致。
文档改了，代码没改——流程照旧。代码改了，文档没改——流程变了，但没有人知道。制度上流程有Owner，事实上没有任何一个Owner能完整地说清楚：我的流程，到底是怎么跑的？
这才是问题的本质。不是没有主人，而是主人的管辖权，在文档层，不在代码层。
我们要通过IT项目，将文档层的流程转换为代码层的流程，但是这个转换过程，需要时间，也需要承载风险。
四
为什么会这样？为什么流程的"法律文本"和"实际运行"会分离成两个世界？
答案，是那条从业务到机器的翻译链。
让我把一条业务规则的旅程，完整地走一遍。
业务部门的主管，在一次例会上说："以后采购金额超过五百万，部门总监批完，还要财务总监会签。"
这句话，是这条规则第一次以"人话"的形式出现。
然后，流程专员把它写进了流程文档："采购申请金额≥500万时，审批路径为：部门经理→部门总监→财务总监。"——这是第一次翻译，从口头的业务语言，变成书面的业务语言。
再然后，IT产品经理（比如当年的我）把流程文档变成需求规格说明书："在OA审批流中，当金额字段≥500万时，在'部门总监审批'节点后插入'财务总监会签'节点，会签通过后流转至采购执行。"——这是第二次翻译，从业务语言变成IT语言。
然后，开发人员把需求规格变成代码，或者在流程引擎的配置界面里拖出一条新的审批路径，配置审批人、条件、超时、转交规则——这是第三次翻译，从IT语言变成机器能执行的形态。
三次翻译，三个角色，三份不同的"真相"。
业务主管脑子里有一句话。流程文档里有一段文字。需求规格里有一个方案。代码里有一组逻辑。
它们说的是同一件事，却没有任何一份东西，与另一份完全一致。
这就是二元割裂的结构性根源。流程文档人可读、机器不可执行；代码机器可执行、人不可读——这不是某个企业的失误，而是翻译链的必然产物：
每一次翻译都有损耗，业务主管的意思，经过三次转述，很难毫厘不差 每一层翻译的产物都各自保存、各自演进，没有同步机制 最终的产物（代码）不可读，原始的产物（文档）不可执行，中间隔着一整条人肉翻译链
所以，业务逻辑的"数字化"，始终没有完成——它不是没有Owner，而是Owner的权威止步于文档，翻译链的终点却在代码，中间没有任何一个环节让逻辑本身成为可执行、可审计、可被直接理解的数字资产。
五
这个割裂的代价，是三重的。
代价一：变更成本与变更幅度无关。
业务部门以为，"加一个会签"是小变更。但在翻译链的世界里，任何变更，无论大小，都要走完"需求→设计→开发→测试→上线"的完整旅程。
改一个审批金额（如果它是配置项）也许很快；但增加一个评审节点、改一条审批路径、调整一次并行与串行——这些流程结构上的变化，几乎都要动到流程引擎或代码。流程引擎的配置要改，关联系统的逻辑要核对，测试要重跑，上线要排期。而有一些流程还涉及到跨系统的集成，那就更复杂了。
于是，"加一个人签字"这样一句话的事，在IT的世界里是"四周的项目"。
变更的代价，与变更的逻辑复杂度成正比，与变更的"一句话程度"无关。
代价二：业务部门与IT之间，存在永久的"翻译依赖"。
业务逻辑一旦进入翻译链，业务部门就失去了对它的话语权——不是制度上的失去，而是操作上的失去。业务部门想改流程？可以，请提交需求，请等评估，请等排期。
IT成了业务逻辑唯一的"翻译中枢"。而任何系统，只要所有变更都必须经过一个单一枢纽，这个枢纽就必然成为瓶颈。
这不是某个IT团队不够快，而是模式决定的：业务逻辑的每一次变更，都必须先被翻译成IT能理解的语言，再被翻译成机器能执行的形态。这个翻译，只有IT能做。
代价三：智能化没有可编排的逻辑基础。
这一条最根本，也最容易被忽略。
智能化是什么？让机器能判断、能行动。机器要判断，需要知道判断的规则；要行动，需要知道行动的流程。这些规则和流程，就是业务逻辑。
如果业务逻辑以两种形态存在——文档（机器不可执行）和代码（机器不可读取）——那么机器既无法"读懂"制度，也无法"编排"逻辑。它只能执行程序员写死的路径。
所以，智能化的前提，不是更强的算法，不是更大的算力，不是更多的数据，而是：业务逻辑必须变成一种机器能理解、能读取、能编排的形态。
逻辑不可编排，智能就无从谈起。
我们一直以为智能化卡在算法和算力上。其实，真正卡住智能化的，是业务逻辑的形态——它还是不可编排的。
六
也许有人会说：不对啊，我们不是有BPM吗？有规则引擎，有低代码平台？它们不就是为了解决业务逻辑的编排问题吗？
是的，它们都尝试过。而且都失败了。失败的原因，指向同一个地方。
BPM（业务流程管理）。
它要求把业务流程形式化——画成BPMN图，定义节点、网关、事件。BPM的初衷，恰恰就是要解决"流程数字化"的问题：让流程变成可建模、可执行的形态。
但它失败了。为什么？
因为真实的业务充满了例外和模糊判断。"这个客户情况特殊，酌情处理""如果负责人请假，自动转给代理人""重大异常要升级处理"——这些模糊地带，BPMN表达不了。强行表达，成本高到无法承受。
于是BPM项目大多停留在"画了流程图"的阶段。图很美，挂在墙上。但流程的"实际运行"还是靠代码，BPM只是给流程增加了一层新的"文档"——机器能读一部分，人也不能全懂，翻译层依然存在，只是换了张皮。
规则引擎。
它能处理确定性的if-then："金额超过五万，升级审批"。但真实的业务判断常常是综合性的："这个供应商的信用等级怎么评？"——涉及历史数据、行业环境、合作关系，不是一个if-then能表达的。
规则引擎只覆盖了规则的冰山一角。企业里真正难处理的，恰恰是那些不能用一个条件表达的判断。
低代码平台。
它降低了写代码的门槛，但本质上还是在写代码——拖拽组件、配置数据流、设置事件。它把"Java"换成了"可视化"，但翻译层没有消失：业务人员还是要把自己的逻辑，翻译成平台能理解的组件和配置。
还有我自己尝试过的"流程描述语言"。
我想造一门语言，让业务人员直接描述逻辑，机器直接执行。结果造出来的东西，本质还是代码——让人学机器的语言。WHEN...THEN...FOR EACH...IF......我失败了，失败得很彻底（这个故事，在第三章讲过）。
这四个尝试，方向各不相同，失败却指向同一个病根：它们都要求，人把逻辑"翻译"成机器能懂的严格形式。
BPM要求人学BPMN，规则引擎要求人学DRL，低代码要求人学组件和配置，我的流程描述语言要求人学WHEN-THEN语法。
每一次，都是人向机器妥协，人学机器的话。
翻译层，始终没有消失。它只是换了一副又一副面孔。
七
那这个问题，有没有解？
有。而且答案，在第四章已经出现了。
让我把时间线理一下。
十年前，我想造"流程描述语言"，我失败了。因为那还是在让人学机器的语言。
十年后的今天，我在Vibe Coding中给AI立了五步规矩，突然发现：我写的那个Skill，和企业里的"流程"是同一个东西。而且——它是可执行的。AI读到"设计文档需我确认后才能开发"，它就直接照做。不需要翻译。
那一刻我意识到：翻译的方向，反过来了。
过去所有方案，都是人学机器的语言——把业务逻辑"翻译"成机器能懂的严格形式。翻译成本太高，所以走不通。
现在，机器学会了人的语言。自然语言第一次同时满足两个条件：人可读，机器可执行。
不过，作为写给企业的书，我要在这里说一句精确的话——免得工程师朋友们拍桌子：自然语言第一次同时满足"人可读、机器可执行"，指的是它第一次成为可被机器理解、可执行意图的业务逻辑表达形式。企业级的可靠执行，仍然需要约束、测试与审计。翻译层也没有消失，它只是翻了个身：从"人把逻辑翻译成机器语言"，变成了"机器理解自然语言 + 形式化约束保证边界 + 测试验收保证质量 + 审计轨迹保证可追溯"。没有这三者，一段自然语言规则还只是提示词；有了这三者，它才是企业资产。这正是接下来几章要做的事。
你写一段中文规则："采购金额超过五百万，部门总监批完后，必须经财务总监会签。"——业务人员看得懂，AI也看得懂，AI直接就能执行。不需要BPMN，不需要DRL，不需要组件，不需要翻译。
一条业务规则，从诞生（业务主管的一句话）到执行（机器照做），中间不再需要三次翻译、三个角色、三份真相。它从头到尾，就是同一段自然语言。
这就是我所说的"流程数字化"：把业务流程从不可执行的文档或不可解释的代码，转化为结构化、可审计、可被AI理解的数字化声明。
而承载这个"数字化声明"的载体，就是Skill。
第4章我写下"Skill即流程"的时候，我以为我解决的是"怎么跟AI协作"的问题。现在回头看，我解决的是一个更大的问题：业务逻辑的数字化表达问题——那个让流程Owner管不到代码、让"加一个会签"要四周、让智能化无从谈起的问题。
名词数字化，我们用了十几年。动词数字化，答案已经出现了。
八
让我把这一章的核心论证，用一句话概括：
企业完成了业务对象数字化，但业务逻辑数字化——那个连接数字化与智能化的关键环节——始终缺失。这不是因为流程没有Owner，而是因为从业务语言到机器语言的翻译链，让逻辑既不可编排、也不可审计、更不可被机器直接理解。智能化的前提不是更强的算法，而是逻辑的可编排性。而AI时代，第一次让业务逻辑的数字化成为可能。
为什么是"第一次"？因为在AI之前，所有试图把业务逻辑从代码中解放出来的尝试——BPM、规则引擎、低代码、流程描述语言——都要求人把逻辑翻译成机器能懂的严格形式。翻译成本太高，高到没有企业能真正做完。
而现在不一样了。大语言模型的出现，意味着机器第一次能够直接理解人的语言。你不需要再创造一种新语言让机器懂——你用自然语言写清楚规则，机器就能懂，就能执行。
企业数字化的上半场，我们建好了全企业的"词典"；下半场要做的，是把"动词"——规则、流程、判断、例外和验收标准——变成可编排、可治理、可验收的数字资产。这一章论证的，就是下半场的入场券。
在下一章，我会详细讲Skill到底是什么——它的结构、它的层次、它为什么是流程数字化的天然载体，以及它和之前的那些尝试到底有什么区别。
先记住这一章的钥匙：
我们编好了全企业的词典。现在，该让那些规章制度，也真正"活"起来了。