让编程智能体（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） 。
在弥补差距之前，先衡量悬崖
大多数团队只是通过轶闻来感受这种差距 —— “智能体不擅长处理我们的东西” —— 这使得确定优先级变得不可能。请像对待任何其他工程指标一样对待它。方法很简单：
构建私有评估集。 从你的积压任务历史中挑选 20 到 50 个涉及内部框架的真实任务：添加一个端点、编写一次迁移、接入标准的观测钩子（observability hooks）。将每个任务与经过评审并合并的解决方案配对。针对公开技术栈对照组运行相同任务。 使用相同的模型尝试 vanilla Django 或 Express 中的等效任务，为你提供基准线。两个通过率之间的差值就是你的“能力悬崖”，你可以将这些数字写入规划文档中。对失败进行分类。 幻觉 API、错误的约定、遗漏的必要模板代码、以及微妙的语义错误，每一种都指向不同的修复方案。一个发明方法名的智能体需要上下文中的参考材料；一个跳过你强制性审计日志装饰器的智能体需要明确的规则。 衡量之所以重要，是因为缓解措施是有实际成本的，不同的失败类别对应着不同的投入。它还为你提供了一个回归测试：模型升级会不可预测地移动这个“悬崖”，一个将公开栈性能提高 20% 的新模型，可能对你的内部栈性能提升毫无帮助。
桥接：上下文比你想象的更便宜，微调成本更高 在低资源语言文献中隐藏的一个好消息是，有针对性的干预是有效的，而且最便宜的干预往往能捕获大部分价值。
指令文件是价值最核心的前一百美元。 一个维护良好的 Agent 文件 —— CLAUDE.md、AGENTS.md，或者是你的工具链所读取的任何约定文件 —— 只要说明了你的框架中无法推断出的规则，就能弥合令人惊讶的巨大差距。让这些文件发挥作用的准则是：仅记录模型无法从代码中推断出的内容，使用具体的指令而非模糊的感觉（“每个处理器必须在返回前调用 ctx.audit()” 优于 “注意审计”），并保持文件足够简短，以免淹没关键信号。一条错误或过时的指令比没有指令更糟糕，因为模型会自信地遵循它。
实际示例的效果优于参考文档。 模型在成为文档阅读者之前，首先是模式补全者。在上下文中放置三个完整的、示范性的框架用法 —— 一个规范的端点、一个规范的迁移、一个规范的测试 —— 效果要好过成页的 API 文档。这反映了微调研究的结论：MultiPL-T 的工作表明，为低资源语言生成高质量的训练示例使 Racket 的通过率提升了十多个百分点，而少样本（few-shot）示例正是同一机制的零训练运行版本。
检索弥合了幻觉差距。 Agent 之所以会发明 ORM 方法，是因为真实的签名不在它的上下文中。索引你框架的源码并在生成时检索相关的代码片段 —— 无论是通过 Agent 内置的代码搜索还是显式的 RAG 层 —— 都能用确定性的事实取代模型的“最近公共邻居”式猜测。针对特定项目的补全研究一致表明，检索内部 API 上下文是解决接口幻觉最高杠杆的修复手段。
微调是最后手段，而非首选。 它确实有效 —— 经过 RAG 微调的小型模型在特定代码库上的表现已经可以媲美大得多的通用模型，且推理成本仅为后者的一小部分 —— 但你会因此继承一套训练流水线、一个评估苦活，以及一个每当框架变更时就会过时的模型。大多数团队应该先穷尽上下文工程的手段。例外情况是那些真正高流量、稳定且特有的技术栈：一个每天由数千名工程师处理的专有 DSL 值得你投入精力去维护这套流程。
一个令人不安的问题：你何时停止对抗？ 在战术性修复之下隐藏着一个战略决策，而大多数组织尚未有意识地做出这个决定：在什么情况下，你会选择让你的技术栈顺应模型的训练分布，而不是去弥合差距？
坦诚地说，模型流畅度（fluency）现在已经是一项架构标准，与性能、人才池和生态系统成熟度并列 —— 它值得被赋予同样的权重。某些情况显然倾向于顺应。如果你的内部框架只是一个对公共库 API 进行简单包装的薄封装，那么你正在为了微小的差异化而支付全额的 AI 协作损耗；删除这个封装可能比记录它更划算。如果你正在启动一个新服务，选择那些枯燥、有大量数据代表的技术栈，可以让你在第一天就获得一个可用的 Agent，而无需任何桥接投入。
但全盘顺应也是一个带有自身成本的陷阱。内部框架的存在通常是为了解决训练分布一无所知的问题 —— 你的合规制度、你的多租户模型、你的部署拓扑。为了迎合模型而拆除它们，是用显性的 AI 效率损失去换取隐性的正确性和安全性债。而且训练分布是掌握在别人手中的移动目标：模型今天偏爱的技术栈反映的是 18 个月前的抓取决策，而马太效应意味着今天的选择会在明天产生复利。
一个可行的决策规则是：在边缘顺应，在核心桥接。在你的内部替代方案不承担核心功能的地方 —— 如样式、脚手架、测试结构、胶水代码 —— 让模型首选的惯用法获胜。对于编码了真实组织约束的框架，投入资源进行桥接（指令、示例、检索）。而对于任何新事物，要求对偏离高资源技术栈的行为提供书面理由，就像你要求引入新数据库的理由一样。
你平台团队的路线图也应反映这种转变。2026 年最高杠杆的框架工作可能不是一个新特性 —— 而是让框架对 Agent 可读：在包中附带 Agent 文件，在代码搜索工具索引的仓库中发布实际示例，并设计形状足够可预测的 API，以便模式补全者能够猜对它们。框架过去竞争的是人类的心智占有率。现在它们也在竞争模型的心智占有率，而忽视第二场竞争的框架将会输掉第一场。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
