claude-sonnet-4-6 实战：5 个高价值文本应用场景与实现要点

为什么选文本模型切入业务

选型的第一问不是「模型强不强」，而是「这个环节值不值得上模型」。工程团队常见的浪费，是把能力当成目标，先接模型再找场景，最后得到一个演示可用、生产难用的功能。

判断一个环节是否适合文本模型，可以用两个维度切分：任务频次和对输出波动的容忍度。

• 高频 + 高容忍：批量摘要、文案改写、工单分类、日志初筛。这类任务量大、单次出错代价低，最适合先跑通，用来积累评测集和提示模板。
• 高频 + 低容忍：字段抽取、金额与日期识别、合规话术生成。价值最高，但必须配套 schema 约束、校验与回退，否则一次错误输出就可能污染下游数据。
• 低频 + 高容忍：一次性分析、内部工具、探索性功能。适合做概念验证，不必投入太多工程成本。
• 低频 + 低容忍：核心结算、法律结论。当前阶段应以人为主导，模型只做辅助材料整理。

以一个 Anthropic 的文本模型如 claude-sonnet-4-6 为例，它适合承担的是「理解 + 归纳 + 生成」这一类语言工作，而不是替你完成领域判断。真正的收益来自把重复的阅读、整理、初稿环节从人手里拿走，同时把校验做成工程约束，而不是寄希望于模型每次都对。

因此在落地顺序上，建议先选一个高频、可量化、有现成人工基准的场景做试点：有历史数据可以对比，有明确的正确率指标，出错也能被下游流程拦住。下文五个场景按这条思路展开，每个都给出输入输出设计、提示结构、校验回退与成本控制要点。

场景一：非结构化文本的结构化抽取

合同、工单、邮件、简历、发票备注，这些文本的共同点是人能读懂，但程序无法直接消费。抽取任务的目标是把它变成稳定的 JSON 字段。

输入设计

先把「抽取什么」写成显式 schema，而不是用自然语言描述一堆字段。字段名、类型、是否必填、枚举取值范围都应在提示中固定下来。对长文本，先截取或分段，把与字段相关的段落定位出来再送模型，能显著降低成本，也减少模型被无关内容干扰。

schema 约束与输出格式

要求模型只输出 JSON，不输出解释性文字。对关键字段使用封闭枚举，例如「合同类型」限定在几个取值内；对日期、金额这类字段，明确要求原样保留原文表述还是归一化格式，两者不要混用。

{
  "party_a": "string",
  "effective_date": "YYYY-MM-DD | null",
  "amount": {"value": "string", "currency": "CNY|USD|other|null"},
  "termination_clause_present": true
}

失败重试策略

解析失败分三类，处理方式不同：

1. 格式错误（JSON 不合法、字段缺失）：把解析错误信息回传给模型，要求仅修正格式后重出，通常一次重试即可收敛。
2. 语义歧义（原文确实没写该字段）：允许返回 null，并在结果中带上 needs_review 标记，进入人工队列，而不是让模型猜。
3. 规则冲突（模型给出的值与校验规则矛盾，如金额为负）：直接判失败，不要反复重试，改走人工。

抽取场景最忌讳的是无限重试。设定次数上限（例如两次），超过就落人工，并把这次输入加入评测集，作为后续提示迭代的样本。

场景二：长文档的摘要与关键信息定位

长文档的难点在于上下文长度和答案定位。一次性塞入整份文档既贵又不稳定，模型容易在中间段落丢失细节。可行的做法是分段、聚合、回溯三步走。

分段策略

按语义边界切，而不是按固定字符数硬切。标题层级、章节编号、空行都是天然的切分点。每段保留一段「来源元信息」（章节名、页码、段落序号），后续引用回溯全靠它。段落长度控制在模型能稳定处理的范围内，太长就再拆，太短则合并，避免碎片化导致语义断裂。

两阶段聚合

第一阶段对每段做局部摘要，并要求输出这一段的要点列表，而不是连贯长文。第二阶段把各段要点拼成结构化摘要，让模型做去重、归并与排序。对于「找出关于某条款的所有表述」这类定位任务，第一阶段只做相关性打分与摘录，第二阶段才生成回答，并强制要求返回来源段落编号。

关键点：让模型在回答里带上引用来源，是抑制幻觉最便宜的手段。没有出处的结论，在流程上视为无效。

引用回溯

把模型返回的段落编号映射回原文位置，展示给用户时可点击跳转。这一步同时是校验手段：如果模型给出的编号不存在或与内容不符，说明分段元信息可能没被正确理解，需要检查提示中的编号格式，而不是先怀疑模型能力。

成本控制

摘要任务按 token 计费，输入长度是主要成本来源。可行的压缩手段包括：去掉页眉页脚与重复模板文字、只送与问题相关的段落、局部摘要复用（同一文档多次问答时缓存分段摘要）。缓存分段结果往往比优化提示词带来的节省更直接。

场景三：客服与售前对话的应答辅助

对话辅助是文本模型最容易见效、也最容易出事故的场景。见效在于它能快速生成语气得体的初稿；风险在于一旦自动发送，错误话术会被放大。

输入组织

一次调用至少包含三块内容：用户消息、检索到的知识片段、以及对话历史。三者顺序建议固定为「系统约束 → 知识片段 → 对话历史 → 当前问题」，并在知识片段上标注来源标题。不要把整份帮助中心塞进提示，按问题检索出少量高相关片段即可。

提示结构与边界

系统约束里要写清四件事：允许说什么、不允许承诺什么、无法回答时如何回复、输出长度上限。尤其是「不确定就说不确定，并转人工」这条，必须在提示中显式写出，否则模型倾向于用流畅的话术掩盖知识缺口。

置信门控与人工复核

用户消息 → 检索知识片段 → 模型生成草稿 →
  ├─ 有出处且通过规则校验 → 进入待发送队列（可配置自动发送）
  └─ 无出处 / 触发敏感规则 / 长度异常 → 转人工复核

门控条件应基于可观测信号，例如草稿是否引用了检索片段、是否命中敏感词与承诺类表述、检索相似度是否过低。把这些条件做成显式规则，比让模型自评「我有没有把握」更可靠。

上线节奏

建议从「只给人工看、不发送」起步，积累一批草稿与人工修改的对照数据，再逐步放开低风险类目。自动发送永远配一个熔断开关。

场景四：代码与配置的审查辅助

代码审查辅助的价值不在于让模型替代 reviewer，而在于让它在人之前把明显问题扫一遍，减少重复劳动。

输入组织

只送 diff，不送整个仓库。每处改动附带文件路径、函数上下文与必要的相邻行。日志和配置片段同理：截取与异常相关的窗口，而不是整份日志。输入里明确告诉模型「这是 diff，+ 为新增行」，避免它把上下文行误判为改动。

审查维度的拆分

一次性让模型「全面审查」往往得到泛泛而谈的结论。把维度拆开更有效：

• 空值与边界：新增分支是否覆盖了 null、空集合、越界输入。
• 资源与并发：打开的资源是否释放，共享状态是否有竞态。
• 配置风险：超时、重试次数、开关默认值是否合理。
• 可读性：命名与注释，优先级最低，可单独一轮。

分轮调用虽然增加了调用次数，但每轮提示更短、结论更聚焦，通常比一轮长提示更划算。

抑制误报

误报是这类功能被放弃的主要原因。三个手段：要求模型给出具体的行号与问题描述，不能泛泛而谈；要求以「建议 / 问题 / 阻断」分级，只有「问题」与「阻断」进入提醒；把历史误报整理成反例写进提示。对无法定位到具体行的结论直接丢弃。

另外要让模型明确：不确定时标注「需人工确认」，而不是给出确定语气。审查结果应作为评论挂在 MR 上，不阻塞合并。

场景五：内容生成与批量文案改写

批量文案是投入产出比直观的场景，但也是最容易产出「看起来都对、实际上不能用」的内容。核心矛盾是规模化与风格一致性。

约束前置

把风格要求写进系统提示，并且给出两到三个正例和一个反例。相比抽象描述「语气专业」，具体例句更能约束输出。字段化的约束更好：字数范围、人称、是否允许感叹号、必须包含的关键词、禁止出现的表述。

模板与变量分离

把固定模板与可变变量分开，variable 部分用结构化数据注入，而不是拼进一段自由文本。这样同一套模板可以批量跑不同商品或不同活动，也便于出错时定位是模板问题还是数据问题。

抽样质检

全量人工审核在批量场景不可行，但全自动发布风险过高。建议分两层：

1. 自动校验：长度、禁用词、关键词覆盖、重复度、格式合法性。规则能拦住的不要交给模型。
2. 抽样复核：按批次随机抽取固定比例人工阅读，并优先抽自动校验接近边界的样本。

抽样比例按业务风险调整，风险高的类目提高比例甚至全检。每轮抽样发现的问题，回灌到提示与规则里，形成闭环。

一致性的度量

一致性可以量化：同一批输入多次生成，比较关键字段的稳定率和文本相似度。稳定率明显偏低的模板，说明约束不足，应先改提示而不是加大审核。批量任务还有一个隐性成本：重试与返工。一次生成合格率提升带来的 token 节省，往往超过精简提示本身的收益。

接入要点：提示结构、校验与成本控制

跨场景的通用工程做法可以归纳为一条流水线：输入归一化 → 提示模板 → 模型调用 → 输出校验 → 计量与回归。

提示分层

把提示拆成三层，各自独立维护：

• 系统层：角色、边界、禁止事项、输出格式契约。改动少，评审严。
• 任务层：本次任务的具体指令与 schema。按场景维护模板。
• 数据层：用户输入与检索片段。只做归一化，不写指令。

分层的直接好处是评测可归因：效果变差时，能快速判断是模板改动还是数据变化。

输出校验

所有输出都应经过校验再进入下游：结构校验（JSON 能否解析、字段类型是否匹配）、业务校验（枚举、范围、交叉字段一致性）、来源校验（引用是否存在于输入中）。校验失败走重试或人工，不要让异常输出静默通过。

成本控制

模型按 token 计费，成本主要来自输入长度与调用次数，而非单次输出。可压缩的方向：

• 缩短输入：检索代替全量投喂，去掉模板性重复文本。
• 减少次数：合并同批任务、缓存稳定的中间结果（如分段摘要、分类结果）。
• 约束输出：明确长度上限，避免长篇解释；抽取任务只要 JSON，不要推理过程。
• 分级处理：先用小模型或规则做粗筛，只把疑难样本交给更强的模型。

具体单价与计费细则请以站点价格面板为准，工程上要做的是把「每次调用消耗多少 token」变成可观测指标，按场景统计，才能定位真正的成本大头。

可观测性

至少记录：请求的场景标识、输入输出 token 数、耗时、校验结果、重试次数。这些数据是后续优化提示与预算的唯一依据。没有计量就没有优化，只有猜测。

上线前的评估与排错清单

上线前先把「怎么算成功」写清楚，再谈接入细节。下面这份清单可以直接拿去用。

评估清单

• 是否有一份人工标注的评测集，覆盖典型样本与边界样本，规模足以支撑结论？
• 每个场景是否有明确的验收指标：抽取的字段准确率、摘要的引用命中率、对话的转人工率、审查的误报率？
• 是否定义了失败路径：格式错误、语义歧义、规则冲突分别怎么处理？
• 提示模板是否版本化，改动是否可回滚？
• 成本是否按场景统计，并设了预算与告警？
• 是否有灰度与熔断机制，出问题能否一键降级到纯人工？

排错清单

问题出现时，按顺序排查，避免直接归因于「模型不行」：

1. 先看输入：送进去的内容是否完整、顺序是否正确、有没有混入脏数据或过期文档。
2. 再看格式：输出解析失败，多半是提示里的格式契约不够硬，而不是模型理解不了。
3. 再看校验：校验规则本身是否有 bug，是否把正常输出误判为失败。
4. 最后看能力边界：用同一批样本在人工基准上对比，确认是真的超出模型能力，还是样本本身有歧义。

一个实用的经验：同一提示连续多次失败、且错误模式一致，通常是提示或数据问题；错误模式随机分布，才更可能是能力边界或采样噪声。

把评估与排错做成固定流程，模型换版本时才能快速判断该不该跟进。需要对照文档确认接入方式时，可在站内模型页查看参数与调用说明。团队真正需要建立的资产不是某一次的提示词，而是这套可复用的评测、校验与计量机制。