這項由美團、香港大學、香港中文大學、中國科學院自動化研究所、南京大學、哈爾濱工業大學、澳大利亞阿德萊德大學機器學習研究所、慕尼黑路德維希馬克西米利安大學、中國科學技術大學以及倫敦瑪麗女王大學等多所機構聯合完成的研究，以綜述論文形式發表於2026年，論文編號為arXiv:2606.15932，感興趣的讀者可通過該編號查詢完整原文。
**代碼生成的"視覺缺口"**
平時我們跟AI說"幫我寫一段排序代碼"，AI可以輕鬆完成。但假如你把一張網頁截圖放到AI面前，說"幫我把這個頁面變成代碼"，或者把一張折線圖放過去，說"幫我把這張圖復現出來"——AI能做到嗎？這就是這篇論文關注的核心問題。
過去幾年，大語言模型（可以把它理解為非常強大的文字處理引擎）在"看文字寫代碼"這件事上已經做得相當不錯了。程序員描述需求，AI生成代碼，這套流程已經被整合到了無數開發工具中。然而現實世界裡，人們表達意圖的方式遠不止用文字——更多時候，我們會拿一張設計稿、一張數據圖、一份手繪草圖來說"我想要這樣的效果"。這種從視覺到代碼的跨越，就像是把一幅畫翻譯成樂譜，既要保留視覺的"樣子"，又要還原其背後的"邏輯"。
這篇綜述論文把這個新興領域命名為"多模態代碼智能"，並系統梳理了從2022年到2026年初的相關研究，覆蓋282篇論文，橫跨四個主要方向。下面，我們就順著這篇研究的脈絡，一起探索這個既新鮮又複雜的領域。
---
一、從文字到圖像：代碼生成的新挑戰
傳統的代碼生成，就像是根據一份菜譜來做菜——菜譜用文字寫清楚了步驟，廚師照著做就行。但現實中，很多時候你手裡只有一盤成品菜的照片，沒有任何文字說明，你得自己"反推"出這道菜怎麼做。這就是多模態代碼生成的本質難點。
研究團隊將這類任務歸結為三種基本形式。第一種叫"多模態直接生成"：給模型一張圖（比如網頁截圖、圖表、設計稿），讓它直接生成對應的代碼。第二種叫"指令驅動代碼編輯"：給模型一張現有的圖和一條指令（比如"把這個按鈕換成紅色"），讓它修改代碼實現視覺上的變化。第三種叫"基於參考的代碼精化"：給模型一份"草稿代碼"和一張目標圖，讓它把草稿改到和目標一致。
在這三種基本形式之外，研究團隊還歸納了兩種更高級的代碼使用方式。一種叫"程序化工具調用"——代碼不是最終產物，而是一個中間推理步驟，用來調用外部工具（比如圖像識別、數學計算），最後得出答案。另一種叫"可執行策略"——代碼是一個動作腳本，驅動機器人或軟體在環境中執行任務。
這個分類框架是整篇綜述的骨架，所有後續內容都可以在這個框架下找到歸宿。
---
二、圖形界面代碼生成：讓截圖變成能跑的程序
考慮這樣一個場景：你是一名創業公司的設計師，畫好了一張網頁設計稿，但公司沒有足夠的前端工程師。如果AI能直接把你的設計稿變成可以運行的網頁代碼，那得省多少時間？這正是"圖形界面代碼生成"這個方向在解決的問題。
研究團隊把這個方向分成了網頁端和移動端兩大塊，發現二者面臨的挑戰截然不同。
網頁端的情況相對樂觀，因為瀏覽器是一個非常理想的"驗證環境"——生成的代碼可以直接在瀏覽器里運行，看看渲染出來的頁面是否和目標圖一致，還可以模擬用戶點擊、表單填寫等交互行為來檢驗功能是否正確。早期研究主要關注"外觀相似度"，用像素級比較來判斷生成的頁面像不像原圖。WebSight和Web2Code等數據集在合成數據上建立了基礎方法。Design2Code則走向真實網站數據，讓模型學會處理真實世界中複雜的頁面結構。
然而隨著研究深入，一個重要的問題浮出水面：一個頁面看起來像，和這個頁面真的能用，是兩碼事。比如，一個表單看起來和原圖一模一樣，但當用戶點擊提交按鈕時什麼也不發生——這樣的代碼在視覺評分上可能很高，但對用戶來說毫無用處。IWR-Bench的研究發現，在他們的測試集上，模型的視覺相似度得分可以達到64%，但交互功能正確率只有24%——這個巨大的鴻溝說明，我們長期以來只盯著"好不好看"，忽略了"能不能用"。
於是，Interaction2Code、WebGen-Bench等更新的基準測試開始引入"交互成功率"這樣的指標，要求模型生成的頁面不僅要好看，還要能響應用戶操作。一些新方法（比如Coder-CUA）甚至引入了一個"電腦使用智能體"來自動模擬用戶行為，檢驗頁面功能是否完整。
移動端的情況則麻煩得多。手機應用是編譯過的二進制程序，沒有統一的運行環境，也沒有可以爬取的源代碼。因此，移動端的研究只能退而求其次，用設計稿截圖、UI層級資訊等"代理信號"來替代真實的運行測試。APPUI用設計稿圖片配代碼的方式建立數據集，CANVAS則關注在Figma這類設計工具里的操作。UICrit提供了專業設計師對界面的批註，幫助模型理解"什麼樣的界面是好的"。這些都是有價值的探索，但研究團隊也坦率地指出，這些信號都只能驗證部分正確性，離真正的"運行測試"還有相當大的距離。
---
三、科學可視化代碼生成：讓圖表說出它的"數據真相"
圖表是科學交流的核心工具。一張折線圖、一份統計表格、一頁公式，背後都藏著數據和邏輯。如果AI能從圖表"反推"出生成這張圖的代碼，那意味著它不僅看懂了圖表的外觀，還理解了圖表背後的數據語義。
這個方向被研究團隊細分為四個子領域：統計圖表、結構化文檔、學術演示文稿和科學演示。
統計圖表的生成存在一個有趣的不對稱性。從文字描述生成圖表（比如"畫一張2020到2024年銷售數據的折線圖"），和從圖表逆向恢復代碼，是兩個完全不同的任務。前者是一個"欠定問題"——同一個描述可以對應無數種合理的可視化方案；後者是一個"約束重建問題"——目標圖只有一個，代碼必須精確還原它的數據、視覺編碼方式和繪圖邏輯。
研究團隊發現，現有的評估方式存在一個根本性的缺陷：視覺相似度高並不等於數據正確。一張圖看起來和原圖幾乎一樣，但可能用了錯誤的數值，或者把X軸和Y軸搞反了，或者把兩組數據的含義混淆了。這就像是臨摹一幅畫，臨摹者可以讓顏色和線條都很像，但他並不理解這幅畫畫的是什麼。ChartMimic、ChartEdit等基準測試開始要求模型不僅重現視覺效果，還要通過"數據提取"來驗證數值準確性。MSRL和ChartMaster則引入了基於渲染反饋的強化學習——簡單說就是讓模型"試畫"，然後看渲染結果是否正確來調整參數。
結構化文檔的挑戰更為綜合。把一頁PDF文檔轉換成Markdown、HTML或者LaTeX格式，聽起來像是簡單的格式轉換，實際上需要同時處理段落文字、表格結構、數學公式和頁面布局四種完全不同的"語法體系"。OmniDocBench和olmOCR-Bench是這個領域的重要基準，前者關注PDF頁面的整體結構還原，後者提供了1400多份各類PDF文檔的測試集。在方法上，早期的流水線方法（先檢測版面，再分區域識別）正在被端到端的視覺語言模型取代，後者可以一次性處理整頁內容，效果更穩健。
學術演示文稿（PPT和海報）的生成面臨的是一個"壓縮+設計"的雙重挑戰。把一篇20頁的論文變成20張幻燈片，不僅要選擇最重要的內容，還要讓每一頁看起來美觀、邏輯清晰。PPTAgent、AutoPresent等方法採用了不同的技術路徑：有的把幻燈片當作可編輯的對象樹來操作，有的用API調用的方式讓AI專注於內容規劃而把排版交給專業工具，有的引入"審稿人"模組來檢查布局是否合理。海報生成的挑戰更大，因為要把大量資訊塞進一張畫布，還得保證不同區塊之間視覺上和諧統一。
科學演示（比如化學結構動畫、數學定理可視化）是整個科學可視化方向里最"高危"的子領域。為什麼說高危？因為一個分子結構圖可以畫得很好看，但違反化學鍵規則；一個數學定理動畫可以很流暢，但實際上演示的是錯誤的推理過程。視覺上的合理性完全無法替代領域知識的正確性。TheoremExplainAgent嘗試用Manim（一個數學動畫庫）生成定理解釋影片，EduVisAgent則通過多智能體協作生成互動教學網頁。這些工作都意識到，驗證生成結果的正確性需要領域專家參與，或者引入領域特定的驗證工具（比如化學鍵驗證器）。
---
四、結構化圖形代碼生成：讓程序理解"形狀背後的邏輯"
如果說圖表是數據的語言，那麼結構化圖形就是設計和工程的語言。這個方向包含三個截然不同的子領域：可縮放向量圖（SVG）、流程圖/架構圖，以及電腦輔助設計（CAD）。
SVG是一種用代碼描述圖形的格式，每一條線、每一個圓、每一個顏色都是代碼里的一個命令。生成SVG的難點在於，模型必須在"視覺好看"和"代碼結構合理"之間取得平衡——一張用SVG寫出來的圖標，不僅要渲染正確，還要方便人類設計師後續編輯修改。StarVector通過大規模SVG數據集訓練模型，實現了圖像到SVG的直接轉換。Chat2SVG結合了大語言模型的語義理解和擴散模型的幾何優化，試圖同時滿足語義和視覺兩方面需求。RLRF則引入了基於渲染的強化學習，讓模型通過"畫出來看效果"的反饋來優化SVG路徑參數。
流程圖和架構圖的生成本質上是一個邏輯推理問題而不是視覺問題。一張流程圖可能看起來很正確，但如果某個分支條件搞反了，或者某個節點之間的箭頭方向錯了，整個圖表達的意思就完全不同了。Flow2Code建立了流程圖到代碼的多語言測試集，StarFlow關注從草圖到結構化JSON工作流的轉換。OmniDiagram提出了一個統一框架，用"生成式視覺追問"作為獎勵信號——簡單說就是讓另一個模型來"審查"生成的圖，看看它和原始邏輯是否一致。
CAD是這三個子領域裡技術門檻最高的。CAD代碼不僅要生成一個在視覺上看起來像目標模型的三維形狀，還要保留設計的"參數化歷史"——比如這個零件的某個孔是先打了一個圓，再擠壓出來的，這個構建順序必須在代碼里正確反映，否則當工程師後來修改設計參數時，整個模型就會"崩掉"。DeepCAD開創了用序列化命令表示CAD歷史的研究範式，後續的CAD-Llama、ReCAD等工作在此基礎上引入了語言模型，讓自然語言描述也可以驅動CAD生成。CAD-Judge提出了"以編譯器為裁判"的思路——用CAD軟體的編譯器來判斷生成的代碼是否合法，而不是依賴昂貴的視覺語言模型評分。
---
五、前沿任務：當代碼成為"看世界"的工具
前面三個方向里，代碼是最終產物——生成一個網頁、一張圖表、一個零件。但研究團隊還關注了另一類完全不同的場景：代碼不是終點，而是過程中的一個工具，用來幫助AI更好地理解和處理視覺資訊。
程序化視覺操作是其中最有趣的一個方向。基本思路是：當AI面對一道視覺推理題時，與其靠"直覺"直接作答，不如先寫一段代碼，用代碼來裁剪圖像、檢測物體、測量距離、標註區域，把"解題過程"變成可以觀察和驗證的一系列操作步驟。VisProg把自然語言問題翻譯成視覺處理程序，ViperGPT用Python腳本調用視覺API來回答問題，Visual Sketchpad讓模型先畫輔助草圖再作答。更近的工作如Visual-ARFT和Pixel Reasoner則通過強化學習來獎勵那些"真正有用"的視覺操作步驟，而不僅僅獎勵最終答案是否正確。
影片代碼生成分為兩個方向：從代碼生成影片，以及從影片中提取代碼。前者的典型場景是用Python腳本生成教學動畫，Code2Video嘗試通過編程腳本生成教育影片，TheoremExplainAgent專注於用Manim生成數學定理可視化。後者的典型場景是從機器人操作影片中自動提取可執行的操作策略腳本，RoboPro用大規模影片數據訓練策略生成模型，減少了昂貴的機器人軌跡數據採集需求。這兩個方向都面臨同一個核心挑戰：代碼描述的是離散的步驟和關鍵幀，而影片呈現的是連續流動的時間，兩者之間的"斷層"很難完全填平。
具身控制是把代碼生成推向物理世界的方向。當一個機器人需要"去廚房拿一瓶水"時，它需要把這個高級目標分解成一系列具體的動作指令：先導航到廚房，判斷水瓶的位置，規劃抓取軌跡，控制機械臂……Code as Policies和ProgPrompt展示了用程序化結構來表達機器人任務的優勢——代碼的層次結構、API調用和條件邏輯讓機器人行為更加透明和可解釋。然而，代碼天然是離散和符號化的，而機器人操控需要處理連續的力反饋、物體接觸動態和傳感器噪聲，這道鴻溝在技術上至今沒有完美的解決方案。
視覺基礎編程研究的是當代碼生成任務的關鍵線索藏在圖像里時，模型能否真正利用這些視覺資訊。HumanEval-V專門設計了253個"純靠文字無法解答"的編程題，圖像是解題的關鍵。SWE-bench MM收集了617個需要藉助網頁截圖來定位和修復Bug的真實軟體工程問題。GUIRepair讓模型生成"復現腳本"來觸發Bug，然後在修復後截圖驗證，形成一個視覺驅動的調試閉環。這個方向最根本的挑戰在於：怎麼證明模型真的用到了圖像資訊，而不是靠猜測或文字描述走了捷徑？
統一多模態代碼生成是一個更宏觀的研究方向，探索能否用一個通用模型來處理前面所有類型的視覺代碼任務。JanusCoder、VisCodex、VisCoder2等工作嘗試通過數據混合訓練來打通不同任務之間的邊界。研究團隊對此保持審慎態度：一個能接受更多任務格式的模型，並不等於一個真正理解了視覺代碼底層規律的模型。真正的"統一"應該體現在跨任務遷移能力上——比如在圖表任務上學到的排版理解，能不能幫助解決流程圖任務——而不僅僅是把更多數據塞進一個模型。
---
六、評估的困境：為什麼"看起來對"還不夠
貫穿整篇綜述的一個核心主題，是對現有評估方法的深度反思。研究團隊總結了當前領域裡五類常見的評估代理及其局限性。
視覺相似度指標（比如SSIM、CLIP分數）是最常用的評估手段，但它只能檢驗外觀，無法判斷數據是否正確、結構是否可編輯、交互是否可用。文本/代碼相似度指標（比如BLEU、TEDS）關注的是代碼字符層面的匹配，但一個語法完全不同的代碼可以生成完全相同的輸出，反之亦然。偏好評分依賴人類評審員或另一個AI模型的判斷，這種方式容易受提示詞影響，難以重現，也很難定位到具體錯誤。智能體回放（讓AI自動模擬用戶操作來檢驗功能）是一個更強的信號，但受限於智能體自身的能力上限，且很難獨立控制評估過程。過程獎勵（獎勵工具調用是否合理、中間步驟是否正確）比只看最終答案更細緻，但一個看起來合理的操作步驟不一定真的起到了關鍵作用。
基於這些觀察，研究團隊提出了四個值得重點探索的未來方向。
第一個方向是"多信號驗證"——對同一個生成結果，同時用視覺相似度、數據準確性、代碼可執行性、結構可編輯性等多個維度來評估，而不是靠單一指標評分。這就像醫生給病人做體檢，不能只量體重，還要查血壓、血糖、肝功能等多項指標。
第二個方向是"多狀態驗證"——不只測試單一輸出狀態，而是把生成的代碼放入一個執行環境，測試它在不同用戶操作、不同數據輸入下的行為是否都正確。這就像測試一輛汽車，不只看停在展廳里好不好看，還要在各種路況下實際開一開。
第三個方向是"跨任務遷移測試"——專門設計測試集來檢驗統一模型學到的能力是否真的在任務間遷移，而不只是在訓練過的任務上表現好。
第四個方向是"可驗證智能體軌跡"——對於那些通過多步驟推理和工具調用來生成代碼的智能體系統，要求它們記錄詳細的操作日誌，每一步操作都能被回放和審查，確保每個視覺操作確實作用於了關鍵資訊，而不是"表演"給評估者看。
---
歸根結底，這篇綜述揭示了一個關鍵洞見：代碼不只是文字，代碼是人類表達意圖、控制電腦和物理世界的工具。當這個工具需要處理視覺世界時，正確性的標準就不再只是"語法對不對"，而是擴展到了"渲染出來的樣子對不對、數據是否精確、交互是否可用、邏輯是否合理、物理上是否可行"——一整個證據鏈。
這個領域還很年輕，從時間線圖上可以看到，2024年第一季度只有17篇相關論文，到2025年第二季度已經飆升到了44篇。每一篇新論文都在試圖解決這個證據鏈上的某一個缺口。對於普通用戶來說，這意味著不遠的將來，你或許真的可以把一張設計稿、一份手繪草圖或者一張數據圖丟給AI，然後得到一段不僅好看而且真的能用的代碼——而AI給你的那段代碼，它自己也"知道"為什麼要這樣寫。
對於有興趣深入了解這個領域的讀者，完整論文可通過arXiv:2606.15932查閱，其中包含282篇相關論文的詳細分類和分析，以及配套的GitHub資源庫，持續更新最新研究成果。
---
Q&A
Q1：多模態代碼智能和普通代碼生成有什麼區別？
A：普通代碼生成是"你用文字說需求，AI寫代碼"。多模態代碼智能則是"你給AI看一張圖（比如網頁截圖、圖表、設計稿），AI把這張圖變成能運行的代碼"。關鍵區別在於輸入是圖像而不是文字，AI需要先理解圖像里的視覺資訊，再把這些資訊轉化為代碼邏輯。
Q2：視覺相似度評分高的代碼為什麼還是可能有問題？
A：視覺相似度只能判斷"好不好看"，無法驗證功能是否正常。一個網頁頁面可以和參考圖看起來一模一樣，但按鈕點擊沒有反應、表單提交會報錯、路由跳轉會失敗。一張圖表可以外觀完全相同，但背後的數值是錯的。就像一輛玩具汽車和真實汽車外形一模一樣，但你沒法真的開它上路。
Q3：當前多模態代碼生成領域最大的技術瓶頸是什麼？
A：最大的瓶頸是"評估"。現有的評估方式大多只檢驗視覺外觀，沒有同時驗證數據準確性、代碼可執行性、交互功能和結構可編輯性。這導致模型優化方向偏差——訓練出來的模型擅長"讓結果看起來對"，但不一定"真正做對了"。這篇綜述呼籲建立多信號驗證體系，從多個維度同時檢驗生成結果的正確性。
