1. 機器人嵌入式崗位的定價邏輯正在被重寫這兩年跟做機器人方向的朋友聊天話題繞來繞去總會落到一個點上同樣是寫嵌入式代碼為什么有人月薪還在原地踏步有人卻已經(jīng)被搶到需要排隊約面試我一開始也以為是行業(yè)炒作直到自己幫幾個團隊做過技術(shù)招聘的參謀翻了幾百份簡歷、面了幾十個人之后才慢慢看清背后的邏輯——機器人嵌入式崗位的定價體系正在從會用什么芯片轉(zhuǎn)向能解決什么系統(tǒng)級問題。這個轉(zhuǎn)變不是突然發(fā)生的而是被整個機器人產(chǎn)業(yè)的落地節(jié)奏推著走的。早些年做機器人很多項目停留在Demo階段一塊STM32跑個電機控制、讀幾個傳感器、串口打印點數(shù)據(jù)就能交差。那時候企業(yè)招人看的是你會不會配寄存器、能不能調(diào)通PWM、懂不懂I2C和SPI的時序。這些能力當然還重要但它們已經(jīng)從稀缺技能變成了入場券。當一塊板子上的活兒被標準化之后它的價格自然會被壓下來。真正開始變貴的是那些能把STM32、RTOS、Linux三樣東西串起來的人。注意不是三樣都會一點而是理解它們各自在機器人系統(tǒng)里扮演什么角色、邊界在哪里、怎么協(xié)作。一個典型的機器人系統(tǒng)底層是MCU做實時控制中間是RTOS做任務(wù)調(diào)度和通信管理上層是Linux跑感知、規(guī)劃、決策。這三層之間的數(shù)據(jù)怎么流、時序怎么保證、故障怎么隔離才是決定一個機器人能不能真正跑起來的關(guān)鍵。而這些問題的解決能力恰恰是當前市場上最缺的。我見過太多候選人簡歷上寫著精通STM32熟悉FreeRTOS了解Linux但一問到你的電機控制任務(wù)和上層規(guī)劃模塊之間怎么同步如果Linux那邊卡了底層控制會不會受影響RTOS里任務(wù)優(yōu)先級怎么分配才能保證控制周期不抖動就開始含糊其辭。這不是他們不聰明而是過去的學習路徑讓他們把這三樣東西當成了三個獨立的技能點而沒有建立起系統(tǒng)級的認知。所以這篇文章我想把這件事掰開揉碎了講清楚哪些傳統(tǒng)能力正在變貴為什么變貴以及如果你現(xiàn)在還在做嵌入式應該往哪個方向補。不管你是剛?cè)胄械男率诌€是做了幾年想往上走的老兵希望這些從實際項目和招聘現(xiàn)場總結(jié)出來的東西能幫你少走點彎路。2. 拆解機器人嵌入式系統(tǒng)的三層架構(gòu)與能力定價2.1 為什么三層架構(gòu)是理解崗位定價的鑰匙要搞清楚哪些能力變貴得先理解機器人嵌入式系統(tǒng)的典型架構(gòu)。我把它簡化成三層雖然實際項目可能更復雜但這個模型足夠說明問題。最底層是實時控制層核心是MCU比如STM32系列。這一層負責電機驅(qū)動、傳感器采樣、執(zhí)行器控制特點是硬實時——控制周期可能是1ms甚至更短錯過一個周期就可能導致機器人抖動甚至失控。這一層對寄存器和外設(shè)的理解要求極高因為你要在微秒級別上摳時序。中間層是任務(wù)調(diào)度與通信層通常跑RTOS比如FreeRTOS、RT-Thread、Zephyr。這一層把底層的實時任務(wù)管理起來同時負責和上層通信。它的核心挑戰(zhàn)是優(yōu)先級管理和資源分配——哪個任務(wù)先跑、哪個可以等、共享資源怎么保護、中斷和任務(wù)之間怎么交互。最上層是感知決策層一般跑Linux負責圖像處理、路徑規(guī)劃、SLAM、AI推理這些計算密集型任務(wù)。這一層的特點是軟實時偶爾卡一下可能不影響整體但它的輸出要能可靠地傳給下面兩層。這三層之間的邊界和接口就是定價的分水嶺。只會寫底層驅(qū)動的人市場上供給充足只會調(diào)Linux應用的人也大有人在但能設(shè)計三層之間協(xié)作機制、能在系統(tǒng)出問題時快速定位是哪一層的鍋的人就稀缺了。2.2 STM32能力的分化從會用到用得好STM32作為嵌入式入門的標配幾乎每個做機器人的人都接觸過。但同樣是STM32能力層次差別巨大?；A(chǔ)層是能用CubeMX生成代碼、能調(diào)通外設(shè)、能寫簡單的控制邏輯。這個層次的人現(xiàn)在確實過剩了。我面過不少應屆生簡歷上寫做過平衡車、做過機械臂一問細節(jié)發(fā)現(xiàn)是跟著教程一步步來的換個芯片就不會了時序出問題也不知道怎么查。進階層是理解STM32的時鐘樹、中斷優(yōu)先級、DMA機制能根據(jù)控制需求反推外設(shè)配置。比如做電機控制你要知道為什么用高級定時器而不是通用定時器為什么PWM死區(qū)時間要精確計算為什么ADC采樣要和PWM中心對齊。這些不是會用的問題而是用得好的問題。高階層是把STM32放在整個機器人系統(tǒng)里考慮。比如你的控制周期是1ms但上層通過串口發(fā)來的指令可能延遲幾毫秒你怎么保證控制的連續(xù)性如果STM32和Linux之間用CAN通信CAN總線負載高了怎么辦這些問題已經(jīng)超出了單芯片的范疇但恰恰是機器人項目里天天遇到的。我個人的判斷是STM32的基礎(chǔ)操作能力正在貶值但把STM32用出確定性的能力在升值。什么叫確定性就是不管外面發(fā)生什么你的控制周期不抖、你的響應時間可預測、你的故障處理有兜底。這種能力在招聘市場上越來越值錢。2.3 RTOS的隱性門檻任務(wù)設(shè)計比API調(diào)用難得多RTOS這塊是很多人容易低估的地方。因為FreeRTOS的API就那么幾個xTaskCreate、vTaskDelay、xQueueSend學起來很快。但真正難的是任務(wù)怎么劃分、優(yōu)先級怎么定、棧怎么分配、任務(wù)間怎么同步。我見過一個典型的坑某團隊做移動機器人底層控制任務(wù)優(yōu)先級設(shè)得最高通信任務(wù)次之日志任務(wù)最低?？雌饋砗侠淼珜嶋H跑起來發(fā)現(xiàn)當通信任務(wù)在往隊列里塞數(shù)據(jù)時如果隊列滿了它會阻塞而阻塞又影響了控制任務(wù)的響應。問題出在哪出在隊列長度和阻塞策略沒有根據(jù)實際數(shù)據(jù)速率來設(shè)計。RTOS的能力定價體現(xiàn)在幾個方面。第一是實時性分析——你能不能算出最壞情況下的任務(wù)響應時間第二是資源管理——棧溢出、內(nèi)存碎片、優(yōu)先級反轉(zhuǎn)這些問題你能不能提前預防第三是調(diào)試能力——系統(tǒng)跑飛了你怎么用Trace工具或者日志定位問題這些能力光看文檔是學不會的必須在實際項目里踩過坑、調(diào)過參數(shù)、分析過波形才能慢慢積累。而市場上能獨立設(shè)計RTOS任務(wù)架構(gòu)的人薪資普遍比只會調(diào)API的人高出一截。2.4 Linux在機器人里的角色不是會裝系統(tǒng)就行Linux這塊誤解最多。很多人以為機器人里的Linux就是裝個Ubuntu、寫個Python腳本這完全低估了它的復雜度。機器人里的Linux核心挑戰(zhàn)是實時性補丁、驅(qū)動開發(fā)、進程間通信、資源隔離。比如你的感知模塊跑在Linux上需要把結(jié)果發(fā)給底層MCU這個通信鏈路怎么保證低延遲如果感知模塊突然占用大量CPU會不會影響通信進程這些問題需要你理解Linux的調(diào)度策略、內(nèi)存管理、網(wǎng)絡(luò)協(xié)議棧。更進階的是PREEMPT_RT補丁的使用。標準Linux內(nèi)核的實時性不夠機器人里經(jīng)常需要打?qū)崟r補丁把內(nèi)核變成可搶占的。這涉及到內(nèi)核配置、中斷線程化、優(yōu)先級繼承等概念。能玩轉(zhuǎn)這些的人在機器人公司里絕對是香餑餑。還有一個容易被忽視的點是Linux和RTOS的協(xié)作。有些機器人架構(gòu)是LinuxRTOS雙系統(tǒng)Linux跑在應用處理器上RTOS跑在MCU上兩者通過共享內(nèi)存或高速總線通信。這種架構(gòu)下你需要設(shè)計跨系統(tǒng)的通信協(xié)議、處理時鐘同步、保證數(shù)據(jù)一致性。這種能力已經(jīng)不是單純的嵌入式或Linux能概括的了而是系統(tǒng)架構(gòu)能力。2.5 三層能力的定價對比誰在貶值誰在升值為了更直觀地說明問題我整理了一個能力定價的對比表。這個表是基于我觀察到的招聘市場情況總結(jié)的不一定精確但趨勢是明確的。能力層次具體技能市場供給定價趨勢原因分析STM32基礎(chǔ)外設(shè)配置、簡單控制充足貶值教程多、門檻低、標準化程度高STM32進階時序優(yōu)化、DMA、中斷設(shè)計中等穩(wěn)定需要項目經(jīng)驗但可替代性尚可RTOS基礎(chǔ)API調(diào)用、任務(wù)創(chuàng)建充足貶值學習曲線平緩文檔完善RTOS進階任務(wù)架構(gòu)、實時性分析稀缺升值需要系統(tǒng)思維和踩坑經(jīng)驗Linux基礎(chǔ)系統(tǒng)安裝、腳本編寫充足貶值通用技能非機器人專屬Linux進階驅(qū)動開發(fā)、實時補丁稀缺升值門檻高與硬件結(jié)合緊密跨層協(xié)作三層通信、故障隔離極度稀缺大幅升值需要全局視野培養(yǎng)周期長從表里能看出來越靠近系統(tǒng)集成和跨層協(xié)作的能力越值錢。這不是說底層技能不重要而是說底層技能已經(jīng)成了基礎(chǔ)而系統(tǒng)級能力才是差異化競爭的關(guān)鍵。3. 從實際項目看能力如何轉(zhuǎn)化為定價3.1 一個移動機器人項目的架構(gòu)演進我參與過一個移動機器人項目從原型到量產(chǎn)架構(gòu)改了三次每次改動都對應著對嵌入式能力要求的提升。第一版是純STM32方案。一塊STM32F4跑所有邏輯電機控制、傳感器讀取、簡單的避障決策。代碼是一個大循環(huán)用狀態(tài)機管理。這個版本能跑但問題很明顯加一個傳感器就要改主循環(huán)控制周期不穩(wěn)定調(diào)試靠串口打印。這個階段團隊需要的是會寫STM32代碼的人。第二版引入了FreeRTOS。把電機控制、傳感器采集、通信分成獨立任務(wù)用隊列傳遞數(shù)據(jù)?？刂浦芷诜€(wěn)定了但新的問題出現(xiàn)了任務(wù)優(yōu)先級怎么定隊列深度設(shè)多少通信任務(wù)阻塞了怎么辦這個階段團隊需要的是懂RTOS任務(wù)設(shè)計的人。我們當時招了一個有RTOS經(jīng)驗的工程師薪資比第一版的嵌入式工程師高了40%左右。第三版變成了STM32Linux雙系統(tǒng)。Linux跑視覺和路徑規(guī)劃STM32跑底層控制兩者通過串口和共享內(nèi)存通信。這個階段問題變成了Linux和STM32之間怎么同步如果Linux崩潰了STM32能不能安全停車通信協(xié)議怎么設(shè)計才能既高效又可靠這個階段團隊需要的是能設(shè)計跨系統(tǒng)架構(gòu)的人。這種人我們找了三個月才招到薪資是普通嵌入式工程師的兩倍多。這個演進過程很典型。機器人項目越往量產(chǎn)走對系統(tǒng)級能力的要求越高對應的薪資也越高。3.2 招聘現(xiàn)場的真實反饋面試官在找什么我?guī)蛶讉€團隊做過技術(shù)面試官發(fā)現(xiàn)一個規(guī)律面試官的問題往往圍繞著邊界和故障展開。比如問STM32不會只問你怎么配置PWM而是問如果你的PWM輸出突然丟了你怎么排查。問RTOS不會只問你怎么創(chuàng)建任務(wù)而是問如果兩個任務(wù)共享一個資源你怎么保證不出問題。問Linux不會只問你怎么寫驅(qū)動而是問如果驅(qū)動導致系統(tǒng)卡死你怎么定位。這些問題考的不是知識點而是系統(tǒng)思維和故障處理能力。一個候選人如果能清晰地回答我會先看哪個日志、再用什么工具、然后怎么隔離問題即使他的具體技術(shù)細節(jié)不是最完美的面試官也會覺得他靠譜。反過來那些只會背API、只會說我做過XX項目但說不出細節(jié)的人很容易在追問下露餡。我印象很深的是一個候選人簡歷上寫精通FreeRTOS我問他你的任務(wù)棧大小怎么定的他說用默認的。再問如果棧溢出了怎么辦他說沒遇到過。這種回答基本就告別高薪了。3.3 薪資數(shù)據(jù)的背后哪些能力溢價最高雖然我不能給出具體的薪資數(shù)字但從招聘市場的反饋來看溢價最高的能力集中在三個方向。第一是實時性保證。能設(shè)計出確定性響應的系統(tǒng)能分析最壞情況執(zhí)行時間能用工具驗證實時性。這種能力在工業(yè)機器人和自動駕駛領(lǐng)域特別值錢。第二是跨系統(tǒng)通信。能設(shè)計Linux和RTOS之間的高效通信機制能處理時鐘同步、數(shù)據(jù)一致性、故障恢復。這種能力在協(xié)作機器人和移動機器人領(lǐng)域需求很大。第三是系統(tǒng)調(diào)試與優(yōu)化。能在系統(tǒng)出問題時快速定位是硬件、RTOS還是Linux的鍋能用Trace、邏輯分析儀、內(nèi)核日志等工具組合排查。這種能力在任何機器人團隊都是剛需。這三樣能力有一個共同點都不是單一技術(shù)棧能覆蓋的都需要跨層理解。這也是為什么我說機器人嵌入式崗位的定價邏輯正在從技能點轉(zhuǎn)向系統(tǒng)能力。4. 如果你想往上走應該怎么補能力4.1 從會用到懂原理STM32的進階路徑如果你現(xiàn)在還在STM32的基礎(chǔ)階段第一步不是急著學Linux而是把STM32吃透。但吃透不是把參考手冊背下來而是理解為什么這么設(shè)計。比如學定時器不要只學怎么配置PWM要理解計數(shù)器的時鐘源、預分頻器的作用、自動重載寄存器的更新時機。學中斷不要只學怎么開中斷要理解NVIC的優(yōu)先級分組、中斷嵌套的規(guī)則、中斷和任務(wù)之間的交互。學DMA不要只學怎么配置要理解DMA和CPU的總線仲裁、傳輸完成中斷的時機、雙緩沖模式的應用。這些原理在機器人項目里都會用到。比如你做電機控制PWM的頻率和死區(qū)時間直接影響電機噪聲和效率你做傳感器采樣ADC的觸發(fā)時機和DMA的傳輸方式直接影響數(shù)據(jù)質(zhì)量。只有理解了原理才能在出問題時知道往哪個方向查。我的建議是找一個實際的機器人小項目比如用STM32做一個云臺控制或者小車驅(qū)動然后刻意去優(yōu)化它的實時性和穩(wěn)定性。不要滿足于能跑要追求跑得穩(wěn)、跑得快、出問題能查。4.2 RTOS的實戰(zhàn)修煉從能跑到能扛RTOS這塊光看文檔是不夠的必須動手做項目。但做什么項目很關(guān)鍵。我的建議是做一個有多個任務(wù)、有資源共享、有通信需求的系統(tǒng)。比如你可以設(shè)計一個數(shù)據(jù)采集系統(tǒng)一個任務(wù)負責ADC采樣一個任務(wù)負責數(shù)據(jù)處理一個任務(wù)負責串口輸出。這三個任務(wù)之間用隊列傳遞數(shù)據(jù)用信號量保護共享資源。然后你可以故意制造一些問題把隊列長度設(shè)小看數(shù)據(jù)丟了怎么查把任務(wù)優(yōu)先級設(shè)錯看系統(tǒng)怎么反應把棧大小設(shè)小看溢出怎么表現(xiàn)。這種故意制造問題的練習比順順利利跑通一個Demo有價值得多。因為在實際項目中問題總是會出現(xiàn)的而你的價值就體現(xiàn)在能不能快速定位和解決。還有一個進階練習是用Trace工具分析任務(wù)調(diào)度。FreeRTOS有Trace功能可以記錄任務(wù)的切換、隊列的操作、中斷的觸發(fā)。你可以用這個功能看看你的系統(tǒng)在運行時到底發(fā)生了什么。很多時候你以為的任務(wù)執(zhí)行順序和實際的根本不一樣。4.3 Linux的切入點從驅(qū)動到系統(tǒng)集成Linux這塊很多人覺得門檻高不知道從哪入手。我的建議是從驅(qū)動開發(fā)切入然后往系統(tǒng)集成走。驅(qū)動開發(fā)的好處是它和硬件結(jié)合緊密和你已有的嵌入式知識有銜接。你可以從寫一個簡單的字符設(shè)備驅(qū)動開始比如控制一個GPIO或者讀取一個I2C傳感器。然后慢慢深入到中斷處理、DMA、內(nèi)存映射這些概念。有了驅(qū)動基礎(chǔ)之后你可以開始理解Linux的進程間通信機制比如共享內(nèi)存、消息隊列、Socket。這些在機器人系統(tǒng)里經(jīng)常用到因為感知模塊和控制模塊往往在不同的進程里。再往上就是系統(tǒng)集成。你需要理解Linux的啟動流程、內(nèi)核配置、實時補丁、資源隔離。這些知識在LinuxRTOS雙系統(tǒng)架構(gòu)里特別重要。因為你要設(shè)計兩個系統(tǒng)之間的通信協(xié)議、處理時鐘同步、保證故障隔離。我個人的經(jīng)驗是Linux的學習曲線比STM32和RTOS都要陡但一旦跨過去你的能力邊界會大大擴展。而且Linux的知識是通用的不僅在機器人領(lǐng)域有用在自動駕駛、工業(yè)控制、邊緣計算等領(lǐng)域都用得上。4.4 跨層協(xié)作能力最難也最值錢跨層協(xié)作能力是三層能力里最難培養(yǎng)的因為它需要全局視野和實際項目經(jīng)驗。什么叫跨層協(xié)作舉個例子你的Linux視覺模塊檢測到一個障礙物需要通知STM32緊急停車。這個過程中你要考慮視覺模塊的檢測延遲是多少通信鏈路的延遲是多少STM32收到指令后多久能停車如果通信中斷了怎么辦如果STM32正在執(zhí)行其他任務(wù)怎么辦這些問題沒有標準答案需要你根據(jù)具體場景來設(shè)計。但有一些通用的原則通信要有確認機制、關(guān)鍵指令要有優(yōu)先級、故障要有兜底策略。培養(yǎng)這種能力最好的方式是參與一個完整的機器人項目從需求分析到架構(gòu)設(shè)計到調(diào)試優(yōu)化全程跟下來。如果工作中沒有這樣的機會可以自己做一個開源項目或者參與一些機器人競賽。關(guān)鍵是要有系統(tǒng)的意識不要只盯著自己那一小塊。5. 常見問題與避坑指南5.1 學習路徑上的常見誤區(qū)誤區(qū)一先學Linux再補STM32和RTOS。這是很多人容易犯的錯誤覺得Linux高級先學高級的。但實際上STM32和RTOS是基礎(chǔ)沒有這個基礎(chǔ)你學Linux也只能學個皮毛。因為機器人里的Linux是要和底層硬件打交道的你不懂底層怎么設(shè)計接口誤區(qū)二追求全棧但每樣都不精。嵌入式領(lǐng)域確實需要廣度但廣度是建立在深度之上的。你至少要在某一個方向上做到能獨立解決問題然后再擴展。否則面試的時候面試官隨便問深一點你就露餡了。誤區(qū)三只看教程不動手做項目。嵌入式是實踐性極強的領(lǐng)域看十遍教程不如自己做一個項目。而且做項目要選有挑戰(zhàn)性的不要做那種跟著步驟走就能完成的。要選那種需要你自己設(shè)計、自己調(diào)試、自己優(yōu)化的。5.2 面試中的高頻問題與應對思路我整理了一些面試中經(jīng)常被問到的問題以及回答的思路。注意這些問題沒有標準答案關(guān)鍵是展示你的思考過程。問題類型典型問題回答思路實時性你怎么保證控制周期的穩(wěn)定性從時鐘源、中斷優(yōu)先級、任務(wù)調(diào)度、代碼執(zhí)行時間幾個方面分析任務(wù)設(shè)計你的RTOS任務(wù)怎么劃分從功能獨立性、實時性要求、數(shù)據(jù)依賴關(guān)系幾個維度說明通信Linux和STM32之間怎么通信對比串口、CAN、共享內(nèi)存等方案說明選擇理由和注意事項故障處理系統(tǒng)跑飛了你怎么查從日志、Trace、邏輯分析儀、代碼審查幾個手段組合排查優(yōu)化你怎么優(yōu)化系統(tǒng)性能從瓶頸分析、優(yōu)先級調(diào)整、代碼優(yōu)化、硬件加速幾個層面說明回答這些問題的時候不要只給結(jié)論要給推理過程。面試官想看的不是你知道什么而是你怎么思考。5.3 職業(yè)發(fā)展中的關(guān)鍵選擇如果你現(xiàn)在在做嵌入式面臨職業(yè)選擇我有幾個建議。第一盡量參與完整的項目。從需求到設(shè)計到調(diào)試到量產(chǎn)全程跟下來。這種經(jīng)歷比在某個環(huán)節(jié)做很久更有價值。第二不要頻繁換技術(shù)棧。嵌入式領(lǐng)域STM32、RTOS、Linux這三樣夠你深耕很多年了。不要今天學這個明天學那個最后每樣都只會一點。第三關(guān)注行業(yè)趨勢但不要盲目追熱點。機器人、自動駕駛、邊緣計算這些方向確實火但火不代表適合你。你要看自己的興趣和優(yōu)勢在哪里然后在這個方向上深耕。第四建立自己的知識體系。不要零散地學要把知識串起來。比如你學STM32的中斷就要想到RTOS的任務(wù)切換想到Linux的中斷處理想到整個系統(tǒng)的實時性。這種系統(tǒng)化的思維才是你區(qū)別于別人的地方。5.4 實操中的避坑技巧最后分享幾個我在實際項目中總結(jié)的避坑技巧。技巧一棧大小不要用默認值。RTOS任務(wù)的棧大小一定要根據(jù)實際使用情況來定?？梢杂胾xTaskGetStackHighWaterMark來查看棧的使用峰值然后留出足夠的余量。技巧二通信要有超時和重試。不管是串口、CAN還是網(wǎng)絡(luò)通信都要設(shè)計超時機制和重試策略。否則一旦通信中斷系統(tǒng)就可能卡死。技巧三關(guān)鍵操作要有日志。不要等到出問題了才加日志。在關(guān)鍵路徑上提前埋好日志點出問題時才能快速定位。技巧四用版本控制管理代碼。嵌入式項目經(jīng)常需要回溯比如上個版本還能跑這個版本不行了。有版本控制你才能快速對比和回滾。技巧五定期做代碼審查。嵌入式代碼往往是一個人寫但問題往往在集成時才暴露。定期做代碼審查可以提前發(fā)現(xiàn)接口不一致、資源沖突等問題。這些技巧看起來簡單但在實際項目中能幫你省下大量調(diào)試時間。而調(diào)試時間恰恰是項目成本的大頭。6. 我對這個方向的一些個人判斷寫了這么多最后說點我自己的看法。機器人嵌入式這個方向未來幾年肯定會繼續(xù)分化。底層驅(qū)動的活兒會越來越標準化甚至被工具鏈自動化掉但系統(tǒng)級的設(shè)計和調(diào)試會越來越值錢。如果你現(xiàn)在還在糾結(jié)學STM32還是學Linux我的建議是先把STM32和RTOS吃透然后帶著問題去學Linux。不要為了學Linux而學Linux而是為了理解整個系統(tǒng)而學。因為最終決定你價值的不是你會用什么工具而是你能解決什么問題。還有一個趨勢值得注意機器人嵌入式正在和AI融合。越來越多的機器人需要在端側(cè)跑推理這對嵌入式的算力、功耗、實時性都提出了新要求。如果你能在嵌入式的基礎(chǔ)上理解一些AI部署的知識比如模型量化、算子優(yōu)化、異構(gòu)計算你的競爭力會更強。但這個話題展開就太長了以后有機會再聊。如果你現(xiàn)在正在這個方向上摸索歡迎交流我也還在學習。這個領(lǐng)域變化太快沒有人能說自己全都懂保持好奇、保持動手比什么都重要。