▼點擊下方名片，關注公眾號，獲取更多精彩內容▼
這里是《賀老師講嵌入式AI》，我是《嵌入式AI：讓單片機學會思考》課程主理人，專注AI在MCU上的落地實踐。
關注公眾號，回復【嵌入式AI】，可以免費獲取更多賀老師準備的專業資料。
我曾經面試過很多35歲以上的嵌入式工程師，有一種很常見的項目履歷：STM32 做過，FreeRTOS 用過，SPI、I2C、CAN、以太網也都調過。五年以后換一款 MCU，十年以后再換一套 SDK，工作內容僅僅停留在會用單片機、做個幾個項目、推出過幾個量產的產品。但是，總是給人一種“沒有真正核心競爭力”的感覺。
雖然量產產品意味著踩過坑、救過火、扛過交付，當然有價值。可是在招聘和崗位調整中，企業更關心的是：這個人除了熟練，究竟掌握了什么別人短期內難以替代的能力？
如果答案仍然是“熟悉更多芯片、用過更多接口、移植過更多系統”，十年經驗很可能變成同一種能力的十次重復。工具越來越成熟，參考工程越來越完整，代碼生成和 AI 編程工具繼續降低門檻，單純依靠熟練度建立的優勢會越來越薄。
嵌入式行業很容易產生一種“項目很多，能力很平”的履歷。上一家公司用 STM32，下一家公司改用 NXP；上一款產品跑 FreeRTOS，下一款產品換成 ThreadX；通信接口從 CAN 變成以太網，芯片手冊和 API 全換了，解決問題的層級卻沒有變化。
這種經驗主要增加執行速度。遇到時鐘異常、總線鎖死、棧溢出、DMA 沖突，老工程師定位得更快，這些能力能夠保證項目交付。問題在于，企業對資深工程師的期待會繼續上升：方案為什么選這顆芯片，功耗和性能怎樣平衡，成本上漲時哪些功能可以裁剪，系統風險在哪里，產品失敗后怎樣劃定技術責任。
會用一款 MCU，回答的是“怎么把功能做出來”；能夠設計系統，回答的是“為什么采用這套方案”。前者依賴工具熟練度，后者依賴對約束、風險和商業目標的理解。年齡越大，企業越希望你承擔第二類問題。
 |
圖 1：項目年限會增加經歷，責任邊界決定這些經歷能否形成職業壁壘
這里還有一個更現實的問題。驅動、協議棧和 RTOS 已經高度標準化，芯片原廠持續補齊 HAL、SDK、中間件和示例工程。AI 編程工具也開始承擔寄存器配置、接口封裝、代碼遷移和常規故障排查。工具不會消滅嵌入式崗位，它會壓縮大量重復工作的時間，并讓“只會按手冊實現”變得更難形成稀缺性。
核心競爭力通常藏在工具無法觸及的地方，比如：故障邊界、安全責任、成本取舍、跨團隊協作，以及產品出了問題以后，誰能給出可信的技術判斷。
TinyML 對職業發展的意義，并不局限于在 MCU 上調用一次神經網絡。關于我的另一篇文章，大家可以參考一下：
“我們老板說了，嵌入式AI就是在單片機上運行神經網絡算法，沒啥難度！”用這4條信息反駁他！
它讓嵌入式工程師開始接觸過去經常由算法團隊、系統架構師和產品經理分別處理的問題：產品功能是否適合使用模型，規則方案能否滿足要求，推理放在 MCU、NPU、MPU 還是云端，模型帶來的功耗、成本、延遲和維護壓力能否接受。
這些問題都沒有一個可以直接復制的標準答案。某個功能使用 if-else 就能穩定完成，增加模型只會提高驗證成本；某些聲音、動作、狀態和異常很難靠固定規則覆蓋，TinyML 才可能帶來明顯收益。能夠做出這類判斷的人，已經開始參與產品定義和系統架構。
芯片原廠的動作也在強化這種變化。ST 已經在 STM32N6 中集成 Neural-ART NPU，并提供 STM32N6-AI 和 ST Edge AI 工具；NXP 的 eIQ 與 MCUXpresso SDK 集成；TI 的 Edge AI Studio 覆蓋 MCU、處理器和雷達；Renesas 用 Reality AI Utilities 連接模型工具和 e2 studio。AI 能力正在進入原廠 MCU / MPU 生態，逐步成為常規開發流程的一部分。
 |
圖 2：原廠正在降低模型部署門檻，工程師的價值會進一步轉向方案判斷和產品責任
當模型轉換、算子優化和代碼生成越來越自動化，“成功跑起來”會逐漸變成入門能力。更有分量的問題會集中在后面：為什么選這個模型，為什么需要 NPU，資源增加換來了什么產品收益，模型失效時系統怎樣降級，固件升級后怎樣防止功能回退，現場誤判會不會引發安全風險。
這正是有多年經驗的嵌入式工程師更容易建立優勢的地方。做過量產的人理解 BOM 成本、實時任務、低功耗、看門狗、故障恢復、EMC、產測和售后維護。補上 TinyML 以后，這些經驗不會作廢，它們會成為約束模型、約束工具鏈、約束產品風險的基礎。
第一步是停止用工具數量證明資歷。熟悉 STM32、NXP、TI、瑞薩，能夠說明適配范圍；熟悉 Keil、IAR、CubeIDE、VS Code，能夠說明開發習慣。真正體現層級的內容，應當是你做過哪些關鍵取舍，解決了哪些系統沖突，承擔過哪些產品結果。
第二步是把 TinyML 學到“能夠參與決策”的程度。你需要理解分類、回歸、異常檢測分別適合哪些需求；能夠讀懂模型輸入輸出、準確率、召回率、誤報率和資源報告；知道 Cortex-M、DSP、NPU 的能力邊界；能夠判斷 TFLite Micro、廠商工具鏈和云端方案各自適合什么項目。
第三步是建立一套自己的方案判斷框架。拿到需求時，先判斷固定規則能否覆蓋，再核算端側模型帶來的收益；確定芯片和工具鏈時，同時看實時任務、功耗、成本、安全和后續維護；評審方案時，主動提出模型失效、版本升級和異常降級策略。做到這一步，你掌握的已經從一項新技術，擴展成了跨軟件、硬件、算法和產品的決策能力。
簡歷也要隨之改變。“熟悉 STM32 和 FreeRTOS，參與多個量產項目”只能說明做過。更有力量的寫法，要說明你負責了什么關鍵模塊、做過什么架構選擇、降低了什么風險、怎樣平衡性能與成本、最終結果由什么指標驗證。增加 TinyML 經歷以后，還要說明為什么采用端側模型、硬件為什么這樣選、模型失敗時系統怎樣處理。
35 歲的真正壓力，在于企業已經很難繼續為“潛力”買單。用人方希望看到一個人能夠獨立承擔更大的問題，并把經驗轉化成判斷、方法和結果。繼續更換 MCU、SDK 和 IDE，只會讓履歷變長；擴大自己能夠負責的技術邊界，才會讓履歷變重。
END
