设想一个做企业服务的团队：基础模型回答专业问题尚可，但生成的客服回复总像内部通知，句子长、礼貌过度，用户读两句就走神。他们想到模型微调，把历史工单和经过确认的回复放进去，期待模型“学会说话”。
这个思路有合理处，但容易把问题想简单。模型微调改变的主要不是知识储备，而是输出习惯：语气、格式、步骤、拒答边界、对指令的遵循方式。它像给模型做岗位培训，不是往模型里塞一本新手册。产品价格、政策条款刚更新时，先看检索增强或提示词约束，往往能解决事实同步；只有表达习惯和稳定结构反复出问题，才值得认真准备训练。
先分清：缺的是知识，还是习惯
把需求拆开，判断会清楚很多。事实更新可以接入外部知识源；流程约束可以用系统提示、工具调用和输出校验；风格模仿、固定字段、稳定分类这类“每次都要照同样方式说”的需求，才接近微调的使用场景。若知识频繁变化，用微调去追更新，维护成本会落在数据上。
数据决定它学到什么，也决定它学偏什么
模型微调的数据不在多，而在边界清楚。只放标准答案，模型可能学会一种腔调，却不知道什么时候不该这么说。准备数据时，正例之外要留失败样本、拒答样本和格式异常样本；历史聊天记录未经审核不要直接投喂，标注口径也要统一。少量高质量样本，评估口径容易保持清楚。
评估不能只看“像不像”
微调后的模型可能更像目标语气，同时在其他任务上变得迟钝。评估时除了看风格，还要看旧能力有没有退化、拒答是否合理、长尾输入会不会崩、格式是否稳定。小流量对照和人工复核不能省。模型微调不是一次训练就结束，版本、数据来源和回退路径都要留痕。
所以，面对“模型不听话”的问题，不妨先问：它缺的是新知识，还是缺一套被反复验证过的表达习惯？前者先接知识源，后者再考虑训练。训练前用一小批失败样本做小规模对照，常常能暴露真正的问题，也能避免把数据工程做成一场昂贵的猜测。