博客 / 詳情

返回

對話織信:聊聊它與 Dify (Agentic)工作流開發平台的區別與聯繫

在AI與低代碼深度融合的賽道上,織信的進階之路頗具代表性。從早期的傳統低代碼平台,到如今的AI企業級低代碼標杆,織信用數年時間完成了一次關鍵跨越。不少人會好奇:

  • 織信和當下熱門的Dify到底有什麼不同?
  • 它從低代碼向AI企業級低代碼轉型的過程中,又經歷了哪些關鍵節點?

本期我們對話織信創始人杜總,覆盤織信的轉型歷程,拆解它與Dify的核心差異,探尋其背後的決策邏輯。

(訪談內容2萬多字,本內容為訪談精簡整理版,約4000字,供參考!)

主持人:現在很多人會把織信和Dify放在一起討論,你覺得兩者最核心的區別是什麼?畢竟都是AI相關的企業級工具。

杜總:最本質的區別,在於核心定位和服務的業務場景完全不同。如果用一個簡單的光譜來劃分,最左邊是聚焦AI應用搭建的工具,最右邊是深耕企業全鏈路業務落地的平台,那Dify更偏向左邊,而織信則穩穩站在右邊。

具體來説,Dify的核心能力集中在AI應用的快速搭建,比如知識庫問答、簡單工作流編排,更偏向“AI工具搭建器”的屬性,服務的場景相對輕量化。而織信的起點是低代碼,核心是解決企業複雜的業務流程落地問題,AI是我們賦能低代碼的關鍵能力,最終目標是讓企業能通過低代碼+AI的方式,快速構建適配自身需求的企業級系統,比如生產管理、客户管理、項目協同等全鏈路場景。

簡單講,Dify是“用AI做工具”,織信是“用AI賦能企業業務系統”,服務的用户羣體和解決的核心痛點完全不同。Dify可能更適合需要快速搭建輕量化AI應用的團隊,而織信則聚焦於有複雜業務流程、需要打通多系統數據、實現規模化AI落地的企業。

image.png

主持人:明白了,核心定位的差異決定了兩者的發展路徑。那我們把話題拉回織信本身,當初為什麼決定從傳統低代碼向AI企業級低代碼轉型?這個決策是基於什麼判斷?

杜總:其實這個轉型不是突然的,而是我們對市場需求的長期觀察和驗證的結果。可以梳理一下我們的時間線,大概分為三個階段。

第一階段是2019-2022年,這是織信的傳統低代碼階段。當時低代碼賽道剛興起,市場需求主要集中在“快速開發”——企業需要擺脱傳統代碼開發的高成本、慢週期,快速搭建一些基礎的業務系統,比如表單管理、簡單的審批流程。這個階段我們的核心目標是把低代碼的“易用性”和“靈活性”做紮實,讓非技術人員也能參與到系統搭建中。

第二階段是2022年底-2023年,是AI探索期。這個階段我們明顯感覺到市場需求變了:企業不再滿足於“能快速搭系統”,更希望“搭出來的系統能更智能”。比如,傳統的客户管理系統需要人工錄入客户信息、分析跟進記錄,效率很低。企業希望能通過AI自動提取客户信息、生成跟進摘要、預測成交概率。

當時我們做了大量的客户調研,發現超過60%的企業客户都有類似的需求。同時,我們也注意到,單純的低代碼平台已經遇到了瓶頸——只能解決“搭建”問題,無法解決“智能賦能”的問題。而AI技術的成熟,正好給了我們突破這個瓶頸的機會。所以在2023年初,我們正式確定了“AI+低代碼”的轉型方向,開始在低代碼平台中融入AI能力。

第三階段是2024年至今,AI企業級低代碼成型期。這個階段我們完成了從“低代碼+AI功能”到“AI企業級低代碼平台”的跨越。區別在於,前者是把AI作為附加功能嵌入,後者是把AI作為核心能力,貫穿於系統搭建、數據處理、流程優化的全鏈路。比如,我們推出的AI原生表單,能自動識別表單字段類型、生成校驗規則;AI流程引擎能根據業務場景自動推薦流程節點,甚至在流程執行過程中智能預警風險。

image.png

主持人:在轉型過程中,有沒有遇到過質疑?比如,有人會不會覺得“低代碼加AI只是噱頭”,或者“你們的核心壁壘在哪裏”?

杜總:肯定有,尤其是在2023年剛轉型的時候。當時最常見的質疑就是“低代碼和AI的結合到底有沒有實際價值”,還有人會問“你們和那些單純做AI工具的平台比,優勢在哪裏”。

其實,我們當時的判斷很明確:AI不能脱離業務場景空談,低代碼是AI落地企業業務的最佳載體。因為企業的核心需求是“解決業務問題”,而不是“擁有一個AI工具”。如果AI不能融入到企業的現有業務流程中,再好的技術也只是擺設。

至於壁壘,核心在於我們多年積累的企業級服務經驗和對業務場景的深度理解。傳統低代碼階段,我們服務了上千家不同行業的企業,從製造、零售到醫療、政務,清楚地知道不同行業的業務痛點和流程特點。比如製造企業的生產流程管理,需要打通設備數據、物料數據、人員數據;零售企業的客户管理,需要整合線上線下的消費數據。這些行業Know-How不是短時間能積累的。

而AI能力的融入,正是建立在這些Know-How的基礎上。我們不是簡單地把AI模型丟給用户,而是針對不同行業的場景,預製了對應的AI解決方案。比如給製造企業提供“AI生產質量檢測”模板,給零售企業提供“AI客户分層運營”模板,用户可以直接基於這些模板快速搭建系統,而不需要自己去調教模型、設計流程。這就是我們的核心壁壘——“行業Know-How+AI+低代碼”的深度融合。

image.png

主持人:轉型過程中,有沒有哪些關鍵的決策或動作,現在回頭看覺得是“做對了”的?

杜總:有兩個關鍵決策,現在看起到了決定性作用。

第一個是“堅持企業級定位,不做輕量化工具”。2023年的時候,很多同行都在做輕量化的AI低代碼工具,比如面向個人或小團隊的表單工具、協作工具,因為這類產品研發週期短、上線快。但我們堅持聚焦企業級場景,哪怕研發週期更長、投入更大。因為我們判斷,企業級市場的需求更剛性、更持久,而且一旦建立信任,客户粘性會很高。事實證明這個判斷是對的,現在我們的客户中,超過80%都是中大型企業,而且復購率很高。

第二個是“模型中立+生態開放”。我們沒有綁定某一個特定的AI模型,而是支持接入主流的開源模型和閉源模型,比如GPT、文心一言、通義千問,還有一些行業專用的開源模型。同時,我們還開放了API接口,支持用户接入自己的私有模型和第三方系統。

這個決策在當時也有爭議,有人覺得“綁定主流模型能降低研發成本”。但我們考慮到,企業客户的需求是多樣化的,有的客户關注數據安全,需要部署私有模型;有的客户需要特定行業的模型能力。如果我們綁定單一模型,就會限制客户的選擇。而“模型中立+生態開放”的策略,讓我們能適配不同客户的需求,也讓我們的平台更有生命力。比如有一家制造企業,之前已經部署了自己的工業AI模型,通過我們的開放接口,很順利地把這個模型融入到了織信的低代碼系統中,實現了生產流程的智能化改造。

image.png

主持人:現在織信的AI企業級低代碼平台,已經落地了哪些比較有代表性的客户案例?這些案例能體現出哪些價值?

杜總:有很多,比如一家大型裝備製造企業,用我們的平台搭建了“AI智能生產管理系統”。這個系統整合了生產設備數據、物料數據、人員數據,通過AI模型實時監控生產過程中的異常情況,比如設備故障預警、物料短缺預警,還能自動生成生產進度報告。上線後,他們的生產效率提升了30%,設備故障率降低了40%。

還有一家連鎖零售企業,用我們的平台搭建了“AI客户運營系統”。系統通過AI分析客户的消費記錄、瀏覽行為,自動給客户分層,生成個性化的營銷方案。比如對高價值客户推送專屬優惠,對流失風險高的客户推送召回活動。上線後,他們的客户復購率提升了25%,營銷費用降低了18%。

這些案例的核心價值,其實就是“降本增效+業務創新”。通過低代碼的快速搭建能力,降低了系統開發的成本和週期;通過AI的智能賦能,提升了業務流程的效率和決策的準確性。而且最重要的是,這些系統都是基於企業的實際業務場景搭建的,完全適配企業的需求,這是通用型軟件無法替代的。

image.png

主持人:站在現在這個節點,你怎麼看待AI企業級低代碼的未來?織信接下來的方向是什麼?

杜總:我認為AI企業級低代碼是未來企業數字化轉型的核心方向。現在很多企業都面臨“數字化轉型難”的問題,要麼是缺乏專業的技術團隊,要麼是現有系統無法適配業務變化,要麼是AI技術落地成本太高。而AI企業級低代碼平台,正好解決了這些問題——它降低了技術門檻,讓非技術人員也能參與系統搭建;它具備靈活性,能快速適配業務變化;它整合了AI能力,降低了AI落地的成本。

接下來,織信的核心方向是“深化行業解決方案+提升AI原生能力”。一方面,我們會針對更多細分行業,比如醫療、教育、政務,打造更精準的AI低代碼解決方案,把行業Know-How沉澱得更深厚;另一方面,我們會持續提升平台的AI原生能力,比如增強AI的流程自動化、智能決策、多模態交互等能力,讓系統更智能、更好用。

image.png

主持人:最後,很多創業者和產品人都很關注織信的發展,你有沒有什麼經驗可以分享?

杜總:核心就兩個字:專注。現在AI賽道很熱鬧,每天都有新的技術、新的概念出現,很容易讓人迷失方向。但我們從成立到現在,始終專注於“企業級低代碼”這個賽道,哪怕中間有很多誘惑,也沒有偏離方向。

另外,要堅持以客户需求為中心。產品的價值最終要由客户來驗證,所以我們一直保持和客户的緊密溝通,從客户的反饋中尋找產品迭代的方向。很多核心功能,比如AI流程預警、模型中立,都是來自客户的需求。

最後,要有耐心。企業級產品的成長週期很長,不可能一蹴而就。我們從傳統低代碼到AI企業級低代碼,用了整整三年時間,中間經歷了很多挑戰,但我們始終相信這個方向是對的,所以一直堅持下來。現在看來,所有的堅持都是值得的。

主持人:感謝你的分享。相信織信的創新曆程,能給很多在AI和低代碼賽道的創業者帶來啓發。

user avatar
0 位用戶收藏了這個故事!

發佈 評論

Some HTML is okay.