从提示词工程到微调：迁移实战手册

你有一个花了数周打磨的系统提示词。它有 2,000 个 token，塞满了示例、边缘情况指令和格式规则。它能用，大部分时候是这样。但它脆弱、昂贵，而且会以各种持续消耗你时间的方式产生不一致的结果。

这是把那个提示词迁移成微调模型的实战手册。这里给出的是一套分步流程，代理商和产品公司的团队用它把成本降低了 60-80%，同时提升了输出一致性。

你已经触到提示词工程天花板的信号

在投入微调之前，先确认你确实到了天花板，而不是提示词本身写得不好。下面是几个具体的判断指标：

你的提示词超过 2,000 个 token。 系统提示词长到这个程度，说明你是在靠指令的绝对数量来编码行为。推理时每个 token 都要花钱，而且提示词越长，模型对指令的注意力就越涣散。如果光是系统提示词就让你每次请求花掉 $0.01-0.03，这已经是结构性问题。

对提示词的小改动会破坏不相关的输出。 你刚修好模型对边缘情况 A 的处理，任务 B 的格式突然就退化了。这说明你的提示词是一座纸牌屋：模型是整体理解指令的，改动某一段会以无法预测的方式和其他段落相互作用。

同样的输入跑出不同的结果。 相同输入、相同提示词、temperature 设为 0，仍有 15-25% 的概率得到明显不同的输出。模型落在了输出空间中的某个区域，注意力上微小的数值差异就会走出不同的路径。这时模型需要的是更强的行为信号，继续加提示词已经解决不了问题。

你在用自然语言编码复杂的条件逻辑。 “如果输入包含日期，就格式化为 ISO 8601，除非它是像‘下周二’这样的相对日期，那就按当前日期换算成绝对日期，但如果输入里还带了时区……”这类逻辑属于代码，或者属于模型学到的行为，而不是系统提示词。

准确率已经见顶。 两周的提示词迭代把准确率从 75% 拉到 82%，再花两周只到了 84%。现在你要耗上一整天，才能再挤出一个百分点。模型手上的信号不足以再往前走。

迁移决策框架

并非每个提示词都值得做成微调模型。这笔账应该这样算：

这个任务每月的 API 成本。 如果单个任务通过 API 每月花费超过 $200（含长系统提示词推高的 token 成本），微调很可能在 2-4 周内回本。一个微调过的 8B 模型跑在单张 GPU 上，每月算力成本大约 $50-150，不需要系统提示词就能处理同样的任务，效果往往还更好。

调用量很重要。 微调有一笔固定的前期成本：准备数据和训练所花的时间。每天 100 次请求，这笔投入几周就能摊平；每天 5 次请求，可能要几个月。低于每天大约 50 次请求，除非一致性对业务至关重要，否则继续用提示词工程。

任务是否足够收窄很重要。 微调最适合范围窄、定义清晰的任务。“把客户邮件分到 12 个类别”是理想的候选，“做一个什么都能干的通用助手”则不适合。如果你的提示词只覆盖一个任务，输入和输出都很明确，那就进入了微调的适用范围。

迁移流程：五个步骤

步骤 1：记录当前的提示词和预期行为

在改动任何东西之前，先冻结现有系统。记录下：

• 完整的系统提示词（在 git 里做版本管理）
• 50-100 个代表性输入及其实际输出
• 哪些输出你认为正确、部分正确、错误
• 你想修掉的具体失败模式

这就是你的评估基准。之后你会拿微调模型和这条基线对比，所以你需要关于现有系统真实表现的诚实数据。大多数团队在真正测量之前，都会高估自己提示词的表现。

步骤 2：从提示词中提取训练数据

系统提示词里的每一个示例，都是一条等着被提取出来的训练样本。一个带 5 个少样本示例的 2,000-token 提示词，本身就已经包含了最初的 5 对训练数据。更值得注意的是，提示词里还藏着隐式的训练数据：

• 每一条指令（“列表一律用项目符号”）都意味着几十对输出使用项目符号的输入-输出样本
• 每一条边缘情况规则都意味着一批会触发该规则的训练样本
• 每一项格式要求都意味着一批演示正确格式的样本

逐行过一遍你的提示词。针对每条指令，造 10-20 对演示该指令被正确执行的输入-输出样本。如果提示词里有 15 条不同的指令，光是把提示词拆解开，就能得到 150-300 条训练样本。

步骤 3：再生成 1,000-2,000 条样本

从提示词里提取出来的样本只是开头，你还需要数量。实际做法是：

1. 用你现在跑得通的提示词 + API 组合
2. 在多样化的输入上生成 3,000-5,000 条输出
3. 严格过滤，只保留达到你质量标准的输出
4. 目标是 1,000-2,000 对高质量训练数据

这一步通常要跑几个小时的 API 调用，视任务不同花费 $20-50。关键在于过滤。不要把平庸的输出放进训练数据。如果现有系统有 80% 的概率产出正确结果，就筛出这 80%，其余的丢掉。

小技巧： 让输入覆盖你已知的失败模式。如果基于提示词的系统在日期格式上有 30% 的出错率，就多生成一批日期格式的样本，并手工订正 API 答错的那些输出。微调模型最能明显超过提示词的地方就在这里。

步骤 4：微调一个更小的模型

训练数据到手之后，微调本身很直接：

• 基座模型： 对多数任务来说，Llama 3.1 8B 或 Qwen 2.5 7B 都是不错的起点。它们小到能在单张 GPU 上训练，又足以胜任范围窄的任务。
• 方法： 多数任务用 rank 16-32 的 LoRA。全参数微调很少有必要，还会加大过拟合风险。
• 训练： 在你的数据集上跑 2-4 个 epoch。epoch 再多就有过拟合风险，数据集越小越明显。
• 验证： 留出 10-15% 的数据做验证，盯住 loss 曲线看是否过拟合。

在 Ertas Studio 上，整个过程视数据集大小和 GPU 可用情况需要 30-90 分钟。你上传数据、选择基座模型、配置 LoRA 参数，然后训练。不用搭基础设施，也不用调 CUDA 驱动。

步骤 5：严格对比质量

拿步骤 1 里的评估基准去跑微调模型，对比这几项：

• 准确率： 微调模型能否追平或超过基于提示词的系统？多数情况下会高出 5-15 个百分点，因为它见过的样本量是提示词里塞得下的 100 倍。
• 一致性： 每条测试输入跑 5 次。微调模型的输出应该几乎完全一致。提示词的结果常有波动，微调出来的行为则更稳定。
• 延迟： 少了 2,000 token 的系统提示词，微调模型处理请求更快。在更小的模型上，延迟通常能降低 30-50%。
• 成本： 算一下每次请求的成本。自托管的 8B 模型，成本通常是带长提示词调用前沿模型 API 的 1/10 到 1/50。

如果微调模型在某些方面表现不佳，就针对这些方面补充训练样本再训一遍。微调和提示词工程一样是迭代的，区别在于每一轮迭代会互相叠加，而不是互相打架。

常见的迁移错误

想微调一个通用模型，而不是把任务收窄。 如果你的提示词干了五件不同的事，不要用一个模型把五件事全包了。训练五个独立的 LoRA 适配器。每个适配器都很小、训练快，并且在各自的任务上做得最好。在 Ertas 上，你可以在推理时切换适配器，没有额外开销。

切换生产流量前测试不充分。 让微调模型先以影子模式运行至少一周：处理真实输入并与现有系统的输出做对比，但结果不返回给用户。要抢在用户之前发现问题。

跳过数据质量这一步。 500 条高质量训练样本胜过 5,000 条平庸样本。把时间花在过滤和订正上。训练数据里的样本要是带着一个格式错误，模型就会把这个错误学过去。

LoRA rank 设得太高。 rank 64 或 128 听上去比 rank 16 更好，但对范围窄的任务来说通常只会过拟合。从低往上走，先评估，确认是欠拟合之后再提高 rank。

成本对比：迁移前后

下面是一家代理商迁移合同条款抽取任务的真实场景：

这个微调模型的训练算力成本是 $40，不到两天就收回了成本。

Ertas 如何把这件事压缩成一个下午

上面的迁移手册有五个步骤。在 Ertas Studio 上，基础设施带来的摩擦几乎降到零：

1. 上传训练数据，格式为 JSONL，Ertas 会校验格式并标出质量问题
2. 选择基座模型，模型库里已预装 Llama、Qwen、Mistral 等
3. 配置并训练，LoRA rank、学习率和 epoch 都有合理的默认值，需要时也可以完全手动控制
4. 评估，内置评估会用你的测试集给出准确率、一致性和延迟指标
5. 部署，一键部署到 Ertas Deploy，或者导出适配器自行托管

从“我有一个想替换掉的提示词”到“我有一个已部署的微调模型”，典型任务的整个流程需要 2-4 小时。模型训练本身是 30-90 分钟，其余时间都花在数据准备上，而这部分无论用什么工具都一样。

难的地方一直在于判断什么时候该切换、以及怎么准备数据。这本手册讲的就是这件事。

---

延伸阅读：

• 提示词工程有天花板。之后该做什么。：更深入地分析提示词为什么会停止改进
• 如何微调 LLM：完整指南：微调过程的技术细节
• 无需代码微调 AI：用 Ertas Studio 的无代码界面完成迁移