前兩天和朋友吃飯，聊起了AI，他說：“現在AI這么厲害，為什么不能用到公司系統中呢？”

我說：“你想用到哪里去？”

他說：“公司系統有個采購審批的功能，需要查詢供應商、歷史采購記錄、預算等信息，然后進行分析、決策，這事兒讓AI干不是很合適嗎？”

我想了下，AI看起來確實很適合，但是它干不了啊，它不理解公司這些復雜的業務系統啊！

難不成讓朋友把信息從業務系統中復制出來，讓大模型去分析處理？ 這就太笨了！

這其實就是AI窘況：看起來熱熱鬧鬧，但都是偏娛樂性的玩具，一旦想落地到企業級應用，真正產生價值就難了！

能不能把AI嵌入到業務系統中，和業務系統進行融合呢？

這得要求AI能理解系統的數據模型，業務邏輯，UI模塊，世界上有無數的IT系統，用的開發語言和技術棧各色各樣，AI如何才能理解它們？這太難了。

不過，難就意味著機會，還可能是非常巨大的機會。

最近朋友圈都在談的JitAI，確實有讓人豁然開朗的感覺！

剛看到JitAI時，我覺得這不就是個低代碼平臺然后加上一些AI原生的功能嘛，深入進去才發現：JitAI是從系統架構的最底層做了創新和重構！是一個面向AI而設計的全新系統架構！而面向GUI的可視化低代碼開發，只是它附帶的一個能力而已。

很感慨，在軟件工程領域，第一次看到中國公司在底層協議、開發框架、開發工具、應用容器平臺這種長期被國外占領的領域做出創新。而且，關于那個一直被程序員吐槽但又放不下的課題---“低代碼開發”，我似乎在JitAI上看到了終極答案，作為做過多年開發的我來說，第一次對“可視化開發”的可行性有了完全的認可！

產品很震撼，我大力硬廣一下：官網鏈接：https://jit.pro/

01

讓AI看懂系統底層的秘密

1.給每個模塊都配上一個詳細的“說明書”

為了讓AI實現對業務系統的感知能力，非得從最底層動刀不可，為此JitAI設計了一個叫做JAAP的應用架構協議。

JAAP協議讓應用的每個模塊都是自描述的，這樣，AI看一眼就知道：

• 模塊的功能（這個模塊是干什么的？）

• 輸入參數要求（需要什么數據？）

• 輸出結果格式（會返回什么？）

• 調用限制條件（什么情況下能用？）

比如這是個元素的定義：

}

AI只要一看這個說明書，就會明白：“嗯，這是個數據模型的定義，主要做用戶管理的，它有個叫做getUserById的方法，可以根據ID獲取用戶，參數是userId，但是必須得登錄以后才行.......”

這種自描述模塊不但適用于后端業務邏輯，也適用于前端UI，這意味著AI不僅能調用后端功能，還能理解和操作前端界面，這為AI驅動全棧系統奠定了基礎。

2.統一調用方式

在傳統的應用中，模塊不同，調用方式也不同：直接調用函數，消息隊列，RPC，Websocket，RESTful......

想讓AI調用它們，得給每種調用模式寫適配代碼，這種復雜度高得可怕。

JitAI的解決方案是：車同軌，書同文，統一調用方式。

每個模塊既然已經有了自描述的功能接口，那就用這種統一的方式來調用它們：

login_result = auth_service.authenticate(username, password)

02

讓AI自動完成業務流程

想想看，當你的系統是由這些自描述的模塊組成，并且調用方式都一樣，會發生什么事情？

AI看到這些東西，估計會高興壞了，這是一個它完全可以理解的世界，它完全可以自動完成非常復雜的業務流程。

這么說略微有點兒抽象，我們可以看一個實際的案例。

有一個對銷售進行話術考核的系統，銷售人員需要針對一些銷售相關的問題做出回答，像這樣：

對每個問題，系統已經設定了標準答案，用它和銷售人員的回答進行對比，然后進行評分，很明顯，這個工作非常適合AI來干。

如果使用傳統的系統，評卷人得把標準答案和銷售的答案復制到AI中，讓AI評判，然后再把AI生成的得分和理由給復制回來，非常麻煩。

但是有了JitAI，在設計評卷系統的時候，可以給這個界面添加一個AI助理：

然后告訴AI助理：應該從界面的哪些字段取值，從數據模型的哪些字段取值，如何評分，最后更新哪些字段......

由于每個模塊都是自描述的，調用方式是統一的，AI在運行的時候可以獲取這些信息，對銷售的回答進行評分，然后直接把結果更新到界面當中去。

整個過程非常絲滑，AI把整個流程都自動完成，完全不需要人工介入。

這不是“加一個 AI 按鈕”，是系統“AI 原生化”！

03

可規模化的建模體系

你可能覺得JAAP這種自描述的模塊非常好，但是一個系統需要很多模塊，自己去開發可就太麻煩了。

其實不用擔心，應用開發所需的絕大部分模塊Jit都已經幫你建好了，你只需要直接使用，或者擴展一下就行。

這就不得不說一下給我印象非常深刻的三層抽象結構了：Meta、Type、Instance。

Meta層定義類別，例如門戶，頁面，組件，模型，這一層最抽象，最穩定，可以說是幾乎不變。

Type層是類型，封裝了技術實現，比如“數據表格組件”，這一層最復雜，不過JitAI框架已經內置了豐富的Type庫，像開發者門戶，數據庫表模型等，程序員可以擴展。

Instance層承載了個性化的業務配置，例如“訂單列表”就是數據表格組件的Instance。

JitAI開發框架中已經實現了大量常用的Meta和Type，已經把前兩層都做完了。

• 門戶、頁面、組件：UI層

• 數據模型、服務：業務邏輯層

• 工作流、權限：流程控制層

• 組織架構、登錄認證、數據源：基礎設施層

而且開發者只要遵循JAAP協議，就可以對框架內的任何Meta元素、Type元素進行重寫替代、也可以擴展自己的新元素。這些元素既可以是前端功能組件、也可以是后端功能模塊。這意味著開發者可以充分復用官方框架的內置全棧能力又絲毫不受束縛，擁有持續集成新能力的無限自由。

大多數情況下，開發者只需要在Instance層選組件、配置數據、寫邏輯，構建一個企業應用非常快。

04

編排+編程的完美統一

看到上面那幾幅圖，你可能會覺得：嗯？又一個低代碼開發平臺？

看起來像，實際上JitAI和低代碼平臺有著本質的不同。

JitAI開發框架就像許多小積木組成的矩陣，低代碼能力只不過是其中的一塊而已。

任何IT系統都是由過程和結構共同組成的，編排形成結構，定義系統由哪些模塊組成、模塊之間如何關聯；編程實現過程，描述系統如何運行、業務邏輯如何執行。

低代碼非常擅長編排，通過可視化拖拽，快速生成應用，但是在開發的時候，一旦出現超越它能力的需求，就抓瞎了。

要么得搞“惡心人”的特殊處理，要么給廠家提要求，升級軟件，這往往是非常漫長的周期。

而JitAI則是一個開放的系統，它擁有JAAP這個開放的協議，每個模塊都自描述，在運行時相互感知、驅動，任何人都可以寫出新的、符合協議的模塊，加入到系統中來，從而輕松實現那些超越能力的需求。

JitAI不但擅長編排，而且非常適合編程，實現了可視化編排+編程的完美統一。

在Jit的可視化開發工具中，可以可視化地組裝模塊，實時預覽效果，當你遇到復雜的邏輯時（這在企業開發中太常見了!），編排的效率就太低了，這時候可以切換到代碼模式，用幾十行代碼清晰表達出來。

更牛的是，在JitAI中實現了雙向的工作流：

1. 可視化拖拽組裝模塊 → 實時預覽效果

2. 自動生成高質量原生代碼 → 代碼可自由修改

3. 代碼修改后 → 可視化視圖自動更新

4. 循環往復 → 可視化與代碼保持同步

比如這個試卷管理的功能，我既可以在可視化界面下配置UI，又可以隨時切換到代碼模式去寫代碼，實現一些復雜的業務，兩者實時同步，非常方便。

既能享受可視化編排的直觀性，又不失去代碼的靈活性，這才是正確的開發范式。

05

AI原生時代的中國方案

朋友的業務系統如果使用JitAI來開發，他的問題將會迎刃而解，因為JitAI從最底層做出了關鍵的創新，可以讓AI理解一個復雜業務系統的方方面面，發揮AI的優勢，幫助我們自動化復雜的業務流程。

不但如此，JitAI提供的高集成度的應用運行平臺、高復用性和高擴展性的開發框架，讓圖形化編排和編程實現了完美統一，讓業務應用開發變得更簡單、輕量、快速和高效。

其實我看到JitAI，心里是非常感慨的，在軟件世界，美國由于起步早，有著先發優勢，很多基礎軟件、應用軟件、框架、庫......早已經被他們占據，軟件生態一旦建成，后來者想要進行切換幾乎不可能。

但是AI時代就不一樣了，大家站在同一起跑線，中國的公司完全有可能制定自己的標準和協議，建立自己的技術生態。

JitAI是我見到的第一家將AI和業務系統融合得這么好的開發平臺，充分展示了中國企業的創新能力，希望有一天JitAI也能在國際舞臺上大放異彩。

最后，建議大家去感受下JitAI的理念和demo（點擊閱讀原文可直達） ：

https://jit.pro/

它會讓你看到：AI + 企業開發，其實可以完全是另一種形態。