不管是軟件產品的用戶、還是軟件公司的老板，或是寫代碼的碼農，都苦軟件開發這個行當久矣，很難見到一個行業屬于甲方、乙方、從業人員都在罵的行業，軟件開發行業就是。

甲方罵我給了那么多費用，為啥還滿足不了我的需求，到處都是bug，交付時間老是延誤。

乙方老板罵甲方，你就這點錢，還三天兩頭改需求，動不動就要我兩天搞完，我又不是超人；乙方老板也罵員工：我一天養你們那么多人，開著高薪，你們怎么連這么簡單的功能都做不好，給我加班！！！

碼農：這些需求你們都沒想好就要我開發，現在三天兩頭改怪我咯，天天催我上線，我連單元測試都沒時間，就這點工資還每個月都拖。

看吧，三輸局面，沒有哪個行業有那么多豆腐渣工程，沒有哪個行業利潤那么薄，沒有哪個行業員工那么辛苦，996最早哪來的？可不就是軟件開發行業傳開的嗎！

看過軟件工程領域圣經《人月神話》的人，都知道銀彈（銀彈就是可以讓強大的狼人被一擊斃命的武器），軟件工程借銀彈來比喻那種一招制敵，解決軟件工程中所有問題的終極武器。

可惜幾十年過去了，軟件開發領域的從業者們還是沒有找到銀彈。但最近幾年涌現的低代碼、零代碼，甚至AI大模型、自然語言編程讓人們不既讓大家又看到了一絲曙光。

可現實遠沒那么理想，低代碼被大家批成業務人員不會用，開發人員不愿用；零代碼更是被嘲諷成玩具，AI大模型和自然語言編程也是說著很美，但真到工作中又不頂事，很難大規模工程應用。

難道最終還是沒有辦法嗎？實際上確實不存在銀彈能一勞永逸的解決所有問題，但也許另一條“合縱連橫”的道路能把這些各有優勢的技術和產品集中貫通起來，成為真正的銀彈。

不知道我在說啥的，繼續往下看，我們現在把軟件開發按照開發模式劃分為四個層次，分別是：

1、傳統硬編碼的開發模式：這個無需多說大家都明白；

2、低代碼開發：大部分常見、簡單開發通過前端拖拉拽和系統配置開發完成，復雜和個性化的需求依然能夠采用代碼編寫的方式完成（代表：各種**云）；

3、零代碼拖拉拽式開發：不需要寫代碼，靠界面上組件的拖拉拽操作以及系統配置即可完成軟件開發（代表：釘釘宜搭、百度愛速搭）；

4、自然語言開發：語音也好、文檔也好、文字也好，只要是人類語言說出來的，就能作為需求輸入完成軟件開發（代表：微軟Copilot，中國電信星辰大模型·軟件工廠）。

現在大部分軟件公司還停留在第一個傳統模式開發的層次上，啥項目都是硬編碼，好點的積累了很多可復用的庫或功能模塊，再有個好的研發管理流程就已經算不錯的公司了。

另外，部分頭部軟件公司或有想法的公司在保留部分傳統硬編碼的開發方式下，大部分產品的開發和項目實施已經轉到低代碼開發模式中，比如像金蝶、用友、致遠、泛微以及一眾saas軟件企業，在長期的業務實踐中，他們總結積累了自己的研發基座，這些研發基座基本就是低代碼平臺，這些基座讓他們提高了開發效率，增強了研發的過程管理。

我拿我所在的小公司舉例，因為憂患意識比較強，所以也很早自研了自己的低代碼平臺用以項目和產品的研發，現在除了20%的歷史遺留項目外，公司80%的項目都已轉入低代碼開發模式，在此模式下已跑了兩年，也未出現很多人詬病的復雜項目無法開發的情況。

當然低代碼最大的客戶并不是軟件公司，而是信息化經費充足，組織規模較大的企業，但低代碼在這些大型組織內還是一種嘗試性的應用，并未大規模的采用后用以替代原有系統和開發模式。

零代碼在軟件公司中較為罕見，更多的是在一些非專業軟件公司，如系統集成商，個人工作室和一些甲方用戶里在小規模的使用。

而自然語言編程更是處于早期，微軟公布（不是發布）類似產品的demo也才過去幾個月的時間，所以現實中并未見到實踐案例。

那這些軟件開發平臺類產品到底什么才是最好的呢？

以我個人淺見，提供給用戶的軟件開發平臺最好的肯定是自然語言開發，簡單易學、受眾面廣，但是以現有的技術和模式來說，自然語言開發在可以預見的很長時間內，局限性還很強，搞不定很多用戶需求。

那怎么辦呢？我的看法就是“合縱連橫”，何謂“合縱連橫”，我們先來看看這幾類產品對應的用戶類型劃分。

1、傳統硬編碼：軟件公司開發工程師；

2、低代碼：懂技術的入門級開發人員，如：軟件公司的初級開發工程師、甲方客戶的開發人員；

3、零代碼：略懂技術的甲方IT人員或軟件公司里的產品經理；

4、自然語言開發：完全不懂開發技術的用戶，如甲方的市場、銷售、老板等人員。

從用戶面來說，從上向下兼容容易，能用硬編碼開發軟件的碼農自然也能用自然語言開發（雖說現在很多開發人員不愿意這么干）。但從下向上兼容就不可以了，一步都不可以，不懂技術的人甚至連零代碼用起來都別扭，更別說低代碼。

很多人會說那么多年下來，搞軟件開發都是碼農主力，為啥你非要去糾結普通業務人員來參與軟件開發，原因如下：

1、普通人員比軟件工程師人力成本低；

2、甲方的業務人員比乙方的軟件工程師懂業務；

3、產品經理比軟件工程師更懂需求和產品設計；

所以“合縱連橫”下有沒有可能出現一種新的軟件開發協作模式，把多種軟件開發平臺集成在一起，讓各類項目相關人員一起協作來完成軟件開發。比如：

先由甲方的業務人員用自然語言開發模式搭建出系統的基本功能框架，這個框架能夠表達出用戶的基本需求、數據組成、展現形式。甲方業務人員在軟件開發方面的能力極限也就到此為止，整個項目的完成度可達到20%-50%；

下一步，在此基礎上，由甲方的IT人員或乙方的產品經理進一步用零代碼把這個“毛胚房”開發成“簡裝房”，這一步的成品已經達到產品原型的地步，但相比傳統的產品原型，這個成品里一些沒有復雜業務邏輯的簡單功能已經能夠直接運行，產品經理的天花板也就到這里，整個項目的完成度可達到40%-70%；

第三步就可以由乙方的初級研發工程師使用低代碼平臺完成簡單代碼的編寫和復雜產品的配置，到這一步時，整個項目的完成度可達到60%-90%，進入“精裝房”階段；

到第四步只剩下少數技術難度較高的特殊需求，或是要對平臺進行底層代碼編寫才能滿足的需求，但也只需要乙方少量的高級工程師或系統架構師就能完成。

以上已經是一個較復雜項目“合縱連橫”各步的完成情況。但實際很多項目并未這么復雜，甚至有10%的項目在第一步就能完成，20%的項目在第二步就能完成，30%的項目第三步可以完成，只有40%的項目才會走到最后一步（以上數據依據本公司項目實踐所得，不代表行業整體情況）。

“合縱連橫”帶來的好處就是，甲方業務人員深度參與，業務需求在第一步就能得到充分的梳理和“釋放”，減輕了業務需求不明給后期帶來的眾多問題，同時甲方人員的深度參與，也會使其獲得成就感和參與感，進而對項目提供更多的支持和配合。

對乙方來說，因為甲方的加入，自身的工程量減輕，清晰的需求也避免了后期的反復，同時只需人力成本較低初級工程師就能完成絕大部分工作，也大大減輕了項目的實施成本。實施成本的降低也會反哺甲方的信息化建設，使其用較少的經費就能完成更多的項目建設。

這樣的項目模式在業內極少見，很多同行肯定也要說，你這個太復雜了，甲方爸爸不光出錢，還得陪你一起搞研發，哪個甲方爸爸愿意這么受累？

確實有這個邏輯存在，但就我的感受，我們服務的客戶，特別是大型客戶、企業客戶，越來越希望能夠深度參與到項目建設過程中，而不是僅僅當個項目經理等著驗收成果，現在很多項目甲方甚至派遣產品經理、開發人員隨同乙方的項目團隊一起開發，就是為了自己的項目過程不走偏，同時在項目結束后能夠從乙方手里全盤接手項目。

“合縱連橫”這種模式有其很大的優勢，但現在鮮有這方面的實施案例，造成這種情況并不是甲方不接受，而是乙方沒有集自然語言開發、零代碼、低代碼、原生代碼于一體的軟件開發平臺，自然無法實施。但從邏輯和理論以及我司這些年的實踐經驗看，確實不乏是一顆能夠解決軟件工程問題的“銀彈”。

這樣的軟件開發平臺集四種開發模式為一身，當高維度開發模式不能滿足項目需求時，可降維使用低一維度的模式繼續項目開發，同時這樣的軟件開發平臺要能集成研發過程管理系統就更加能使項目開發如虎添翼，方便甲乙雙方項目人員的工作協同進而提高研發效率和質量。

以上過程本人已部分實踐，歡迎同行探討。