一个团队拿到还不错的基座模型，手头有一批业务问答和标注样本，第一反应常是：要不要做模型微调？这个念头很自然，因为微调听起来像把通用能力往具体任务上拧一拧。但真正开始后，麻烦往往不在训练脚本，而在前面那些没想清楚的问题。
先看问题是否稳定
如果业务问题每天都在变，今天要摘要，明天要分类，后天又要多轮追问，模型微调很容易变成追着需求跑。它更适合相对稳定的输入输出关系：同类任务反复出现，格式和判断标准比较明确，团队也能持续维护样本。反过来，规则还没定、答案依赖频繁更新的外部信息，先做检索或提示词约束，通常更轻。
数据不是越多越好，而是要能解释
准备样本时，最容易出现的情况是“有答案，但说不清为什么”。这样的数据进到训练里，模型学到的可能是标注者的口头习惯，而不是任务本身。更稳妥的做法，是先把样本分成几类：边界清楚的、模棱两可的、明显错误的。前两类决定模型能学到什么，后一类要尽早剔除。模型微调不是数据清洗的替代品，它会把数据里的偏差一并放大。
评估集要像刹车，不是装饰
训练损失下降，并不自动等于业务变好。需要留出一部分不参与训练的样本，最好还能覆盖真实使用中的长尾表达。评估时别只看整体准确率，也要看错误集中在哪：是把否定句看反了，还是对格式要求不敏感。没有评估集的模型微调，很像闭着眼调方向，训练越久越难判断该停在哪里。
还有一个常被忽略的边界：有些问题不该靠微调解决。需要实时变化的知识、严格的权限控制、复杂的多步工具调用，往往要在系统层面处理。模型微调能改变表达风格和任务适配，却不能替代数据治理、权限设计和流程约束。把它放回工程系统里看，期望会更实际。
小步验证，比一次做大更可靠
如果决定尝试，可以先选一个边界清楚的任务，用少量高质量样本跑一轮，观察模型在固定评估集上的变化，再决定是否扩大。记录训练前后同一批问题的回答差异，比只看一个总分更有信息量。团队也要预留回退方案：新版本不合适时，能迅速切回原来的调用方式。
微调真正考验的，不是会不会写训练代码，而是能不能把任务、数据和评估说清楚。它有用，但不是所有问题的起点。先承认这一点，后面的选择反而会清楚很多。