微调和提示词工程怎么选？改模型还是改问法

大模型答不好时，第一反应是加提示词还是动微调？微调和提示词工程怎么选，经验顺序很固定：先问能不能靠说法解决，不行再考虑改模型。两条路都有效，但成本结构和适用场景差得很远，顺序搞反了会白烧很多工时。

结论先说：先试问法再谈改模型

提示词工程改的是输入，微调改的是参数。改输入的成本是几分钟到几小时，改参数的成本是几天到几周。在这个差距面前，默认策略应该是先把提示词磨到极限：要求写清楚、例子给足、格式指定死，多数日常问题到这一步已经解决。

什么时候提示词真的不够？三类信号：同类错误反复出现，加例子也纠不过来；输出格式总是不稳，换个问法就变形；同样的要求每次都要在提示词里长篇重申。专属测试集上如果这些场景稳定失败，才是微调登场的时机。

两条路径各改变了什么

提示词工程不改变模型本身，它改变的是模型的输入分布。你把任务说清楚、把格式演示出来，模型按上下文里的线索组织输出。它的天花板在于上下文长度和模型的指令理解能力，超长、极复杂的任务，提示词会鞭长莫及。复杂任务还要在提示词里做任务分解，把大问题拆成小问题依次问，这本身就是一门工程。

微调改变的是模型的默认行为。训练数据里的模式被固化进参数，模型不用每次被提醒就按那套方式工作。它的天花板在于数据质量和训练方法，数据覆盖不到的场景，微调一样无能为力。文心一言和通义千问对外提供的定制能力，本质都是把后者产品化。

成本结构与见效速度

提示词的成本几乎全在人工打磨上，没有算力门槛，改完立刻生效，回滚也只是一句话的事。微调的成本是三段的：数据准备最贵，训练要算力，评估和迭代要反复循环。一次微调的完整周期，够把提示词迭代十几个版本。

两条路改的东西、花的时间和天花板，放在一起看。

见效速度还体现在协作上。提示词方案谁都能改，运营、产品、工程师都能上手，改完发版即生效。微调方案要排队等训练资源，一次实验周期里，业务需求可能都变了两轮。LoRA 的秩怎么取这类参数决策，也得等数据就绪之后才有意义。

什么信号说明该换路线

从提示词转向微调的信号：提示词长度逼近上下文上限；同样的约束需要在每次对话里重复；错误模式高度一致，说明模型缺的是内化而非说明。满足两条以上，就可以启动微调的可行性评估，先做数据盘点再谈训练。

反过来，从微调退回提示词的信号也存在：微调后效果不稳定，换个问法就崩，说明数据覆盖不足；或者任务本身变化太快，模型还没训完需求就改了。微调与 RAG 的路线也要在这个决策点一起评估，三条路的成本差着量级。最终拍板前，用同一份续训与微调的判断检查目标是否匹配。

两条路也不是非此即彼。成熟做法是提示词打底、微调加固、提示词收尾：日常用提示词控场，把稳定重复的要求沉到微调里，再用简短的提示词处理长尾。这样既控制了成本，又保住了复杂任务的灵活性，回滚时也只需要回退一层。

自查清单：同类错误是否反复出现；格式是否总不稳；要求是否每次都要重申。中两条以上，再启动微调评估。先问说法，再动参数。

关于微调与提示词，问得最多的三个

• 提示词写得好还有必要微调吗？有，追求稳定性和省 token 时微调更划算，内化的习惯不用每次重申。
• 微调后提示词就随便写行吗？不行，微调改变默认行为，复杂任务仍需清晰指令，只是可以短一些。
• 先微调再补提示词还是相反？多数情况先提示词摸清需求，摸清了再微调，数据定义会更准，顺序反了容易白忙。