中國ToB軟體公司想賺錢,先對AICoding祛魅

撰稿 | 數睿資料董事長兼 CEO 穆鴻
編輯 | InfoQ
4 月,Lovable推出“視覺化編輯”功能,允許使用者透過視覺化介面修改 AI 生成的介面;5 月起,Anysphere 逐步讓 Cursor 脫離 IDE,推出“後臺代理”,支援 Slack 整合,並可透過移動或 Web 瀏覽器傳送自然語言指令,實現功能開發或修 bug。
AI Coding 類產品,在演進的第一階段,已經完成了對專業開發者的提效;但在第二階段,服務於“公民開發者”時,情況發生了變化。
專案管理協會 (PMI) 將“公民開發者”定義為:無需編碼知識即可構建應用程式的人,全稱是:Citizen Development,簡稱 CD。
企業需要在不增加成本的情況下,加快交付速度,這裡最優的解決方案就是培養“公民開發者”,只需要 IT 提供支援,“公民開發者”就可緩解企業 IT 團隊的沉重壓力,在 GenAI 能力成熟後,“公民開發者”群體的興起幾乎已是既定事實。
“公民開發者”不懂程式碼,因此 AI Coding 產品正試圖讓自己變得更“親民”,儘量減少人與 AI 互動過程中的“程式碼含量”。
況且,企業開發往往是團隊作戰,很多問題並非技術能解決的,而是人的問題。例如,前端的業務需求變化和後端技術實現如何高效對齊;各個部門之間的資料、業務系統如何打通;資料安全如何保證;有限的專案預算和客戶預期如何平衡等等。任何一個環節出錯,都可能給企業造成大量損失。
然而,對於這些問題,現有的 AI Coding 產品仍有諸多“不穩定因素”。
DevOps 在 6 月 19 日釋出的報告中指出,儘管許多 AI 工具可以生成原始碼,但它們很少考慮應用程式的設計和架構,或者架構元件之間的關係;無法像人類開發者那樣,在生成程式碼時充分考慮可維護性、可重用性、可擴充套件性和效能;此外,AI 生成的程式碼通常不安全且包含錯誤。而早在 2022 年,斯坦福大學就有研究表明,相當一部分人工智慧生成的程式碼包含安全漏洞,這對企業來說更為致命。
企業級應用軟體開發,是否還有更好的選擇?
1 “Code + GenAI”  VS  “No Code + GenAI”
在企業級軟體交付中,乙方公司常遇到的頭號難題就是“定製”,特別是面向中大型 B 端客戶。
儘管標準化軟體足以解決很多問題,但超過 60% 的軟體專案仍以定製交付為主,這主要是因為客戶需求多樣且變化快。然而,傳統的高度依賴手寫程式碼的定製開發模式,加之頻繁的需求變更和激烈的市場競爭,導致許多專案成本失控,最終“入不敷出”。
長遠來看,更大的挑戰在於,軟體應用不僅僅侷限於傳統的 IT 場景。如今,數字化轉型已滲透到企業的各個崗位和角色,每個人都需要有個性化的應用來提升工作效率。
同時,生產環境的軟體還需與管理軟體實現高效的資料聯通和互動響應,這對軟體的架構設計、軟體本身的功能邊界以及軟體應用的實際效果都提出了極高的要求。
這些困境都使得整個國產軟體行業的發展步履維艱,亟需尋找更高效、更可控的開發模式來打破僵局。
那麼,企業為“公民開發者”提供的 IT 支援方案,應該是 Code + GenAI 嗎?無論是程式碼完成、程式設計任務還是專案的一些自動化,包括 Cursor、Github Copilot 等在內的很多工具已經可以大幅度提升程式碼編碼效率,甚至重塑開發者的工作流程。未來,“生成、確認和驗證”成為新常態,即“AI 生成 80% 的內容,人來完成 20% 的確認和驗證工作”。
可就是這 20% 的確認和驗證,實際上需要相當強的專業能力。我們先來看看市面上 AI Coding 類產品的定位和分類。

圖片部分引用自海外獨角獸公眾號《AI Coding 最全圖譜:Agent 將如何顛覆軟體》
如上圖左所示,針對面向的是專業開發者還是公民開發者,以及從軟體工程智慧化程度兩個維度,目前的市面上的產品,當然很多還不能稱為產品只能說是實驗品,大體可以分到四個維度。目前比較成熟的也比較熱的是左下象限,即面向專業開發者的 Copilot 型的 AI Coding 工具,Anysphere 的 Cursor、Codeium 的 Windsurf 以及微軟的 Github Copilot 是典型代表,它們可以完成包括程式碼完成、程式設計任務以及專案自動化等任務,大大提升了跟程式碼相關的很多工的效率和質量。但在企業級應用軟體定製交付中,如果我們仍然用編碼的形式去完成定製任務,那麼,下面這些問題仍然是巨大的挑戰:
  • 複雜業務邏輯的實現:大模型並不能完成諸如多系統整合、強合規性和類似物聯對接等私有場景的一些編碼任務,這在定製中是最常見的。
  • 資料安全和合規風險:敏感業務資料輸入公有的 AI 模型可能洩漏隱私,此前就有報道稱,使用者使用 Loveable 開發的 web 應用中,超過 10% 有安全問題。
  • 問題修改和缺陷修復:如果程式碼有問題要去修改問題,可能需要去理解生成的完整程式碼,或者要去關注到散落在各處的程式碼相關性。
  • 需求的歧義和幻覺:需求歧義會導致生成功能偏差,模型幻覺也會導致結果答非所問。
  • 企業的規則和最佳實踐:如果我們需要定製程式碼能夠遵循企業自己的一些規則,或者能夠習得歷史的最佳實踐,我們需要給大模型很多對齊的工作,大部分 AI Coding 工具甚至不支援這些功能。
在企業中,“可信性大於創造性,凡是不能被驗證的,就是不能被使用的”。從這個意義上來說,這類 AI Coding 工具仍然是軟體工程人員最好的工具,需要人和工具協同來提升效率,短期內很難完全取代編碼人員了,或者將軟體定製交付的效率提升數倍、乃至數十倍。
另外,在真實的企業場景中,企業應用軟體成功開發只是第一步,要讓這個軟體絲滑融入企業的業務流程,解決客戶問題,還需要大量瑣碎的需求溝通、程式碼檢視、程式碼修改、部署、運維、文件撰寫和維護等工作,這是個“軟體工程”問題,傳統意義上,是一個需要產品經理、架構師、開發人員、測試人員以及運維人員的一個混合團隊才能完成的事情。
因此,已經有業界頭部的 AI Coding 企業開始探索新嘗試。例如,Loveable 就在近期釋出了視覺化設計器。此外,業內也出現了類似 Devin 這種覆蓋軟體工程更多領域的、更自動化的工具。只是,這些工具大部分還處於實驗階段,還不能真正用於大型企業的商業化應用軟體交付中。
企業應用軟體的複雜性,決定了在當前階段,必須透過人機協同的方式,才能確保交付質量。
這也是為什麼,我認為,無程式碼平臺仍然是此類解決方案的必備軟體能力——無程式碼平臺的本質是 No Code + GenAI,比 Code + GenAI 更適配“公民開發者”的能力情況。
2 為什麼說無程式碼是當下最合適的形態?
我們這裡所說的“無程式碼”,並非傳統的無程式碼開發,而是與生成式 AI 融合形成的新產物。
過去十年間,產業界一直試圖解決企業定製軟體交付的問題。“低程式碼”和“無程式碼”開發被作為最重要的舉措之一被提出。
一時之間,無論是軟體廠商,還是企業的 IT 部門都號稱自己是低程式碼或無程式碼開發。但實踐當中,企業會發現這些產品大多隻能應對簡單需求,但對於業務邏輯比較複雜、資料分析要求較高以及對頁面美觀和互動效果要求較高的需求,就顯得力不從心了。
更不用說中大型企業對可靠性、效能、可測性以及安全性的要求更是很多平臺無法系統化解決的。這些功能特性的完成,需要大量的技術積累、研發投入和業務打磨。
從應用場景上看,如果只是作為某一個或者幾個垂直業務的延伸,低 / 無程式碼是可以在有限條件下,滿足定製擴充套件需求的,但作為數字化底座型,或者業務無關型的底層平臺,很少有產品能滿足要求。
我們可以通過幾個不同的維度,來量化感知這種產品要求。
首先,曾經有客戶問我,為了做 smardaten,數睿資料大概投入多少預算在研發上。我表示,結合融資和我們自己的投資情況,總投入大約四、五個億。他表示,那差不多。
做平臺與做應用軟體是完全不同的生產模式,你不能期望花費 500 萬建立一個平臺,產生 5 個億的價值,這個可能性不大。
第二,從軟體體量的角度看,smardaten 的程式碼行數超過 500 萬,全部由我們自己編寫,體量非常大。我們大約有 1500 個元件,包括各種介面、邏輯以及演算法等元件。此外還有 15 萬個功能項。在低 / 無程式碼領域,許多公司的元件數量,甚至比我們小一個數量級。
第三,在我看來,一家企業如果沒有超過 1000 個專案並且這其中還要有一定數量的較大規模的應用軟體的交付經驗,是無法積累足夠的能力和形成成熟的產品的。所以交付經驗,也是一種隱性的產品要求。
以上因素導致,國內企業級低 / 無程式碼賽道,“能上桌”的玩家其實很少,體感上不超過 10 家,常年與數睿資料共同出現的企業,也只有 5 家左右。
如果以上在產品維度的能力積累做得足夠好,那麼用無程式碼平臺來完成企業定製化軟體的交付,就變得非常合適了。
Gartner 預估,未來 5 年軟體應用的需求量是過去 40 年之和。在現有供需環境下,專業程式設計師難以獨自承擔如此龐大的開發任務,因此,視覺化的、無程式碼的方式應運而生,旨在讓“人人都能成為軟體工程師”。
而 AI 在這一過程中扮演著關鍵角色,它並非直接生成交付客戶使用的軟體應用,而是生成無程式碼平臺上的物料,尤其是 DSL(領域特定語言)。這些 DSL 再經過各種引擎的翻譯後,會變成實際的程式碼,從而大大簡化了軟體開發的流程,使得非專業程式設計師也能參與到應用構建中來。
過去大家對無程式碼有很多誤解,比如:無程式碼不支援寫程式碼,無程式碼不支援複雜業務邏輯,無程式碼只適合簡單應用開發、只能設計一些簡單的工作流……
但我們過去九年的實踐已經證明,大部分複雜的企業應用軟體都可以採用數睿資料的無程式碼平臺開發,這其中也包括了對效能要求極高或者業務邏輯特別複雜的應用的部分甚至全部。國外也已出現了諸如 bubble、unqork 等較大規模的企業級無程式碼開發平臺,甚至傳統的低程式碼平臺像微軟的 Power Platform 或者西門子的 Mendix 等也在強化它們的無程式碼開發能力。
這樣一個無程式碼平臺,應當在可靠性、效能以及安全性等企業級應用必備特性上有很好的基礎。在這個大邏輯之上,我們總結了七個具有一定行業普適意義的核心特徵,即“ADVANCE”。具體來看,可理解為:
  • A (AI First) 目標是讓 AI 生成 80% 的工作內容,人類主要負責驗證和確認,從而大幅提升效率。
  • D (Data Driven) 強調支援資料驅動的應用開發,覆蓋資料(Data)、資訊(Information)、知識(Knowledge)以及智慧(Wisdom)的全生命週期管理。
  • V (Visualized) 指提供豐富的視覺化介面,確保確認、修改和驗證過程直觀便捷。
  • A (Adaptive) 意味著平臺具備強大的適應性,採用積木式的組裝式開發模式,且積木元件本身支援靈活擴充套件。
  • N (Natural) 追求自然的互動體驗,讓使用者感覺平臺不僅好用,而且愛用。
  • C (Citizen Usable) 是核心主張——人人可用,目標是讓懂業務、具備基礎 IT 知識的普通使用者也能成功交付應用。
  • E (Economic) 聚焦經濟性,即大大降低平臺自身成本以及使用該平臺交付專案的成本。
不過,面對日益複雜的企業軟體定製需求,“No Code+ GenAI”的開發正規化還有待完善,仍要面臨如下挑戰:
  • 互動設計升級:構建精準提示詞體系、標準化工具呼叫介面及閉環反饋機制,強化人機協作效率;
  • 上下文增強:融合平臺原生資料、垂直領域知識庫與長時記憶能力,提升需求理解精度;
  • 泛化能力平衡:在 DSL 可控性與開放問題解決間取捨,透過多 Agent 協作拆解任務,複用大模型在資料庫設計、工作流編排等場景的泛化知識;
  • 成本效益最佳化:根據企業級應用場景,在模型引數規模、推理成本與輸出質量間動態調優;
  • 擴充套件性保障:預留專業程式碼開發介面,支援透過生成式編碼實現外掛開發、演算法整合等定製化需求。
儘管目前仍面臨一些挑戰,但我們仍然認為,短期內,具備強大 GenAI 能力的無程式碼開發平臺幾乎是客戶解決企業應用軟體定製問題的最優解。
從技術和產品能力來看,除非原始碼型的 AI Coding 的產品形態出現重大變化,進化成了全新物種,否則它們和無程式碼平臺不存在相互取代、吞噬的問題。無程式碼平臺以自然語言生成應用為核心,將大語言模型作為作業系統,加速應用開發全流程;同時透過結構化設計規避模型幻覺,確保企業級應用的可信度要求。針對公民開發者,平臺提供視覺化操作介面,支援便捷修改與微調。伴隨知識庫積累(涵蓋行業模型、開發流程、應用模板等),平臺自動化水平將持續提升,未來也有望孵化更智慧的軟體工程 Agent,推動行業革新。
從市場增長的潛力來看,過去無程式碼產品正在面臨新的增長機會。
據 Gartner 預測,到 2028 年,60% 的開發團隊將採用低程式碼平臺作為核心開發平臺,而到 2029 年,80% 的企業將依賴低程式碼開發任務關鍵型應用,市場規模預計突破 460 億美元。在這之中,海外需求更旺盛,市場規模佔比 97%,國內佔比約 3% 左右,大概百億人民幣左右。
國內外市場之所以有如此巨大的差距,原因是複合的,與需求情況、人力成本、專案平均毛利、技術積累都有關係。但國外市場正在對國內市場形成反哺——企業可以從全球化的市場中,得到更多的商業機會,進而加速完成技術和產品積累,以更優質的產品,撬動國內市場更多的需求。
以數睿資料為例,公司在新加坡的子公司也已經運作起來了,年營收突破千萬,還在穩步增長。
綜合來看,如果無程式碼平臺,在技術、產品上有生命力、想象力,在全球市場又有足夠的利潤空間,那麼我們沒有理由不擁抱它。相反,為了概念新穎而盲目追求“AI is All”,不根據客戶的實際情況來制定解決方案,或許才是對 GenAI 浪潮最大的誤解和錯付。
今日好文推薦
Cursor終結者?Grok 4正式登頂!馬斯克揚言程式設計碾壓,20萬N卡年賺47億美金!
16 年老程式設計師用 Claude Code 搞副業:我只手敲了 1000 行,剩下 95% 程式碼靠自動生成
180 天狠賺 5.7 億,8 人團隊全員財富自由,最大功臣是 Claude 和 Gemini
Cursor 搭 MCP,一句話就能讓資料庫裸奔!?不是程式碼bug,是MCP 天生架構設計缺陷


相關文章