行业应用场景 入门教程

行业应用场景入门教程：从理论到实践的最后一公里

通用教程教你如何调用 API、微调模型、编写提示词，但当你真正面对自己的行业问题时，这些知识却常常难以落地。原因很简单：代码片段是抽象的，而你的业务需求是具体的。

行业应用场景入门教程正是为了解决这个“最后一公里”的断层问题而生。它不是另一份通用文档，而是一套系统化的操作指南，它将通用的工具能力（API 调用、模型微调、提示词工程）精准地映射到具体的业务领域（如客服、电商、医疗、金融）。

下一步：请求与响应格式 入门教程、请求与响应格式 实用技巧

这里没有空中楼阁。你得到的不是抽象的代码，而是可直接运行、适配行业术语、数据格式和合规要求的方案原型。本文将以一个完整的电商商品分类项目为例，为你演示从场景分析、环境配置到结果验证的全过程，并揭示五个新手最容易遇到的“埋点”与解决方案。

动手前，请完成三项关键准备

贸然开始，只会让问题变得更复杂。请在执行下列步骤前，稳妥地完成这三项准备：

1. 校验工具版本：以 Claude API 为例，最新稳定版名为 claude-3-5-sonnet-20241022。如果你还在使用 claude-v1 这样古老的版本，部分参数名称和模型行为会截然不同。直接复制网上的配置前，务必先核对 API 版本号，版本不匹配时，即使是相同的代码也会引发不兼容或报错。
2. 准备最小化样本数据：这是将潜在错误成本隔离在指尖的关键一步。切勿直接用全量生产数据进行测试。相反，准备 5–8 行脱敏后的典型输入输出对。这份数据应覆盖三种类型：正常情况、边界值（如极短的标题）、以及一条异常值（如不存在的类目）。下文示例会展示具体格式。
3. 清晰界定场景边界：制定一张简洁的能力需求表，明确你的行业场景要求和不要求哪些能力。这能有效阻止在教程中混入无关的步骤，让你始终聚焦于核心目标。

检查项	完成标准	常见遗漏
API 密钥权限	确认您有调用目标模型的权限，且配额足够。	使用他人的测试密钥，导致流程中途被限流。
样本数据脱敏	替换掉姓名、手机号、身份证号码（PII）等个人信息。	直接从生产库复制数据表的前几行。
行业术语词典	至少列举 10 个本场景必须正确识别的专业术语。	模型将“保额”错误理解为“保证金额”。
输出格式模板	明确定义好 JSON Schema 或 Markdown 模板。	用自然语言描述输出格式，导致解析失败。

四步走：以电商商品分类为例

接下来的每一步，我们都将围绕一个电商商品文本自动分类场景展开。目标是将商品标题和描述，精准地映射到预设的品类树中（例如：一级类目“手机数码” → 二级类目“手机配件” → 三级类目“手机壳”）。

1. 定义输入输出格式

首先，明确模型吃什么，吐什么。我们采用结构化的 JSON 格式，告别随心所欲。

输入示例：

{
  "title": "iPhone 15 Pro 磁吸透明手机壳",
  "description": "适用于苹果手机，支持 MagSafe，四角防摔气囊设计"
}

输出示例（同样为结构化 JSON，字段固定）：

{
  "level1": "手机数码",
  "level2": "手机配件",
  "level3": "手机壳",
  "confidence": 0.92
}

边界情况：当商品属于“其他”类目时，confidence 值应小于 0.6，且 level3 留空。这个细节在后续的测试中至关重要。

2. 编写场景化 System Prompt

通用教程里简单的一句 “You are an expert assistant”，不足以让模型理解你的行业术语和分类规则。你需要一个强约束的 System Prompt。

针对我们的电商分类场景，System Prompt 应包含以下几个关键约束：

你的任务是按以下规则对商品标题和描述进行分类：

1.  严格使用类目表中已定义的标签，禁止自行发明新类目。
2.  如果无法确定三级类目，将 level3 设为空字符串，并将 confidence 设为 0.5 以下。
3.  注意同义词映射：“手机壳”和“保护壳”都归入“手机壳”类目；“苹果”作为品牌名处理，非水果。
4.  输出必须严格遵循 JSON 格式，不要任何额外解释。
5.  类目定义如下：（此处粘贴完整的类目表，至少包含一级、二级、三级共 30+ 条目；例如：手机数码 -> 手机配件 -> 手机壳/屏幕保护膜/充电器，家居生活 -> 水具/杯壶 -> 保温杯/玻璃杯...）。

3. 按正确顺序构造请求

新手最容易犯的错误是颠倒了操作顺序：先调用了模型，再补上 System Prompt；或者先传数据，再设置 temperature。正确的执行顺序是：

1. 初始化客户端：设置 API endpoint、密钥和默认参数。
2. 设置 System Message：将上一步编写好的长 Prompt 作为 system 参数传入。
3. 预热模型（推荐）：用一条无关的通用指令（例如“请确认分类规则已加载”）发起一次空请求。这能确保模型预热后，输出更稳定。
4. 传入用户消息：按定义的输入格式，传入待分类的商品数据。
5. 设定推理参数：对于分类这种确定性任务，使用 temperature=0 来消除随机性；由于输出很小，max_tokens=200 就足够了。

4. 批量测试并比对

准备一个小型测试集（7 条），并记录每一条的预期结果。这能帮你迅速发现 Prompt 和类目表的潜在问题。

测试用例	预期 level1	预期 level3	说明
iPhone 15 磁吸透明壳	手机数码	手机壳	正常情况
不锈钢保温杯 500ml	家居生活	水具/杯壶	非数码类
充电宝 20000mAh 快充	手机数码	移动电源	注意不是手机壳
苹果苗 两年嫁接苗	其他	（空）	品牌混淆
安卓平板支架桌面款	手机数码	平板支架	注意是支架不是壳
商品标题极短：“壳”	手机数码	手机壳	信息不足但可推断
商品标题为空	其他	（空）	极端边缘

逐条执行后，用脚本或手动将模型输出与预期值对比。如果 7 条中有超过 2 条不符，说明你的 System Prompt 或类目表有缺失。不要急着改代码，先回到步骤 2 修复 prompt。

快速验证三要素

每次执行完一批预测，用下面三个检查点快速确认结果的有效性：

1. 格式检查：模型是否输出了有效的 JSON？一个常见陷阱是，模型可能会将 JSON 包在 Markdown 代码块（\`json ... ```）内。你的后处理逻辑必须主动移除代码块标记，而不是期望模型自己纠正。
2. 类目存在性：检查输出的 level2 和 level3 是否真实存在于你的类目表中。模型有时会“幻觉”出一个看似合理但未定义的类目，例如把“手机壳”写为“手机套壳”。务必用脚本进行交叉比对。
3. 置信度合理性：confidence 值是否和实际情况匹配？当商品标题很短或类目模糊时，模型输出 0.95 以上的高置信度是一个危险信号，说明你的 prompt 约束力不足。

新手卡点 Top 5 排查指南

根据反馈，以下五个问题覆盖了 80% 的新手卡点。这张排查表能帮你快速定位问题，而不是在错误的方向上浪费时间。

问题现象	最可能的根因	排查步骤	回退方案
模型返回非 JSON 格式混乱	max_tokens 太小（<100）或 temperature 过高（>0.3）。	先设为 temperature=0，max_tokens=300 重新测试。	使用 response_format 参数（如 API 支持）强制输出 JSON。
类目全被归到“其他”	System Prompt 中的类目表过长，超过了模型上下文限制。	检查实际送入的 token 数。将类目表精简为核心条目（约 20 个），再分批测试。	将类目拆分成多个子 prompt，针对不同商品类型分别调用。
同义词无法正确映射	System Prompt 中未定义同义词列表。