在大模型生成内容、打标签、调 Prompt 等实操工作中，即便打标签这类简单应用，也极易遭遇准确率偏低、Prompt 臃肿复杂、泛化能力弱等问题。作者结合实战踩坑经历，总结出 6 条核心教训，从构建完整判断逻辑、分而治之做分类，到让模型理解底层逻辑、补充项目上下文等，揭示大模型落地的关键并非单纯的 Prompt 技巧，而是对业务的深度理解、对模型边界的清晰认知和对系统设计的整体把握。

前段时间做了大量大模型生成内容、大模型打标签、评估、调 prompt 工作，如用大模型给内容打上诈骗手法、作弊渠道等，这是一个很简单的应用场景，但依然会遇到很多问题。

如准确率上不去、prompt 越写越长越写越复杂、泛化能力太弱、逻辑之间存在冲突…

根据踩过的坑，总结了这些点教训

01 打标签本质上是不断补漏洞的过程

每发现一个误判的 case，我就在 prompt 里加一条规则；每发现一个漏判的 case，再加一条规则。

就这样，prompt 变成了一张打满补丁的网。

后来我才明白，打标签不是简单告诉大模型”这是 A，那是 B”，而是要帮它建立一套完整的判断逻辑——什么是边界、什么情况下会冲突、不同条件之间的优先级怎么排，而且需要强调 prompt 骨架，弱化细节，才能提升泛化能力。

这需要真正理解业务，而不是机械地堆砌 if-else 规则。

02 分而治之比一锅端更有效

我一开始想让大模型一步到位，直接从客诉文本中提取所有标签。

但效果很差。后来想起之前做内容安全的经验：识别危险标识时，会先把小图切出来，再用精准模型识别。

然后我改了思路：先让大模型判断客诉的大类，然后再根据不同类别，用不同的 prompt 做二级分类。

准确率从 60%+，提升至接近 90%。

03 让模型理解”为什么”比告诉它”怎么做”更重要

之前写 prompt，总是纠结于输出格式、标签名称这些表面问题。

但后来发现，真正重要的是让大模型理解背后的逻辑——为什么这条客诉应该被标记为诈骗？是因为提到了转账？还是因为语气异常？

当我把 prompt 的重点从”怎么说”转向”怎么想”之后，效果明显提升。

04 模型需要上下文

整个项目是一个复杂的多 Agent 协作项目，整个闭环有二十多处调用大模型，打标签只是其中一环节

最开始每个环节的 prompt 都是独立的，效果一般。后来在每个环节的 prompt 里都补充了项目背景：我们为什么做这个项目、这个环节在整个流程中扮演什么角色、它的输出会被下游如何使用，让他理解这个项目，效果好很多。

这就像老板给你派活，如果只说”你去做这个”，你可能做得一塌糊涂；但如果告诉你项目的来龙去脉、你做的事情对整体的意义，你就会做得更好。

大模型也一样，它需要理解上下文。

05 中间层要产出证据，不是结论

在那个风控项目中，系统有多层大模型调用。一开始让每层模型都输出”结论”，但到最后推理时，反倒因为数据缺失细节，导致大模型反而没法做推理了——因为中间层只给了它结果，没给推理过程。

后来调整策略：中间层输出”支撑证据”，也就是给机器看的推理过程；只有最后一层才输出给人看的”结论”。

06 接受不完美，但要让不完美可控

大模型一定会出错，这是它的原理决定的。

所以关键不是追求”零错误”，而是通过机制设计，让错误变得可控、可接受。

同时也要花精力说服业务方接受这个现实——大模型不是万能的，它的价值在于提升效率，而不是完全替代人。

打标签看似简单，实则复杂。它考验的不是 prompt 技巧，而是对业务的理解、对模型边界的认知、对系统设计的把握。