不知為啥，我有那種有點無法自控的愛管閒事兒的臭毛病，因而在有的微信羣中把自己羣暱稱改成了「熱心網友」。
最近有些同行在找工作，刷八股文，問某種面試題該怎麼回答，諸如此類。
看到他們那樣，我心裏就急得上躥下跳的——明明前方是火坑，咋還接二連三看似心甘情願地往裏跳呢？？？
在當下這個時間點，我的同行絕大部分是以 HTML、CSS、JavaScript 等為核心的「Web 前端」，他們之中絕大部分是業務前端，這些人中絕大部分做中後台類應用。
中後台的「勢」
中後台類應用有兩個重要特點——
第一，業務流程和數據安全遠遠優先於產品體驗，與所謂的「產品力」、花裏胡哨的視覺設計等相比，讓業務流程順利地走下去，使數據保持完整要重要得多，其他的只是錦上添花。
尤其是在面向製造業等實體行業時，就算沒有數字產品，業務也照樣跑，只不過是效率低了些；數字產品只為提效而存在，無權改變既有業務規則，不能本末倒置。
所以説，做中後台類應用的公司或部門不需要 to C 的那種「產品經理」，需要的是能夠梳理明白業務方（主要是行業或領域專家）需求且準確傳達的「需求經理」。
第二，中後台類應用前端部分高度模式化，又由於是業務與數據優先，在整個系統層面可以更好地建模，並抽象出以模型為源頭嚮應用成品自動推導的構建管線。
也就是説，只要從業務中提取出了模型，基於某種機制在描述出各種關係後，就能夠直接看到應用可操作的最終效果。
描述關係的方式可以是：
- XML、JSON、JS 純對象等類編程體驗的 DSL；
- 在頁面中拖拉拽的可視化操作；
- 讓 AI 理解需求文檔後轉譯。
其中，最後一種便是我所提倡並追求的「知識驅動的、智能的產研一體化平台」所具備的能力。
至於那個「機制」是什麼，目前我看好的有兩個：
- 由 Canonical 基於自創的可逆計算理論所實現的 Nop 平台；
- 師兄正在研發中的 BFF 框架。
但他們都缺少純前端部分的支持，我的「反混沌前端工程」會把這個空位補上。
工程師的「命」
在 ChatGPT 出現在大眾視野之前，我們就認為在中後台類應用研發流程中設計師與前端工程師會被幹掉，由「需求經理」與後端工程師協作就能勝任。
而 ChatGPT 及類似產品的出現，讓大部分後端 CRUD 工程師被幹掉也成為了可能，「需求經理」僅需編寫詳實的需求文檔即可。
既然業務研發工程師會被知識驅動的、智能的產研一體化平台所替代是「勢」，那我們何不去加快這個進程？！
在我們看來從事此類研發的崗位是沒有未來的，但有些人並不如此覺得——或以現狀的眼光去思考，或認為人類比 AI 強。
然而事實是——科技的迭代與增長速度從來不是線性的，其發展所帶來的影響之一就是要求人們革新自己的知識與技能；人類最愚蠢的地方就是自以為是。
結語
雖然本文中主要聊的是中後台類應用的業務研發工程師會「死傷慘重」，不代表 to C 的就「毫髮無損」，只不過比例不會那麼大。
與我所秉持的設想相比，師兄的一個説法更誇張了點——沒準兒哪天 AI 大力出奇跡，直接生出由源碼構成的應用，而不是那種經過層層抽象的。
這種應用是個黑盒，從軟件工程角度來看是不可維護的，任何最佳實踐、優化手段都將失效——既沒意義，又沒必要——就像有了車之後，關於騎馬的知識與技能都沒用了。
很多時候我覺得自己像是那種人——告訴別人幾天後大家會迎來災難，要趕緊逃亡，然而一個個卻覺得我是在胡説八道，看我笑話。
所以，這是我最後一次的勸誡，希望看到且看懂的人能有所行動，別再往火坑裏跳。
本文其他閲讀地址：個人網站｜微信公眾號
