《AI即软件》第三章:一条走不通的路

一

"0改1再改回0"那件事之后，我很长时间都在想一个问题。

那段代码之所以成为"化石"，不是因为它复杂。它简单到任何人都能看懂——0改成1，1改回0，小学生都能理解。它之所以成为化石，是因为它承载的业务逻辑没有被"说出来"。

没有人用一句人话写下："试制加工时，临时将Part状态标记为已发布以触发生产试制，完成后恢复。"

如果这句话被写下来了，写在任何一个业务人员能看到、能理解、能管理的地方，那它就不会成为化石。它会被讨论，会被质疑，会被优化，会在不需要的时候被正式废止。

但它没有被写下来。它被"实现"了。实现成了一段代码。代码能跑，但代码不会说话。

从那天起，我脑子里开始长出一个念头：能不能让业务逻辑"说话"？

不是让它变成代码——代码是机器的语言，业务人员听不懂。也不是让它变成流程图——流程图是给人看的，机器跑不了。而是找到一种形态，让业务逻辑既能被人读懂，又能被机器执行。

一种"业务语言"。

这个念头一旦长出来，就再也按不下去了。

二

我的思路是这样的：

我们花了十几年做"业务对象数字化"——把客户、产品、物料、组织这些"名词"统一定义、统一管理，放在数据中台里。那业务逻辑——那些"动词"——为什么不能用同样的思路来做？

对象有对象的模型。逻辑也应该有逻辑的模型。

对象有统一的管理平台（数据中台）。逻辑也应该有一个统一的管理平台——我创造了一个概念，叫做"逻辑中台"。

对象通过CRUD接口对外提供服务。逻辑也应该通过某种接口对外提供服务——当某个条件满足时，触发某个动作。

那逻辑用什么语言来描述？我想了很久，最后的结论是：创造一种新的语言，我称之为"流程描述语言"。

我当时的类比是SQL。

SQL是什么？SQL是你用一种接近自然语言的语法，告诉数据库"我要什么数据"。你不需要知道数据存在磁盘的哪个位置、用什么索引。你只需要写"SELECT * FROM customers WHERE city = 'Shanghai'"，数据库引擎帮你翻译成底层的磁盘读取操作。

我想做的，是业务逻辑领域的SQL。用一种结构化的、接近业务语言的语法，描述"当什么条件满足时，做什么动作"。然后一个"解释器"——类似数据库引擎——把你的描述翻译成系统能执行的逻辑。

我甚至开始设计这套语言的雏形。

三

我设想的语法大概是这样的：

以PLM里一个真实的场景为例：当图纸的状态变更为"发布"时，与这张图纸关联的所有Part启动发布流程，并检查发布CheckList。

如果用我的"流程描述语言"来写，大概是：

WHEN 图纸.状态 CHANGES_TO "发布"

THEN

FOR EACH Part WHERE Part.关联图纸 = 图纸.编号

START 发布流程

EXECUTE 检查CheckList

END

你看，它不是代码。没有类、没有方法、没有变量声明、没有异常处理。它读起来像一句业务规则的描述。一个研发工程师看到这段话，能立刻理解它在说什么。

然后，一个"解释器"读取这段描述，把它翻译成PLM系统能执行的工作流调用、状态机变更、事件触发。

在这个设想里，业务人员写规则，解释器做翻译，系统做执行。产品经理不需要翻译，程序员不需要翻译。翻译层消失了。

我进一步设想：所有的业务逻辑，都用这种语言来描述，统一注册在"逻辑中台"里。逻辑中台建在数据中台之上——数据中台管"名词"，逻辑中台管"动词"，动词和名词绑定在一起，形成具体的动宾结构——满足什么条件的情况下，如何操作哪个对象。业务对象通过属性识别，与业务逻辑关联。

图纸是一个业务对象，它有"状态"这个属性。当"状态"这个属性的值发生变化时，逻辑中台检测到这个变化，找到与"图纸"关联的所有业务逻辑，然后触发执行。

这套机制如果成立，那"0改1再改回0"这种化石就永远不会再出现了。因为那条逻辑会被显式地写在逻辑中台里，所有人都能看见它，所有人都能理解它，修改它需要走审批流程，删除它需要做影响分析。

我被这个想法激动了很长时间。

四

然后我开始尝试实现它。

第一个碰壁：语法设计。

"图纸发布触发Part发布流程"——这个简单。一条规则，一个触发条件，一个动作。我的语法能描述它。

但真实的业务逻辑不是这样的。

我试着描述一个稍微复杂一点的场景：研发变更流程。一个工程变更发起后，需要评估影响范围——如果影响到已量产的产品，需要通知生产部门评估库存和在制品；如果影响到已发货的客户设备，需要通知服务部门评估是否需要召回；如果变更涉及安全件，需要启动安全评审委员会的审批。

我试着用我的语法来写：

WHEN 工程变更.状态 CHANGES_TO "已批准"

THEN

IF 工程变更.影响范围 CONTAINS "已量产产品"

THEN NOTIFY 生产部门 EVALUATE "库存和在制品影响"

IF 工程变更.影响范围 CONTAINS "已发货设备"

THEN NOTIFY 服务部门 EVALUATE "召回必要性"

IF 工程变更.涉及安全件 = TRUE

THEN START 安全评审委员会审批

END

看起来还行？但问题马上来了。

"影响范围"怎么判定？它不是一个简单的字段，它需要去查BOM、查关联关系、查产品状态。这个"查"的过程本身就是一个复杂的逻辑。我的语法能描述"查"吗？

"EVALUATE '库存和在制品影响'"——这个评估是谁来做？是人还是系统？如果是人，怎么等待人的结果？等多久？超时了怎么办？如果是系统，用什么算法？调哪个接口？

"NOTIFY 生产部门"——通知谁？生产部门的哪个角色？通过什么渠道？如果那个人请假了呢？要不要自动转给代理人？

每一个问号，都意味着我的语法需要增加新的结构、新的关键字、新的描述能力。

我加了IF，加了FOR EACH，加了NOTIFY，加了EVALUATE，加了WAIT，加了ESCALATE，加了TIMEOUT……语法越来越复杂，越来越像一门真正的编程语言。

然后有一天，我盯着我设计的那套语法，突然意识到一个让我非常沮丧的事实：

我设计出来的东西，和代码有什么区别？

它确实比Java好看一点。但它本质上还是一套形式化的、有严格语法规则的、需要学习才能掌握的语言。业务人员看到"WHEN...THEN...FOR EACH...IF...CONTAINS...EVALUATE..."，他们的反应不会是"啊，我懂了"，而是"这是什么？我需要学这个吗？"

我花了这么大力气，造出来的东西，只是把Java变成了另一种语法。翻译层没有消失——它只是从"业务语言→Java"变成了"业务语言→我的流程描述语言"。业务人员还是看不懂，还是需要一个"懂这门语言的人"来帮他们写。

那个人，以前叫程序员。现在叫"流程描述语言工程师"。

换了个名字而已。

五

第二个碰壁，比第一个更致命。

就算我接受这套语法不够"自然"，就算我接受它需要一定的学习成本——我仍然面临一个无法逾越的问题：

我穷举不了。

业务逻辑的多样性是无限的。我设计了触发条件、动作、分支、循环、等待、升级……但我永远不知道下一个业务部门会提出什么样的逻辑需求。

"如果这个客户的信用等级是A，并且过去一年的订单总额超过一千万，并且当前没有未结清的逾期账款，那么自动授予白金折扣。但如果该客户属于特殊行业，则无论金额大小，都需要合规审查。除非该客户已经通过了年度合规审查并且审查结果在有效期内。"

这段话，一个业务人员用中文说出来，清清楚楚，没有任何歧义。但你让我用形式化语法来描述它？我需要嵌套三层IF，需要定义"有效期"的计算方式，需要处理"除非"这个逻辑反转，需要定义"年度合规审查"的状态查询……

而且这只是一个场景。企业里有成千上万个这样的场景。每一个都有不同的结构、不同的嵌套深度、不同的例外处理。我的语法要覆盖所有可能性，它就会变成一门和Java一样复杂的语言。如果我不覆盖所有可能性，那总有些业务逻辑是它描述不了的——描述不了的部分，还是得写代码。

我陷入了一个两难：语法越简单，表达力越弱，能覆盖的场景越少；语法越复杂，表达力越强，但就越像编程语言，就越需要专业人员来写，就越偏离"让业务逻辑被人理解"的初衷。

表达力和可理解性，是一对不可调和的矛盾。任何形式化语言都逃不开这个矛盾。

六

第三个碰壁，是最现实的。

就算我在理论上解决了前两个问题——就算我设计出了一门既简洁又有表达力的语言——我仍然面临一个非常朴素的问题：

我做不出来。

设计一门语言是一回事。实现一个能解析这门语言、把它翻译成可执行逻辑的解释器，是另一回事。这需要编译原理的知识，需要形式语言理论，需要工作流引擎的开发经验，需要分布式系统的设计能力。

我是一个产品经理。我会写需求文档，会画数据模型，会做项目管理。但我不会写编译器。

我可以去找开发团队帮忙。但我能想象到他们的反应："你要我们停下来，花半年时间帮你造一门语言和一个解释器？然后呢？然后所有的业务系统都要改造来对接你的逻辑中台？这个工程量有多大你知道吗？"

我知道。我没有足够的技术能力去实现它，也没有足够的组织影响力去推动它。

这个想法，最终停留在了我的笔记本里。几页纸的语法设计草稿，一些零散的架构图，一个没有写完的"逻辑中台"概念文档。

我没有跟正式提出过这个方案，不是不想，是不敢。我知道它经不起追问。

七

这件事过去了。我继续做我的产品经理，继续翻译需求，继续写文档，继续参加评审会议。

但我心里始终有一个结。

我知道我的方向是对的——业务逻辑必须从代码里走出来，必须被显式地描述、统一地管理。"0改1再改回0"的教训告诉我，不解决这个问题，企业IT就永远在"堆代码"和"改代码"的循环里打转。

但我也知道我的方法，也许是错的。造一门语言，造一个解释器，造一个逻辑中台——这条路走不通。不是因为想法不好，而是因为范式不对。

我仍然在试图让人去适应机器。我造的那门"流程描述语言"，虽然比Java好看，但它仍然要求使用者按照机器的逻辑来组织思维——先定义触发条件，再定义动作，再处理分支，再考虑异常。这是机器的思维方式，不是人的。

人不会这样想问题。人会说："图纸发布了，相关的Part也要走发布流程，记得检查CheckList。"一句话说完了。没有WHEN，没有THEN，没有FOR EACH。

但我当时不知道还有什么别的路。在2010年代，机器听不懂人话。你要让机器执行一个逻辑，你就必须用机器能理解的方式告诉它。这是铁律。

所以我把这个想法收起来了。收了很多年。

直到有一天，机器突然听懂了人话。

那一天，一切都不一样了。