企业官网建设流程全解析

Claude Opus 5 的讨论热度来得快，去得也快。标题里的“失宠”更像是一个工程现象：某款模型在评测榜上被推得很高，团队切换到线上后却没有得到预期收益，甚至因为成本、延迟或输出格式不稳定重新切回原模型。如果只是围观这场讨论，很容易把问题归结为“模型不够好”，但真正值得复盘的是选型方法。大模型应用的决策链路上，最危险的一句话就是“大家都说它最强，直接换”。

这篇文章不评价 Claude Opus 5 本身的能力高低，而是从工程角度回答一个更实际的问题：当一个新模型出现，团队应该用什么流程决定“要不要换”，以及换了之后如何验证、如何灰度、如何回滚。文章会围绕场景拆解、评测集建设、指标设计、灰度切换、问题排查五个环节展开，最后给出可以直接复用的模型选型检查清单。

1. 为什么默认某款模型最强，在大模型应用里最危险

1.1 榜单分数和真实业务之间存在三种偏差

大模型的能力榜单通常覆盖数学、代码、常识问答、多轮对话等通用任务。这些任务和实际业务请求之间，存在三种容易被忽略的偏差。

第一种是分布偏差。榜单里的题目分布来自公开数据集，而你的线上请求来自特定的业务形态，比如客服工单、合同抽取、医疗问答、电商评价分类。一个模型在通用知识榜单上表现好，不代表它在你这个垂直领域里同样强。尤其当业务语料带有行业术语、产品名、内部流程时，模型之间的差距会明显变化。

第二种是期望偏差。榜单题目通常有固定答案，评测只看对错。但业务系统往往要求模型输出可解析的 JSON、遵守固定枚举值、不输出敏感内容、不编造事实。模型语义上答对了，但输出多了一段解释、改变了一个字段名、把布尔值写成了字符串，下游解析就会失败。这种格式层面的失败，在榜单分数里根本看不到。

第三种是时效偏差。榜单分数是一个时间点的快照，模型 API 后面的版本可能在更新，提示词策略可能调整，多模态行为也可能变化。今天测出来排名第一的模型，三个月后未必还是同样的表现。如果团队只看一次评测结果就固定选型，等于把决策建立在一个会漂移的基准上。

1.2 “失宠”的常见业务原因不只是能力不足

一款模型从被追捧到被换掉，在真实业务里通常不是因为它“变笨了”，而是因为它没有满足工程约束。常见原因主要有五类。

成本因素占第一位。旗舰模型的单次调用价格通常高于标准模型，如果业务日调用量很大，模型“聪明”带来的收益可能覆盖不了成本的上涨。尤其是长上下文场景，输入 token 一多，成本会成倍增长。

延迟因素排第二。能力更强的模型往往需要更长的思考时间，非流式接口的总耗时和首 token 时间都会变长。如果产品要求用户在几秒内看到回复，延迟超标就无法接受。

第三是输出格式不稳定。有的模型在生成 JSON 时会自动加 Markdown 代码块标记，有的会输出多余注释，有的字段名会变化。这些问题在评测里如果只做人工阅读，很难提前发现。

第四是领域短能力。通用能力强不代表特定场景强，比如复杂合同条款识别、长文档关键信息抽取、企业私有知识库检索增强回答，在不同模型之间差异很大。

第五是行为变化。同一次升级后，模型对同一段敏感输入的回复可能从保守变成激进，或者从拒绝回答变成给出带风险的建议。这种安全策略的变化，会在灰度时突然暴露。

1.3 把“最强”问题改写成可验证的工程问题

正确的做法不是争论“谁最强”，而是把问题改写成：在当前业务场景、成本上限、延迟约束下，哪个模型最合适。

这意味着选型是一个多目标决策，而不是单点排名。团队要先把业务场景拆成一类一类的评测单元，再为每个单元定义验收标准，然后用统一流程跑出可对比的数据。只有到了这一步，模型选型才从“印象流”变成“可复现、可审计”的工程问题。

2. 先把业务场景拆成评测单元，再谈模型对比

2.1 定义场景和约束

在整理评测集之前，先要明确业务到底需要模型完成什么任务。建议从六个维度描述每个场景：

• 任务类型，包括文本分类、信息抽取、摘要生成、代码生成、工具调用、多轮对话。
• 输入形态，包括纯文本、图片加文本、长文档、表格、URL 内容。
• 输出约束，包括 JSON 结构、枚举值、Markdown、代码片段。
• 响应要求，包括首 token 时间、总耗时上限。
• 成本要求，包括单个调用预估最高费用。
• 安全红线，包括禁止输出的内容类型、隐私字段脱敏要求。

例如“客服工单摘要”这个场景，任务类型是抽取加摘要，输入是用户留言，输出必须包含 summary 和 action 两个字段，且不能编造处理结果。定义越具体，后续评测越容易执行。

2.2 收集真实输入，不要只靠团队自己编

评测样本的质量决定选型结论的可靠性。只靠项目成员凭经验编写十几条 prompt，通常会遗漏线上真实的高频情况。推荐按以下顺序收集样本：

• 从线上日志中抽样最近一到三个月的真实用户请求。
• 从客服工单、运营反馈、用户投诉中提取典型问题。
• 从历史错误案例中补充边界情况，比如空文本、超长文本、方言、错别字、混合语言。
• 从公开数据集中补充少量通用能力样本，用于观察基础能力变化。

样本进入评测集前必须做数据脱敏。凡是包含姓名、手机号、地址、订单号、内部系统路径等内容，都要替换成模拟数据，避免评测过程产生隐私泄露。

2.3 用 must 项和 nice to have 项定义验收标准

每个评测用例不能只给一个“理想答案”，因为人工对标准答案的判断容易不一致。更可靠的做法是给每个用例定义 must 项和 nice to have 项。

• must 项：不满足即判失败，比如“必须包含订单号”“不能编造物流时间”“输出必须符合 JSON Schema”。
• nice to have 项：满足更好，但不决定成败，比如“语言简洁”“主动给出下一步操作建议”“语气礼貌”。

下面是一个评测单元定义的例子：

建议先做 50 到 100 条种子样本，跑第一轮评估，再逐步扩充到几百条。样本太少时，模型之间的几个 case 差异就会改变结论，不具备稳定性。

3. 用统一评测集做横向对比，数据才可信

3.1 评测用例的结构化格式

评测集不应该是散落的文本文件，建议用 JSON 或 YAML 管理每个用例。结构化格式方便自动化脚本读取，也方便后续做版本对比。

下面是一个评测用例的示例结构：

{ "case_id": "cs-summary-001", "scenario": "客服工单摘要", "input_text": "用户说：我上周在平台下了一个订单，订单号是 880102，付款已经完成了，但是订单页面一直显示待发货，已经两天了。", "expected": { "must_contain": ["880102", "已付款", "待发货"], "must_not_contain": ["已发货", "退款"], "output_schema": { "type": "object", "properties": { "summary": { "type": "string" }, "action": { "type": "string" } }, "required": ["summary", "action"] } }, "note": "客服需要先安抚用户，再核查发货状态，不能直接承诺时间" }

这个结构包含了模型输入、预期约束和备注。自动化脚本可以用 must_contain 做关键词检查，用 output_schema 做 JSON 结构校验，再用人工抽查处理语义层面的判断。

3.2 对比时必须统一参数，否则结果不可比

多个模型横向对比时，最大的坑是各个模型使用的参数不一致。比如一个模型用 temperature 0，另一个用 0.7，后者的输出差异可能来自随机性，而不是模型能力。

建议在评测记录中固定这些参数：

同时要把每次评测的时间、模型名称、调用参数、结果都记录下来。没有这些元信息，评测数据无法复现。

3.3 人工评估和 LLM-as-judge 怎么配合

评测结论不能完全依赖人工打分，因为人看多了会疲劳，标准会漂移；也不能完全依赖另一个大模型打分，因为 judge 模型本身也有偏好。

推荐组合方式：先程序化校验硬性约束，再让人工或 judge 模型校验语义质量。

• 程序化校验：检查 JSON 格式、枚举值、关键词是否出现、字段类型是否正确。
• LLM-as-judge：用于给“答案是否有帮助”“是否忠于原文”这类开放指标打分。注意不要用被评模型自己给自己打分，避免偏好偏差。
• 人工抽检：对自动判为通过和失败的用例各抽一部分，确认判断标准没有跑偏。

每次评估都要保存原始输出，不要只保存分数。没有原始输出，后续发现分数异常时无从排查。

3.4 输出格式校验要写进评测流程

很多模型在真实业务里“翻车”不是因为内容错，而是因为格式无法解析。评测流程必须在打分前增加输出格式校验步骤。

一个常见问题是模型把结果包在 Markdown 代码块里，导致 JSON.parse 直接失败。此时应该先做一层清理，把代码块标记剥离，再解析 JSON。但也要记录清理前的原始输出，因为如果模型频繁需要清理才能解析，说明格式稳定性差，不适合直接接入生产。

注意：评测的目标不是找到一个“大部分时候能用的模型”，而是找到在下游解析、安全限制、成本约束下稳定工作的模型。格式问题在评测阶段就必须暴露。

4. 比完准确率后，延迟、成本和稳定性才是决策关键

4.1 建立多维指标表

技术选型会议最怕只摆一个准确率数字。准确率只代表“内容正确性”，不代表系统能稳定服务。建议至少收集以下指标：

这些指标共同决定一个模型能不能接入生产，不能只看其中一项。

4.2 延迟测试要注意流式和非流式的区别

延迟测试不能只测一个总耗时。要区分流式接口和非流式接口，并分别记录 TTFT 和完整响应时间。

流式接口更适合交互型应用，用户看到首 token 后等待焦虑会下降。非流式接口更适合批处理任务，但完整响应时间会更长。对于同一个模型，输入长度从 500 token 提升到 5000 token，TTFT 和总耗时可能变化很大。因此压测要用接近线上真实分布的输入长度，而不是用几个短 prompt 估算。

4.3 成本估算要基于 token 统计，而不是拍脑袋

成本估算最容易漏掉的点是输出 token 数。不同模型在相同任务上的输出长度差异很大，有的模型喜欢先分析再给结论，输出 token 数会明显更多。

单次调用成本公式：

单次成本 = (输入 token 数 / 1,000,000) × 输入单价 + (输出 token 数 / 1,000,000) × 输出单价

如果模型版本支持输入缓存，公式要加上缓存命中率：

单次成本 = (缓存命中 token / 1,000,000) × 缓存读取单价 + (未命中输入 token / 1,000,000) × 输入单价 + (输出 token 数 / 1,000,000) × 输出单价

实际估算时可以跑一批真实请求，分别统计平均输入 token、平均输出 token，再套进公式。不要只用模型官方示例来估算，因为业务 prompt 里常包含大量固定模板，会影响输入长度。

4.4 稳定性测试必须包含重复调用和长期观察

稳定性包含两层含义：单次重复调用的输出一致性和跨时间的行为漂移。

重复调用测试很容易做，挑 20 到 30 个代表性用例，每个跑 3 到 5 次，统计有哪些 case 的输出结果发生变化。变化越大，意味着生产环境越难做结果缓存和可预期判断。

长期观察需要做第二次或第三次评测。比如在首次评测完成的四周后，用同一套评测集再跑一次，观察分数是否变化。如果模型 API 版本更新导致行为漂移，团队就能在灰度前发现。

5. 从评测通过到灰度上线，中间还隔着一条生产链路

5.1 先用影子模式收集新模型在真实流量上的表现

评测集再完善，也覆盖不了线上所有输入变化。正式切换前，建议先做影子模式。

影子模式的思路是：线上请求正常发给当前模型，同时复制请求发给新模型，但新模型的返回结果不返回给用户，只写入日志或存储，供后续对比分析。

影子模式可以回答几个问题：

• 新模型在真实线上输入上的输出格式是否稳定。
• 新模型和当前模型在相同输入下的答案差异有多大。
• 新模型的响应时间是否满足生产要求。
• 新模型的输出是否触发额外的安全策略或敏感词拦截。

影子模式的主要成本是双倍 API 费用，所以建议按采样率运行，比如只复制 10% 到 30% 的请求，而不是全部流量。

5.2 灰度策略要按业务特征控制

影子模式验证结束并不代表可以直接切全量。建议按灰度阶梯逐步放量，每一阶段都要观察错误率、延迟、成本和用户反馈。

常见的灰度阶段：

• 5% 内部用户：先给自己团队或内部体验用户，第一时间发现明显问题。
• 20% 低风险流量：选择对错误容忍度较高的场景，比如辅助写作，而不是支付相关的决策。
• 50% 核心场景：此时要观察指标是否显著变差。
• 100% 全量：只有前三个阶段没有问题才推进。

灰度期间要保留当前模型作为备用。不要一升级就把旧调用代码直接删掉，否则回滚时还要重新开发。

5.3 回滚和熔断要提前设计

模型切换经常出现“灰度数据看起来还行，放量后开始报错”的情况。如果回滚开关没有提前设计，故障时间会被拉长。

建议满足以下条件时就自动或手动回滚：

• 错误率超过 1%，或者连续多次请求返回 5xx。
• P95 延迟超过业务允许的上限。
• 单日 API 费用超过预算阈值的 150%。
• 用户投诉量明显上升。

回滚操作应该是一个开关，而不是改代码重新发版。模型名称、API Key、切换开关、参数配置都应该外置到配置中心或环境变量中，运维人员能在控制台上快速切换。

注意：灰度观察不能只看平均值。要按业务场景拆开看，比如“长文档摘要”和“短文本分类”可能表现完全不同。某一个场景拖垮平均值时，要能定位到具体场景。

5.4 切换前检查清单

下面的检查清单可以直接用于发布评审：

6. 切换后效果变差，按这条链路查

6.1 评测通过但线上效果差

现象：评测集达标率很高，灰度后用户反馈准确率下降。

可能原因：线上输入分布和评测集分布不一致。评测集里高比例是规整文本，线上却存在大量错别字、口语化表达或超长内容。

检查方式：随机抽取线上请求，重新补充进评测集，回放对比。看新模型在哪些输入上表现差，这些输入在评测集中占比是多少。

处理建议：扩充评测集，加入线上真实样本，重新跑一轮对比。不要把评测集当成一次性的，要持续迭代。

6.2 输出格式不稳定

现象：模型返回内容语义正确，但 JSON 解析失败比例高，或者字段名偶尔变化。

可能原因：提示词里对输出格式的约束不够强；模型行为不同，有的模型对 JSON Schema 跟随能力弱；输出被 Markdown 代码块包裹。

检查方式：查看解析失败样本的原始输出，统计失败类型。是多了代码块标记，还是字段类型错误，还是多余字段导致校验失败。

处理建议：在提示词中加入 few-shot 示例；启用 API 的原生 JSON 模式或结构化输出能力；在解析层增加容错清理，但要在评测中监控清理频率。

6.3 成本超出预算

现象：灰度后账单上涨明显，超出了评测时的估算。

可能原因：线上输入 token 比评测样本长；新模型输出倾向写长文；重试次数过多放大了成本。

检查方式：按场景拆分 token 统计，分别看输入 token 和输出 token 的分布。重点排查长尾请求，比如超长文档摘要。

处理建议：设置 max_tokens 上限；对长文档先做切片，再分段处理；考虑加缓存层；在路由层把简单任务分流到成本更低的模型。

6.4 用户投诉变多

现象：回答风格变化、拒绝回答比例上升、处理问题方式不一致。

可能原因：新模型的系统提示词对齐不够；不同模型对安全规则的执行强度不同；多轮对话中的上下文风格不一致。

检查方式：导出投诉样本，对比新旧模型在相同输入下的输出。关注拒绝率变化和敏感话题处理差异。

处理建议：对齐 system prompt 和安全策略；如果问题集中出现在特定场景，可以先用路由层把该场景切回旧模型；无法解决时回滚。

7. 模型选型不是一次性决定，而是一套持续流程

7.1 定期重测，避免模型行为漂移

模型选型结论有时效性。当出现这些情况时，要重新触发评测：

• 新模型版本发布。
• 模型服务商调整价格。
• 业务语料发生重大变化，比如新产品线上线。
• 距离上次评测超过一个季度。
• 线上投诉或错误率异常上升。

重测时优先跑同一套种子评测集，保证结果可对比。同时扫描线上日志，补充新出现的请求模式。

7.2 用多模型路由避免单点绑定

业务不必把所有场景都绑定在一个模型上。更稳妥的做法是按任务难度和风险等级做路由。

简单场景可以这样设计：

• 低成本小模型处理短文本分类、关键词抽取、打标任务。
• 标准模型处理常规摘要、基础问答、信息提取。
• 旗舰模型只处理复杂推理、长文档理解、高风险决策辅助。

路由层可以基于规则，比如输入长度超过阈值、任务类型属于复杂推理、抽取结果置信度低于某个值时，升级到更强模型。也可以用小模型先做意图识别，再决定调用哪个模型。

这样做的好处是让成本可控，同时避免“一个模型失败，整个业务不可用”。

7.3 沉淀三类资产：评测集、对比报告、切换 Runbook

团队真正可以长期复用的不是某次选型结论，而是选型过程中沉淀的资产。

评测集要纳入版本管理，包含用例、标注结果、历史评测记录。每次评测都要能回答“上次我们是怎么得出这个结论的”。

对比报告要记录模型名称、调用时间、评测集版本、各项指标、结论和负责人。报告不是给人看的，是给未来决策提供依据的。

切换 Runbook 要写成能照着执行的操作手册，包含配置项位置、灰度命令、回滚开关、监控面板链接。做一次模型选型后，把这次操作整理成 Runbook，下次换模型时能节省大量时间。

7.4 区分学习环境和生产环境的要求

本地或开发环境可以快速试错，用简化 prompt 和最小样本验证思路，这时不需要严格的评测流程。

生产环境则必须补上几件事：数据脱敏、访问审计、限流控制、日志留痕、成本监控、权限隔离。学习环境跑通的 prompt，直接复制到生产环境往往要补充大量约束。

实践建议：把评测集和切换 Runbook 纳入工程资产，放在代码仓库里管理。新人接手时可以按 Runbook 快速完成一次模型对比，而不是靠问老同事“上次是怎么换的”。

回到题目中的“无默认赢家”。这不是否定 Claude Opus 5 或任何新模型的价值，而是提醒团队：模型能力会快速变化，业务需求也在变化，没有哪一个模型能永远默认胜出。真正能长期使用的是那套评测集、灰度流程、监控指标和切换机制。把模型当作可以替换的组件，比把模型当作答案更稳妥。