prompt 工程和微调的区别

刚上手做应用的人常在这卡住：效果不好，到底是提示词没写对，还是该去微调？很多人跳过调提示词直接买卡训练，钱花了效果还不如改几行 system 提示。这篇不给你结论式答案，只给一套判断顺序：先看问题属于哪一类、再看数据和算力条件是否满足、最后才是动手。

刚上手做应用的人常卡在同一个地方：效果不好，到底是提示词没写对，还是该去微调？很多人跳过调提示词，直接买卡开训，钱花了一轮，效果还不如改几行 system 提示。这篇不给结论式答案，只给一套判断顺序：先看问题属于哪一类，再看数据和算力条件够不够，最后才是动手。整套顺序的目标是让你花最少的力气定位问题，而不是一上来就选最重的方案。

下面会先把两条路各自改什么、适合什么讲清，再给一张对照表和一套从提示词到微调的判断顺序，最后补上成本、数据合规和上线验证的检查项。所有涉及数字的地方都会指向站内页面，你看的时候数字可能已经变了，自己去核对最准。

先分清两者改的是什么

提示词工程改的是输入，模型权重一动不动，改完立刻生效、随时回退，试错成本几乎可以忽略；微调改的是权重本身，要经过数据准备、训练、合并、部署一整条链路才能上线，中间任何一步出问题都要回头重做。这两条路不是替代关系，是先后关系，弄清楚这一点，后面所有判断都会顺很多。

提示词工程

在输入侧下功夫，用 system 提示、few-shot 例子、格式约束去引导模型行为，模型本身不变

微调

在权重侧下功夫，用自有数据再训练一轮，把某种稳定行为固化进模型里

检索（RAG）

把外部知识在推理时喂给模型，适合知识会变、内容量大的场景，和上面两条不是同一类问题

要特别注意一点：微调不是往模型里塞新知识的常规手段。想让模型知道你的产品文档、内部规章、最新政策，优先看检索那条路。微调真正擅长的是固化某种稳定的行为习惯或领域表达方式，比如固定的输出结构、特定的语气、专业领域的措辞。这三条路的分界，可以对照 /stacks/fine-tuning 里的服务商目录了解落地形态。

什么情况下提示词就够了

任务描述清楚、样本量少、需求还在频繁变——这三个条件只要占一个，就先老老实实调提示词。具体动作是：加 few-shot 例子、把输出格式固定下来、把边界情况和反面例子写进 system 提示。很多人一遇到效果不稳就怀疑模型能力，其实大部分时候是输入侧没交代清楚。

• 判断标准一：你手工给几个例子，模型大部分情况能做对，只是不稳定，那多半是提示词和采样参数的问题
• 判断标准二：同一类错误在不同写法下表现不一样，说明输入侧能影响结果，值得继续调
• 判断标准三：换个更强的模型试一次，如果错误明显收敛，说明当前模型够用，问题在提示词
• 不适用的情况：无论怎么换写法、怎么给例子，模型都在同一类 case 上系统性出错，那问题不在输入侧

什么情况下才轮到微调

微调值得考虑的前提是四条同时成立：任务高度重复且调用量大、对输出格式或风格有一致性硬要求、有稳定且标注过的自有数据、调用成本或延迟已经成为实际瓶颈。只满足一两条就上微调，通常是在给自己找麻烦。这四条可以当成一张门槛表，缺一条就先别动。

数据规模别凭感觉，先在站内按你的任务类型和模型规模估一遍，参考 /stacks/fine-tuning 与 /models/deploy 的口径。数据不够就用提示词先顶。反过来，一次性任务、长尾需求、数据没法持续维护的场景，都不适合微调——微调后的模型很快会过期，维护成本会高于收益。

一套能照着走的判断顺序

下面这套顺序建议按部就班走，每一步做完留个记录，别凭感觉跳到下一步。跳步最常见的后果是：你在微调阶段发现其实是提示词问题，但数据已经标了一半，骑虎难下。

1. 重写三遍提示词把同一个失败案例的 prompt 用三种不同写法重写，看错误是否收敛。收敛说明输入侧能影响结果，继续调提示词。
2. 补例子或换模型加 few-shot 例子，或换一个更擅长该类任务的模型试一遍，对比错误率变化。这一步是为了排除模型能力问题。
3. 确认问题类型判断是行为问题还是知识问题。行为问题看微调，知识问题看检索，两者别混在一起解决。
4. 检查数据条件确认有没有几百条以上干净、可复现的标注数据，训练集和验证集要能分开。数据不够就回到上一步。
5. 走微调并留验证集数据够、任务稳定，再进微调流程，同时预留验证集做前后对比，别用训练集自评。

每一步的验收标准可以事先写下来，比如「重写三遍后同类错误下降才算通过」。具体数字口径到 /usage 和 /tools/model-cost-calculator 按当时的数据算，别用记忆里的旧数字做判断。

成本账要按几条线分开算

提示词的成本是 token 消耗加上人工调优时间，随调用量线性增长；微调的成本是数据标注、一次训练、后续每次重训，以及可能更高的部署门槛。很多人只比单次调用单价，忽略了维护频率，结果微调版在模型换代或业务口径变化时要重跑一轮，提示词版改几行就完事。

具体单价和租卡行情随时在变，到 /official-api 和 /compute/price-index 看当时的数字，再套进 /tools/model-cost-calculator 算总账。算的时候把维护频率也折算进去，只看单次调用价容易得出反直觉的结论。

数据和合规上的坑

微调数据要能覆盖线上真实分布，否则模型只会背你给的那点样本，换个说法就懵。训练集和验证集必须分开，否则效果评估没有意义。这两条是最常被忽略、又最容易毁掉整个项目的地方。

• 数据分布：标注样本要尽量贴近线上真实输入，包括那些看起来不规范的问法
• 数据切分：训练集、验证集严格分开，验证集不参与任何训练或调参
• 数据留存：涉及用户数据、合同文本、医疗法律内容的，先确认授权范围和留存要求
• 模型许可：部分权重对商用或蒸馏有限制，别等上线才发现不能用

合规这块参考 /safety 与 /ai-dict/category/safety 的说法，站内对常见风险点有整理。如果业务本身属于强监管领域，建议在微调前先走一遍内部法务或合规确认，别把技术验证和合规确认混在一起做。

上线后怎么验证有没有变好

固定一批真实失败案例当回归集，提示词版和微调版跑同一套，人工或规则打分对比，别看单条示例就下结论。回归集要从线上真实 case 里挑，别只用自己造的测试样本，否则上线后容易翻车。

如果微调版在回归集上没有明显优势，果断回退到提示词版，别为了沉没成本硬撑。很多时候两者可以并存：提示词负责通用任务，微调版只接特定高频场景，按路由分发，这样风险和收益都更可控。