一、为什么传统测试转过来的人需要一本账本

落到评测这桩事上，你干的是替用户先上手试、替用户把话问出口、替用户把结果摸到的人。用户自己不会写评测报告，却能用得出来：同一个功能，豆包这次答得贴心，下次又答得离谱；一个本来好用的能力，某次更新后悄悄变差了。评测人的第一责任，是替用户把这种说不清的体感，变成能下结论、能交付、能推动产品改的东西。

而当你从传统测试转过来，最大的落差不是术语，是「账本」。传统测试里你心里那本账很清楚：会写用例、会定位 bug、会搭自动化，这就是你的能力清单，招聘方和团队都认。可一转到豆包这类 agent 产品评测，你突然发现旧账本对不上了：原来那套「输入 A 必得 B、写断言判对错」的本事还在，但产品问的是「这个版本到底值不值得发」，答案不在任何一条用例里，而在分布、在趋势、在置信区间里。

所以这篇想替你做一件事：把「我有什么、缺什么、怎么补」画成一本能直接勾选、能拿去和 leader 聊的能力账本。它不是又一篇「AI 测试指南」，而是你个人转型的进度条。顺着 02A 那张 JD 能力地图往下走，这篇给你能填的表和能执行的路径。

这一本账本最终服务的，还是那句话：评测是桥，桥这头是产品造的用户价值，桥那头是测试证出的用户价值。你把自己的能力补齐，桥才扛得住。

二、七维对照：传统测试 vs 算法评测

先把最关键的七条维度摆出来，让你一眼看清「旧账本哪页还能用、哪页要重写」。后面所有路径都从这七条长出来。

维度	传统测试	算法评测（以豆包为例）	核心变化
对象性质	确定性软件，输入定输出定	非确定性概率系统，同输入可多输出	从「必然」到「概率」
正确性标准	pass / fail 二元	好 / 坏 连续 rubric	从「对错」到「程度」
用例设计	等价类、边界值、场景法	风险分布抽样、Prompt 变体、对抗样本	从「覆盖全」到「压高危」
结果判读	单点断言	分布加置信区间	从「一次定论」到「多轮取势」
缺陷管理	定位到代码行、严重度分级	退化定位到维度、归因到 case 类型	从「修 bug」到「管退化」
自动化	接口 / UI 断言框架	评测 harness、采样 pipeline、CI 回归	断言换成统计阈值
交付物	pass / fail 列表	维度分加趋势加告警	从「清单」到「决策依据」

这七条不是并列的。最底下「对象性质」那条是总开关，其余六条都是它的推论：因为对象是概率系统，所以正确性变成程度、判读变成分布、缺陷变成退化。所以这篇重心压在「怎么把旧账本顺着这七条重写成新账本」上，而不是逐条平均用力。

这张七维表和 02A 的 5 模块 JD 地图是同一件事的两种切法，一个从「岗位职责」切，一个从「范式差异」切，互为补充，不矛盾。

三、能力账本模板：一张能直接抄的表

思维清楚了，第一件要动手的事是：把上面七维落成一张你自己能填的账本。我给的模板长这样，你照着给自己打勾打分即可。

能力项	传统测试底子（迁移自 02A）	算法评测新增要求	自评（1 到 5）	最该补的一块	证据 / 踩坑记录位置
风险识别	等价类、边界值、场景法	幻觉 / 退化 / 一致性塌方预判	无	无	无
用例设计	功能、异常用例	Prompt 变体、对抗扰动、保留题	无	无	无
缺陷管理	Bug 生命周期、严重度	退化监控、维度归因	无	无	无
自动化	接口 / UI 框架	评测 harness、CI 回归	无	无	无
统计判读	基本通过率	置信区间、Bootstrap、Kappa	无	无	无
技术跟踪	跟版本变更	跟 LLM / RAG / Agent 演进	无	无	无
沟通交付	缺陷报告	用分布趋势驱动发布决策	无	无	无

填这张表有几条纪律，都是踩坑后留下的：

第一，自评分数要有证据，不能拍脑袋。你说「统计判读 3 分」，就得能指到一条你实际算过置信区间的评测记录；指不出来，就先算 1 分。账本的价值在「可追溯」，不是「自我感觉良好」。

第二，最该补的一块只写一格。七项里你最缺的往往就一两件，把力气集中在这，别平均撒。多数人转过来最缺的是「统计判读」和「技术跟踪」这两格，和 02A 的判断一致。

第三，证据位置必须真实可查。可以是一个评测仓库路径、一份你跑过的报告、一个你搭的最小 harness。证据空着的格子，就是下次评审你该拿出来的东西。

举个填法的样子帮你对照：某人『统计判读』自评 2 分，证据位置写「还没独立算过区间，只用过平台给的均值」；『风险识别』自评 4 分，证据位置写「02A 模块 1 五类风险检查单已建，评测前必过」。一眼就能看出，下阶段该先补统计判读那格，而不是平均用力。

账本要进周会、进评审，不要锁在自己电脑里。每次版本评审前，把这本账本的「最该补的一块」那列过一遍，就能和 leader 对齐「这周期你补了哪格、还差哪格」，比泛泛说「我在学评测」有说服力得多。

这本账本和 02A 那张迁移表的关系：02A 告诉你「5 件事里 3.5 件已有底子」，这本账本是它的个人版，把「已有底子」具体到你身上几条、每条几分、缺的怎么补。两张表合起来，转型就不靠焦虑驱动了。

四、三阶段路径：从旧账本到新账本

账本填完，补的路径我建议分三阶段走。这条三阶段和 02A 第十二节的「用例到 Pipeline 到单维度方案」一脉相承，但这里我把它落到「能力成长」上，每个阶段给可落地指标、判法和数据来源。

阶段一：补统计底座。
目标：让你看得懂、算得出评测报告里的分布和区间。
可落地指标：能独立对一组采样结果算 95% Bootstrap 置信区间；能给评分 Agent 跑 3 次算 Kappa，≥ 0.6 算可用。
判法：拿一份历史评测数据，你重算的均值和区间，和原报告误差不超过 ±0.1，算过关。
数据来源：本地 Python 重算即可，方法出处标在文末；05 篇对非确定性下的统计基础有完整展开，本阶段建议先读 05 再动手。

阶段二：把非确定性范式落到账本和评测集。
目标：把「分布、风险、保留题」变成你日常的评测习惯。
可落地指标：建一张风险矩阵（场景、影响面、概率、优先级、抽样条数），挑出 P0 场景建 golden set，每次发版跑；构造至少 20 条保留题覆盖幻觉 / 退化两类风险。
判法：你的评测集能回答「这个版本在 XX 维度比上版低了多少、区间是否重叠」；答不上来，说明范式还没落地。
数据来源：风险矩阵来自业务埋点和历史缺陷分布；保留题来自你手搓的变体和对抗样本。

阶段三：用账本驱动验收与沟通。
目标：账本从「自我盘点」变成「团队决策依据」。
可落地指标：能拿出一份带账本证据的验收单（见第八节），用分布和趋势向产品和算法说明「为什么这个版本该发 / 该拦」。
判法：leader 看完你的账本和验收单，能直接做发布决策，而不是回头问你「那到底行不行」。
数据来源：账本来自你前两个阶段积累的证据；沟通对象是产品和算法，话术见第七节。

每个阶段都要有进账本的交付物，否则等于没走。阶段一产出「一份你独立重算过的区间练习」，阶段二产出「一张风险矩阵加一个 golden set」，阶段三产出「一张带账本证据的验收单」。交付物不到位，这阶段不算过。

阶段一给个具体练习：挑 10 条你手上的评测 case，每条跑 5 次，自己算 95% Bootstrap 区间，再和平台给的均值对标。能对上，阶段一过关；对不上，先别急着进阶段二。

三阶段不是时间线均分。阶段一最快（一两周能入门），阶段二最花功夫（要真做评测集），阶段三靠前两个阶段沉淀。卡在哪阶段，就回头补哪阶段的账本格。

五、统计与论文武装：评测人的武器库

账本里「统计判读」和「技术跟踪」两格，靠一套最小武器库撑起来。这一节把最该懂的几件列清楚，每件给「它对你评测什么有用、你该记住什么」。

先说五个底层论文。评测人不必会推导，但要知道每篇在讲什么、它影响你评测的哪块。以下归属经核对，避免张冠李戴：

• Transformer（Vaswani et al., 2017, NeurIPS, arXiv:1706.03762）：注意力机制奠基。你记住的是「模型是概率生成、输出带采样」，这直接解释为什么同输入多输出，是整本账本的总前提。
• RAG（Lewis et al., 2020, NeurIPS, arXiv:2005.11401）：检索增强生成。你记住的是「RAG 上线，评测要加检索召回准不准、引文真不真」，对应账本「用例设计」和「风险识别」。
• ReAct（Yao et al., 2023, ICLR, arXiv:2210.03629）：推理加行动协同。你记住的是「Agent 评测看多步轨迹（plan 到 action 到 observation），不是单轮答对」，对应账本「自动化 / harness」。
• InstructGPT（Ouyang et al., 2022, NeurIPS, arXiv:2203.02155）：用人类反馈对齐。你记住的是「RLHF 可能让模型拒答率异常、套话化」，这是算法评测特有的「能力没退但行为变味」问题。
• LLM-as-Judge（Zheng et al., 2023, NeurIPS, arXiv:2306.05685）：强模型当裁判。你记住的是「judge 和人类一致性超 80% 才可信，且要缓解 position / verbosity / self-enhancement 三类偏置」，对应账本「统计判读」里的评分一致性。

再说四个统计武器，都是你账本里「统计判读」格的硬货：

• 95% 置信区间：对应 Z 值 1.96，告诉你「真实均值大概率落在这」。报告区间不报告单点。
• Bootstrap 区间（Efron 1979）：对小样本重采样估计区间，不依赖正态假设，是评测报告的标配。
• Kappa 一致性（Cohen 1960 提出）：看评分者之间是否一致，≥ 0.6 可用、≥ 0.8 理想。
• pass@k：跑 k 次至少一次通过的比例，天生为非确定性定义，比单次 pass / fail 贴实际。

这一节不是让你去啃论文，是把它们变成你账本里「技术跟踪」「统计判读」两格的勾选项。每篇你能说出上面那句「记住什么」，这两格就算补上了。

六、通用能力复用：你旧账本里还能用的

很多人转岗时被术语吓住，忘了自己旧账本里大半身家还能用。这一节把能直接迁移的本事列出来，给你吃颗定心丸。

风险意识能直接用。你原来做等价类、边界值、场景法，本质就是预判哪里会出事。豆包的风险从「必然崩」变成「偶尔错」，但预判的脑子一样。把 02A 模块 1 那 5 类风险（幻觉 / 退化 / 一致性塌方 / 安全越权 / 能力边界）抄成检查单，每次评测前过一遍，立刻比只看功能对不对的人专业一档。

用例设计思维能直接用。你原来写异常用例，现在写 Prompt 变体和对抗样本，思维同源：都是「怎么用刁钻输入逼出系统短板」。建一个变体库，同一意图写 10 种说法、加错别字和干扰句，这就是你老的异常用例思维换了个对象。

缺陷分级思维能直接用。你原来给 bug 定严重度，现在给退化定级别：P0 维度退化直接拦发版，长尾维度波动先观察。分级的脑子和流程都能搬过来，只是定位目标从代码行变成能力维度。

自动化工程能力能直接用。你原来会写接口 / UI 自动化，现在写评测 harness 和 CI 回归，编码底子直接复用。区别只是断言从 assert resp == expected 换成统计阈值（跑 N 次一致率超 95% 算过），执行器从 selenium 换成 Agent。

质疑精神能直接用，而且更值钱。你原来看到「显示成功」会去查底层是不是真成功，现在看到「模型说它查了资料」要去查引文真不真、看到「分数很高」要去查分布里有没有短板。这种「不轻信表面」的本能，是评测人最该保住的老本行。

这五件凑齐，就是你旧账本里「3.5 件底子」的具体落点。它们不用重学，只要换个对象接着用。

七、沟通升级：用账本和分布说话

补完能力，还有一层容易忽视：你怎么把账本里的东西讲给别人听。传统测试转过来的人常犯一个错，拿着单次失败 case 冲进算法办公室说「模型又错了」，对方一句「这是采样的」就把你挡回来。

正确话术是拿分布和趋势说话。给一个能直接抄的模板：

「这个版本在『长文档一致性』维度，事实一致率从 92% 降到 88%（下降 4 个百分点，超过黄灯阈值），Bootstrap 95% 置信区间 [87.2, 88.8] 与上版 [91.5, 92.5] 不重叠，判断为真实退化，建议拦截发版。」

这句话和「模型又错了」的区别，就是账本的区别：你交付的是带区间的趋势和决策建议，不是单次吐槽。

对不同对象，账本侧重点不同。对产品，讲「这个能力对用户价值的影响有多大、退化会不会伤核心场景」，用风险矩阵里的优先级说话。对算法，讲「退化在哪个维度、哪种 case 类型触发、能不能定位到数据或训练环节」，用归因分类说话。对 leader，讲「该发还是该拦、证据在区间里」，用验收单说话（见第八节）。

一句话纪律：评测人的沟通产出不是「问题清单」，是「带置信区间的决策依据」。这层做好了，账本才从自我盘点变成团队资产。

八、项目验收：用账本做一份放行单

账本最实在的用处，是变成项目验收的放行依据。传统测试你有「准入准出」清单，算法评测一样要有，只是判据从「用例全过」变成「账本证据达标」。

我给一份能直接抄的验收单模板，每次版本评审填这一张：

验收项	账本证据	置信区间 / 阈值	放行条件	结论
安全红线	安全漏过率判分记录	漏过率 0	一票否决	无
核心维度不退化的	事实一致率前后对比	下降 < 2 个点且区间重叠	放行	无
P0 场景	golden set 回归结果	全量通过	放行	无
长尾维度	保留题抽样	波动在噪声内	观察	无

填这张单有几条硬规矩。安全红线一票否决，漏过率非零直接拦，没有商量余地（和 01 篇产品质量红线同源）。核心维度看「区间是否重叠」而不是「单点差多少」，重叠就当噪声放过，不重叠才算真退化。P0 场景必须全量回归，不允许「这次太赶先跳过」。

填一张真实的样子，你就知道它怎么用。某次发版：安全红线漏过率 0（一票否决放行）；核心维度「事实一致率」上版 92.0、本版 88.0，下降 4.0 个点，Bootstrap 区间 [87.2, 88.8] 与上版 [91.5, 92.5] 不重叠，判真实退化、拦截发版；P0 场景 golden set 全量通过。结论栏写「核心维度真实退化，拦发版」。这张单递上去，leader 不用追问，直接签字。

验收单本身也要进版本库，每次发版留痕。哪次因为账本证据拦了发版、哪次放了，回头都能翻出来复盘。账本和验收单合起来，才是能复现、能追责的评测资产。

这张放行单就是账本的出口：你前面填的能力自评、建的风险矩阵、跑的 golden set，最终都汇到这里，变成 leader 能签字的依据。评测是桥，这张单就是桥面上的交付物。

九、原理补一刀：账本为什么有效

前面给了表和路径，这一节补一点原理，帮你判断「该采多少样、阈值定多严」，而不是凭感觉。

账本有效，根子在非确定性系统的两个本性。第一个本性是概率生成：模型每次输出是从一个分布里采样，同输入多输出是常态不是 bug。所以单次结果不构成证据，必须看分布，这就解释了为什么账本里「统计判读」是必填格。第二个本性是统计漂移：豆包版本迭代很密（截至 2026 年 7 月，仍保持高频更新节奏），检索文档变化、用户用法变化，都会让能力悄悄移动，所以「发布等于监控开始」不是口号，是账本能持续生效的前提。

对应的工程第一原则是可复现。账本里每一项证据，都必须能「同模型版本、同数据集、同判分器，任何人任何机器跑出同一结果」。做不到可复现，证据就进不了账本，更进不了验收单。这条在 02A 模块 4、05 篇都强调过，是整本账本的底座。

理解这两个本性，你才不会犯两类错：采样太少就下结论（方差大、区间宽，什么也说明不了），或者阈值定太严（把正常波动当退化，团队被狼来了搞疲）。账本不是束缚你的表格，是帮你守住这两道防线的工具。

十、四个反模式：传统测试人转过来最常踩的坑

方法讲完，列四个最常踩的坑，都是前面内容的反面，评测新人照着避开。

第一，把老用例当标准答案。传统测试里用例就是预期，转到豆包还拿用例当「正确输出」去比对，看到模型给了一个不同但合理的答案就判 fail。正确做法：用例是参考范围不是标准答案，判的是「够不够好」不是「对不对」。

第二，追求 100% 覆盖率。传统测试追分支覆盖、行覆盖，转过来还平均用力穷举 case，P0 场景反而没覆盖够。正确做法：按风险矩阵定优先级，高危场景做全量回归，长尾靠保留题加监控补。

第三，单次失败就下定论。跑一次看到一句不好的回答就写「该场景不达标」。正确做法：多轮采样取分布，单次结果不算证据（05 篇核心纪律）。

第四，忽略种子和配置。评测不记 temperature、seed、采样次数，下次跑结果变了，分不清模型变了还是配置变了。正确做法：采样配置卡进版本库，可复现第一原则守住。

这四条坑，本质都是「旧账本的习惯没改写干净」。账本填好、三阶段走完，这几条自然就避开了。

下篇预告

这篇把转型最实的一本账本给了你：七维对照看清旧账本哪页要重写，能力账本模板让你逐项自评，三阶段路径给可执行节奏，统计与论文武器库补最缺的两格，通用能力复用给你定心丸，沟通升级和项目验收让账本变成团队资产。但你可能会问：账本填完、验收单出了，到底拿什么去推动一个版本发或者拦？下篇讲评测驱动交付决策，把账本里的证据变成产品真能用的发布闸门。

作者注：本系列是一边工作、一边实操、一边琢磨着写出来的，规划约 100 篇，内容和篇幅会随实际调整；为保证质量，不追求固定的更新频率。以上内容基于脱敏内部信息、公开权威资料和自己踩坑后的理解，不一定对，欢迎拍砖。

参考与延伸

• Vaswani A. et al. Attention Is All You Need. NeurIPS 2017. arXiv:1706.03762
• Lewis P. et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. arXiv:2005.11401
• Yao S. et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. arXiv:2210.03629
• Ouyang L. et al. Training language models to follow instructions with human feedback (InstructGPT). NeurIPS 2022. arXiv:2203.02155
• Zheng L. et al. Judging LLM-as-Judge (MT-Bench / Chatbot Arena). NeurIPS 2023. arXiv:2306.05685
• Efron B. Bootstrap Methods, 1979. Cohen J. A. Kappa 系数 (1960).
• 跨篇：02A 篇（5 模块 JD 能力地图、迁移表、3.5 件底子），05 篇（非确定性统计基础、多轮采样、置信区间、风险矩阵），01 篇（产品质量红线、能力分治）。