去年年底我回望過去三年的項(xiàng)目清單發(fā)現(xiàn)一個有意思的事——同樣是從零搭系統(tǒng)第一年我搭的是能用就行第二年我搭的是可擴(kuò)展第三年我開始琢磨這東西以后能不能復(fù)用給別的客戶。說實(shí)話這個轉(zhuǎn)變不是誰教我的。是被現(xiàn)實(shí)逼出來的。先說說我踩的一個坑。那會兒接手一個金融客戶的 AI 風(fēng)控系統(tǒng)部署客戶要求兩周內(nèi)上線。我按老路子來——研讀文檔、搭環(huán)境、寫腳本、調(diào)參數(shù)一套流程走下來系統(tǒng)跑起來了客戶也挺滿意。但問題出在第三周客戶說我們還有個新業(yè)務(wù)線能不能也接進(jìn)來我一看好家伙之前那套東西完全是按單一場景寫的要接入新業(yè)務(wù)線等于重寫一遍。你沒看錯就是重寫。那是我第一次意識到FDE 和架構(gòu)師之間差的不是代碼量是我怎么知道三個月后會發(fā)生什么的預(yù)判能力。技術(shù)深度從能跑到知道為什么能跑FDE 的日常是解決問題?？蛻粽f這個 API 調(diào)不通你上去查網(wǎng)絡(luò)、查配置、查權(quán)限搞定了。但架構(gòu)師會追問一句為什么這個 API 的設(shè)計(jì)會導(dǎo)致調(diào)不通是協(xié)議選型的問題還是接口設(shè)計(jì)的問題我見過很多 FDE 做了兩三年技術(shù)上非常熟練——Docker 玩得溜K8s 排障一把好手各種云服務(wù)信手拈來。但問他們?yōu)槭裁从眠@個中間件而不是那個回答往往是之前一直這么用的。有意思的是我后來跟一個真正從 FDE 轉(zhuǎn)成架構(gòu)師的前輩聊他說了一句話我記到現(xiàn)在你每天在客戶現(xiàn)場遇到的那些怪問題90% 都指向一個共同的東西——系統(tǒng)設(shè)計(jì)的妥協(xié)。每一次妥協(xié)都是你的學(xué)習(xí)機(jī)會。從那以后我每修一個 bug都會多花半小時搞清楚這個 bug 產(chǎn)生的根因是什么它在架構(gòu)層面反映了什么問題如果讓我重新設(shè)計(jì)我會怎么避免行業(yè)廣度你得懂客戶的業(yè)務(wù)比客戶自己還懂這話說得有點(diǎn)絕對但道理是真的。做 FDE 的頭兩年我服務(wù)的客戶集中在金融行業(yè)。后來轉(zhuǎn)到醫(yī)療、零售、制造每換一個行業(yè)我發(fā)現(xiàn)核心問題都差不多你想做架構(gòu)設(shè)計(jì)不懂業(yè)務(wù)邏輯設(shè)計(jì)出來的東西就是空中樓閣。舉個例子我在醫(yī)療行業(yè)做 AI 輔助診斷的部署時最開始以為只要把模型跑起來就行。結(jié)果客戶說你這個系統(tǒng)得通過 HIPAA 合規(guī)審查——我當(dāng)時連 HIPAA 是啥都不知道。后來啃了一個月合規(guī)文檔才明白人家那個慢不是技術(shù)不行是數(shù)據(jù)隱私保護(hù)的要求層層疊疊。這讓我意識到FDE 轉(zhuǎn)架構(gòu)師有一個繞不開的階段你得建立至少 2-3 個行業(yè)的深度認(rèn)知。不是知道這個行業(yè)有 AI 應(yīng)用那種淺層認(rèn)知而是這個行業(yè)的痛點(diǎn)在哪、數(shù)據(jù)長什么樣、合規(guī)紅線在哪、決策鏈條怎么走。說實(shí)話這事沒有捷徑。就是靠項(xiàng)目積累一個客戶一個客戶地啃。商業(yè)敏感度從把活干完到幫客戶賺錢這是最難的一個維度也是最能區(qū)分高級 FDE和架構(gòu)師的東西。我參與過一個零售客戶的庫存預(yù)測項(xiàng)目。最初的需求很明確做一個銷量預(yù)測模型接入現(xiàn)有系統(tǒng)。我按部就班地做完了上線一切正常。但三個月后客戶跟我說這個模型他們基本不用。為啥因?yàn)殇N售預(yù)測不準(zhǔn)確嗎不是。預(yù)測準(zhǔn)確率 87%技術(shù)上沒毛病。后來我花了一周時間蹲在客戶的倉庫里跟運(yùn)營人員聊才明白問題出在哪他們需要的不是準(zhǔn)確率 87% 的預(yù)測模型而是當(dāng)預(yù)測到某款商品要斷貨時能自動觸發(fā)補(bǔ)貨流程的系統(tǒng)。我交付的是一個預(yù)測工具他們想要的是一個決策工具。這就是商業(yè)敏感度的問題。架構(gòu)師和 FDE 最大的區(qū)別不是技術(shù)方案誰寫得好而是你能不能從客戶的業(yè)務(wù)目標(biāo)倒推出技術(shù)架構(gòu)而不是從技術(shù)能力出發(fā)去湊業(yè)務(wù)場景。誰適合走這條路誰不適合說實(shí)話不是每個 FDE 都要成為架構(gòu)師也不是每個 FDE 都適合。如果你是這樣的 FDE我建議你往架構(gòu)師方向走 - 你遇到 bug 的時候不想只修好還想搞清楚為什么設(shè)計(jì)成這樣 - 你做完一個項(xiàng)目腦子里會想如果換一種架構(gòu)會不會更好 - 你愿意花時間跟客戶聊業(yè)務(wù)而不是只跟技術(shù)對接人溝通 - 你對這東西怎么賺錢有興趣超過了這東西怎么實(shí)現(xiàn)但如果你更享受寫代碼本身喜歡鉆研某個技術(shù)領(lǐng)域不喜歡跟客戶喝酒吃飯聊需求——那也沒什么不對。高級 FDE 專家路線同樣走得通而且市場上非常稀缺。結(jié)尾FDE 到架構(gòu)師不是升級是轉(zhuǎn)行說實(shí)話從 FDE 到架構(gòu)師不是升職加薪那種線性成長。它更像是一種思維方式的切換——從怎么解決問題到怎么定義問題從這個系統(tǒng)怎么搭到這個系統(tǒng)為什么存在。我到現(xiàn)在也不敢說自己已經(jīng)是架構(gòu)師了。但有一點(diǎn)我很確定如果你做了兩年 FDE 之后開始覺得光寫代碼不夠了那說明你已經(jīng)在往那個方向走了。下一篇第 11 篇我會聊聊 FDE 的面試怎么準(zhǔn)備——系統(tǒng)設(shè)計(jì)、行為面試、案例面試一套完整的備戰(zhàn)思路。也是這個系列里我最想寫的一篇因?yàn)槲易约寒?dāng)年面試的時候踩的坑比誰都多。你覺得 FDE 到架構(gòu)師最大的門檻是什么是技術(shù)深度還是行業(yè)認(rèn)知還是別的什么歡迎在評論區(qū)聊聊。