上一篇文章聊過一次 Skill（Skill是什么，嵌入式開發(fā)也該開始準備了），當時更多是講它為什么重要。
這篇我想往下走一步：如果真的要在嵌入式開發(fā)里創(chuàng)建一個標準 Skill，應該怎么做？
我現(xiàn)在越來越覺得，Skill 不是一個概念問題，而是一個工程習慣問題。
以前我們和 AI 協(xié)作，大多是臨時對話。
寫一個驅動，就告訴它不要動態(tài)內存、要有超時、錯誤碼要統(tǒng)一。
查一個 RTOS 問題，就告訴它先整理現(xiàn)象、再列可能方向、不要直接下結論。
做一次代碼 review，就提醒它重點看指針、數組、中斷、并發(fā)、實時性，不要只說命名和注釋。
這些話說一次沒問題，說三次就有點浪費。
如果同一套規(guī)則反復出現(xiàn)，它就不應該繼續(xù)停留在聊天記錄里，而應該沉淀成 Skill。
Skill 的本質，就是把老工程師反復提醒的話，變成 AI 默認遵守的工作規(guī)則。
1
標準 Skill 不是一段超長提示詞
很多人第一次做 Skill，容易把它寫成一篇很長的提示詞。
把所有經驗、所有規(guī)則、所有例子都塞進一個文件里。看起來很完整，但實際用起來不一定好。
因為 AI 每次工作時，最怕上下文太亂。
一個好的 Skill，應該像一個小型工程包。
入口文件只放最關鍵的觸發(fā)條件和工作流程。
詳細檢查項放到參考文件里。
能腳本化的部分放到腳本里。
需要復用的模板放到 assets 或 templates 里。
這樣做的好處是，AI 先看到核心規(guī)則，真正需要時再加載詳細資料，而不是一上來就被幾千行內容淹沒。
一個比較標準的目錄可以這樣設計：
embedded-code-review/├─ SKILL.md├─ references/│ └─ review-checklist.md├─ scripts/│ └─ check_embedded_c_smells.py└─ adapters/└─ cursor-embedded-code-review.mdc
其中 SKILL.md 是核心入口。
references/ 放詳細規(guī)則，比如嵌入式代碼審查清單。
scripts/ 放可以重復執(zhí)行的小工具，比如掃描高風險函數、動態(tài)內存、忙等。
adapters/ 放不同工具的適配層，比如 Cursor 的 .mdc 規(guī)則文件。
這個結構不復雜，但已經足夠應付大多數團隊的第一版 Skill。
2
先選一個真實場景，不要一上來做大而全
如果你問我嵌入式行業(yè)最適合先做哪個 Skill，我會選代碼審查。
原因很簡單。
它高頻、風險低、價值明顯。
嵌入式 C/C++ 代碼里，很多問題不是語法錯，而是工程風險。
比如數組越界、長度字段沒有校驗、中斷里調用阻塞接口、volatile 用錯、任務之間共享變量沒有保護、DMA buffer 沒處理 cache、等待硬件狀態(tài)沒有超時。
這些問題靠 AI 臨時 review 也能發(fā)現(xiàn)一部分，但如果沒有規(guī)則，它經常會把重點放偏。
它可能會說變量名可以更清楚，注釋可以更完整，函數可以拆分。
這些建議不是完全沒用，但不是嵌入式 review 的第一優(yōu)先級。
所以代碼審查 Skill 的第一件事，就是告訴 AI：
先看會不會死機、丟數據、破壞硬件狀態(tài)、影響實時性。
風格建議往后放。
這就是工程邊界。
3
一個嵌入式代碼審查 Skill 應該怎么寫
下面是我會放進 SKILL.md 的核心內容。
注意，Skill 里面可以是中文，而且我建議嵌入式團隊內部使用時就寫中文。
因為很多工程規(guī)則本來就是團隊內部口徑，中文更容易寫清楚，也更容易讓新人理解。
---name: embedded-code-reviewdescription: 嵌入式 C/C++ 代碼審查 Skill。用于審查 MCU、RTOS、驅動、BSP、通信協(xié)議、低功耗、異常處理相關代碼，重點發(fā)現(xiàn)指針越界、并發(fā)競態(tài)、中斷上下文誤用、實時性風險、內存/棧風險、錯誤處理不完整、硬件寄存器和時序需要人工確認的問題。---# 嵌入式 C/C++ 代碼審查## 工作原則- 先判斷代碼場景：裸機主循環(huán)、RTOS 任務、中斷服務函數、驅動層、協(xié)議解析、啟動/低功耗、測試腳本。- 優(yōu)先審查會導致死機、數據損壞、實時性失效、硬件誤操作、量產風險的問題。- 不把風格建議放在前面，除非風格問題會引入實際風險。- 涉及寄存器位、芯片時序、電氣限制、DMA/cache、編譯器特性時，標注“需要人工確認”。- 如果代碼上下文不足，先列缺失信息，再基于現(xiàn)有證據給出條件化判斷。
這段里最重要的是 description。
很多工具觸發(fā) Skill 時，主要先看名字和描述。描述寫得太虛，AI 就不知道什么時候該用。比如只寫“用于代碼審查”，范圍太大。最好把觸發(fā)場景寫具體：MCU、RTOS、驅動、BSP、通信協(xié)議、低功耗、異常處理。
后面的工作原則則是為了防止 AI 跑偏。
嵌入式代碼 review 和普通業(yè)務代碼 review 不一樣。普通代碼可能更關注可讀性、抽象、復用、測試覆蓋。嵌入式當然也關心這些，但第一優(yōu)先級通常是穩(wěn)定性、實時性、資源和硬件邊界。
4
審查順序要寫清楚
Skill 里一定要有順序。
因為沒有順序，AI 會按它自己的習慣來。它可能先看命名，再看函數長度，最后才提一句“注意數組越界”。
我會把審查順序寫成這樣：
## 審查順序1. 內存安全：空指針、數組越界、長度字段可信度、結構體對齊、生命周期、棧上大對象。2. 并發(fā)與中斷：volatile、原子性、臨界區(qū)、鎖順序、ISR 中阻塞、ISR 中調用不可重入接口。3. 實時性：忙等、無超時等待、長臨界區(qū)、日志打印、動態(tài)內存、不可控循環(huán)。4. 硬件交互：寄存器讀改寫、清標志順序、外設狀態(tài)機、DMA buffer、cache 一致性、上電/復位時序。5. 錯誤處理：返回值丟失、錯誤碼不統(tǒng)一、失敗后資源狀態(tài)不一致、重試策略缺失。6. 可維護性：接口邊界、模塊職責、命名、注釋，只在影響理解或維護風險時提出。
這個順序背后其實是嵌入式工程師的判斷。
先看會不會出事故，再看好不好維護。
這不是說代碼風格不重要，而是面向工程風險時，優(yōu)先級不能錯。
5
輸出格式也要固定
如果不固定輸出格式，AI 很容易寫成一段散文。
看起來很順，但不好落地。
我更喜歡讓它按問題卡片輸出：
## 總體判斷- 風險等級：高 / 中 / 低- 主要風險：一句話概括- 需要補充的上下文：如果沒有則寫“無”## 具體問題### [P1] 問題標題- 位置：文件名/函數名/關鍵代碼片段- 觸發(fā)條件：什么情況下發(fā)生- 可能后果：死機、丟數據、實時性下降、硬件誤操作等- 修改建議：給出可執(zhí)行建議- 是否需要人工確認：是/否，原因
這套格式有幾個好處。
第一，面向修改，不只是面向評論。
第二，方便你放到 code review 里。
第三，能強制 AI 說明觸發(fā)條件。很多風險不是一句“這里可能有問題”就結束了，必須說明什么情況下會觸發(fā)。
第四，能把“需要人工確認”單獨拎出來。
這對嵌入式非常重要。
AI 可以提醒你 DMA 可能有 cache 一致性問題，但具體芯片、具體 cache 策略、具體 MPU 配置，必須回到工程里確認。
6
詳細規(guī)則不要全塞進 SKILL.md
SKILL.md 不適合放太長。
詳細檢查項可以放到 references/review-checklist.md。
比如：
# 嵌入式代碼審查詳細清單## 內存與邊界- 指針參數是否檢查為空。- 長度字段是否先驗證再使用。- payload_len、frame_len、offset 是否可能溢出。- 數組下標是否由外部輸入直接決定。- 棧上是否創(chuàng)建大數組或大結構體。## 中斷與并發(fā)- ISR 中是否調用可能阻塞、加鎖、打印、分配內存的函數。- 中斷和任務共享變量是否只用 volatile，但缺少原子性或臨界區(qū)。- 多任務共享資源是否有一致的加鎖順序。
這樣做的好處是，入口保持清爽，細節(jié)又不會丟。
以后你發(fā)現(xiàn)團隊又踩了新坑，比如某個芯片 DMA buffer 必須 32 字節(jié)對齊，就可以補到 checklist 里。
Skill 會隨著項目經驗慢慢長出來。
7
腳本是 Skill 里很容易被忽略的部分
很多人做 Skill 只寫文檔，不放腳本。
我覺得這有點可惜。
有些事情讓 AI 每次分析，不如直接腳本掃描。
比如嵌入式 C 里可以先粗略掃這些高風險模式：
它不負責最終判斷，只負責給 AI 和工程師提供第一輪線索。
這類腳本很適合隨著項目迭代。
比如你們項目里禁止使用某些 API，就加進去。
比如要求驅動層不能調用日志接口，也可以掃。
比如發(fā)布前要檢查某些 debug 宏是否關閉，也可以掃。
當 Skill 里有腳本，AI 就不只是“會說”，而是能配合工具做一些確定性的工作。
8
嵌入式行業(yè)寫 Skill 要特別注意什么
我覺得有幾條很重要。
第一，中文沒問題，而且很多時候更適合。
團隊規(guī)則、調試習慣、歷史問題，用中文寫得更自然。name 建議用英文短橫線，因為工具識別和目錄兼容更穩(wěn)；但正文、清單、輸出要求完全可以用中文。
第二，硬件事實必須留人工確認口。
寄存器、時序、電氣特性、errata、DMA/cache，這些不能讓 AI 裝懂。Skill 里必須反復強調，不確定就標注“需要人工確認”。
第三，不要把 Skill 寫成知識百科。
Skill 不是教材，不需要解釋什么是指針、什么是 RTOS。AI 本身知道很多通用知識。你要寫的是你們項目里更在意什么、按什么順序做、哪些地方不能踩。
第四，腳本越確定，越應該沉淀。
比如掃描危險 API、統(tǒng)計棧使用、解析 map 文件、檢查發(fā)布宏、生成測試表，這些都很適合放進 Skill。
第五，輸出格式要面向工程流轉。
不要讓 AI 輸出一大段作文。要讓它輸出能放進 review、bug 單、測試報告里的結構化內容。
AI 發(fā)展到現(xiàn)在，已經不是只會幫我們補一個函數了。
它能看工程，能改工程，能生成工程，也能參與重構。
能力變強以后，最重要的問題反而不是“AI 會不會”，而是“它會不會按我們的工程規(guī)則做”。
嵌入式開發(fā)尤其需要這個邊界。
因為我們面對的不是純粹的軟件邏輯，還有硬件、實時性、資源限制、量產風險和現(xiàn)場問題。
所以標準 Skill 的價值，不是讓 AI 看起來更聰明。
而是讓 AI 更守規(guī)矩。
它知道先看指針和邊界，而不是先夸命名。
它知道 ISR 里不能隨便阻塞。
它知道硬件手冊沒確認的地方要標出來。
它知道輸出的問題要能被工程師直接拿去修改、驗證和復盤。
對嵌入式工程師來說，未來很重要的一項能力，可能就是把自己的經驗整理成 Skill。
你踩過的坑，你反復提醒新人的規(guī)則，你每次 review 都會看的點，你每次調試都會走的路徑，都值得沉淀下來。
工具會變，模型會變，Cursor、Codex、Claude Code 的入口也可能繼續(xù)變。
但有一件事不會變：真正能長期復用的，不是某一次對話里的答案。而是你沉淀下來的工程方法。
