三者干的是三件不同的事
一个口诀：任务说清楚靠 prompt，知识靠 RAG，行为靠微调。
prompt 是口头叮嘱，告诉模型这次干什么、按什么格式来，改的是这一次的输入。RAG 是给开卷资料，把模型不知道的知识摆在它面前，改的是信息来源。微调是拿标注数据继续训练，改造模型本身，改的是它的行为习惯：说话的腔调、输出的格式、对行话的理解。
混淆这三个是新手最常犯的错。想让模型知道公司新政策，去更新知识库，不是去微调；想让它永远用三句话回答，去微调，别指望 prompt 每次都能压住。
默认顺序：prompt、RAG、微调
按成本从低到高排，也按这个顺序试。prompt 几乎零成本，今天改明天上线，先把这一步榨干。不够再上 RAG，需要工程投入，几周的量级，解决知识问题。还不够，才轮到微调。
给个量级感受一下：prompt 改动以小时计，RAG 搭建以周到一人月计，微调从攒数据到上线以月计，还要留出持续维护的人力。三者差着一两个数量级，所以「先试便宜的」不是保守，是理性。
微调贵在全生命周期：几千条高质量标注数据起步，训练、评测、部署，一套流程下来以月计。而且基座模型每半年左右升级一代，你微调出来的能力，新基座可能自带了，还得重新评估要不要迁移重做。我的估计是，业务需求里九成都到不了微调这一步，被前两步消化掉了。
一个例外：如果第一天就知道调用量巨大且格式极稳定，比如每天百万次的结构化抽取，可以跳过中间步骤，直接评估微调加小模型，账算得过来。
微调真正的适用场景
微调改的是「怎么说话」，不是「知道什么」。真正值回票价的场景有这么几类。
输出格式必须绝对稳定，比如给下游系统喂 JSON，prompt 压不住那百分之几的格式漂移，微调可以。语气风格要千人一面，比如客服话术统一成品牌腔。领域行话理解，医疗病历、法律文书的术语和写法跟通用文本差得远。还有用大模型生成数据去教小模型，把大模型的能力蒸馏到小参数模型上，推理成本能降一个量级。
最后这条是近年很现实的用法：线上流量大，大模型调用费扛不住，就用大模型产标注、小模型上线跑。
反过来说，只要需求里带「知识会更新」四个字，微调就基本出局了。
常见误区
最大的误区是拿微调灌知识。把公司文档塞进训练数据，指望模型「学会」，结果是幻觉照样有，知识更新一次要重训一次，还会把旧知识挤忘掉一部分。知识问题走 RAG，这条路又便宜又可溯源。
第二个误区是低估数据门槛。微调的效果上限是数据质量定的，几百条随手标的脏数据，训出来的是一个更自信的烂模型。第三个误区是以为一劳永逸，微调模型是活的资产，要持续评测和维护。
还有人把微调模型当护城河，这也不成立：同样的数据别人三周就能复刻，壁垒还是数据本身和场景理解，不在那个权重文件上。
现实方案都是组合拳
成熟的 AI 应用很少单用一条路线。拿客服机器人举例：system prompt 定人设和红线，RAG 接商品库和政策库解决知识问题，意图分类这种高频小任务用微调过的小模型来跑，便宜又快。
PM 的活儿就是把需求拆成链路，每一段用最便宜的方案接住。判断依据永远是同一条：这段需求的本质是任务、知识还是行为。每个环节对号入座，方案就出来了，这比背任何选型清单都可靠。
这套拆法还有个附带好处：每个环节独立可换。基座模型换代了，只换生成那一环，知识库和分类模型原地不动，升级成本可控。