《AI即软件》第一章:企业IT的三次跃迁一
在一家以管理和数字化先进实践而成为业界标杆的大型科技公司里，业务部门提出一个IT需求，从需求提出到版本发布实现，需要多长时间？提出一个需求，需要经过层层评审，从部门经理审批，到IT分析，到工作量评估，再由产品经理出面与需求提出人沟通需求，输出对需求的原型设计和需求文档，再进行版本排期，而一个正式版本发布，开发2周，集成测试和用户接收测试2周，又需要4周时间。一个需求从提出到实现，7-8周是最快的交付周期。如果这个需求再复杂一点，涉及到多个系统之间的集成和联调，那周期就会被拖得更长了。需要多个系统的业务、IT相互沟通，约定版本发布周期、联调时间、对接需求，一路走下来，两三个月的时间就过去了。这不是某一家企业的问题。这是这个时代几乎所有大中型企业的常态。公司越大，系统越多，管理和流程做得越规范和越好，IT需求的实现周期，就越长。我们花了三十年时间，把企业里的每一个环节都"信息化"了。我们有OA、有ERP、有CRM、有PLM、有MES、有WMS、有HR系统、有财务系统。每一个环节都有系统支撑，每一笔数据都有地方存放。从"有没有系统"的角度看，我们做得很好。我们有一个理念：IT系统支撑着企业管理流程的落地。但如果换一个角度来理解：企业的流程和业务逻辑，是谁在管理的，如何管理的？答案是：业务部门在管，但管理在流程文档和流程图中。这就形成了一个一层一层的“翻译”过程。业务部门书写流程文档，IT的产品经理将“业务语言”翻译成“IT语言”重新描述它，然后程序员再将“IT语言”翻译成机器能够识别的“机器语言”（简称“程序代码”）。每一次翻译，都有损耗。每一次翻译，都有时间成本。而每一次翻译，都需要一个"人"来完成。那个"采购申请超过五万需要总监审批"的规则，写在OA系统的Java代码里；那个"供应商必须在合格名录中"的校验，写在ERP的ABAP代码里；那个"合同金额超过百万需要法务会签"的流程，写在合同系统的某个配置文件里。这些规则，同时也记录在采购部门的流程文档里。这些规则分散在多个系统的代码里，由不同的开发团队在不同年代用不同语言写成。没有任何一个人——无论是业务人员还是IT人员——能够完整地看见、理解、并管理这些规则的全貌。业务部门想改一个审批规则？提需求，审批，等排期，IT评估，开发，测试，上线。8周！这就是我们花了三十年建成的"数字化企业"的真实面貌。系统有了，数据有了，但业务逻辑——那些真正驱动企业运转的规则和流程——仍然被锁在代码深处，不可见，不可编排，不可被业务人员直接触碰，需要经过一层一层的翻译才能够最终变成机器能执行的逻辑。二
业界有一个被广泛接受的认知：企业IT的发展会经历三个阶段——信息化、数字化、智能化。这个判断大体是对的。但"大体对"往往意味着"细节模糊"。当我们追问"数字化到底做了什么""智能化到底要做什么""从数字化到智能化具体怎么走"的时候，共识就开始瓦解了。在信息化之前，企业的业务记录是纸质的。订单写在纸上，库存记在本子上，审批靠签字盖章。信息化的核心动作是：把这些纸质记录搬进系统。于是我们有了财务软件、有了进销存系统、有了OA。信息化的价值是巨大的——数据不再丢失，查询不再翻箱倒柜，统计不再手工汇总。但它的本质没有改变业务流程本身。你以前怎么审批，现在还是怎么审批，只不过从"在纸上签字"变成了"在系统里点按钮"。信息化阶段，每个系统是一座孤岛。财务有财务的数据，采购有采购的数据，生产有生产的数据。它们之间不通，不对齐，甚至对同一个"客户"或"物料"的定义都不一致。数字化的核心动作是：打通孤岛，建立统一的数字资产。于是我们有了主数据管理——全公司对"什么是客户""什么是产品""什么是物料"有了统一的定义和唯一的编码。我们有了数据中台——所有核心数据在一个地方被统一管理，通过标准接口对外提供服务。我们有了API网关——系统之间不再靠人工搬运数据，而是通过接口自动交互。数字化的价值也是巨大的——数据一致了，系统通了，报表准了，决策有了统一的数据基础。但数字化做了一件非常关键的事，同时留下了一件同样关键的事没做。做完的那件事，我称之为"业务对象数字化"。我们把企业里的核心实体——客户、产品、物料、组织、人员、合同一一抽象出来，统一定义，统一管理，形成了企业的数字资产。用更朴素的话说：我们把企业里的"名词"数字化了。没做的那件事，是"业务逻辑数字化"。那些驱动业务运转的规则、流程、判断标准——"什么条件下触发什么动作""谁审批""走什么路径""什么算异常"——它们没有被数字化。它们仍然以两种形态存在着：要么写在流程文档里（人看得懂，但机器跑不了），要么写在系统代码里（机器跑得了，但人看不懂）。用同样朴素的比喻：我们把"名词"管好了，但"动词"还散落一地。如果信息化是让机器"记住"，数字化是让机器"看见"，那智能化应该是让机器"判断"和"行动"。不是人告诉机器"你把这个数据从A搬到B"，而是机器自己知道"这个数据应该去哪里、为什么去、去了之后下一步做什么"。但问题来了：机器要"判断"和"行动"，它需要知道判断的规则和行动的流程。这些规则和流程，就是业务逻辑。如果业务逻辑还锁在代码里，机器怎么"判断"？它只能按照程序员写死的if/else执行。如果业务逻辑还写在流程文档里，机器怎么"行动"？它读不懂那些Visio画的流程图。所以，从数字化到智能化之间，缺失的不是更强的算法，不是更大的算力，不是更多的数据。缺失的是：业务逻辑的可编排性。三
2023年以来，大语言模型的爆发让"智能化"这个词突然变得无比性感。每个企业都在谈AI，每个IT部门都在规划大模型应用，每个咨询公司都在卖"AI转型方案"。但如果你走进大多数企业的IT部门，问他们："你们的AI落地了吗？"得到的回答大概率是："我们在做一些试点。"试点什么？智能客服、知识问答、报告生成、代码辅助。这些当然有价值，但它们有一个共同特征：它们是在现有系统的边缘做"加法"——给现有流程加一个AI助手，给现有系统加一个对话入口。这不是智能化。这是给自行车装了一个电动马达——更快了，但还是自行车。真正的智能化，不是"在现有流程上加一个AI功能"，而是"让业务逻辑本身变得可被AI理解、编排和执行"。前者是锦上添花，后者是范式变革。但后者需要一个前提：业务逻辑必须从代码里走出来，从文档里走出来，变成一种人和机器都能理解的、可编排的、可执行的形态。这个前提，就是我在本书中要反复论述的核心命题——我称之为"流程数字化"。四
我在一家大型科技企业做了二十多年的IT产品经理。不是高管，不是架构师，不是技术大牛。我的日常工作，是坐在业务部门和开发团队中间，把业务人员说的话翻译成IT人员能理解的需求文档，然后再把IT人员的实现方案翻译回业务人员能听懂的语言。二十多年里，我经历了这家企业从信息化建设到数字化转型的全过程。我参与过CRM的实施，做过主数据治理，建过数据中台，管过PLM产品。我亲手把一个个业务对象——客户、产品、物料、组织——从混乱的多系统定义中抽象出来，变成全公司统一的数字资产。我为这些成就感到自豪。但我也越来越清楚地感受到一个天花板：对象统一了，数据通了，但业务逻辑——那些真正让企业"运转"起来的规则和流程——仍然是一团乱麻。它们分散在几十个系统的代码里，没有人能看见全貌，没有人能快速调整，每一次变更都是一次小型工程。这个困惑困扰了我很多年。我尝试过解决它——我甚至试图创造一种"语言"来描述业务逻辑，让业务人员能写、让机器能跑。这个尝试失败了。我会在后面的章节里详细讲述这次失败。但正是这次失败，加上后来一段意想不到的经历，让我最终找到了答案。五
让我把这本书要回答的核心问题，用最简单的话说清楚：企业已经完成了"业务对象数字化"，但还没有完成"业务逻辑数字化"。后者是从数字化通往智能化的必经之路。而AI时代，第一次让这条路变得真正可走。为什么"第一次"？因为在AI之前，所有试图把业务逻辑从代码中解放出来的尝试——BPM、规则引擎、低代码——都要求人把逻辑"翻译"成机器能懂的严格形式。这个翻译成本太高，高到没有企业能真正做完。但现在不一样了。大语言模型的出现，意味着机器第一次能够直接理解人的语言。你不需要再创造一种新语言让机器懂——你用自然语言写清楚规则，机器就能懂，就能执行。这个变化，让"业务逻辑”的数字化，从一个美好的愿景，变成了一个可操作的现实。Skill是用自然语言描述的、可被AI直接理解和执行的业务规则。它既是人可读的文档，也是机器可执行的指令。所见即所得。围绕Skill，我们可以构建一套全新的企业IT架构——数据中台管数据，Skill中台管逻辑，AI Agent负责执行。IT部门从"写代码的人"变成"建平台的人"，业务部门从"提需求等排期的人"变成"自己编排逻辑的人"。AI不是软件的插件，不是某个功能模块，不是锦上添花的"智能助手"。AI就是软件本身。传统应用退化为Agent的工具，UI退化为Agent的输出窗口，业务逻辑从代码迁移到Skill。这本书，就是关于这个跃迁的完整论述：它是什么，为什么是现在，怎么建，谁来做，以及它会带我们去哪里。但理论是灰色的。在展开理论之前，我想先讲几个故事——关于我如何走了二十年弯路，如何失败，如何在一次最不经意的经历中突然想通。因为这套理论不是从书本里来的。它是从泥里长出来的。
夜雨聆风