gemini-4-carbon 实战：文本模型的 5 个高价值应用场景与接入要点

为什么用场景而不是榜单来评估文本模型

模型选型最常见的误区，是拿一张榜单当结论。榜单上的综合分数反映的是评测集合上的平均表现，而你的业务只关心一种任务形态：把客服邮件抽成结构化字段，或者把用户反馈分成五类。这两件事对模型的要求完全不同——前者要求严格遵循输出格式、字段不缺失，后者要求标签判定稳定、边界样本不摇摆。一个综合分很高的模型，完全可能在你这个具体任务上不如一个分数中游的模型。

更实际的做法是先拆任务形态，再判断模型是否匹配。文本类需求大致可以归为几类：结构化抽取（从自由文本里取字段）、分类与路由（打标签、决定去向）、生成长文压缩（摘要与要点）、基于资料的问答与改写、以及评审质检（判断合格与否并给出理由）。每一类的输入输出契约不同，对提示词的敏感度不同，出错后的修复成本也不同。

所以评估流程应当是：先确定任务属于哪种形态，写出 20 到 50 条真实样本，定义清楚什么叫“做对了”，再让候选模型跑一遍，人工比对结果。gemini-4-carbon 是 Gemini 4 系列中最强的型号，面向最复杂的多步骤长周期任务，同样适合用这种方式来验证，而不是先入为主地相信它的宣传描述。

下文按 5 个高价值场景展开，每个场景给出输入输出约定、提示词设计要点和成本控制思路，你可以直接对照自己的需求挑选。

场景一：非结构化文本到结构化数据

这是文本模型最容易产生直接业务价值的一类任务：输入是工单正文、客户邮件、合同片段、会议记录，输出是固定字段的 JSON。典型字段包括问题类型、涉及产品、紧急程度、关键实体、用户诉求摘要等。

输入输出契约要先定死

落地前先写清楚 schema，例如字段名、类型、可选值枚举、是否允许为 null。schema 一旦确定，就要让模型在输出层严格遵循。做法是在提示词中直接给出字段定义和一个完整示例，而不是只描述“请抽取关键信息”。示例比描述更有效，尤其在字段语义容易歧义时。

约束输出格式的三层手段

第一层是提示词：明确“只输出 JSON，不要解释，不要 markdown 代码块标记之外的文字”。第二层是结构校验：拿到响应后立刻做解析与字段校验，枚举值不在范围内、必填字段缺失、类型不符都判为失败。第三层是重试：校验失败时，把校验错误信息作为附加指令重新发起一次请求，通常比原样重试成功率高得多。

注意不要指望一次就完美。对于长文本，模型可能遗漏后段信息；对于字段多的 schema，可能把两个相近字段填反。这些都需要在校验层兜住，而不是在提示词里反复加感叹号。

成本控制

抽取类任务的输入往往很长、输出很短，成本集中在输入侧。能裁剪的历史对话、邮件签名、法律免责段落，都应该在送进模型前去掉。只保留与字段相关的段落，既省钱又提准确率。

场景二：内容分类与路由

分类任务的形态是：一段文本进，一个或几个标签出，标签决定后续走哪条流程——派给哪个团队、进哪个队列、触发哪种自动回复。

标签设计比模型选择更重要

先确认标签集是否互斥、是否穷尽。如果存在“其他”这类兜底类，要明确它的判定标准。标签数量不宜一开始就很多，十类以上时模型在边界样本上的混淆会明显上升，建议先合并相近类别，跑通后再拆细。每个标签最好配一句判定说明和一个正例，写进提示词。

置信度与兜底

可以在提示词里让模型给出一个简短的判定理由，把它当作路由依据：理由明确且自洽的直接分流，理由含糊或自相矛盾的进入人工队列。但要注意，模型自报的置信度并不总是校准良好的，务必在真实样本上验证它是否真的能区分“容易”和“难”的样本。更稳妥的做法是看多个候选标签的分布，或者由规则层判断模型给出的判定理由是否充分。

同时必须有一条兜底分支：解析失败、标签不在枚举内、多标签冲突，一律走人工或默认队列。路由是强影响链路，宁可多走人工，也不要错误自动分派。

成本控制

分类任务输入长度中等、输出极短，token 消耗主要看输入。可以只把标题、开头段落和关键句送进模型，而不是整篇文档；对于超长内容，先截断再分类，多数场景下效果损失有限。

场景三：长文摘要与要点提炼

长文摘要的难点不在“写一段总结”，而在“不丢关键信息、不重复概括、不编造”。单次调用处理超长文本时，模型容易遗失中段内容，也容易把开头反复改写。

分段摘要再合并

常见做法是把长文按段落或章节切块，逐块生成要点，再把要点合并成最终摘要。切块时尽量按语义边界切，而不是按固定字数硬切，否则一句话被截断两半会引入噪声。合并阶段让模型只基于已产出的要点做压缩，而不是回头再看原文，可以显著减少重复与发散。

明确摘要的目标受众与粒度

提示词里要写清楚：摘要给谁看、要多长、需要保留哪些要素（数字、结论、待办）。如果不指定，模型会给出平均化的泛泛之谈。另一个有效约束是“按条目输出”，每条一句话，避免连贯长段落里塞入冗余过渡语。

质量校验

摘要类输出没有唯一正确答案，但可以做几个廉价检查：长度是否在范围内、是否包含要求的关键要素、是否出现了原文没有的数字或实体。最后一项尤其重要，模型在压缩过程中偶尔会“补全”一个看起来合理的数字，这在业务文档里是硬伤。

成本控制

这是输入 token 消耗最大的场景。分段摘要意味着同一份文档会被多次读取，成本随长度近似线性增长。建议对超长文档设置长度上限并明确降级策略，例如只对前若干章节做细摘要、其余做粗摘要。

场景四：基于自有资料的问答与改写

这个场景的形态是：用户提问，系统先从自有资料中检索出候选段落，把它们拼进上下文，让模型基于这些段落作答或改写。它和通用问答的区别在于，答案必须落在给定资料内。

上下文组装

检索回来的段落要先排序再截断，把最相关的放在靠近指令的位置。每段资料带上来源标识，便于模型在答案中引用，也便于你排查错误。如果检索结果之间互相矛盾，提示词应明确要求模型指出冲突，而不是自行挑选一个。

拒绝回答比强行回答更有价值

提示词中必须写明：如果资料不足以回答，就直接说明资料中没有相关信息，不要凭常识补充。这条约束能显著降低幻觉率，但前提是你要在评测集里专门准备一批“资料里确实没有答案”的问题，否则测不出来。

改写场景的额外约束

对于“把资料改写成用户能看懂的一段话”这类需求，除了内容准确，还要约束风格：长度、语气、是否允许使用列表、是否必须保留原文术语。改写输出的可读性很依赖这几条，缺一条就会得到风格漂移的结果。

成本控制

成本几乎全部由拼进上下文的资料长度决定。检索阶段多召回再截断，往往比把 Top-K 调大更省钱；同一会话内的重复问题可以缓存答案；对改写任务，明确限制输出长度能同时降低费用和提升风格一致性。

场景五：评审与质检辅助

评审类任务的形态是：给定一份内容（文案、代码注释、客服回复、商品描述）和一套标准，输出通过或不通过，以及不通过的原因。它不追求创造性，追求的是判定一致。

把评审标准写成可判定的条目

“语气是否友好”这种标准没法稳定执行。要拆成可判定的条目：是否包含禁用词、是否出现承诺性表述、长度是否在区间内、是否包含必要信息项。每条标准对应一个布尔判定和一个简短理由，输出结构固定为逐条结果加总体结论。

区分硬性校验与软性建议

能由规则代码完成的检查（正则、长度、词表）不要交给模型，既慢又不稳。模型适合处理规则覆盖不到的部分：语义是否前后矛盾、表述是否会引起误解、是否偏离给定标准。把这两类结果分开输出，人工复核的成本会低很多。

输出设计

让模型对每条标准输出“通过 / 不通过 / 无法判断”三态，而不是二态。加入“无法判断”能明显减少模型在信息不足时的强行判定，也给你一个明确的待人工处理队列。理由字段限制在一句话内，既省 token 又便于汇总统计。

成本控制

质检往往是批量任务，单条成本低但总量大。控制手段是标准化提示词模板、压缩待审内容（只送需要检查的部分）、以及用规则前置过滤掉明显合格的样本，只把有疑点的送进模型。

接入实现：接口、参数与输出约束

上面 5 个场景在接入层面有大量共性，可以抽成一套通用流程：提示词模板 → 模型调用 → 输出校验 → 失败重试。模型调用统一走 Chat Completions 兼容接口 https://api.hiapi.ai/v1/chat/completions，SDK 的 base_url 为 https://api.hiapi.ai/v1，支持流式输出。

模型名与线路

同一模型提供两条线路：标准线路的模型名不带后缀，Vertex 线路在模型名后加 @vertex，例如 gemini-4-carbon@vertex。切换线路只改 model 字段，请求的其余部分不变；两条线路的模型能力一致，价格不同，见后文价格表。

输入与长度上限

输入只支持文本和图像，不支持音频、视频和 PDF。上下文长度为 1,048,576 token，单次最大输出 65,536 token，给长文摘要这类场景留出了较大空间，但分段处理依然是控制成本与稳定性的有效手段。

推理强度

推理强度通过 reasoning_effort 指定，可选 low、medium、high。档位怎么选，应当按实际任务评测确定：用真实样本把各档位各跑一轮，比较准确率、耗时与 token 用量后再定默认值。推理强度越高，耗时与输出 token 越多，需要结合场景权衡。

当前不支持的能力

本接口目前不支持工具调用 / function calling、联网搜索、computer use、结构化输出 / JSON 模式。因此输出格式的约束必须落在提示词与代码校验层：提示词给出字段定义和完整示例，代码解析响应并逐项校验，不依赖接口侧的 schema 强制。

请求示例

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-4-carbon",
    "reasoning_effort": "medium",
    "stream": true,
    "messages": [
      {"role": "user", "content": "把下面的工单抽取为固定字段的 JSON：..."}
    ]
  }'

提示词模板的结构

推荐固定为四段：角色与任务说明、输入数据、输出格式定义与示例、边界与禁止事项。输入数据用明确的分隔符包起来，避免与指令混淆。示例要完整可解析，不要写“类似这样的 JSON”然后给一个残缺片段。

输出校验是必需品而不是可选项

拿到响应后先做解析：JSON 能否解析、必填字段是否齐全、枚举值是否合法、数值是否在合理区间。校验失败不要静默降级成空结果，要记录下来，因为失败率本身就是一个重要的模型质量指标。

重试策略

建议最多重试一到两次，且重试时把校验错误作为附加信息告诉模型，例如指出哪个字段缺失或哪个枚举值非法。原样重试的收益通常很低。同时设置超时与并发上限，避免单条异常拖垮整个批次。

记录与可观测性

每次调用至少记录：场景标识、输入 token 与输出 token 用量、校验结果、耗时。这些数据既用于成本分析，也用于后续换模型或改提示词时的对比基线。没有这层记录，任何优化都只能靠感觉。

按 token 计价的成本控制与上线建议

gemini-4-carbon 按 token 计价，这意味着成本由输入长度和输出长度共同决定，且不同场景的成本结构差异很大。抽取和问答场景以输入为主，摘要场景输入输出都重，分类和质检则是输入重、输出极轻。先搞清楚你的场景把钱花在哪一侧，优化才有方向。

价格与选型基线

下表单位为美元 / 百万 token，三列依次是输入、缓存输入、输出。

三个型号的定位不同：gemini-4-carbon 是 Gemini 4 系列最强的型号，面向最复杂的多步骤长周期任务；gemini-4-argon 适合大多数软件工程与知识工作，能力与成本均衡；gemini-3.8-flash 速度快、价格低，适合高并发低延迟任务。同一任务可以先用 Argon 或 Flash 跑通，再判断是否值得升级到 Carbon。

线路与推理强度同样是成本变量：标准线路的单价低于 @vertex 线路。推理强度档位按实际任务评测选择，用真实样本比较各档位的准确率与 token 用量后再确定默认值。

压缩输入

最常见的浪费是把整份文档原样送进模型。可以做的：去掉模板化的页眉页脚与免责声明、裁剪历史对话只留最近几轮、检索结果按相关度截断、长文只送需要的章节。这些改动通常不损失准确率，却能直接减少输入 token。

限制输出

输出侧的控制更简单：明确最大长度、要求条目化而非长段落、禁止复述输入。很多提示词里写“请详细说明”，在按 token 计费的模式下就是成本放大器，除非业务真的需要细节。

先小规模评测再放量

不要用官方描述替代自己的验证。建议的做法是：为每个场景准备几十条真实样本，定义可判定的通过标准，先跑一轮看准确率与失败模式，再决定是否扩大范围。评测集要留存，作为后续回归基线。

建立可复用的评测与回归流程

换模型、改提示词、调整上下文长度，都会影响结果。有一套固定的评测脚本和指标，才能在改动后几分钟内判断是变好还是变坏。这是把文本模型长期用下去的基础设施，比任何单次调优都重要。

先选一个场景、几十条样本、一套明确的通过标准，跑通之后再谈扩展。可以在 HiAPI.ai 的模型页查看 gemini-4-carbon 的接口说明与计费口径，按输入与输出的实际 token 用量做预算更准确。