微软工程师把AI编程效率拉高47%：让编译器当翻译

让AI读源码、数括号来改代码，就像给建筑师一张建筑照片而非蓝图——明明有完整结构图，却非要AI自己猜哪堵墙承重。

这是Yaroslav Horokhov在GitHub上的原话。他做了套工具，让Claude直接操作Roslyn编译器的结构化模型，而非 raw text。效果：AI找类、改方法、下断点，全部走编译器语义层，响应速度比文本编辑快一截。

文本编辑的荒谬：AI在"看图说话"

Horokhov的类比很毒：现有AI编程工具（包括Cursor、GitHub Copilot的某些模式）本质是让大模型当 OCR——读文件、猜结构、拼字符串。编译器加载项目时早已生成完整抽象语法树（AST，Abstract Syntax Tree），包含每个字段的类型、每个方法的签名、每个继承关系的指向。

但AI接触不到这些。它拿到的是 `.cs` 文件的字符流，靠训练时学到的C#语法规律来推断"这里该加个括号"。

Horokhov算了笔账：一个中等规模的解决方案，Roslyn加载后索引全部符号仅需数秒。AI通过他的工具查询任意类，延迟在毫秒级。而走文本路径，大模型需要逐文件读取、解析、建立心理模型——这个过程对Claude 3.7 Sonnet来说，一个复杂类的理解成本约15-30秒，且容易 hallucinate 继承关系。

他的方案是：让AI用JSON对话编译器，而非用自然语言对话代码文件。

RoslynMCP的运作：三层协议

工具全名 RoslynMCP，基于Model Context Protocol（MCP，模型上下文协议）实现。架构分三层：

第一层，语义索引。Roslyn加载解决方案后，AI可通过类名、接口名、方法名直接定位符号，无需文件路径。查询"谁调用了 `TaskService.AddTask`"，返回的是编译器解析后的调用图，而非文本搜索结果。

第二层，结构化编辑。AI不生成代码字符串，而是发送JSON指令：目标类 `TaskService`，目标方法 `AddTask`，操作类型 `InsertIfBlock`，位置路径 `if[0].else`。Roslyn接收后，在语法树层面插入节点，自动处理缩进、括号匹配、using语句补全。同一响应包还包含编译器诊断：若新代码有类型错误，AI立即收到Error级别反馈，而非等到生成后才发现。

第三层，运行时穿透。通过DTE（Development Tools Environment）API，AI能设置断点、启动调试、单步执行、读取局部变量值。这是静态分析工具（如AST-based linter）无法触及的领域——AI可以看到 `userCount` 在第三循环迭代时的实际数值，而非猜测其可能范围。

Horokhov放出的Demo视频里，Claude用自然语言指令完成了一个典型重构：将同步方法改为异步，自动插入 `async/await` 关键字，更新返回类型为 `Task`，并追溯所有调用方添加 `.Result` 或改为 `await`。全程无人工干预，编译器保证语法正确性。

Skills系统：给AI写"操作手册"

工具的另一设计是Skills（技能）机制。Horokhov认为，AI需要像人类一样"先读说明书再上手"。每个Skill定义了Roslyn工具的正确使用方式：参数格式、执行流程、异常处理策略。

例如 `RefactorToAsync` Skill包含：检查方法是否已标记async、识别所有阻塞调用（如 `File.ReadAllText`）、生成等效异步版本（`File.ReadAllTextAsync`）、处理调用链上游的兼容性。Skill用YAML描述，存于项目目录的 `.claude/skills/` 下，Claude Code自动加载。

GitHub仓库已开源12个基础Skill，覆盖常见重构场景。Horokhov在VS Code扩展中内置了同款Skill集，供Claude Chat面板调用。

这套机制解决了大模型工具调用的核心痛点：幻觉。未经约束的AI可能编造不存在的Roslyn API参数，或在错误上下文调用工具。Skill相当于强制类型检查——Claude必须按Schema填充参数，否则请求被拒绝。

语言设计的转向：为AI造语法

Horokhov在文末抛了个判断：未来会出现专为AI设计的编程语言——不是供人类键入，而是供AI作为结构化对象直接操作。RoslynMCP是朝这个方向的早期实验，基底仍是C#和人类可读语法，但交互层已完全对象化。

这个判断有先例支撑。2024年，OpenAI的Swarm框架、Anthropic的Computer Use API，都在尝试让AI脱离"生成文本-等待执行-解析输出"的循环，转而直接调用结构化接口。编程领域，GitHub Copilot Chat的 `/fix` 命令已部分接入语言服务器协议（LSP），但仍是文本中心的设计。

RoslynMCP走得更远：它把编译器变成了AI的"原生数据库"。查询不是字符串匹配，是符号解析；编辑不是字符替换，是语法树变换；调试不是日志阅读，是运行时状态订阅。

Horokhov没有公布量化基准，但给出了一个观察指标：在内部测试中，处理同等复杂度的重构任务，走RoslynMCP路径的Claude平均交互轮数比文本编辑模式少60%。原因是编译器承担了"理解代码结构"的认知负荷，AI只需决策"做什么"而非"怎么拼"。

工具已上架VS Code Marketplace，搜索"RoslynMCP"可安装。GitHub仓库星标数在公开两周内从0涨至340，Issue区活跃着C#开发者提交的Skill需求：WPF代码生成、Entity Framework迁移脚本、xUnit测试模板。

有个细节值得玩味：Horokhov在README里埋了句自嘲——"这玩意儿可能明天就被官方团队收编，也可能因为Roslyn API变动而崩掉。但至少现在，AI终于不用数括号了。"

如果编译器接口成为AI编程的标配，人类程序员的角色会变成什么？是更高层的设计者，还是调试AI生成代码的"语法树审计员"？