讓AI讀源碼、數(shù)括號來改代碼，這事聽起來就像拿著建筑藍圖不用，非要給工人拍張照片說"你自己琢磨"。

但這就是當(dāng)下大多數(shù)AI編程助手的現(xiàn)狀——它們在文本層面折騰，而編譯器早就握有完整的代碼結(jié)構(gòu)模型。一位開發(fā)者把這個問題捅破了：既然Roslyn（C#編譯器平臺）加載解決方案時就把整個項目索引完畢，AI為什么還要當(dāng)"文本民工"？

從文本到對象：AI終于不用"猜"代碼了

RoslynMCP的核心思路很直接：AI不再碰文本，而是直接操作編譯器內(nèi)部的結(jié)構(gòu)化對象。

具體怎么玩？Roslyn加載解決方案后，AI能瞬間定位任意類，向上追溯基類型、接口、調(diào)用方，向下深挖派生類型、實現(xiàn)、被調(diào)用方。每次搜索都是語義級的，由編譯器解析——不是文本grep那種笨辦法。

改代碼時，AI不敲字符。它要類結(jié)構(gòu)，Roslyn給JSON：字段、方法、類型、修飾符一目了然。然后AI按名稱鎖定具體方法，Roslyn生成語法、格式化、返回編譯器診斷——全打包在一個響應(yīng)里。

更細的操作也有。塊級導(dǎo)航讓AI能用路徑定位任意嵌套塊，比如TaskService.AddTask.if[0].else，只改那個else塊，其他紋絲不動。

調(diào)試層面，AI通過DTE（開發(fā)工具擴展）API設(shè)斷點、啟動調(diào)試、單步執(zhí)行、讀取局部變量——完整運行時檢查，不止靜態(tài)分析。

技能系統(tǒng)：教AI"看說明書"用工具

這套方案藏著一個容易被忽略的設(shè)計：技能（Skills）。

作者打了個比方：人用筆電之前得看說明書，AI也一樣。技能就是Roslyn工具的使用說明書——參數(shù)怎么填、工作流程是什么、出錯了怎么辦。

Claude Code用戶能從GitHub復(fù)制技能文件到項目的.claude/skills/目錄。內(nèi)置的Claude Chat面板也預(yù)裝了這些技能，路徑在Skills/.claude/skills/。

這意味著AI不是拿到API就瞎折騰，而是按說明書規(guī)范操作。對復(fù)雜編譯器接口來說，這層約束很實在。

一種新語言的雛形？

作者在GitHub寫道：「我認為最終會出現(xiàn)專為AI設(shè)計的編程語言——不是給人敲的，而是讓AI作為結(jié)構(gòu)化對象來操作。這是朝那個方向的早期實驗，基于C#和Roslyn。而且它已經(jīng)可以用了?！?/p>

這個判斷有點意思。現(xiàn)在的編程語言全是為人眼和手優(yōu)化的：縮進、換行、括號對齊，都是為了人類可讀。但AI不需要這些——它要的是關(guān)系明確的圖結(jié)構(gòu)。

RoslynMCP沒造新語言，而是讓AI繞過文本層，直接啃編譯器的語法樹。效果類似：AI看到的不是字符流，而是類型、成員、調(diào)用關(guān)系的對象網(wǎng)絡(luò)。

項目已上架VS Marketplace，GitHub倉庫開源。兩個Demo視頻展示了實際交互：AI查詢類結(jié)構(gòu)、修改方法體、調(diào)試運行——全程沒有文本編輯的鬼畫符。

有個細節(jié)值得玩味。作者提到AI改代碼時，Roslyn會返回編譯器診斷——這意味著AI能立刻知道自己改的東西能不能編譯通過。對比之下，純文本編輯的AI助手得等整個文件重編才能發(fā)現(xiàn)語法錯誤，反饋延遲完全不同。

如果這種模式跑通，其他語言的編譯器平臺會不會跟進？畢竟Roslyn的結(jié)構(gòu)化能力不是C#獨占，LLVM、TypeScript編譯器、甚至JVM都有類似的基礎(chǔ)設(shè)施。問題是，有多少開發(fā)者愿意讓AI跳過自己寫了十幾年的文本界面？