谷歌工程师用1个语法树，把3种祖传代码喂给了AI

当你的AI代理同时看到Thrift、Protobuf和Excel三份"同义词表"，它会做什么？

它会把"用户ID"翻译成三个不同的变量名，然后自信满满地写出一份编译都过不了的缝合怪代码。这不是AI不够聪明，是你没给它一张能看懂所有方言的地图。

01 | 一个让CTO失眠的问题：迁移还是等死？

某游戏公司的技术负责人曾算过一笔账：后端200万行Thrift代码，客户端150万行Protobuf，策划表格3000张Excel。如果统一成一种接口描述语言（IDL），需要18个月，期间所有新功能停摆。

「我们试过三次，」他在技术沙龙里吐槽，「每次开会都说'这次来真的'，三个月后回滚，因为客户端和后端永远不可能同时准备好。」

这种困境的残酷之处在于：不是技术做不到，是组织做不到。就像让一栋楼的住户同时搬家——理论上可行，实际上会演变成谁先谁后的政治斗争。

AI代理的崛起让这个问题更尖锐了。Cursor、Windsurf这些工具承诺"理解你的代码库"，但当代码库本身就是一座巴别塔时，AI的理解力反而成了破坏力。它会交叉引用三个不同来源的"Item"定义，生成一份看似合理、实则灾难的代码。

Semantic modeling项目的起点，正是这个绝望的问题。团队没有选"推倒重建"或"维持现状"任何一个选项，而是造了一个翻译中枢：Unified AST（统一抽象语法树）Hub。

这个设计的狡猾之处在于：它承认碎片化的合法性，然后给碎片化发护照。

02 | 语法树作为"元认知层"：AI和人类终于说同一种黑话

传统思路是把所有IDL转成某种"标准格式"，比如全迁到Protobuf。这相当于强迫北京人、上海人、广东人全说普通话——技术上可行，社交上自杀。

Unified AST的做法更像个联合国：每种IDL保留自己的"外交身份"，但在中央枢纽获得平等代表权。

具体实现上，编译器为每种IDL配备独立解析器。Protobuf的field number、Thrift的optional标记、Excel的列类型，这些"方言特征"被完整提取，而非粗暴抹平。最终汇入一个统一的图结构，节点之间标注语义等价关系。

代码层面，这体现为一种"包裹语法"：

// ai_context.deuk

// 1. 原封不动引入祖传Protobuf

include "legacy/item_base.proto"

// 2. 给它贴个AI能看懂的元标签

table = { key: "item_id" }

第二行是关键。它没有修改.proto文件，而是声明了一个"认知意图"：这个Protobuf消息，在业务语义上等价于一张以item_id为主键的表。人类读得懂，AI代理也读得懂——而且两者读的是同一份声明。

「meta-cognitive intent（元认知意图）」这个术语听起来唬人，实际就是个双语文本框。就像给祖传代码配了个同声传译：左边是Thrift方言，右边是AI能处理的语义图，中间没有信息损耗。

03 | 0.1%扰动承诺：为什么这次迁移不会烂尾

技术迁移项目的死亡率，往往和"改动范围"成正比。Unified AST的设计刻意压缩了这个范围。

现有.proto和.thrift文件零修改——这是硬性约束。团队甚至不允许为了"适配新系统"而重命名一个字段。所有语义标注通过外部.deuk文件完成，像给古籍做批注，而非改写古籍本身。

这种保守主义的收益是即时的。一个中等规模的游戏项目，可以在一周内完成语义层搭建，而不触碰任何运行中的服务。AI代理第二天就能拿到一份统一的上下文：它现在知道，Thrift里的UserProfile、Protobuf里的PlayerData、Excel里的角色基础信息，指向的是同一个业务实体。

输出端的灵活性同样激进。Unified AST作为中央枢纽，可以向任意方向生成代码：C#供Unity客户端、TypeScript供Web端、Python供数据分析。每种生成器只看到经过验证的语义图，无需关心源头是Thrift还是Protobuf。

「我们内部叫它'语法树瑞士'，」项目成员在文档里写道，「永久中立，但所有人都得经过它。」

04 | 从文本解析到语义证明：AI需要的不是更多数据，是更少歧义

早期的AI代码助手依赖向量检索：把代码库切成片段，按相似度喂给大模型。这在单一技术栈里勉强能用，跨IDL场景下彻底失效——"Item"在三个文件里出现，向量空间里的距离却告诉AI它们是三个无关概念。

Unified AST提供的是证明，而非猜测。context resolver（上下文解析器）会显式标注：节点A（Protobuf/Item）≡ 节点B（Thrift/ItemStruct）≡ 节点C（Excel/道具基础信息）。这种等价关系是可验证的，而非统计意义上的"可能相关"。

对AI代理而言，这改变了游戏规则。它不再需要在三个命名空间里做模糊匹配，而是面对一张已经消歧的语义图。生成代码时，它能确定自己引用的"Item"在整个系统中有唯一、一致的解释。

这种确定性直接转化为可靠性。测试数据显示，在跨IDL场景下，AI生成代码的编译通过率从34%提升至89%。剩下的11%通常是业务逻辑错误，而非类型不匹配——这已经属于"人类该管"的范畴。

05 | 遗留系统的AI化：一场关于尊重的技术伦理

技术圈有个隐秘的偏见：新工具总想证明自己比旧工具优越，进而暗示旧工具的用户"落后了"。Unified AST的设计哲学相反——它把遗留代码视为需要被理解的"他者"，而非需要被拯救的"落后者"。

这种姿态有实际好处。当Thrift文件被标记为External Dialect（外部方言）而非"待淘汰格式"时，维护它的后端团队更愿意配合。没有人在被贬低的状态下积极协作。

更深层的意义在于：它承认了技术债务的复杂性。那些"祖传代码"之所以存活至今，往往因为它们承载着无法被轻易提取的业务知识。Unified AST不做考古学家，不做拆迁队，它做档案管理员——给每份文档建立索引，让需要的人能快速找到关联。

项目文档里有个细节：编译器会保留原始IDL的注释位置。如果某个Protobuf字段的注释写着"别动，2018年的坑"，这个警告会原样出现在Unified AST的元数据中，最终传递给AI代理。

AI不会理解"2018年的坑"是什么意思，但它会知道这里有个需要人类判断的标记。这种谦卑——承认有些信息机器处理不了——反而是系统可靠性的来源。

目前，这套架构已在3个中大型游戏项目中落地。最激进的案例里，团队用Unified AST同时协调了5种IDL格式，包括一份2007年的自定义二进制协议。AI代理最终生成的客户端代码，首次实现了与这份古董协议的无差错对接。

那位CTO后来反馈，他们评估了18个月的迁移计划，现在被压缩到了6周——而且没有人需要学习新语法。唯一的问题是：当AI突然能看懂所有祖传代码时，那些专门负责"翻译"不同团队需求的架构师，接下来该干什么？