當前位置：首頁 > 科技 > 軟件

規則引擎與商業CRM的完美邂逅：將智能決策融入商業擴展

來源：責編：時間：2023-11-02 09:09:32 318觀看

導讀一、背景介紹商業CRM系統的商機模塊業務復雜、場景繁多、規則調整頻繁，商機流轉效率一定程度決定了銷售開單的效率。如何高效配合產品側完成業務規則調整，商機流轉經歷了硬編碼到半配置化的優化升級，過程中遇到了一些問

一、背景介紹

商業CRM系統的商機模塊業務復雜、場景繁多、規則調整頻繁，商機流轉效率一定程度決定了銷售開單的效率。如何高效配合產品側完成業務規則調整，商機流轉經歷了硬編碼到半配置化的優化升級，過程中遇到了一些問題，也總結了一些經驗，今天來和大家掰開揉碎了講一講這其中遇到的問題和解決方案。

1.1 什么是CRM

先看一下CRM的官方定義：

CRM(Customer Relationship Management)：客戶關系管理，是指企業為提高核心競爭力，利用相應的信息技術以及互聯網技術協調企業與顧客間在銷售、營銷和服務上的交互，從而提升其管理效率，向客戶提供創新式的個性化的客戶交互和服務的過程。

其最終目標是：吸引新客戶、保留老客戶以及將已有客戶轉為忠實客戶，增加市場。

可以這么簡單的理解，CRM的核心價值就是：將潛在客戶更高效的轉化為客戶，將客戶更高效的轉化為長期客戶。

圖片

介紹完什么是CRM，那CRM系統就很容易理解了，用于支撐企業進行客戶關系管理的系統，就可以稱作CRM系統。這個定義比較寬泛，每個公司對CRM中功能邊界也不完全一樣，大家初步理解這個概念就行。比如轉轉商業CRM系統，主要包含：商機管理、客戶管理、銷售/運營人員管理、業績管理、效率監控等功能模塊。

1.2 商機業務介紹

要想把潛在客戶變成客戶，就需要銷售人員進行跟進，對潛在客戶進行產品的售賣，用戶購買產品后，變成客戶。這個潛在客戶，我們稱作“商機”，也就是一次成單的機會，有的CRM系統中，也稱為“線索”。

上圖是潛在用戶到客戶簡單的流轉圖

從商機生成到最終成單，銷售跟進過程中，涉及一些概念，比如商機池（公海池、私海池）、商機狀態/來源/類型/等級、商機的流轉等。

商機池：各種商機的集合。公海池：該集合里的商機當前不歸屬于任何銷售，所有銷售均可以看到公海里的商機。私海池：綁定了特定銷售的商機集合，比如銷售A的商機私海池，只有銷售A可以看到和跟進，其他銷售不可見、不可跟進。商機流轉：商機在跟進過程中，被不同的銷售跟進，狀態發生不同的變化。流轉規則：流轉過程中會有各種各樣的業務規則限制，比如銷售最多可以認領100條商機、負責手機類目的銷售不能認領電腦類目的商機、銷售剛放棄的商機不能立馬重新認領、單位時間內不進行電話溝通的商機將流出銷售私海等等。

二、商機流轉遇到的問題

2.1 商機流轉業務特點

這里舉一個例子來說明商機的流轉，業務背景：商機對應用戶主營類目為手機，銷售A、B負責手機類目，銷售C負責電腦類目，銷售D也負責手機類目。

圖片

這是一個簡單的流程，實際流程比這個復雜。從這個簡易的流程介紹中，可以窺見部分商機流轉模塊的業務特點，總結起來有三點：

狀態的多樣性

圖片

狀態間轉換場景繁多

圖片

流轉規則復雜多變

圖片

2.2 商機流轉業務痛點

之前商業CRM中關于流轉的處理邏輯，好多都是硬編碼，舉個銷售認領某條商機的例子：

//狀態校驗if(checkClueStatus(param)){ return “狀態不合法”;}//綁定人校驗if(checkClueBindUser(param)){ return “上一個綁定人不可以為···”;}//私海容量校驗if(checkPrivateClueCount(param)){ return “私海庫已滿，無法操作··”;}//類目校驗if(checkClueCate(param)){ return “類目不匹配，無法操作··”;}//任務是否完成校驗if(checkClueTaskFinished(param)){ return “任務未完成，無法操作··”;}  ······bind(param);//綁定操作log();//日志記錄操作

從代碼中可以看出，銷售從公海進行認領一條自己覺得有價值的商機時，并不是直接就讓該商機流入到該銷售私海中，這個過程會有各種規則的業務校驗。

2.2.1 痛點

硬編碼實現的業務，維護成本大；
業務規則經常調整，難以應對變化，產研配合效率低；
業務規則調整需要配合修改代碼，重新上線后生效。

2.2.2 訴求

規則抽取成可配置項，調整方便；
校驗相關閾值，可隨時動態調整，無需上線；
代碼優雅度適當提高。

帶著我們的痛點和訴求，接下來看看可以找到什么樣的解決方案。然后我們進入了調研階段，發現對于這種策略比較密集的業務，規則引擎是一個可參考方向，然后就開始了解規則引擎相關細節，了解完后，發現和業務問題匹配度很高。接下來，先介紹一下規則引擎相關的基本知識。

三、什么是規則引擎

3.1 什么是規則

規則就是：條件 --> 推理 --> 結果。一個完整的規則是需要這三部分元素的，平時大家討論規則，某些時候只是在討論第一部分的條件，比如學校的行為規范，咱們國家的各種法律條文，可能關注的部分是需要滿足什么條件（不能做什么什么），后面的推理和結果省去了。比如學生準則里的不辱罵同學，這是一個條件，那怎么算辱罵呢，這是推理過程，辱罵后會發生什么呢，會受到老師批評，這是結果。

那什么是推理引擎和規則引擎呢？

推理引擎：如果由程序來處理推理過程，那么這個程序就叫做推理機/推理引擎。
規則引擎：基于規則的推理機易于理解、易于獲取、易于管理，被廣泛采用。這種推理引擎被稱為“規則引擎”。是一種嵌入在應用程序中的組件，實現了將業務決策從應用程序代碼中分離出來，并使用預定義的語義模塊編寫業務決策。接受數據輸入，解釋業務規則，并根據業務規則做出業務決策。

3.2 推理引擎原理

圖片

模式匹配器決定選擇執行哪個規則，何時執行規則；
議程管理模式匹配器挑選出來的規則的執行次序；
執行引擎負責執行規則和其他動作。

推理引擎通過決定哪些規則滿足事實或目標，并授予規則優先級，滿足事實或目標的規則被加入議程，具體過程：

將初始數據（fact）輸入至工作內存(Working Memory)。
使用Pattern Matcher將規則庫(Rules repository)的規則（rule）和數據（fact）比較。
如果執行規則存在沖突（conflict），即同時激活了多個規則，將沖突的規則放入沖突集合。
解決沖突，將激活的規則按順序放入Agenda。
執行Agenda中的規則。
重復步驟2至5，直到執行完畢Agenda中的所有規則。

推理方式分為正向推理和反向推理

正向推理（演繹法）：事實驅動，正向推理，直到無事實可用或者得出結論為止；
反向推理（歸納法）：目標驅動，提出假設，尋找支持該假設的證據，如果能找到證明，結論正確，如果不能，換假設繼續。

常見的模式匹配算法有Rete,LFA,TREAI,LEAPS。Rete算法是目前效率最高的一個演繹法推理算法，許多規則引擎都是基于Rete算法來進行推理計算的。

3.3 Rete算法

3.3.1 Rete算法簡介

Rete在拉丁語中是“net”，有網絡的意思。Rete算法由Carnegie Mellon University的Dr Charles L. Forgy設計發明，是一個用來實現產生式規則系統（production/inference）的高效模式匹配算法。
RETE算法可以分為兩部分：規則編譯（rule compilation）和運行時執行（runtime execution）。

規則編譯：是指根據規則集生成推理網絡的過程。
運行時執行：指將數據送入推理網絡進行篩選的過程。

相關概念：

事實（fact）：對象之間及對象屬性之間的關系
規則（rule）：是由條件和結論構成的推理語句，一般表示為if…Then。一個規則的if部分稱為LHS（left-hand-side），then部分稱為RHS（right hand side）。
模式（module）：就是指IF語句的條件。這里IF條件可能是有幾個更小的條件組成的大條件。模式就是指的不能在繼續分割下去的最小的原子條件。

3.3.2 Rete算法原理

圖片

這是Rete算法的原理圖，Rete算法涉及兩種網絡和6種不同作用的節點。

網絡節點：Type Node、Select Node、Join Node、Teminal Node、Alpha Memory、Beta Memory
alpha網絡：過濾working memory，找出符合規則中每一個模式的集合，生成alpha memory（滿足該模式的集合）。
Beta網絡：有兩種類型的節點Beta Memory和Join Node。前者主要存儲Join完成后的集合。后者包含兩個輸入口，分別輸入需要匹配的兩個集合，由Join節點做合并工作傳輸給下一個節點。

3.3.2.1 Rete推理網絡生成過程

圖片

創建root節點（根節點），推理網絡的入口。
拿到規則1，從規則1中取出模式1（模式就是最小的原子條件，所以規則模式的關系是1：n）。

a) 檢查模式1中的參數類型，如果是新類型，添加一個類型節點。

b) 檢查模式1對應的Alpha節點是否存在，如果存在記錄下節點的位置；如果沒有，將模式1作為一個Alpha節點加入到網絡中。同時根據Alpha節點建立Alpah內存表。

c) 重復b，直到處理完所有模式。

d) 組合Beta節點：Beta(2)左輸入節點為Alpha(1)，右輸入節點為Alpha(2)；Beta(i)左輸入節點是Beta(i-1),右輸入節點為Alpha(i)，并將兩個父節點的內存表內聯成為自己的內存表。

e) 重復d，直到所有Beta節點處理完畢。

f) 將動作Then部分封裝成最后節點做為Beta（n）。

重復2，直到所有規則處理完畢。

3.3.2.2 Rete匹配過程

圖片

導入需要處理的事實到facts集合中。
如果facts不為空，選擇一個fact進行處理。否則停止匹配過程。
選擇alpha網的第一個節點運行（建立網絡的時候設定的），通過該節點則進入alpha網的下一個節點，直到進入alpha memory。否則跳轉到下一條判斷路徑。
將alpha memory的結果加入到beta memory中，如果不為Terminal節點，則檢測另一個輸入集合中是否存在滿足條件的事實，滿足則執行join，進入到下一個beta memory重復執行3。若另一個輸入集合無滿足條件的事實，返回到2。如果該節點為Terminal節點，執行ACT并添加到facts中。

3.3.3 Rete算法實例

上面介紹的這些都偏理論化，可能有一點不太容易理解，沒關系，接下來咱們用一個具體的例子，看看Rete算法到底是如何運行的。咱們依然以這個選拔籃球苗子的例子來說明。

圖片

首先看下對應的網絡圖

圖片

Rete匹配過程
匹配過程詳解

A節點：拿StudentFact的年級數值進行年級匹配，如果年級符合條件，則把該StudentFact的引用記錄到A節點的alpha內存區中，退出年級匹配。

B節點：拿StudentFact的性別內容進行性別匹配，如果性別符合條件，則把該StudentFact的引用記錄到B節點的alpha內存區中，然后找到B節點左引用的Beta節點，也就是C節點。

C節點：C節點找到自己的左引用也就是A節點，看看A節點的alpha內存區中是否存放了StudentFact的引用，如果存放，說明年級和性別兩個條件都符合，則在C節點的Beta內存區中存放StudentFact的引用，退出性別匹配。

D節點：拿StudentFact的年齡數值進行年齡條件匹配，如果年齡符合條件，則把該StudentFact的引用記錄到D節點的alpha的內存區中，然后找到D節點的左引用的Beta節點，也就是E節點。

E節點：E節點找到自己的左引用也就是C節點，看看C節點的Beta內存區中是否存放了StudentFact的引用，如果存放，說明年級，性別，年齡三個條件符合，則在E節點的Beta內存區中存放StudentFact的引用，退出年齡匹配。

F節點：拿StudentFact的身體數值進行身體條件匹配，如果身體條件符合，則把該StudentFact的引用記錄到D節點的alpha的內存區中，然后找到F節點的左引用的Beta節點，也就是G節點。

G節點：G節點找到自己的左引用也就是E節點，看看E節點的Beta內存區中是否存放了StudentFact的引用，如果存放，說明年級，性別，年齡，身體四個條件符合，則在G節點的Beta內存區中存放StudentFact的引用，退出身體匹配。

H節點：拿StudentFact的身高數值進行身高條件匹配，如果身高條件符合，則把該StudentFact的引用記錄到H節點的alpha的內存區中，然后找到H節點的左引用的Beta節點，也就是I節點。

I節點：I節點找到自己的左引用也就是G節點，看看G節點的Beta內存區中是否存放了StudentFact的引用，如果存放了，說明年級，性別，年齡，身體，身高五個條件都符合，則在I節點的Beta內存區中存放StudentFact引用。同時說明該StudentFact對象匹配了該規則，形成一個議程，加入到沖突區，執行該條件的結果部分：該學生是一個籃球苗子。

3.3.4 Rete算法的優點

可共享node和memory，提高效率；
memory存儲中間結果，空間換時間，避免重復計算；
Rete 匹配速度與規則數目無直接關系，因為fact只有滿足本節點才會繼續向下沿網絡傳遞。

3.3.5 Rete算法的缺點

規則的條件與facts的數目如果過大，對應memory會指數級升高，極端情況下會耗盡系統資源。

3.3.6 Rete算法使用建議

容易變化的規則盡量置后匹配，可以減少規則的變化帶來規則庫的變化。
約束性較為通用或較強的模式盡量置前匹配，可以避免不必要的匹配。
針對 Rete 算法內存開銷大和facts增加刪除影響效率的問題，技術上應該在 AlphaMemory 和 BetaMemory 中，只存儲指向內存的指針，并對指針建里索引（可用 hash 表或者非平衡二叉樹）。
Rete 算法 JoinNode 可以擴展為 AndJoinNode 和 OrJoinNode，兩種節點可以再進行組合。

看完這個匹配的過程，相信大家對規則引擎中常用的Rete算法有了一定的了解。回到規則引擎，那為啥用規則引擎呢，也就是它有何優勢，以及有哪些適用的場景呢？

3.4 規則引擎優勢

高靈活性：規則保存在知識庫中，規則變動可以輕易做出修改。
容易掌控：規則比過程代碼更易于理解，因此可以有效地來彌補業務人員和開發人員之間的溝通問題。
降低復雜度：在程序中編寫大量的判斷條件，很可能是會造成一場噩夢。使用規則引擎卻能夠通過一致的表示形式，更好的處理日益復雜的業務邏輯。開發人員也可以更關注邏輯處理，而無需過多關注邏輯判斷。
可重用性：規則集中管理，可提高業務的規則的可重用性。而且，傳統的代碼程序通常會添加不必要的變數，很難進行重復利用。
規則外部化：即有利于規則知識的復用，也可避免改變規則時帶來的代碼變更問題。

3.5 規則引擎使用場景

一般多用于規則較多且規則調整頻繁的業務場景，比如：積分規則、計費系統、信用風險評估、監控告警、工作流系統。

3.6 規則引擎的分類

網上有兩種分類方式，這里我列舉出來，供大家了解。

基于實現方式
基于完成度和功能配置

圖片

四、商機流轉問題解決方案

了解了上面這些業務背景以及遇到的問題，也熟悉了規則引擎的理論知識，現在需要制定具體的解決方案了，我們怎么做的呢？市面有各種各樣的規則引擎，先進行技術選型，這里列舉下當前主流規則引擎優缺點。

圖片

通過各方面綜合評估，重點放到了Drools和easyRule兩者，且easyRule最終勝出。

4.1 Drools和easyRule對比

圖片

確定了要使用easyRule就得知道easyRule如何使用的，先介紹下其相關概念和使用方法。

4.2 easyRule插件介紹

4.2.1 規則說明

name：規則命名空間中的唯一規則名稱
description：規則的簡要描述
priority：規則的優先級
facts：觸發規則時的一組已知事實
conditions：在給定一些事實的情況下，為了應用該規則，需要滿足的一組條件
actions：滿足條件時要執行的一組操作(可能會添加/刪除/修改事實)

4.2.2 規則定義方式

通過在POJO上添加注解來聲明
通過RuleBuilder API編程

4.2.3 組合規則用法

Easy Rules提供了3種CompositeRule的實現。

UnitRuleGroup：要么應用所有規則，要么不應用任何規則。--要么全用要么不用
ActivationRuleGroup：激活規則組觸發第一個適用規則并忽略組中的其他規則。--首個選用
ConditionalRuleGroup：條件規則組將具有最高優先級的規則作為條件，如果具有最高優先級的規則的計算結果為true，那么將觸發其余的規則。--優先級最高說了算

4.2.4 自定義優先級

值越低優先級越高。要覆蓋此行為，可重寫compareTo()方法以提供自定義優先級策略。

4.2.5 引擎執行模式

skipOnFirstAppliedRule：當一個規則成功應用時，跳過余下的規則。--一個成功，不管其他
skipOnFirstFailedRule：當一個規則失敗時，跳過余下的規則。--一個失敗，不管其他
skipOnFirstNonTriggeredRule：當一個規則未觸發時，跳過余下的規則。--一個不符合，不管其他
rulePriorityThreshold：當優先級超過指定的閾值時，跳過余下的規則。--優先級達標，不管其他

4.2.6 多種監聽器可供選擇

支持自定義規則監聽器、規則引擎監聽器。

4.2.7 表達式語言支持

支持MVEL、SPEL表達式語言，可通過編程方式定義規則。

4.2.8 規則中的錯誤處理

對于條件求值過程中可能發生的任何運行時異常(丟失事實、表達式中輸入錯誤等)，引擎將記錄一個警告，并認為條件求值為false。
對于任何在執行操作時可能發生的運行時異常(丟失事實、表達式中輸入錯誤等)，該操作將不會執行，引擎將記錄一個錯誤。

4.3 easyRule使用樣例

還是用篩選籃球苗子的例子

圖片

定義一個學生實體類

public class Student {    /**     * 年級     */    private Integer grade;    /**     * 性別     */    private String gender;    /**     * 年齡     */    private Integer age;    /**     * 是否強壯     */    private Boolean isStrong;    /**     * 身高     */    private Integer height;    /**     * 是否一個好苗子     */    private Boolean isGoodSeed = true;}

定義規則（有多種方式，我列舉幾種）

//創建規則1-年級Rule rule1 = new MVELRule()        .name("grade rule")        .description("判斷一個學生是否是一個籃球好苗子-年級")        .priority(1)        .when("student.getGrade() <= 3")        .then("System.out.println(/"年級-不是好苗子/");")        .then("student.setIsGoodSeed(false);");

//創建規則2-性別Rule rule2 = new MVELRuleFactory(new YamlRuleDefinitionReader()).        createRule(new FileReader(                ResourceUtils.getFile("classpath:gender-rule.yml")));

規則2需要的yml文件內容如下：

name: "gender rule"description: "判斷一個學生是否是一個籃球好苗子-性別"priority: 2condition: "student.getGender().equals(/"girl/")"actions:  - "System.out.println(/"性別-不是好苗子/");student.setIsGoodSeed(false);"

//創建規則3-年齡  Rule rule3 = new MVELRuleFactory(new JsonRuleDefinitionReader()).          createRule(new FileReader(                  ResourceUtils.getFile("classpath:age-rule.json")));

//創建規則4-是否強壯Condition condition = new MVELCondition("!student.getIsStrong()");Action action = new Action() {    @Override    public void execute(Facts facts) throws Exception {        Student student1 = (Student) facts.get("student");        student1.setIsGoodSeed(false);        System.out.println("強壯-不是好苗子");    }};Rule rule4 = new RuleBuilder()        .name("strong rule")        .description("判斷一個學生是否是一個籃球好苗子-是否強壯")        .priority(4)        .when(condition)        .then(action).build();

@Rule(name = "height rule" ,description = "判斷一個學生是否是一個籃球好苗子-身高")public class HeightRule {    @Condition    public boolean checkHeight(){ return student.getHeight() <= 170;}    @Action    public void action(){        System.out.println("身高-不是好苗子");        student.setIsGoodSeed(false);    }    private Student student;    public HeightRule(Student student){        this.student = student;    }}//創建規則5-身高HeightRule rule5 = new HeightRule(student);

創建實例(fact)

//創建一個Student實例(Fact)  Student student = new Student(3,"girl",9,true, 160,true);  Facts facts = new Facts();  facts.put("student", student);

創建引擎，并執行規則

//注冊規則Rules rules = new Rules();rules.register(rule1);rules.register(rule2);//rules.register(rule3);rules.register(rule4);rules.register(rule5);//創建規則執行引擎，并執行規則RulesEngine rulesEngine = new DefaultRulesEngine();System.out.println("開始判斷是否是一個籃球苗子：" + JSON.toJSONString(student));rulesEngine.fire(rules, facts);System.out.println("是否為好苗子：" + student.getIsGoodSeed());

執行結果

圖片

4.4 商機流轉如何接入easyRule

熟悉了easyRule如何使用的，接下來看看我們如何在項目中落地的，我們分了幾步：

將easyRule工具包進行二次改裝，使其執行規則后能有返回值，封裝成jar包，將規則引擎抽取成通用能力。

初始化規則相關配置（首次初始化+定時更新）；

提供對外public T fire(String ruleId, V v)通用的規則引擎api接口。

圖片

這里我們將規則引擎的處理結果進行了返回，因為業務上很多場景需要，比如不符合規則時的提醒文案。

將現有的流轉規則進行整理提取，將各種判斷條件拆解成單一的指標判斷。
項目中引入easyRule工具。

項目中配置規則引擎相關配置；

實例化RuleEngineTemplate類；

根據場景，組裝上下文context；

調用ruleEngineTemplate.fire(ruleId,context)方法。

圖片

引入后，我們的商機流轉流程發生了如下變化：

圖片

4.5 商機解綁流程舉例

商機解綁流程

圖片

解綁對應的規則配置application.yml

spring:  easy-rule:    priority-threshold: 100    skip-on-first-failed-rule: false    skip-on-first-applied-rule: true    skip-on-first-non-triggered-rule: false    rules:      - rule-id: "opportunity_unbind"        rule-file-location: "opportunity_unbind" #規則配置文件        rule-config-type: JSON        rule-factory-type: SPEL

具體的規則配置json

[      {        "name": "bind_check_cate",        "description": "判斷是否凍結-72小時",        "condition": "@opportunityUnbindRuleBll.checkOpportunityNeedFreeze(#context.getOpportunityId(), n,m)",        "priority": 4,        "actions": [          "@clueOpporBll.unbindOpportunity(#context,T(OpportunityStatusEnum).UNBIND, T(com.clue.enums.OpportunityMinorStatusEnum).UNBIND_FROZEN)"        ]      },      {        "name": "task_bind_out",        "description": "任務商機流回公海",        "condition": "#context.getOpportunityStatus() == T(com.enums.OpportunityStatusEnum).TASK && #context.getOperationTypeEnum() == T(com.OpportunityOperationTypeEnum).TASK_BACK_PUBLIC",        "priority": 5,        "actions": [          "@clueBll.unbindOpportunity(#context,T(com.zhuanzhuan.biz.clue.enums.OpportunityStatusEnum).UNBIND, T(com.OpportunityMinorStatusEnum).UNBIND_NORMAL)"        ]      },      {        "name": "unbind_operate",        "description": "判斷解綁后去向，現階段全部回到公海",        "condition": "true",        "priority": 10,        "actions": [          "@clueOpportunityBll.unbindOpportunity(#context,T(com.OpportunityStatusEnum).UNBIND, T(com.enums.OpportunityMinorStatusEnum).UNBIND_NORMAL)"        ]      }    ]  }]

業務代碼

public Result<ParallelExecuteDTO> unbindOpportunity(UnbindOpportunityRequest request) {  return parallelExecutor.parallelExecute(request.getOpportunityIds(), (Long opportunityId) -> {            final Result<String> unbindResult = opportunityUnbindRuleBll.unbindOpportunity(opportunityId, request.getOperator(),                  request.getReasonType(), request.getReasonDesc(), request.getOperationType());            logger.info("method=unbindOpportunity, act=unbind, opportunityId={},unbindResult={}", opportunityId, unbindResult);            return unbindResult;            }        );    }

4.6 引入規則引擎前后效果對比

圖片

五、總結

在easyRule引入商機流轉業務過程中，從調研到選型再到最終落地，遇到了各種大大小小的問題，但最終的效果還是比較明顯的，對團隊的整體效率提升非常明顯，這里有幾點總結與建議與大家分享。

系統引入規則引擎，一定要場景符合，不能為了引入而引入；
業務規則轉換為抽象的規則配置，可以多和業務人員交流，他們對于規則的理解可能更深刻；
選擇規則引擎方案后，需要定好規則維護規范，后續執行按照規范維護；
對于集群中沒有直接引用的代碼，不要直接清理，有可能是在規則文件里有引用。

作者介紹

楊迎，轉轉商業后端開發工程師，目前負責商業B端相關業務系統開發（商機線索、客戶運營、銷售運營管理、廣告發布等）。

本文鏈接：http://www.www897cc.com/showinfo-26-16530-0.html規則引擎與商業CRM的完美邂逅：將智能決策融入商業擴展

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇：在Lombok的加持下，“小狗”.Equals(“老狗”) = True

下一篇：聽說你會架構設計？來，弄一個微信群聊系統

標簽：

熱門焦點

把LangChain跑起來的三個方法

使用LangChain開發LLM應用時，需要機器進行GLM部署，好多同學第一步就被勸退了，那么如何繞過這個步驟先學習LLM模型的應用，對Langchain進行快速上手？本片講解3個把LangChain跑起來
得物效率前端微應用推進過程與思考

一、背景效率工程隨著業務的發展，組織規模的擴大，越來越多的企業開始意識到協作效率對于企業團隊的重要性，甚至是決定其在某個行業競爭中突圍的關鍵，是企業長久生存的根本。得物
微信語音大揭秘：為什么禁止轉發？

大家好，我是你們的小米。今天，我要和大家聊一個有趣的話題：為什么微信語音不可以轉發？這是一個我們經常在日常使用中遇到的問題，也是一個讓很多人好奇的問題。讓我們一起來揭開這
造車兩年股價跌六成，小米的估值邏輯變了嗎？

如果從小米官宣造車后的首個交易日起持有小米集團的股票，那么截至2023年上半年最后一個交易日，投資者將浮虧59.16%，同區間的恒生科技指數跌幅為52.78%
消息稱小米汽車開始篩選交付中心：需至少120個車位

IT之家 7 月 7 日消息，日前，有微博簡介為“汽車行業從業者、長三角一體化擁護者”的微博用戶 @長三角行健者發文表示，據經銷商集團反饋，小米汽車目前
英特爾Xe HPG游戲顯卡：擁有512EU，單風扇版本

據10 月 30 日外媒 TheVerge 消息報道，英特爾 Xe HPG Arc Alchemist 的正面實被曝光，不僅擁有 512 EU 版顯卡，還擁有 128EU 的單風扇版本。另外，這款顯卡 PCB
AI藝術欣賞體驗會在上海梅賽德斯奔馳中心音樂俱樂部上演

光影交錯的鏡像世界，虛實幻化的視覺奇觀，虛擬偶像與真人共同主持，這些場景都出現在2019世界人工智能大會的舞臺上。8月29日至31日，“AI藝術欣賞體驗會”在上海
三翼鳥智能家居亮相電博會，讓用戶體驗更真實

2021電博會在青島國際會展中心開幕中，三翼鳥直接把“家”搬到了現場，成為了展會的一大看點。這也是三翼鳥繼9月9日發布了行業首個一站式定制智慧家平臺后的
2021中國國際消費電子博覽會與青島國際軟件融合創新博覽會新聞發布會隆重舉行

9月18日，2021中國國際消費電子博覽會與青島國際軟件融合創新博覽會新聞發布會在青島國際新聞中心隆重舉行。發布會上青島市政府領導聯袂出席，對本次雙展會情