在不少团队里，模型微调很容易变成一句口头需求：效果不够好，那就微调一下。听起来像给模型打补丁，实际问题常常不在模型，而在我们还没说清楚什么叫“好”。是回答短一点，还是愿意追问？是格式稳定，还是遇到不确定时敢于拒答？这些标准不写下来，训练样本就会替我们做决定。
先给“好”下一份笨定义
需求里常出现“专业”“自然”“像人”这类词，对人有感觉，对训练却太滑。可操作的做法，是把目标拆成可观察的行为：固定输出结构、减少无关扩写、在缺少条件时先追问、把步骤说清楚。每条都配正例和反例。只收理想答案，模型容易学会在相似问题上自信地给漂亮话；把边界样本放进去，它才知道什么时候该停。
这也是微调真正起作用的地方：它改变的是模型在特定任务上的行为倾向，不是把一整套业务知识塞进参数里。把它当数据库更新，往往失望；把它当应答习惯的校准，预期才不至于悬空。
数据不是堆出来的，评估也不能靠感觉
准备样本时，数量是一个维度，覆盖决定边界是否被看到。一个任务里真正难的是边角情况：用户表达含糊、输入格式不统一、问题超出范围。样本如果只来自顺利路径，上线后遇到异常输入，模型仍可能露怯。另一个常被忽略的环节是评估。至少留出一批不参与训练的样本，按事先写好的标准看结果，而不是每次凭印象说“这次好像顺一点”。评估标准可以朴素，但要稳定；否则调来调去，只是把问题挪到了看不见的地方。
真正有效的模型微调，往往从缩小问题开始。不是“让模型变聪明”，而是“让它在某个流程里少犯某类错”。目标越窄，样本越容易对齐，评估也越能落地。反过来，如果连错误类型都说不清，微调很可能只是把模糊需求包装成一次训练。
它不负责所有事
有些问题可以先从流程入手。知识频繁更新、需要引用来源、答案依赖外部文档时，检索增强通常可以先考虑；提示词能解决的格式约束，也未必需要训练。它像最后几公里的工艺：任务稳定、样本可控、评估清晰，它才有发挥空间。样本很少时，可以先检查提示词、输入结构和人工复核，不必急着训练。训练数据里的偏差还会被模型学走，上线后也需要持续观察分布变化。
所以，模型微调不是不能做，而是要知道它改的是什么。它改不了含糊的目标，也替代不了清晰的验收。下一次有人提“微调一下”，不妨先问那个很土的问题：谁在定义“好”，我们准备拿什么样本和标准证明它变好了。答得上来，再谈训练也不迟。