讓AI讀源碼、數(shù)括號來改代碼，就像給建筑師一張建筑照片而非藍圖——明明有完整結構圖，卻非要AI自己猜哪堵墻承重。

這是Yaroslav Horokhov在GitHub上的原話。他做了套工具，讓Claude直接操作Roslyn編譯器的結構化模型，而非 raw text。效果：AI找類、改方法、下斷點，全部走編譯器語義層，響應速度比文本編輯快一截。

文本編輯的荒謬：AI在"看圖說話"

Horokhov的類比很毒：現(xiàn)有AI編程工具（包括Cursor、GitHub Copilot的某些模式）本質是讓大模型當 OCR——讀文件、猜結構、拼字符串。編譯器加載項目時早已生成完整抽象語法樹（AST，Abstract Syntax Tree），包含每個字段的類型、每個方法的簽名、每個繼承關系的指向。

但AI接觸不到這些。它拿到的是 `.cs` 文件的字符流，靠訓練時學到的C#語法規(guī)律來推斷"這里該加個括號"。

Horokhov算了筆賬：一個中等規(guī)模的解決方案，Roslyn加載后索引全部符號僅需數(shù)秒。AI通過他的工具查詢?nèi)我忸?，延遲在毫秒級。而走文本路徑，大模型需要逐文件讀取、解析、建立心理模型——這個過程對Claude 3.7 Sonnet來說，一個復雜類的理解成本約15-30秒，且容易 hallucinate 繼承關系。

他的方案是：讓AI用JSON對話編譯器，而非用自然語言對話代碼文件。

RoslynMCP的運作：三層協(xié)議

工具全名 RoslynMCP，基于Model Context Protocol（MCP，模型上下文協(xié)議）實現(xiàn)。架構分三層：

第一層，語義索引。Roslyn加載解決方案后，AI可通過類名、接口名、方法名直接定位符號，無需文件路徑。查詢"誰調用了 `TaskService.AddTask`"，返回的是編譯器解析后的調用圖，而非文本搜索結果。

第二層，結構化編輯。AI不生成代碼字符串，而是發(fā)送JSON指令：目標類 `TaskService`，目標方法 `AddTask`，操作類型 `InsertIfBlock`，位置路徑 `if[0].else`。Roslyn接收后，在語法樹層面插入節(jié)點，自動處理縮進、括號匹配、using語句補全。同一響應包還包含編譯器診斷：若新代碼有類型錯誤，AI立即收到Error級別反饋，而非等到生成后才發(fā)現(xiàn)。

第三層，運行時穿透。通過DTE（Development Tools Environment）API，AI能設置斷點、啟動調試、單步執(zhí)行、讀取局部變量值。這是靜態(tài)分析工具（如AST-based linter）無法觸及的領域——AI可以看到 `userCount` 在第三循環(huán)迭代時的實際數(shù)值，而非猜測其可能范圍。

Horokhov放出的Demo視頻里，Claude用自然語言指令完成了一個典型重構：將同步方法改為異步，自動插入 `async/await` 關鍵字，更新返回類型為 `Task`，并追溯所有調用方添加 `.Result` 或改為 `await`。全程無人工干預，編譯器保證語法正確性。

Skills系統(tǒng)：給AI寫"操作手冊"

工具的另一設計是Skills（技能）機制。Horokhov認為，AI需要像人類一樣"先讀說明書再上手"。每個Skill定義了Roslyn工具的正確使用方式：參數(shù)格式、執(zhí)行流程、異常處理策略。

例如 `RefactorToAsync` Skill包含：檢查方法是否已標記async、識別所有阻塞調用（如 `File.ReadAllText`）、生成等效異步版本（`File.ReadAllTextAsync`）、處理調用鏈上游的兼容性。Skill用YAML描述，存于項目目錄的 `.claude/skills/` 下，Claude Code自動加載。

GitHub倉庫已開源12個基礎Skill，覆蓋常見重構場景。Horokhov在VS Code擴展中內(nèi)置了同款Skill集，供Claude Chat面板調用。

這套機制解決了大模型工具調用的核心痛點：幻覺。未經(jīng)約束的AI可能編造不存在的Roslyn API參數(shù)，或在錯誤上下文調用工具。Skill相當于強制類型檢查——Claude必須按Schema填充參數(shù)，否則請求被拒絕。

語言設計的轉向：為AI造語法

Horokhov在文末拋了個判斷：未來會出現(xiàn)專為AI設計的編程語言——不是供人類鍵入，而是供AI作為結構化對象直接操作。RoslynMCP是朝這個方向的早期實驗，基底仍是C#和人類可讀語法，但交互層已完全對象化。

這個判斷有先例支撐。2024年，OpenAI的Swarm框架、Anthropic的Computer Use API，都在嘗試讓AI脫離"生成文本-等待執(zhí)行-解析輸出"的循環(huán)，轉而直接調用結構化接口。編程領域，GitHub Copilot Chat的 `/fix` 命令已部分接入語言服務器協(xié)議（LSP），但仍是文本中心的設計。

RoslynMCP走得更遠：它把編譯器變成了AI的"原生數(shù)據(jù)庫"。查詢不是字符串匹配，是符號解析；編輯不是字符替換，是語法樹變換；調試不是日志閱讀，是運行時狀態(tài)訂閱。

Horokhov沒有公布量化基準，但給出了一個觀察指標：在內(nèi)部測試中，處理同等復雜度的重構任務，走RoslynMCP路徑的Claude平均交互輪數(shù)比文本編輯模式少60%。原因是編譯器承擔了"理解代碼結構"的認知負荷，AI只需決策"做什么"而非"怎么拼"。

工具已上架VS Code Marketplace，搜索"RoslynMCP"可安裝。GitHub倉庫星標數(shù)在公開兩周內(nèi)從0漲至340，Issue區(qū)活躍著C#開發(fā)者提交的Skill需求：WPF代碼生成、Entity Framework遷移腳本、xUnit測試模板。

有個細節(jié)值得玩味：Horokhov在README里埋了句自嘲——"這玩意兒可能明天就被官方團隊收編，也可能因為Roslyn API變動而崩掉。但至少現(xiàn)在，AI終于不用數(shù)括號了。"

如果編譯器接口成為AI編程的標配，人類程序員的角色會變成什么？是更高層的設計者，還是調試AI生成代碼的"語法樹審計員"？