行业应用案例实用技巧

编辑部发布 2026-06-23 更新 2026-06-27 12 分钟阅读 2,440 字

行业应用案例实用技巧 是将特定技术或方法应用于真实行业场景时，提炼出的可重复、可验证的操作经验与避坑指南。它不同于泛泛的最佳实践，而是聚焦于某个垂直领域（如金融、医疗、电商、制造）的上下文、约束条件和交付标准，帮助从业者从"知道怎么做"跨越到"做对并交付"。

准备工作

在套用任何行业应用案例之前，请确认以下前提已满足，否则后续步骤很可能会偏离方向：

目标场景已明确：你处理的是文本分类（如客服工单自动打标）、结构化数据提取（如发票信息抽取），还是生成式任务（如邮件草稿）？不同任务对提示词结构和输出格式的要求差异很大。
有可对照的基准：至少准备 5-8 条真实输入（避免使用合成数据进行第一轮测试），并标注期望输出。没有基准就无法判断是"改进了"还是"改坏了"。
版本与环境已知：如果你在使用 Claude API，注意不同模型版本（如 claude-3-haiku vs claude-3.5-sonnet）对指令跟随能力和输出长度的表现不同。查阅官方 release notes 确认当前模型的行为。
评估指标事先定义：对于生成式输出，不要仅凭"看起来好不好"来判断。先定义结构正确率、语气一致性、关键字段覆盖率等硬指标。

动手前自查清单

我已将真实样本（至少 5 条）和期望输出放在同一份文档中
我已确认当前 API 版本与目标模型的文档匹配
我已写下输出必须包含的字段或结构限制
我已准备好至少一个边界案例（如空输入、超长输入、罕见格式）
我决定使用哪种模板结构（单轮指令 vs 多轮对话 vs 带示例的 few-shot）
我记录了初始状态——第一次调用的输出长什么样

步骤：从案例到可复用模板的四步法

下面用一个真实的行业场景——电商售后描述的意图分类——来演示这四步。假设你的输入是"收到的外套拉链卡住，申请换货"，期望输出是包含 意图、商品、问题类别、诉求 四个字段的 JSON。

第一步：拆解一个成功案例，提取结构

从一条你手动验证过的正确输出出发，反向推导出它遵守的规则。例如：

原始案例
输入：收到的外套拉链卡住，申请换货
输出：{"意图":"换货","商品":"外套","问题类别":"功能故障","诉求":"换货"}

从这条案例中提取出的结构规则：

输出必须是合法 JSON，包含 4 个固定键
意图 字段取自预设列表：换货 / 退货 / 退款 / 咨询
问题类别 采用三级分类：功能故障 > 配件损坏 > 外观瑕疵 > 其他
诉求 字段取自用户原文中的动宾短语，不可自行发明新词

第二步：将结构写成系统提示词

避免使用自然段落描述规则。应采用格式化的、程序能精确解析的写法。

你是一位电商售后分单助理。请按照以下规则将用户的售后描述转换为 JSON 输出。

【输出格式】
必须输出一个 JSON 对象，包含以下四个键：意图、商品、问题类别、诉求。

【意图映射】
- 含"换货""换一个"等 → "换货"
- 含"退货""我不想要了"等 → "退货"
- 含"退款""退钱"等 → "退款"
- 以上匹配皆失败 → "咨询"

【问题类别映射】
- "拉链坏了""漏电""无法开机"等涉及正常功能失效 → "功能故障"
- "扣子掉了""包装破损"等 → "配件损坏"
- "有划痕""颜色不对"（非功能问题）→ "外观瑕疵"
- 以上皆不匹配 → "其他"

【诉求字段】
提取用户原句中的动宾短语。例如"申请换货"→"换货"，"帮我修一下"→"维修"。不要改写或摘要。如果用户没有明确诉求，输出空字符串。

【边界情况规则】
- 一条消息包含多个问题的，只处理第一个完整句
- 输入中没有商品名词时，商品字段输出空字符串

新手最容易在这里出错：规则粒度要么太粗要么太细。太粗（如只写"判断意图"）模型会自由发挥；太细（如为每个品牌编写商品词表）会降低泛化能力。通常保持 5-10 条规则比较合适。

第三步：用样本验证，逐条对比输出

用第一步准备的 5-8 条测试样本调用 API，逐条检查输出字段。下面是一个典型检验表：

输入样本	期望意图	实际意图	期望问题类别	实际问题类别	通过？
收到的外套拉链卡住，申请换货	换货	换货	功能故障	功能故障	✅
这个杯子有划痕，我要退款	退款	退款	外观瑕疵	外观瑕疵	✅
请问运费怎么算	咨询	换货	其他	功能故障	❌
（空输入）	-	-	-	-	❌

为什么要逐字段检查？ 整体正确率可能会欺骗你：模型在意图字段准确率达 90%，但在问题类别字段可能仅 60%。如果只看整体通过率，你会漏掉分类层面的系统性偏差。

第四步：根据失败案例修正规则

从检验表中找出失败案例，回到第二步添加或修改规则。例如针对"请问运费怎么算"被误分类为"换货"：

添加一条优先级规则：如果句子中出现疑问词（吗、呢、请问、如何），且没有商品名称，则优先输出"咨询"，不再进行其他字段的映射。
增加空输入兜底：如果输入长度 < 5 个字符，直接返回固定 JSON {"意图":"咨询","商品":"","问题类别":"其他","诉求":""}。

重复第三至四步两轮，通常就能达到该场景 95% 以上的字段级准确率。

如何判断成功

不要仅依赖一两个随机样本。在完成至少一轮修正后，执行以下三组检查：

结构完整性检查：所有输出都是合法 JSON 吗？键名、类型、值是否在定义域内？用脚本批量运行 50 条验证。
边界案例检查：特别检查空输入、超长输入（超过模型 token 限制）、包含表情符号的输入以及全大写输入。这些最容易导致输出格式崩塌。
偏差漂移检查：对比修正前后的输出，确保你只修正了错误案例，没有把之前正确的案例改坏。保留每次的版本快照。

可视化参考：如果你在进行批量测试，建议在表格中将修正前后的输出并排列出，用颜色标记差异——绿色表示修复成功，红色表示新引入的错误。这样能一目了然地看出改动是否有副作用。

常见问题排查

输出格式频繁崩塌

检查点：先确认模型版本是否支持 JSON 模式。Claude 3.5 Sonnet 的 response_format 参数比早期版本更稳定。
操作：在系统提示词中加入"只输出 JSON，不要加任何说明文字"。如果仍然偶尔带出注释，在应用层增加后处理解析，解析失败时重试。

规则越写越长，但准确率不再提升

检查点：回顾第三步的检验表，看新增的失败案例是否集中在某两类极端模糊的边界（如"外观瑕疵"与"其他"之间的灰色地带）。这种情况通常意味着规则已经触及模型能力的上限。
操作：不要继续堆砌规则。改为增加 3-5 条 few-shot 示例，放入用户消息中，这比修改系统提示词更有效。或者考虑先用分类器做第一层过滤，再使用大模型进行细化。

第一版表现良好，但换到真实环境后效果崩塌

检查点：确认真实环境中的输入分布与测试样本是否一致。常见的原因是测试样本经过人工清理（去掉了乱码、拼写错误、emoji），而线上数据不够干净。
操作：从线上日志抽取 100 条随机输入，重新执行第二至四步。必要时在提示词中加入"原样保留用户输入中的符号和大小写"。

常见问题解答