寫Verilog、調(diào)CUDA，總翻車？工業(yè)代碼大模型開始學(xué)會先想后寫了

代碼大模型會寫代碼，這件事已經(jīng)不新鮮了。

真正新的問題是：它會不會在寫之前先想清楚，這段代碼一旦進入真實系統(tǒng)，會發(fā)生什么？

這個問題在工業(yè)場景里尤其關(guān)鍵。因為工業(yè)代碼和普通編程不一樣，它不是 “語法通順、功能差不多” 就算過關(guān)，而是要面對真實硬件、真實工具鏈和真實約束。一個 Verilog 模塊可能語法沒問題，卻在仿真或綜合階段直接失敗；一個 CUDA kernel 可能邏輯上說得通，卻在 grid 配置、索引映射或顯存約束上出錯；?個嵌入式程序也可能因為寄存器順序或中斷邏輯不對，根本跑不起來。

所以，工業(yè)代碼大模型真正缺的，往往不是 “寫” 的能力，而是 “想” 的能力。

最近，北航聯(lián)合多家單位提出的InCoder-32B Thinking，瞄準的正是這個問題。它不是簡單把代碼模型再做大，也不是只給模型加?層通用的長鏈推理，而是試圖讓模型學(xué)會：在工業(yè)環(huán)境里，代碼為什么會錯，錯了之后環(huán)境會給出什么反饋，下?步又該怎么改。

一、它不是普通的 thinking model

而是面向工業(yè)代碼的 thinking model

這幾年，thinking model 很火。大家已經(jīng)習慣了讓模型 “先想?想，再回答”。

但工業(yè)代碼場景有個特殊問題：很多時候，單靠語言層面的思考并不夠。因為工業(yè)任務(wù)的難點，不只是邏輯推理，還包括對工具鏈行為、硬件約束和執(zhí)行反饋的理解。你可以在紙面上分析很多步，但如果根本不知道 GPU 的 shared memory 限制，不知道 Verilog 綜合器如何報錯，不知道幾何建模中的非法結(jié)構(gòu)意味著什么，再長的 reasoning 也可能是空轉(zhuǎn)。

InCoder-32B Thinking 的不同之處，就在于它不是把 “思考” 當作純文本技巧，而是直接建立在工業(yè)環(huán)境之上。它試圖讓模型的 reasoning，天然綁定真實執(zhí)行反饋，而不是脫離系統(tǒng)的 “自洽解釋”。

換句話說，它不是?個 “更會說” 的模型，而是?個 “更接近工程實際” 的 thinking model。

二、真正的新意

是讓模型從 “報錯 — 修復(fù)” 里學(xué)會思考

InCoder-32B Thinking 的核心設(shè)計之一，是Error-driven Chain-of-Thought（ECoT）。

它的關(guān)鍵點在于：模型的 thinking，不是人為寫出來的，而是從一輪輪 “生成 — 執(zhí)行 — 報錯 — 修復(fù)” 的過程中提煉出來的。模型學(xué)習的，不只是最終答案，而是工程師如何一步步定位問題、修復(fù)錯誤、再驗證結(jié)果。

這在工業(yè)代碼中尤為重要。因為很多問題并不是 “不會寫”，而是 “哪?寫錯了”。比如 GPU kernel 越界，本質(zhì)可能是 shape 和索引映射不一致；RTL 編譯失敗，可能是端口聲明或位寬不規(guī)范。

ECoT 做的事情，就是把這些真實失敗和修復(fù)過程中的 reasoning 保留下來，讓模型學(xué)會從錯誤中思考，而不是只記住正確答案。

三、讓模型先 “預(yù)判結(jié)果”

再去寫代碼

如果說 ECoT 讓模型學(xué)會 “如何改錯”，那么另?個關(guān)鍵設(shè)計 Industrial Code World Model（ICWM），則讓模型學(xué)會 “提前預(yù)判”。

可以把 ICWM 理解為?個工業(yè)代碼的 “世界模擬器”：給定任務(wù)環(huán)境和候選代碼，它會預(yù)測這段代碼在真實工具鏈中的結(jié)果 —— 是通過、編譯失敗、運行報錯，還是性能不達標，并生成相應(yīng)的診斷信息。

這帶來的變化很關(guān)鍵：模型不再只是寫代碼，而是開始預(yù)估代碼進入真實系統(tǒng)后的后果。

論文顯示，ICWM 在多個工業(yè)場景中的結(jié)果預(yù)測準確率達到 96.7%，多輪軌跡?致性達到 94.4%。這意味著，它已經(jīng)能夠在相當程度上替代真實執(zhí)行環(huán)境，用于大規(guī)模數(shù)據(jù)生成和推理訓(xùn)練。

更重要的是，這也改變了訓(xùn)練數(shù)據(jù)的來源。

InCoder-32B Thinking 的 reasoning 數(shù)據(jù)，不是人工構(gòu)造的解釋，而是通過真實執(zhí)行流程 “跑出來的”：任務(wù)生成 → 代碼執(zhí)行 → 收集報錯 → 多輪修復(fù) → 記錄完整軌跡。

GPU、芯片、嵌?式、3D 建模等任務(wù)，都在對應(yīng)的真實工具鏈中驗證。

最終保留下來的，不只是正確答案，而是完整的錯誤 — 修復(fù)路徑。這種數(shù)據(jù)天然包含工業(yè)系統(tǒng)最關(guān)鍵的信息：代碼在真實環(huán)境中的行為反饋。

四、工業(yè)代碼不是統(tǒng)?模板能解決的

它需要 “自適應(yīng)思考深度”

論文還有一個很有意思的發(fā)現(xiàn)：不同任務(wù)的思考深度差異極大。

GPU kernel 優(yōu)化的中位 thinking 長度達到19015 個字符，而 agentic coding 單步只有91 個字符，差距超過200 倍。

這說明，工業(yè)代碼并不存在一個統(tǒng)一的 “思考模板”。有些問題需要長鏈路推理（比如性能優(yōu)化、硬件約束），有些則適合短決策（比如多輪 agent 操作）。

InCoder-32B Thinking 學(xué)到的，不是固定長度的 CoT，而是根據(jù)任務(wù)復(fù)雜度和環(huán)境反饋，動態(tài)調(diào)整思考深度 —— 復(fù)雜問題深推理，簡單問題快速決策。

這種能力，更接近真實工程師，而不是模板化的語言模型。

五、結(jié)果說明：工業(yè)代碼模型的競爭

已經(jīng)開始從 “會寫” 轉(zhuǎn)向 “會驗證”

從結(jié)果來看，這條路線是有效的。

InCoder-32B Thinking 在14 個通用代碼 benchmark和9 個工業(yè)代碼 benchmark上進行了評測。在通用任務(wù)上保持競爭力，在工業(yè)場景中則取得顯著提升，包括CAD Coder 84.0%、KernelBench L2 38.0%等指標。

更關(guān)鍵的是，這些提升是跨領(lǐng)域的 —— 芯片設(shè)計、GPU 優(yōu)化、嵌入式、編譯器、3D 建模都受益。

這說明它學(xué)到的，不是某個領(lǐng)域技巧，而是?種更底層的能力：

理解執(zhí)行反饋 → 組織推理 → 完成修復(fù)

如果說過去大家比的是誰 “寫得更像人”，那么現(xiàn)在，工業(yè)代碼模型開始比的是誰 “更像工程師”。

開源信息

模型與代碼現(xiàn)已開源。

Hugging Face：https://huggingface.co/Multilingual-Multimodal-NLP/IndustrialCoder

GitHub：https://github.com/CSJianYang/Industrial-Coder

當代碼大模型開始不只生成代碼，而是開始預(yù)測代碼進入真實工業(yè)環(huán)境后的后果，工業(yè)代碼智能的門檻，也就從 “會寫程序” 抬高到了 “會理解系統(tǒng)”。