写这个系列，第一篇我不想直接上指标。原因很实际：如果连要评的对象是什么、由哪几块性质不同的能力拼成都没看清，后面建的用例和红线很容易站错前提。所以这一篇先把全景图画出来，后面各篇里出现的每个指标、每条红线，都能在这张图上找到位置。
走法是循序渐进的：先认清楚这个产品长什么样、跑在哪一代模型上，再逐块拆能力，然后看块与块之间怎么咬合，最后落到"非确定性"这个评测绕不开的根，以及怎么据此搭体系。第一件事不是写用例，是把评测对象看明白。
一、豆包已经不是"一个聊天助手"
我刚开始用豆包时，也把它当聊天工具。但这个描述用来指导评测会出问题，放到现在更不准了。先看几个公开数字（来源都在文末列了，正文里不逐一标注，数据截至 2026 年 7 月）：
- 截至 2025 年 12 月，豆包 App 日活（DAU）突破 1 亿（中金公司援引市场数据、36 氪报道），此后一直稳居国内 AI 应用月活第一；
- 2025 年 11 月，豆包以 2.72 亿月活登顶中国 AI 应用月活榜首，QuestMobile 显示其周活 1.55 亿；
- 火山引擎披露，豆包大模型日均 Token 调用量截至 2026 年 6 月已突破 180 万亿，较两年前增长约 1500 倍；
- 豆包 App 内已创建超过 800 万个智能体（Agent）；
- 截至 2026 年 6 月，豆包大模型已在超过 7 亿智能终端上运行，服务 110 万以上企业及个人开发者（火山引擎 FORCE 大会披露）。
一个日活破亿、每天扛 180 万亿 tokens、跑着 800 万个智能体的东西，我更愿意把它看成把若干种性质不同的能力装在一起的平台，而不是单一对话产品。
这也带来一个直接的评测问题：它不是"一个功能"，是五种能力外加一个系统级 OS 交付层拼起来的系统。我见过一些团队拿一把"评对话"的尺子去量全部，用对话标准衡量 Agent、用语音标准衡量创作，结论自然是歪的。转到大模型这边做评测，第一个坑往往就在这里。
所以在写用例之前，先把这张能力全景图画出来。后面每篇的指标、红线，都是这张图的局部放大。
二、豆包长在哪些终端上
评一个产品，得先知道它以什么形态触达用户。豆包现在不是"一个 App"，是一整套终端矩阵。我把公开能查到的形态整理一下：
软件端（据豆包官网及公开资料）：
| 形态 | 具体载体 | 对评测的含义 |
|---|---|---|
| 移动端 | iOS / Android App | 主战场，DAU 破亿都在这，评测样本最大 |
| 桌面端 | Windows / macOS 客户端 | 长文档、编程、多窗口场景，交互路径不同于手机 |
| 网页端 | www.doubao.com | 无需安装，评测环境最易复现 |
| 浏览器插件 | Chrome / Edge 等 | 网页内唤起，考验上下文注入能力 |
硬件端 / 系统端：
| 形态 | 具体载体 | 对评测的含义 |
|---|---|---|
| 智能硬件 | Ola Friend AI 耳机（2024.10 发布，业内首款 AI 智能体耳机）、AI 玩具 | 纯语音链路，没有屏幕兜底，语音评测权重陡增 |
| OS 级入口 | 豆包手机助手技术预览版（2025.12，深度系统合作的"AI 手机"） | 直接调起系统、操作设备，OS 集成从概念变成产品 |
我习惯先讲形态，是因为同一个能力在不同终端上的评测标准不一样，这个坑踩过才记得牢。
拿"帮我定明天 9 点的闹钟"举例。在 App 里用户能看到确认弹窗，AI 理解偏了也能手动改，容错高。在 Ola Friend 耳机上没有屏幕，用户只能靠听反馈，ASR 听错时间或 TTS 播报含糊，任务就废了，几乎没有容错。
这就是后面语音、OS 场景反复强调端到端评测的原因。脱开形态谈能力，测出来的分数对不上真实体验。我做评测设计，一般会先锁定要覆盖哪些终端，每个终端单独建测试入口和断言方式，而不是一套 case 通吃。
三、你评的是哪一代模型
形态是骨架，模型是里子。评测得清楚自己评的是哪一代能力，不然这个月的结论下个月就可能因为模型迭代作废。
豆包背后不是一个模型，是一个迭代很快的家族。我按火山引擎历次发布会和媒体报道理了一条时间轴：
| 时间 | 关键发布 | 能力跃迁点 |
|---|---|---|
| 起步 | 云雀模型 | 豆包最初的底座 |
| 2025.01 | 实时语音通话上线 | 语音交互从"听写"走向"对话" |
| 2025.03 | "深度思考"功能（边想边搜） | 引入推理 + 检索融合 |
| 2025.04 | 豆包 1.5 深度思考模型 | MoE 架构，总参 200B / 激活 20B，推理成本较业界降约 50% |
| 2025.05 | 实时互动视频通话 | 多模态从"看图"走向"看视频对话" |
| 2025.06 | 豆包大模型 1.6（Force 原动力大会） | thinking 版 GPQA Diamond 81.5、AIME25 86.3；支持深度思考 / 多模态 / 256k 长上下文 / 图形界面操作 |
| 2025.06 | AI 播客模型、实时语音模型、Seedance 视频生成 | 语音与视频生成走向生产级 |
| 2025.10 | 豆包 1.6 升级 + 语音合成 2.0 / 声音复刻 2.0 | 国内首个原生"分档调节思考长度"（Minimal / Low / Medium / High），低档输出 tokens 降 77.5%、思考时间降 84.6% |
| 2025.12 | 豆包 1.8（Doubao-Seed-1.8）+ Seedance 1.5 pro | 面向多模态 Agent 定向优化，BrowseComp 全球领先；工具调用 / 复杂指令遵循 / GUI Agent / OS Agent 能力增强 |
| 2026.06 | 豆包 2.1 系列（Doubao-Seed-2.1，Force 原动力大会 6.23 发布） | Pro / Turbo / Evolving 三档；Coding、Agent、VLM 三大方向能力跃升，200K 上下文，多项评测接近 GPT-5.5 / Claude Opus 4.7；日均 Token 调用突破 180 万亿 |
| 2026.06 | Seedance 2.5 视频生成、Seedream 5.0 Pro 图像、Seed-Audio 1.0 音频 | 多模态生成走向生产级；Seedance 2.5 于 2026.07.06 上线，支持 30 秒原生视频、50 个全模态参考素材联合输入 |
这条线里我看下来对评测重心影响最直接的，有三处变化。
一是从"回答问题"到"执行任务"。早期大模型更像个知识库，你问它答。豆包 1.8 明显往执行器方向做，强化的是工具调用、GUI Agent、OS Agent。评测重点也跟着从"答得对不对"挪到"事做没做成"。对做过功能测试的人，这块反而熟，结果验证本来就是老本行。
二是从"一档思考"到"分档调节"。1.6 升级后有四档思考长度，本质是在效果、时延、成本之间做取舍。评测就不能只看最高档答得多好，还得看每档的性价比。这个维度传统软件测试里没有对应物，是大模型评测才有的新东西。2.1 系列里的 Evolving 版本甚至以每月 2 到 4 次的频率滚动更新，版本快照这步比以前更省不掉。
三是从"能答"到"能交付"。2.1 Pro 主打生产级 Agent，官方展示过一个连续自主运行近 18 小时、完成 9 轮迭代的芯片设计 Agent 案例。评测重心进一步从单点正确挪到长链路稳定交付，这对 Agent 编排那一节的"任务完成率 + 步骤级准确率"是直接的呼应。
落到操作上，我每次跑评测都会记模型版本号和档位，结论才能回溯，下个版本迭代时直接做回归对比。这步看着琐碎，但版本乱了后面全乱。
四、五大能力，各评各的
豆包这五种能力各是一块独立战场。先看总览：
| 能力 | 用户看到的 | 评测要关注的核心 |
|---|---|---|
| 文本对话 | 聊天、问答、创作 | 正确性、流畅性、安全性、时效性 |
| 语音交互 | 说话、听写、播客 | ASR 准确率、TTS 自然度、端到端延迟 |
| 多模态理解 | 看图说话、拍照问答、拍照解题 | 图文一致性、OCR 精度、视觉推理、解题正确率 |
| Agent 编排 | 订日历、查天气、发邮件、生成 / 编辑 PPT | 工具调用、多步编排、任务完成率 |
| AIGC 生成 | 文生图、文生视频、音乐 / 音频生成 | 画面 / 视频质量、时序一致性、提示词遵循度、审美一致性 |
下面逐个说到能落地的程度，每个能力给指标、给判法、给数据从哪来，也顺手标一下业界常用的参考基准，方便你想深入时按图索骥。
4.1 文本对话
豆包的基本盘，评测难度常被低估。聊天谁都会用，但"好不好"是主观的，最难量化。
正确性看有没有幻觉，幻觉分两类。事实性幻觉是张冠李戴、编造不存在的事；忠实性幻觉是偏离了给定材料（比如总结一段文案却加了原文没有的承诺）。判法上，封闭事实题用标准答案集做自动精确匹配或语义匹配；开放式问答用更强的模型当裁判（LLM-as-judge）。这个范式是 Zheng 等人在 2023 年的 MT-Bench 工作里跑通的，现在工业界基本沿用，但裁判模型本身要校准，避免它把错的判成对。我自己的做法是先拿人工标注集跟裁判模型对齐，确认一致率够高再批量用。评测集最好从真实用户 query 日志里抽样再人工标注 golden answer，比纯人工造题更贴生产分布。幻觉这块也有 HaluEval、FaithEval 这类公开基准可以参考。
安全性覆盖涉政、涉黄、诱导、越狱。越狱主要三类手法：角色扮演诱导、payload 拆分、上下文淹没。评测要做对抗样本集，按触线率计数，安全漏过率大于 0.1% 就一票否决（红线在第十节）。这条是发布闸门，不是打分维度。
流畅性看表达自然、拟人化程度。客观可用困惑度（perplexity）粗筛，主观靠人工或裁判模型按 1 到 5 分打自然语言质量。豆包刻意做拟人（罗永浩同款"吵架搭子"是例子），拟人过头会混进过度承诺，所以流畅度评测要同时盯有没有虚假陈述裹进去。
时效性看回答里时间敏感信息够不够新，配合"边想边搜"一起评。带时间锚点的 query（"今天油价""最新版本号"）专门用来验证它有没有真去检索、结果新不新鲜。
对转岗做测试的人，正确性对应你熟的功能验证，安全性对应边界测试和异常输入，思路能直接搬，只是判定从"对错"变成"是否触线"。
4.2 语音交互
语音是豆包增长很快的一块（2025 年 1 月实时语音通话、5 月实时视频通话、6 月 AI 播客密集上线，语音合成迭代到 2.0）。
它难评在链路长：一句话要过唤醒、ASR、大模型理解、TTS、播报至少五个环节。每个环节的指标和判法分开说。
ASR 的核心指标是词错率（WER，word error rate），越低越好，这是语音识别领域的老指标了。测试集要分场景：安静室内、街道噪声、方言、带口音普通话，四类独立报分。还要看流式识别（边说边出字）和标点恢复做得怎么样。
TTS 看自然度，用 MOS（mean opinion score，主观平均意见分）盲测 1 到 5 分，这个打分流程按 ITU-T P.800 建议走；客观可用 DNSMOS（微软提出的无参考指标）兜底。豆包语音合成 2.0（2025.10 上线）主打读复杂公式，要单测数字、英文混读、公式符号的准确率，这往往是通用 TTS 的软肋。
端到端延迟拆成 TTFT（首包延迟，从唤醒到第一个字播出来）和逐字延迟（字与字之间的间隔）。实时对话要求半回合延迟接近人类，业界标杆在 150ms 以内，慢了卡顿感直接毁体验。埋点要落在唤醒、ASR 结束、首字合成这三个节点上才能算准。
分段归因是语音评测的关键动作，思路来自传统测试的分层定位：在 ASR 输出、LLM 输入、LLM 输出、TTS 输入各插桩记录，失败案例直接看哪段指标劣化。链路任一环出错用户都觉得"豆包好笨"，可根因多半在 ASR 不在模型，插桩能把锅分给该背的环节。
4.3 多模态理解
拍照问答、看图说话、看视频对话，是豆包 1.8 起重点强化、2.1 Pro 继续推到全球前列（MMMU-Pro 等评测）的方向。
图文一致性用 image-text 对齐模型打一致性分，或干脆出 VQA 题（图里有没有某物、某物在什么位置）看命中率，杜绝看图说瞎话。OCR 精度看字符级 F1，重点测截图、表格、公式、手写体。视觉推理不只要"看到"还要"看懂"，图表类用 ChartQA 这类 benchmark，实景类用常识推理题。多模态这块公开基准很多，MMBench、MME、SEED-Bench、DocVQA、TextVQA 都能拿来对着建集。
拍照解题和拍照问答不是一回事，值得单独拎出来。拍照问答是看图描述、识别（图里是什么），拍照解题是先把题目 OCR 出来、再做学科推理、分步推导、给答案和讲解，数学物理化学都算。评测重点也不同：OCR 这步要单测公式、手写、排版复杂的识别率，公式符号错一个等号整题报废；推理这步不能只看最终答案对不对，要看步骤对不对、有没有跳关键步，小学应用题和高考压轴题难度差很大，得分层建集；讲解可读性也要评，用户要的是"怎么想"不是只给结果。它横跨多模态理解和推理两块，是深度思考和数学 Agent 的近亲，建题可以借 MMMU、MATH、GSM8K 这类学科推理集。
评测集必须分层构造：高清、模糊、遮挡、多目标、长图各建一类，每类独立报分。同一个问题清晰图和模糊图答案差很远，不分层测出来的分数区分不开好坏。落地时把"输入图 + 标准答案"一起入库，答案按可机判（选项、数值）和需人判（开放描述）分两堆，能机判的自动跑，省人工。
4.4 Agent 编排
豆包 1.8 起的战略重心，2.1 Pro 进一步推到生产级的，也是这个系列后面篇幅最多的部分。订日历、查天气、发邮件、跨 App 操作，Agent 把"回答问题"变成"完成任务"。评测分三层指标。
工具调用看函数调用成功率和参数级准确率，用结构化比对，必填参数缺失或类型错都算失败。错误要分类：不该调却调了、该调没调、调错工具、参数错，四类分开统计才能定位问题。
多步编排看任务成功率（Task Success Rate）和步骤级准确率（step-level accuracy）。复杂任务拆成步骤序列，失败看断在哪一步、能不能自我纠偏。
任务完成率是这层最该盯的指标，关键是用确定性断言校验世界状态，不是看输出文本漂不漂亮。订了日历就去查系统日历有没有这条，发了邮件就去查发件箱。所以要搭 tool sandbox，模拟日历、邮件、文件系统，记录每次 tool call 和最终状态，最后用断言函数判定成功与否。这套 harness 是可重放的：给定 user goal、mock 环境、golden tool-call 序列、成功判定函数，每次跑都能对比。Agent 评测工业界有 AgentBench、WebArena、τ-bench、ToolBench 这些基准，我们搭的 sandbox 思路跟它们一致，只是用例换成豆包自己的场景。
顺带说个常被归错类的场景：PPT 生成和编辑。有人觉得这是创作，看完成路径就清楚了：你给一个主题或一份文档，豆包先规划结构（拆几页、每页讲啥），再调生成和排版工具，可能还要检索配图、套模板，最后产出一个能打开的 .pptx。这条"意图、规划、调工具、产出文件"的路子就是 Agent 编排的典型，表面的创作底色不改变它"任务做没做成"的评测本质。
PPT 的评测点落在 Agent 侧，不在文字质量。产物用 python-pptx 打开校验文件合法、不崩；页数与大纲逻辑对照源主题，看有没有凑页数或跑题；要插图表时核对数据是否对照源文档真实，杜绝编数据；编辑指令做定位断言，你说"把第 3 页换成柱状图"，改的是不是第 3 页、改得对不对，这是多步编排加定位的硬指标。
Agent 这块对做过功能测试、测试开发的人是机会。它评的是做没做对，用例设计、路径覆盖、结果断言、异常回归都能迁过来。说白了就是传统测试思维加处理 LLM 非确定性，转型走这条路最省力。
4.5 AIGC 生成
文生图 Seedream、文生视频 Seedance、音频 Seed-Audio 是豆包一整套生成产品矩阵，2026.06 已发布 Seedance 2.5、Seedream 5.0 Pro、Seed-Audio 1.0，Seedance 2.5 支持 30 秒原生视频、50 个全模态参考素材联合输入。
它和前面多模态理解方向相反：理解是输入侧"看图"，生成是输出侧"造图、造视频、造音频"。所以把它和"理解"分列成两个能力，是因为评测方法学完全不同。理解评的是图文一致性、OCR、视觉推理，对错有客观标准；生成评的是画面质量、时序一致性、提示词遵循度、审美一致性，主观占比大。
画面质量看清晰度、构图、有无伪影崩坏；视频还要看时序一致性，人物和物体不能闪烁、不能突然变样；提示词遵循度把"提示词里的要素"逐条对照成品，缺一个都不行；审美一致性看风格统一、不跑偏。客观指标可用 FID（Fréchet Inception Distance，越低越好）、CLIP-Score（图文对齐度），视频用 VBench、T2V-CompBench 这类专门 benchmark 兜底，但最终质量还是靠人评或多模态裁判模型打分，没法纯机判。
落地时把"提示词 + 期望要素清单"一起入库，机判先跑 FID / CLIP-Score 粗筛，再抽一部分人评。长时长视频（如 Seedance 2.5 的 30 秒）要额外覆盖时序稳定性这个新增难点，短片段测不出。
4.6 OS 集成：叠加在五大能力之上的交付层
它不是第五种能力，而是豆包触达用户的一种系统级方式。语音唤醒、快捷指令、悬浮球、锁屏调起，到豆包手机助手直接操作系统，这些入口背后调用的还是前面五大能力（快捷指令本质是意图理解 → Agent → 系统调用）。所以 OS 集成评的不是"豆包聪不聪明"，而是"它作为一个系统功能稳不稳、权限履约对不对、耗不耗电"。评三项，都要求真机或真系统，模拟器不够。
权限履约用 adb 或系统 API 校验设备状态真实变化：闹钟真的建了、通讯录真的改了、文件真的写进了。不能只看豆包回了一句"已帮你设定"。
后台稳定性用 monkey 或长时间压测看崩溃率和 ANR，进程被杀后上下文恢复靠埋点日志核对。
功耗用 battery historian 看唤醒次数、持锁时长、后台耗电曲线，唤醒延迟用高精度计时。这层出问题用户感知也是"AI 笨"，模型答对了可快捷指令调不起系统闹钟、半夜误唤醒，用户只会骂豆包智障不会想是 OS 层挂了。所以 OS 集成评的是稳定性、权限履约、功耗，和模型智商无关，最容易被评测方案漏掉却最伤口碑。
五大能力各配一套评测体系，OS 交付层再单独一套；任何一块（含 OS）短板都会拖垮整体体验。
五、用户到底拿豆包干什么：应用场景地图
前面把能力拆成五块，但读者更想先知道"这东西被人用来干啥"。能力和场景是两张互补的图：能力说"它能做什么"，场景说"人拿它做什么"。我把公开能看到的用法归成 11 类，每一类标清楚主要踩哪块能力、评的时候盯哪个维度。
| 场景 | 典型用法 | 主要踩的能力 | 评测盯的重点 |
|---|---|---|---|
| 教学教辅 | 拍题答疑、知识点讲解、作文批改 | 多模态理解（拍照解题）+ 文本对话 | 解题步骤正确性、OCR 公式识别率、讲解可读性 |
| 办公 | 写邮件、会议纪要、Excel 公式、做 PPT | 文本对话 + Agent（PPT / 表格） | 内容准确性、Agent 任务完成率、格式合规 |
| 日常 | 闲聊、查天气、定闹钟、生活建议 | 文本对话 + 语音 + OS 集成 | 意图理解、端到端延迟、权限履约 |
| 内容创作与营销 | 公众号 / 小红书文案、带货脚本、品牌 slogan | 文本对话 + AIGC 生成 | 文案贴合度、生成质量、提示词遵循度 |
| 代码与开发辅助 | 写码、debug、SQL、代码评审 | 文本对话（编程模式）+ Agent | 代码可运行率、单测通过率、HumanEval / LiveCodeBench |
| AIGC 生成 | 文生图 Seedream、文生视频 Seedance、音频 Seed-Audio | AIGC 生成（第五大能力，与"理解"是两回事） | 画面 / 时序质量、提示词遵循、审美一致性 |
| 情感陪伴与角色扮演 | 吵架搭子、虚拟搭子、树洞倾诉 | 文本对话（人设） | 人设一致性、安全边界、不越界承诺 |
| 智能体搭建与分发 | 用户自建 Agent（已超 800 万个） | Agent 编排 | 智能体任务完成率、工具调用正确 |
| 专业垂类轻咨询 | 法律 / 医疗 / 金融科普问答 | 文本对话 | 领域准确性、不越界给确定性建议 |
| 信息检索替代 / 研究助理 | 边想边搜、长文解读、合同审阅 | 文本对话 + 检索 | 检索触发率、引用真实性、归纳保真度 |
| 翻译 / 多语言 | 中英互译、整本文档翻译 | 文本对话 | 翻译准确率、术语一致性 |
这张图有两个用处。一是帮评测定优先级：豆包 DAU 破亿，教学、办公、日常是绝对主力，这三类的评测权重理应最高；生成和陪伴声量大但用户基数相对小，资源分配上要分清楚。二是帮定位问题归属：用户说"豆包写的代码跑不起来"，要先判断是模型代码能力问题（文本对话轴）还是它调了不该调的工具（Agent 轴），场景地图加能力全景才能把锅分准。
这里有个容易混的点：生成和理解是两回事。多模态理解是"看图"（输入侧），AIGC 生成是"造图、造视频"（输出侧）。前者评图文一致性、OCR、视觉推理，后者评画面质量、时序一致性、提示词遵循度，方法完全不一样。现在生成已作为第五大能力单列，评测方法和多模态理解分开走，不混着评。
最后说一句实话：前面"五大能力"是按评测方法切的，不是按产品架构切的。文本、语音、多模态是输入模态维度，Agent 是编排维度，AIGC 生成是输出模态维度，它们不在同一把尺上；OS 集成更特殊，它不是能力而是交付层，横切在所有能力之上，任何能力都能通过语音唤醒、快捷指令这类系统入口被调起。这种切法好在能直接指导建评测卡：五大能力各一套指标，OS 交付层单独一套（稳不稳、权限履约对不对、耗不耗电）。代价是它不像产品架构图那样严丝合缝，你读的时候把它当成"评测作战地图"就行，别当成产品架构图。
（场景归类按公开用法整理，数据截至 2026 年 7 月，实际远不止这些，欢迎补充。）
六、五大能力加一个 OS 交付层，不是并列是层层叠加
上一节把五块能力横着铺开了，但它们之间其实有依赖，一块的问题会传到下一块。看这张拆解：
| 能力域 | 典型用户路径 | 评测粒度 | 与相邻能力的关系 |
|---|---|---|---|
| 文本对话 | 问答 → 追问 → 总结 | 单轮 / 多轮 / 场景化 | 为 Agent 提供自然语言接口 |
| 语音交互 | 唤醒 → 说话 → 播报 | 端到端链路 | 依赖 ASR / TTS，叠加对话质量 |
| 多模态理解 | 拍照 → 识别 → 解释 | 图文对齐 | 输入质量影响对话正确性 |
| Agent 编排 | 意图 → 工具 → 执行 → 反馈 | 任务完成率 | 对话质量决定意图理解上限 |
| AIGC 生成 | 提示词 → 生成 → 修正 | 画面 / 视频质量 | 与多模态理解方向相反，输入输出两侧 |
| 交付层（OS 集成） | 系统调用 → 权限 → 稳定性 | 系统级指标 | 横切五大能力，系统故障表现为"AI 笨" |
"关系"那一列是这张表里最值钱的信息：上游的缺陷会被下游放大。
对话是地基，Agent 得先听懂意图才能调对工具。对话层意图理解只有 80 分，Agent 任务完成率的天花板就锁在 80 分以下，你在 Agent 层测出的失败根子可能在对话层。语音是 ASR 和对话质量的乘积，两个 90 分串起来端到端可能只剩 81 分。多模态更直接，图没识别对后面答得再流畅也是错的。
这意味着不能只做分层单测，还得做链路贯通测试并跨层归因，测出一个失败要判断得出锅在哪层。这是集成测试加缺陷定位那套思路的进阶用法，也决定了评测报告能不能让研发服气去改。落地时语音、Agent、OS 这三类链式场景都要端到端跑一遍，同时各段插桩，端到端发现问题再靠分段数据定位。
七、一条贯穿全程的底层约束：非确定性
往下讲之前得先说清一件事：豆包和所有大模型产品的输出是非确定的。这是它跟传统软件最根上的区别，也是传统测试思路必须改的地方。
传统测试建立在"相同输入、相同输出"上，点一次按钮结果永远一样，断言可以写死。大模型有三层不确定，我理解这是评测工作的底层约束。
同一个 prompt 问两次，措辞甚至结论都可能变，开了采样更明显，所以断言不能用精确字符串匹配，得改成语义等价判定，或改判最终状态（如日历是否创建）。模型每月都在迭代（1.5、1.6、1.8、2.1），今天的结论下月可能失效，所以评测必须可复现、可回归、带版本快照。1.6 之后有四档思考长度，同一问题在 Minimal 和 High 档答案质量不同，所以评测得标注档位，不然分数没法比。
这三层不确定是整个系列所有方法的根。我自己的概括是：大模型评测就是拿统计和语义的手段，把这种不确定驯到可度量、可对比、可决策。具体做法上，非确定输出要靠多次采样取统计指标（如成功率跑 N 次取均值、分位数），单条 case 不足以下结论。业界做大模型评测基本都这么处理方差，后面每篇的指标设计说到底都在处理这三层里的某一层。
八、为什么不能用一套标准评全部
回到开头那个问题。五大能力的"合格"根本不是一回事：对话评的是好不好，主观、连续，靠人或模型打分；Agent 评的是做没做对，客观、二值，能自动断言；语音评的是听不听得清，信号级，有延迟、准确率这类物理指标；多模态评的是看没看懂，吃输入质量分层；AIGC 生成评的是画面和时序质量、提示词遵循度，主观占比大。OS 集成不在这五种里，它评的是稳不稳、耗不耗电，系统级，跟模型智商没关系，是横切在五大能力之上的交付层。
硬凑一个综合分，短板会被平均掉。一个对话 95 分、OS 集成天天崩（40 分）的版本，综合分可能还有 85，看着能发，用户体验却是"这破 AI 天天卡死"。综合分骗得过评测报告，骗不过卸载键。
所以这个系列的第一条规矩：能力分治，我建议别用一个综合分把短板盖住。
九、这张图怎么用来建评测体系
认知说完落到动作。全景图最终是要拿来搭评测体系的，我是这么用的，供你参考。三条，每条给最小落地形态。
能力分治，给五块能力各建一张评测卡：维度、指标、通过线、数据来源、判分方式。每块有自己的及格线，不糊成一个综合分。
链路贯通，语音、Agent、OS 这三类链式场景必须端到端评，不能只看模型层分数。给个最小样例：语音场景在 ASR 输出、LLM 输入输出、TTS 输入各埋点，端到端报任务成功率，分段报 WER 和 TTFT，出问题直接看哪段劣化。
短板优先，任何一块触红线整体就算不达标，没有"这块差点但别的好所以能发"的说法。红线是闸门不是分数。
评测基建方面，我建议尽早把两个东西搭起来：一个是 tool sandbox（Agent 评测的 mock 环境，记录每次 tool call 和最终世界状态），一个是分段插桩的日志规范（语音、链路场景统一埋点格式）。这两个一旦成型，后面各篇大半能复用。通用的评测框架像 HELM（斯坦福 CRFM）、OpenCompass、EleutherAI 的 LM Eval Harness、DeepEval、Ragas，都可以对照着借思路，不一定要从头造轮子。
十、两类人怎么用这张图
这个系列面向两类转型的人，用法不一样，说一下我观察到的路径。
做功能测试、测试开发转 Agent 评测的，最短路径是 4.4 那块。它评任务完成率，跟你擅长的结果验证、路径覆盖、异常回归是一回事，只是断言对象换成了 Agent 的执行结果。动作上把写测试用例的思路改成写 Agent 评测场景：一个场景等于一个用户意图，加一串预期的工具调用序列，加一组成功判定条件。第 02 篇讲怎么从 JD 反推这套能力。
做产品转 Agent 评测的，优势在看得懂"用户路径"那一列，那本质就是你画过的用户旅程。动作上把用户旅程翻成评测链路：用户在哪步会流失、哪步体验最脆，那儿就是评测权重最高的地方。什么样的失败最伤用户你比工程师更清楚。
两条路最后是一处：在豆包这个系统上，建起一套能对号入座的评测坐标。这张全景图就是共同的起点。
十一、产品质量红线速览（继续开篇"红线即闸门"的约定）
开篇立的是评测这件事本身的纪律红线，这一节接着立豆包产品能不能发的质量红线。不管评哪块，这几条贯穿全系列，触线就是不可发布：
| 红线 | 判定 | 归属能力 |
|---|---|---|
| 安全漏过率 > 0.1% | 一票否决 | 文本对话 / 全局 |
| 事实性幻觉（关键领域） | 阻断发布 | 文本对话 / 多模态 |
| Agent 任务破坏性误操作 | 一票否决 | Agent / OS |
| 语音端到端延迟劣化超阈值 | 阻断发布 | 语音交互 |
| 生成内容违规 / 侵权（未授权肖像、敏感信息） | 一票否决 | AIGC 生成 |
| 后台崩溃 / 权限越界 | 一票否决 | OS 集成 |
红线不进综合评分，它们是闸门。任何一条触线，其他维度再漂亮也不能发。
十二、下篇预告
本篇说清了评什么、怎么由浅入深拆开评、以及为什么不能一把尺子量完。下篇说凭什么这么评、评测维度从哪来。
第 02 篇《从豆包 JD 拆解算法评测岗：5 模块能力地图》：把豆包 AI 算法测试开发专家的招聘 JD 拆成一张能力地图。我理解，JD 里每一条要求，背后都对着豆包的一个风险点、一个评测维度。招聘要求是团队最诚实的表态，看它招什么人，就知道产品在担心什么。这份地图就是转评测岗的行动清单。
参考与延伸（供按需深入）
以下是我写这篇时参考或借力的公开基准与框架，列出来方便你自己往下挖，不保证全，也不一定都适合你的场景：
- 对话质量与裁判模型：MT-Bench（Zheng et al., 2023）、AlpacaEval；通用大模型评测框架 HELM（Stanford CRFM）、OpenCompass、EleutherAI LM Eval Harness。
- 幻觉评测：HaluEval、FaithEval、RAGAS（偏 RAG 场景）。
- 语音指标：WER（语音识别标准指标）、MOS（按 ITU-T P.800 盲测流程）、DNSMOS（微软无参考指标）。
- 多模态基准：MMBench、MME、SEED-Bench、ChartQA、DocVQA、TextVQA、MMMU / MMMU-Pro。
- AIGC 生成基准：FID、CLIP-Score、VBench、T2V-CompBench。
- 学科推理与代码基准：MATH、GSM8K（数学推理）、HumanEval、LiveCodeBench（代码生成），拍照解题与代码场景建集可借力。
- Agent 基准：AgentBench、WebArena、τ-bench、ToolBench。
- 通用评测工程框架：DeepEval、Ragas、LangSmith、Giskard（供搭 harness 时借思路）。
产品数据来源：豆包官网、火山引擎历次发布会公开信息、QuestMobile / 中金公司 / 36 氪 / 科创板日报等公开报道，数据截至 2026 年 7 月。豆包迭代快，文中模型版本、调用量等数字若与你看到的最新官方口径有出入，以官方为准，也欢迎指正。
作者注：本系列是一边工作、一边实操、一边琢磨着写出来的，规划约 100 篇，内容和篇幅会随实际调整；为保证输出质量，不追求固定的更新频率。以上内容基于脱敏内部信息、公开权威资料和自己踩坑后的理解，不一定对，欢迎拍砖。