作为天天拿豆包试用的评测人，你读到这一篇，应该已经跟着系列走完了从定位、角色、术语、基准、统计基础、能力账本、交付闸门，一直到顶层设计与数据飞轮的全程。认知框架基本立起来了。但我自己的体会是，一个近百篇的长系列，最大的风险不是某一篇没看懂，而是一路走下来，回头已经看不清自己站在整张地图的哪个位置。
你拿豆包帮写周报、帮总结长文档、帮写代码，这些具体的使用场景背后，其实都对应一张地图上的一个格子：它属于哪类能力、该用哪一把尺子、前面已经覆盖到哪、后面还差什么。总览不是把前面各篇复述一遍，那是注水。总览的作用是给你一个坐标，让单篇之间从散点连成一条能随时定位的线。
这一逻辑本身也回扣北极星：无论产品视角还是测试视角，本质都在回答"如何保证 agent 产品为用户带来最大用户价值"。地图把"价值"拆成可操作的能力与维度，评测人拿着它能立刻说清自己这步在保哪层价值。
下面矩阵以本系列 taxonomy 为唯一真相源（五大能力：文本对话、语音交互、多模态理解、Agent 编排、AIGC 生成，OS 集成作为横切交付层），不沿用规划文档里按业务场景切分的旧表。每一行给的是可落地的"尺子"，不是泛泛而谈。
| 能力维度 | 核心评测维度 | 代表基准 / 工具 | 后文待展开 |
|---|---|---|---|
| 文本对话 | 指令遵循、多轮一致性、事实性、安全红线 | MMLU、MT-Bench、TruthfulQA、BBH | 长上下文"大海捞针"（#19 起）、推理链质量（#19 起）；对话与推理合计 8 篇，从 #19 对话与推理评测起 |
| 语音交互 | 识别准确率（WER）、合成自然度（MOS）、端到端时延 | LibriSpeech、Common Voice、MOS 评测 | 流式首字延迟、端到端语音体验（语音与音频 8 篇，从 #27 起） |
| 多模态理解 | 图文理解、视觉问答、图表与文档解析 | MMBench、MMMU、SEED-Bench | 跨模态一致性、视频理解（多模态 4 篇，从 #49 起） |
| Agent 编排 | 任务完成率、工具调用正确性、多步规划 | AgentBench、WebArena、TAU-bench | 安全沙箱、端到端长任务（Agent 与自动化 9 篇，从 #41 起） |
| AIGC 生成 | 文生图质量、风格一致性、图文对齐 | CLIPScore、HPS、VBench | 3D 生成、视频生成时序（生成与创作 4 篇，从 #49 起） |
| OS 集成（横切交付层） | 端到端任务可达、系统稳定性、跨应用编排 | 真机 adb、工具沙箱、端到端脚本 | 跨 App 编排评测（平台与工程化 23 篇，从 #60 起） |
表中基准名（MMLU / MOS / AgentBench / CLIPScore 等）均为学界通用评测基准，所引属方法、架构、原理层面结论，不绑定特定模型版本分数。
注：03（JD 里的技术术语）和 05（非确定性系统的测试思维）是跨篇通用基础，不专属某一能力，上表各能力行均可复用，并非只归"文本对话"一行。第一幕 00 至 09 已覆盖能力框架与交付闭环，"已覆盖"篇目不再单列，后续单能力深评从第二幕起按上表"待展开"编号展开。
怎么用这张表，我一般会这么干：拿到一个评测需求，先定它落在哪一行的"能力维度"，再查"核心评测维度"和"代表基准"就能直接开干，不用从零想尺子。举个例子，假设产品同学说"想评一下豆包帮我写周报的能力"。落到矩阵里，它是「文本对话」行（指令遵循 + 事实性 + 多轮一致性），代表基准可以借 MT-Bench 的多轮一致性、TruthfulQA 的事实性，但"周报格式合规"这个维度矩阵里没现成基准，属于「待展开」。"待展开"列里写的篇目编号，就是后续单能力深评的坑位，需要时直接跳过去看。
矩阵能成立，前提是维度分治这条纪律站得住，详细展开见 08 篇。它的反面是"只看综合分"：一个 90 分的综合分，可能安全维度已经漏过红线，只是被其他维度拉高了。01 篇讲能力分治不靠综合分盖短板，07 篇讲红线一票否决，根源是同一件事。维度设计上有几条原则：维度正交（"准确性"和"正确率"是同一维度的两个叫法，不能算两次）、可量化（"总体感觉不错"不是可量化指标）、可迭代（指标体系支持新增废弃权重调整，不硬编码写死在代码里）。这三条是后面搭战略路线图的底座。
前面那张矩阵是按本系列 taxonomy（五大能力）切的，适合"拿到需求先定能力维度"。但实际规划时，系列内部还按"业务场景"做过一张导航表，切分维度不同：它从用户侧场景出发，告诉你每类场景后面排了几篇、从第几篇开始展开。两张表不是矛盾，是同一个评测体系的两个入口，一个从能力看，一个从场景看。下面这张按业务场景的表，供你从"我要评什么业务"出发定位时用。
| 场景 | 篇数 | 核心评测维度 | 代表基准 / 工具 | 从第几篇开始 |
|---|---|---|---|---|
| 对话与推理 | 8 篇 | 正确性、幻觉、RAG、推理链 | MMLU / TruthfulQA / RAGAS | #19 |
| 语音与音频 | 8 篇 | ASR / TTS / 端到端体验 | Whisper / CHiME / MOS | #27 |
| 安全与合规 | 7 篇 | 越狱 / 偏见 / 对齐 / 伦理 / 风控 | BBQ / RSP / AILuminate | #34 |
| Agent 与自动化 | 9 篇 | 工具调用、编排、沙箱 | AgentBench / WebArena | #41 |
| 生成与创作 | 4 篇 | 图文一致性 / 时序 / VBench / 3D | CLIPScore / VBench | #49 |
| 编程与开发 | 4 篇 | pass@k / SWE-bench / 代码安全 | HumanEval / SWE-bench / CyberSecEval | #53 |
| 办公与生产力 | 2 篇 | 文档 / 表格 / PPT 可用度 | Copilot 基准 | #56 |
| 翻译 | 3 篇 | BLEU / COMET / XCOMET / 实时翻译 | WMT / Flores-200 / XCOMET | #58 |
| 平台与工程化 | 23 篇 | Pipeline / UX 洞察 / 数据策略 | LM-Eval-Harness | #60 |
| 方法论与交付 | 21 篇 | 评分 Agent / 动态评估 / 竞品 / 发布 | GPT-Judge / EDD | #83 |
两张表对照着看会更清楚：比如"安全与合规"在场景表里是独立一行（7 篇），但在能力矩阵里它作为横切维度分布在每一行（安全红线、越狱、偏见）；再比如"翻译"在场景表里单独成行，但在能力矩阵里它归在文本对话（事实性 + 多语言）和语音交互（流式首字延迟）的交叉地带。从能力看能锁技术范围，从场景看能对齐业务排期，两个入口都走得通。
按本篇语境把已发布九篇的贡献归个档（02A/02B 在此合称一篇"JD 拆解"），方便你回查：
九篇合起来，是一条"认知框架到工程闭环再到战略自进化"的线：先知道评什么（00-01），再知道谁来评、要懂什么（02-03），用什么尺子、什么统计底气（04-05），怎么管能力和交付（06-07），最后怎么让体系自进化、往前看战略（08）。
站在地图上看，后续该按三条策略推进，我一般是这么读的：
第一，先全景后细节。不在没建立框架时跳进单点工具。你已经有了 01 的全景和本篇矩阵，下一步是逐能力深评，而不是反过来。第二，维度分治加结果汇总。每个能力独立评测、独立看维度分，发布前再做加权综合。这是 01、07 反复强调的纪律，后面会展开成指标体系设计。第三，理论到实操到工程闭环。统计方法论（05）是理论，单能力深评是实操，平台化与飞轮（08 及后续）是工程闭环，三者互相印证。
给评测人的分阶段路线建议：第一阶段补认知（00-07 已覆盖）；第二阶段挑一两个能力做单能力深评，把矩阵里"待展开"的坑填上；第三阶段走工程化与平台化，让评测能随时对任意版本跑完整流程。08 篇已经专门讲了这套顶层设计与数据飞轮怎么搭。
拿着这张地图，任何一个评测任务你都应该能立刻答出几件事，答不出就说明范围没想清：评哪层价值（保用户眼前体验还是保长期演进）、哪维能力（落到矩阵哪一行）、用什么尺子（对应哪些基准、落点在已覆盖还是待展开）、证据够不够硬（数据来自哪、检索日期、是否标了来源、有没有可落地指标和判法）。这几问是把前面九篇压成的一张随身卡，测试转的人用它锁技术范围，产品转的人用它把技术翻成业务语言，对齐北极星那句"最大用户价值"。
至此，第一幕认知基础（00 到 09）全部收线：从定位、角色、术语、基准、统计基础、能力账本、交付闸门，到顶层设计与数据飞轮，再到本篇总览地图，一张能随时定位的评测地图交到你手里。站在战略层看评测，从"会跑 benchmark"升级到"能设计评测战略"，这第一步已经走完。
第一幕到此收尾。第二幕起，会按本篇矩阵"待展开"的坑位逐个做单能力深评，把框架落到真刀真枪的评测里：从对话与推理、语音交互、多模态理解，到 Agent 编排、AIGC 生成、OS 集成，每个能力独立成篇、独立看维度分。本篇的导航地图是这些深评篇的目录，需要时随时回来定位。
作者注：本系列是一边工作、一边实操、一边琢磨着写出来的，规划约 100 篇，内容和篇幅会随实际调整；为保证质量，不追求固定的更新频率。以上内容基于脱敏内部信息、公开权威资料和自己踩坑后的理解，不一定对，欢迎拍砖。