很多人谈大模型微调时，会自然地把它理解成“把知识灌进模型”。
这个理解越来越不准确。
在今天的大模型工作流里，事实知识更适合放在外部：RAG、数据库、搜索、文档上下文、工具调用。微调更适合做的，是改变模型的输出倾向：语气、格式、结构、术语偏好、拒答边界、推理姿态、品牌声音、客服话术、代码风格。
也就是说，fine-tuning 更像是把某种行为习惯压进模型，而不是把一套事实资料可靠地写进模型。
这就带出一个更有意思的问题：
如果微调主要迁移的是风格，而不是事实，那么我们是否可以不用 fine-tuning，而是用 prompt engineering 先把风格“逆向工程”出来？
Reddit 上的讨论，基本给出了一个务实答案：可以，而且多数情况下应该先这么做。
Reddit 的大致共识
我看到的讨论主要集中在 r/LocalLLaMA、r/PromptEngineering、r/OpenAI 这些社区。它们的立场并不完全一样，但有几个共同点很清楚。
第一，facts 不该主要依赖 fine-tuning。
LocalLLaMA 里经常有人提醒：如果模型“不知道某个事实”，优先考虑 RAG 或上下文注入；如果模型“说话方式、输出格式、任务行为不对”，才考虑 fine-tuning。这个区分很重要。事实是会变化的，风格和行为模式才更适合被固化。
第二，如果目标只是“让模型像某个人或某个品牌那样写”，Reddit 更倾向先用 examples 和 prompt。
很多人的经验是：把几段高质量样本放进 prompt，让模型先分析写作风格，再按这个风格改写，效果已经很好。尤其是在 GPT-5、Claude、Gemini 这类强模型上，few-shot examples 往往比小规模微调更可靠，也更容易迭代。
第三，所谓“逆向风格”，不是简单写一句 “write like X”。
真正有效的做法，是让模型从样本文本中提取风格指纹：
- 句子长短和节奏；
- 常用转折方式；
- 抽象概念和具体例子的比例；
- 情绪温度；
- 是否喜欢反问；
- 是否使用讽刺、隐喻、类比；
- 论证结构是线性推进，还是先抛结论再拆解；
- 常用词和禁用词；
- 段落长度；
- 结尾是开放式、判断式，还是行动建议式。
这类风格指纹可以被整理成一张 style card。之后模型写作时，不需要每次读完整样本，只要读取这张 style card，再加三到五个代表性例子，就能稳定复现相当多的风格特征。
第四，Reddit 对 fine-tuning 的态度并不是否定，而是反对滥用。
很多人认为 fine-tuning 仍然有价值，但它应该用在更明确的场景里：你要大量生成同类内容，你要降低 prompt 长度和推理成本，你要让小模型学会特定输出格式，你要让模型在客服、销售、审阅、写作等固定流程中保持稳定口吻。
换句话说，fine-tuning 不是第一步。它更像是最后的压缩和固化步骤。
为什么 prompt engineering 更适合风格逆向
风格本质上不是一个事实集合，而是一组可观察的选择。
一个人写作时，总在做选择：用长句还是短句，用概念还是故事，用冷静分析还是情绪推动，用直接判断还是保留余地。这些选择反复出现，就构成了风格。
大模型很擅长从样本中识别这种模式。
所以，与其说我们是在“教”模型一个新风格，不如说我们是在帮模型明确它要模仿哪些可见特征。强模型本来就见过大量写作方式；prompt engineering 的作用，是把目标风格从模糊感觉变成可执行约束。
这也是为什么 few-shot 往往有效。一个好的例子不仅告诉模型内容，还告诉模型节奏、力度、段落组织和语气边界。
而小规模 fine-tuning 反而可能带来问题。
如果数据量少，模型容易记住表层表达，而不是学会背后的风格原则。结果可能是：它会重复某些词、某些句式、某些套路，看起来“像”，但很快变僵硬。尤其是文学写作、评论写作、个人 voice 这类任务，过度微调很容易把活的风格压成模板。
还有一个更真实的短板：模型可能在学会风格之后，反而失去一部分跟随指令的能力。
比如，一个模型用一万篇没有行内引用的长文做 LoRA 微调。微调之后，它确实学会了那种流畅、自然、 citation-free 的文章风格，但也开始忽略新的显式指令：请在正文中按 [1]、[2] 插入行内引用。
这不是事实检索失败。来源仍然可以从 retrieval metadata 里打印出来，provenance 仍然完整。但模型不愿意把引用织进正文，因为一万篇训练样本已经把“不要在正文里打断叙事”的风格压成了强习惯。风格覆盖了格式指令。
这类问题的修法也很典型：
- 用 base model 生成，保留更强的 instruction-following，但会失去一部分 voice；
- 在 prompt 里 few-shot 行内引用格式，让模型重新看到目标输出长什么样；
- 或者做第二道 citation insertion pass，先让风格模型写正文，再由另一个步骤把
[1]、[2]插回合适位置。
这个例子很好地说明：fine-tuning 不只是“加能力”，它也会重塑模型的优先级。当风格样本足够强、足够单一时，模型可能把风格当成比当前指令更高的规则。
这也是 Reddit 上很多人倾向 prompt-first 的原因。
一个更合理的工作流
如果我要做一个“风格迁移型 LLM 写作系统”，我不会第一步就 fine-tune。
我会这样做。
第一步，收集样本。
不要追求海量，先追求代表性。十篇平庸文本，不如三篇最能体现风格的文本。样本最好覆盖不同场景：短评、长文、反驳、解释、总结、建议。
第二步，生成 style analysis。
让模型分析这些文本的风格，但不要只给形容词。不要停留在“犀利、温暖、专业、有洞察”这种空话。要让它输出可执行规则，例如：
- 每段通常不超过三句话；
- 先给判断，再解释理由；
- 避免营销腔；
- 少用形容词，多用因果关系；
- 重要结论用一句短句单独成段；
- 技术概念要落到工作流或产品判断上。
第三步，压缩成 style card。
style card 应该短，最好几百字以内。它不是文章分析报告，而是推理时可反复使用的写作规范。
第四步，用 few-shot examples 校准。
给三到五个高质量例子，让模型知道 style card 在真实文本里长什么样。例子不要太多，否则上下文会变重，也容易让模型复制具体内容。
第五步，facts 外置。
涉及事实、数据、新闻、产品、论文、法规、公司情况，一律从外部检索或文档上下文注入。不要指望 style model 自己记住事实。写作模型负责表达，事实系统负责供料。
第六步，必要时再 fine-tune。
当 prompt 方案已经跑通，而且你发现调用量很大、成本很高、prompt 太长、输出稳定性仍不够，再把这套风格规则和高质量输入输出样本拿去 fine-tune。这个时候 fine-tuning 的目标不是探索风格，而是把已经验证的风格固化下来。
Prompt 和 fine-tuning 的真正分工
这件事最后可以归结成一句话：
Prompt engineering 是显式风格控制层，fine-tuning 是风格固化层，RAG 是事实供给层。
三者不应该互相替代。
如果你用 fine-tuning 存事实，事实会过期，模型会幻觉，维护成本会很高。
如果你只用 prompt 控制长期稳定行为，prompt 会越来越长，系统会越来越难管理。
如果你只用 RAG，而不控制表达风格，输出会像资料拼接，没有声音。
好的系统应该把这三件事分开：
- facts：外部系统提供；
- style：prompt / style card / examples 控制；
- habit：fine-tuning 固化。
这比“到底 prompt engineering 好，还是 fine-tuning 好”更接近真实问题。
对企业应用的启发
这个判断对企业 AI 很重要。
很多企业想做“懂我们公司业务的模型”，第一反应是 fine-tune。其实更合理的拆法是：
业务事实进知识库；
业务流程进工具和 agent workflow；
公司口吻、审阅标准、报告格式、销售话术，才考虑 style prompt 或 fine-tuning。
比如一个医药 CRM 助手，不应该靠 fine-tuning 记住医院、医生、合同、拜访记录。这些都应该来自数据库和权限系统。fine-tuning 最多让它学会公司内部的沟通方式：怎么写拜访纪要，怎么总结医生异议，怎么生成下一步行动建议，怎么避免不合规表述。
再比如合同审阅 agent，合同条款和法规变化应该来自检索；fine-tuning 可以让它学会固定的审阅口吻、风险分级格式和法律团队习惯的表达方式。
这才是可维护的架构。
结论
Reddit 的意见其实很朴素：不要把 fine-tuning 神秘化。
如果你只是想得到一种写作风格，先用 prompt engineering 逆向出来。让模型读样本、提取风格指纹、生成 style card、配合少量 few-shot examples。这样便宜、可解释、可调试，也更不容易把风格训练死。
如果这套 prompt 已经证明有效，再考虑 fine-tuning，把它压进模型里，换取一致性、低延迟和低成本。
事实不要放进微调里。
风格先用提示词显式控制。
习惯最后才用微调固化。
这大概是目前最稳妥的路线。