用大白话写业务规则，Rust 帮你编译成标准决策模型
企业级 DMN 决策平台「伏羲」全栈 Rust 实现：业务人员用自然语言描述规则，LLM 智能体生成结构化 DSL，校验后编译为标准 DMN 1.5 XML。规则引擎二十年的老问题，换了个 AI 解法。
银行信贷审批、保险理赔、供应链风控，这些系统的核心是一堆业务规则——而规则引擎是软件工程里最「两头受气」的组件：业务人员嫌它要写代码，开发人员嫌它逻辑散乱难维护，审计人员要的是「规则可追溯」。伏羲智能决策平台给这个二十年老问题开的药方很激进：让业务人员直接说大白话，让 AI 把大白话变成标准规则文件。
综述
伏羲是一个企业级 DMN（Decision Model and Notation，决策模型与记法）决策自动化平台，全栈 Rust 实现。它的核心流程是：业务人员用自然语言描述业务规则 → LLM 智能体把描述转换成结构化 DSL → 经过校验后编译为标准 DMN 1.5 XML，交给规则引擎执行。
这个定位有几个关键点：一是「自然语言即规则输入」，把规则编写从程序员手里还给业务人员；二是输出物是 DMN 1.5 标准 XML——不是私有格式，意味着规则可以被标准引擎执行、被合规审计、被跨系统复用；三是全栈 Rust，运行时性能与部署形态（单二进制、低资源占用）都更贴近企业内网交付。
DMN 本身是 OMG（对象管理组织）维护的标准，专门描述决策逻辑与决策表，与 BPMN（流程）互补——流程管「怎么走」，决策管「走到哪怎么判」。伏羲选择的路径，是把「AI 写规则」落在标准格式上，而不是再造一个私有规则语言。
专业分析
规则引擎这个领域，一直有两个互相拉扯的痛点。业务侧要「看得懂、改得动」：规则本质是业务资产，不该锁在代码里；工程侧要「可执行、可测试、可追溯」：自由文本没法跑，跑了也没法证明对错。过去的低代码规则产品大多妥协——可视化拖拽确实不用写代码，但复杂规则一多，画布比代码还难读；DSL 方案表达力强，业务人员又学不会。
伏羲的巧妙之处在于用 AI 把这两端接起来：输入用自然语言（业务友好），输出用标准 DMN（工程友好），中间那道「翻译+校验」的活交给 LLM 智能体。 自然语言的不确定性，由「结构化 DSL + 编译校验」这一层兜底——模型先产出受约束的 DSL，再经语法与语义校验后才落成 XML，等于给 LLM 的输出加了类型系统。
这个设计其实在回答一个更普遍的问题：LLM 进企业系统的正确姿势，不是直接让模型执行，而是让模型「生成可编译的中间产物」。 规则、配置、查询、合同条款——凡是历史上靠人肉翻译成机器语言的场景，都可以套这个「自然语言 → 受限 DSL → 校验 → 标准件」的模板。伏羲只是第一个把它做在决策规则上的产品。
要泼的冷水同样具体：自然语言写规则，歧义与边界情况仍在——「金额较大」这种词在不同语境下含义不同，最终仍要落到阈值；规则之间的冲突检测、版本管理与灰度发布，考验的是平台工程而非 AI；另外 DMN 生态在企业里的渗透率本身有限，标准件也得有愿意用的运行时。
关联信息与影响
这条情报放在「AI Agent 改造企业软件」的叙事里，是少见的「把 AI 焊进合规管线」的案例。多数 Agent 产品在帮人写代码、写文档，伏羲在帮企业把「业务知识」变成「可审计的决策资产」——它服务的不是开发者效率，而是组织的规则治理。
它与决策引擎生态的既有玩家（Drools、Camunda DMN、各类国产规则平台）形成两种关系：对私有 DSL 的老平台是替代威胁；对标准 DMN 的运行时是上游供给——伏羲不做引擎，只做「规则的生产端」，这反而让它能和标准生态共存。
对国产基础软件还有一个注脚：全栈 Rust 的选择意味着新一代企业中间件开始把「资源占用、单文件交付、内存安全」当成卖点，而不是默认 Java 系全家桶——技术选型的风向在变。
未来展望
短期，看两个证明点：复杂真实场景（如百条以上规则、多决策表联动）下 LLM 翻译的正确率与冲突检测能力；以及 DMN 运行时生态对它输出物的兼容成熟度。
中期，如果「自然语言 → 标准规则」跑通，规则资产会迎来一次「重新入库」浪潮——企业把散落在代码、文档、老系统里的规则批量迁移成 DMN，规则治理从文档驱动变成模型驱动。
长期，决策自动化会和 Agent 合流：业务人员不只写规则，而是「描述一个决策目标」，系统自己拆解、生成、验证规则集并持续根据结果调优——规则引擎从「执行工具」变成「自优化的决策体」的雏形，可能就藏在这类项目里。
信号强度
大模型厂商：企业级「LLM 产物校验」需求凸显——模型输出的可靠性不再只靠提示词，而靠下游的受限 DSL 与编译闸门，这为工具链厂商留出生态位。
研究者：自然语言到结构化规范的转换、规则冲突的自动化检测，是可发表且贴近产业的题目；DMN 作为目标格式降低了实验的工程成本。
开发者：Java 系规则平台的经验贬值风险上升，Rust/标准件/LLM 管线成为新技能点；同时「规则工程」岗位可能从写代码转向定义与校验。
业务人员（风控、信贷、保险等）：终于可以「用自己的话」维护规则，但要接受 AI 翻译件仍需人工复核——角色从「提需求」变成「审规则」。
关联产业链：决策引擎、低代码平台、合规审计工具商需要重新定位；Rust 企业中间件生态与 DMN 运行时是确定性受益方。
规则引擎二十年没解决的事，不是技术不够，而是「业务语言」和「机器语言」之间始终差一个可靠的翻译官。伏羲赌的是：这个翻译官可以由 AI 来当，只要在它身后立一道编译校验的墙。这个赌注如果成立，「写规则」这件事会第一次真正属于业务人员。
devtool/伏羲智能决策平台（AI 情报库 2026-09-07 收录）
本文基于 AI 情报库收录的条目展开深析；事实性信息以原始报道为准，分析与展望为编辑观点。
原始报道：https://www.oschina.net/news/502330（开源中国）
