当微调不再是默认答案

很长一段时间里，做一个垂直 AI 应用的标准动作是微调：准备数据、训练一个版本、跑评测，再把它部署起来。模型答得不好，先想到的也是再补一批数据。

2026 年 5 月，Latent Space 用一句很重的标题概括正在发生的变化：The End of Finetuning。 起因是 OpenAI 收缩微调服务，但真正值得看的不是一个接口的去留，而是越来越多应用开始绕过“改模型”这条路。

有时要改的不是树，而是它每次醒来看到的花园。

模型不会，还是模型没拿到

一个客服 Agent 不知道刚更新的退款规则，微调当然能让它记住。但规则下个月又变了，训练出来的记忆立刻过期。把规则放进可检索的知识库，回答前现查，更新只需要替换一份文档。

一个编程 Agent 总忘记项目的目录约定，也不一定需要训练。把约定写进项目规则，在会话启动时加载，成本更低，错了也能直接改。

这里其实混着三类问题：

• 知识缺失：用检索和上下文补。
• 能力缺失：给工具、示例或更强的模型。
• 行为偏差：稳定且反复出现时，才考虑微调或强化学习。

微调过去经常同时承担这三件事。现在模型的基础能力更强，窗口更长，工具调用也更可靠，把问题拆开以后，真正需要改权重的部分变少了。

很长的提示词不是廉价微调

另一种极端是把所有东西都塞进提示词。产品说明、历史对话、代码规范、几十个工具描述一起送进去，看起来省掉了训练，实际把维护成本转移到了上下文。

模型每次都要重新读，规则之间还会争夺注意力。内容越多，不等于相关信息越多。上下文工程真正处理的是选择：这一刻该让模型看到什么，哪些东西应该暂时留在门外。

微调把经验写进权重，长上下文把经验摊在桌面。前者不容易更新，后者容易变乱。二者都不是免费的。

顶尖应用为什么还在训练

“微调结束了”只适用于大多数并不需要自有模型的应用。Cursor、Cognition 这类把模型行为直接做成核心产品的团队，反而还在增加针对开放模型的训练和强化学习。

差别在于回报能不能覆盖成本。

如果只是让模型知道一份业务手册，改权重太重。如果产品每天重复同一种高价值动作，错误模式稳定、反馈可量化，训练带来的每一点提升都会被调用次数放大，账就可能算得过来。

这个花园的文章规范也一样。标题口吻、标签数量、结尾怎么收，都能写成模型每次会读的规则，没有理由为此训练一个模型。真正有价值的是把改稿中反复出现的问题固化进下一轮，而不是把整个花园压进一组权重里。

原始材料：The End of Finetuning。

先判断缺的是知识、工具还是行为，再决定要不要动模型。