AI产品经理在SFT（监督式微调）中的角色远比想象中关键。本文揭示了从判断是否真的需要微调，到制定可量化的目标与标注标准，再到数据分布与训练监控的全流程避坑指南。那些让算法团队束手无策的「爆款感」定义、标注SOP的魔鬼细节，以及模型「变蠢」的隐蔽陷阱，都将在实战经验中得到清晰拆解。

做 AI 产品一段时间后，我发现一个规律：很多团队 SFT 做失败，不是因为算法不行，是因为 PM 没搞清楚自己该负责什么。

这篇文章是我自己学完之后的理解，不是技术教程，就是把我觉得 PM 必须懂的那些事说清楚。

第一件事：先搞清楚要不要做 SFT

遇到模型效果不好，很多人第一反应是”要不要微调”。这个反应通常是错的，因为微调成本最高，应该是最后才动的牌。

我现在的判断顺序是这样的：

先试提示词（Prompt）。如果模型其实懂这件事，只是格式不对或者语气不对，改提示词就够了，成本几乎为零。

提示词搞不定，看是不是知识问题。如果模型在乱说——给出了错误信息、编造了不存在的内容——这是知识库的问题，往里塞文档让它说话前先查资料，而不是微调。

上面两条都走不通，才考虑 SFT。它解决的是那种”怎么写提示词都不稳定”的问题：特定的说话风格、极度定制的输出格式、复杂的业务逻辑。

一个判断标准我觉得比较好用：如果你能用一段话把标准说清楚，提示词大概率够了。如果你必须靠举例子来说明好坏，而且例子得超过二十个，差不多就到了考虑 SFT 的边界。

PM 在 SFT 里，核心就是三件事

SFT 这件事，算法工程师负责训练，但整个项目的方向盘在 PM 手里。

1. 定目标：说清楚模型微调之后要达到什么状态，要能量化。”写得更像博主”这种说法没用，要说”在测试集上，人工评分的爆款感从 3 分提升到 4 分以上”。目标不清楚，训练就没有方向。
2. 定标准：这是 PM 最核心的交付物。模型没有价值观，它的价值观是你用数据喂出来的。什么是好回答、什么是烂回答，必须由你来定义，落成一份标注 SOP。
3. 做终审：模型练出来能不能上线，这个判决权在你手里。不是算法说”练好了”就算过关，是你准备的那套测试题跑出来结果达标，才叫过关。

最花时间的活儿是写好一份标注 SOP

SOP 是给标注员写的工作指南，写得模糊，每个人按自己理解来，模型学出来的逻辑就会乱。

一份能用的 SOP，至少要把这几件事说清楚：

这个模型要扮演什么角色，说话风格是什么样的。输入和输出的格式长什么样，如果有结构化要求就定死格式。每个维度的好坏怎么判断，要给体感描述而不是空洞的数字——比如”5 分是像真人博主、有情绪起伏，1 分是开口就在这个快节奏的时代”。再挑几个满分样本和几个典型烂例子，说清楚好在哪、烂在哪。

写 SOP 之前，建议先自己手动写 20 组训练样本。 在写的过程中，你会发现很多原来根本没想到的细节——日期格式、空字段怎么填、遇到矛盾信息怎么处理。这些细节不亲手写一遍，你是发现不了的。

SOP 写完之后，找两个完全不懂业务的人按照它标几条数据，看他们标出来的结果对不对味——这就是 SOP 合不合格的最直接检验。

数据：量不够靠质，但分布别偏

数量上，MVP 阶段几百到两千条高质量数据基本够用。但数量不是关键，分布才是关键。

如果你做美食文案，训练集里 90% 都是火锅，模型练完之后处理甜品、轻食的能力会断崖式下跌。在准备数据之前，先列一个分类表，确保每个子场景都有覆盖，宁可每类少一点，也别让一个类型把整个数据集占满。

还有一个陷阱：用 AI 批量生成训练数据的时候，模型最后学到的是生成工具的语气，而不是真实用户的语气。生成的数据必须经过人工处理，把 AI 腔剔掉，否则你的产品永远有股机器感。

训练过程中，有两条线值得你盯着看

算法跑训练的时候，你去问进度，他会打开一个面板给你看两条曲线：训练损失和验证损失。

理想的状态是两条线都在稳步下降，差距不大。这说明模型在认真学你 SOP 里定义的逻辑。

危险信号是其中一条线开始往上翘，两条线分道扬镳。这说明模型开始死记硬背那些训练例子，遇到新的场景就不行了。出现这个情况，要让开发及时停止训练，从效果最好的那个时间点取出模型。

有一点需要纠正一个常见误解：很多人说”验证曲线不能比训练曲线低”，这个说法不准确。 由于训练和验证时模型的工作方式有一些技术差异，验证曲线轻微低于训练曲线是正常现象，不是异常。真正需要警惕的是两条线走势明显背离，而不是谁高谁低。

一个可以直接问开发的话：“两条曲线的趋势有没有出现明显的分叉？” 这一句话就够了，不需要深入技术细节。

几个真实的坑

以为训练指标好就等于产品好用。 训练指标衡量的是数学层面的准确程度，它测不出文案有没有人味、情绪到不到位。指标再好看，如果输出还是”在这个快节奏的时代”开头，这个微调就是失败的。

评测集没有代表性。 如果测试题全是简单场景，结果会虚高。上线之后遇到稍微复杂一点的真实请求，模型就露馅。评测集要覆盖不同难度，边缘情况也要有。

没有版本管理。 SFT 不是一次性的，每轮迭代都可能出现练好了这个、坏掉了那个的情况。每个版本的模型、数据、评测结果要有对应记录，出了问题能立刻切回上一个可用版本。这件事要在项目启动时就说清楚，不能等出问题才想起来。

忘了检查模型有没有”变蠢”。 模型学了特定风格之后，有可能把原来的一些通用能力丢掉。评测时除了业务场景题，加几道普通常识题摸一下底——如果爆款感提升了但基础智力退化了，这个版本不合格。

说到底

SFT 这件事，算法工程师能把模型练出来，但他没办法告诉你”爆款感”是什么、”博主味”长什么样。这件事只有你能定义，也只有你能判断有没有学到位。

训练指标达标只是入场券。你手里那套测试题跑出来的结果，才是最终的判决。