微调还是写提示词？一个能省下三个月工期的决策框架

📅 2026/4/26 ✍️ 小文 📖 约 1 分钟

微调被过度使用，也被过度恐惧。本文给出「稳定性—数据量—更新频率—成本」四维判断法，附五个真实场景的结论，以及混合方案（提示词 + 小样本微调 + RAG）的分工方式。

“我们要不要微调一个模型？”

这个问题在 2026 年依然每周被问一次。答案通常不是”要”或”不要”，而是”你要解决的是哪类问题”。

一、先分清两类问题

所有”模型表现不好”的情况，最后都归到两类：

A 类：模型不知道。 缺领域知识、缺公司内部信息、缺最新事实。微调几乎帮不上忙，因为微调擅长改变”行为方式”，不擅长注入”事实储备”。

B 类：模型不照做。 知道该怎么做，但输出格式不对、语气不对、总是多写一段、总是不调用指定工具。微调和提示词都能改善，选择取决于稳定性和成本。

最常见的错误是用微调去解 A 类问题。 花两个月构造 5000 条问答样本，训出来的模型记错得更自信了——因为它学会的是问答的句式，不是知识。

按顺序问四个问题，每一步都可能直接给出答案：

如果规则能用 10 条以内的自然语言描述清楚（“输出必须是一个 JSON，字段固定为 a/b/c”），先写提示词。写不出来、或者写出来要 3000 字还互相冲突，才考虑微调。

提示词写不清，往往说明业务规则本身没定清楚。 这时微调只是把混乱固化进权重。

微调的下限是 500–1000 条分布真实的样本。注意是真实分布，不是精心构造的漂亮例子。

一个实用的判断：你手上有没有至少 1000 条真实用户输入和人工确认过的正确输出？没有就别谈微调，先建数据回流。

微调模型的规则更新周期通常是周级到月级（重新标注、训练、评测、上线）。如果你的业务从提出改到上线要求 24 小时，这条路是堵死的。

微调最大的隐性收益是提示词变短：把 2000 字的格式说明、few-shot 示例、风格指南塞进权重，每次调用省下大量输入 token。

粗算：如果每次调用能省 1500 input token，日调用 10 万次，单价 3 元/百万 token，一年省下约 1.6 万元。加上训练与评测的人力成本（通常几万到几十万），只有调用量足够大、运行足够久，这笔账才算得过来。

如果调用量小，微调的经济理由几乎不存在——你只是花钱买了一点格式稳定性。

在”微调 or 提示词”之外，还有一项常被跳过的工作：改进输送给模型的上下文本身。

在决定微调前，先确认以下四件事是否已经做到：

很多团队微调之后发现提升有限，回头一看是提示词里有三条互相冲突的规则。

成熟团队的做法通常是三层分工：

一句话概括：提示词管”这次要什么”，检索管”事实是什么”，微调管”一贯怎么做”。

如果决定走微调，先确认：

第三条最常被忽略，但在实际项目里救过很多次命：微调模型在长尾输入上的退化，往往只有上线才暴露。

微调不是升级版提示词，它是把规则固化进模型的一次性投资。投资前先问：规则会不会变？样本够不够？省下的钱回不回本？