你的内部框架是一种低资源语言

让编程智能体（coding agent）构建一个 React 组件，它第一次尝试就能写出地道的、基于 Hook 的、带有无障碍标注的代码。让同一个智能体使用你公司的内部 ORM —— 那个平台团队维护了六年、拥有出色文档和上百个内部用户的框架 —— 它就会幻觉出不存在的方法，从其他库里发明配置选项，并自信地交付出基于它臆造的 API 编写的代码，而这些代码根本无法通过编译。

这种差异并非源于质量。你的 ORM 可能比模型能完美处理的一半开源库设计得都要好。差异在于训练数据。React 背后有数百万个公开仓库；而你的框架则一个都没有。在自然语言处理（NLP）的术语中，你的内部框架是一种低资源语言（low-resource language） —— NLP 研究人员针对低资源语言记录的每一个后果，现在都适用于你的代码库。

能力悬崖是可衡量的

高资源目标和低资源目标之间的差距并非一种玄学；它是代码生成研究中最稳定复现的结果之一。在 MultiPL-E 基准测试（将相同问题翻译成不同语言进行测试）中，那些能轻松解决 Python 问题的模型，在公开语料库稀薄的语言上表现会大幅崩溃：CodeLlama-34B 在 Racket 题目上的通过率仅为 16% 左右，而 Lua 为 38% 左右，Python 的通过率则高得多。McEval 多语言评估在 40 种语言中也发现了同样的规律 —— 性能取决于语料库的大小，而非语言本身的难度。

关键的洞察在于，这条曲线并不会停留在公开语言上。它会继续下滑，而你的内部框架就处于曲线终点之外。Racket 至少还有教科书、Stack Exchange 上的问答和数千个公开仓库。你的内部 RPC 层只有内部 Wiki 页面和大家口口相传的经验。

从模型的角度来看，你是在要求它编写一种它从未见过的语言 —— 与此同时，它对邻近公开库的熟练程度反而会对你产生负面影响，因为它会用它所知道的最接近的模式来填补空白。这就是为什么你的 ORM 幻觉出的方法看起来异常像 SQLAlchemy：模型并不是在随机瞎猜，它是在用高资源的“邻居”进行替代。

最近关于特定项目代码补全的研究精准地界定了这种失败：当模型缺乏内部 API、命名约定和项目风格的知识时，它并不会平稳降级 —— 而是会生成看起来合理、却违反约定的代码，迫使评审人员逐行检查。这种“看似合理但错误”是代码评审中最昂贵的失败模式，因为它很容易混过粗略的浏览。

马太效应随每个模型版本发布而加剧

研究 AI 编程助手“马太效应（Matthew Effect）”的研究人员记录了这种反馈循环：流行的技术获得更好的 AI 支持，更好的 AI 支持推动更多的采用，更多的采用产生更多的公开代码，而下一代模型则在更向既得利益者倾斜的语料库上进行训练。每一次训练运行都让“富者愈富”。

你可以实时观察到这个循环的运行。给六个不同的顶尖模型一个模糊的“帮我构建一个 Web 应用”的提示，它们会收敛到几乎相同的技术栈 —— React、TypeScript、Tailwind、shadcn/ui —— 这并不是因为委员会决定了什么，而是因为那是训练数据的聚集地。Tailwind 的原子化类是可预测的原子令牌，不需要跨文件协作。shadcn 以纯源码形式交付组件，模型可以读取并重新生成，而不是需要记忆的模糊 API。这些属性对语言模型来说非常重要，而对人类来说则从未如此重要，拥有这些属性的技术栈正在拉开差距。

对于你的内部框架来说，这个循环是反向运行的。每过一个季度，模型对公开栈的熟练程度与对你内部栈的熟练程度之间的差距就会扩大。你的平台团队改进了框架，模型毫无察觉。与此同时，你的工程师们看到智能体能一次性搞定 React 功能，却在内部代码上跌跌撞撞，便开始默默地倾向于选择智能体能派上用场的路径。现在，框架的实际拥有成本中增加了一个三年前还不存在的条目：AI 辅助惩罚（AI-assistance penalty）。

在弥补差距之前，先衡量悬崖

大多数团队只是通过轶闻来感受这种差距 —— “智能体不擅长处理我们的东西” —— 这使得确定优先级变得不可能。请像对待任何其他工程指标一样对待它。方法很简单：

加载中…