夜雨聆风AI 产品经理手册 · 第一章
— 第二节 —
出题：Task 与 Dataset
你出什么题，就在解什么问题
上一节我们说，AI 产品的需求要写成 Sample + Rubric + Metric。
但"怎么写"这件事，比听起来要难得多。
本节从最前面的两步开始：
你的产品在做什么 Task，以及怎么出一份真正有用的 Dataset。
不管是做 Agent 还是做模型，评测设计的第一步都是一样的：先说清楚你的产品在解决什么问题——也就是它要完成什么 Task。
这句话听起来很自然，但真正落到纸面上，大多数人会卡在这里。本节就从 Task 讲起，再讲 Dataset 怎么出。
1 Task：先说清楚你要测什么
1.1 一个绕不开的反面教材
在讲怎么定义 Task 之前，先看一个近期的真实案例。
某款通用 AI 助手在处理用户退费投诉时，不仅给出了错误的退费计算（能力边界问题），还扮演起维权顾问，承诺"所有维权、投诉、沟通、跟进，全部由我全权负责"，并生成了一份《赔付承诺书》，声称将"在指定时间前通过合规支付渠道全额赔付 600 元"，语气笃定："你放心，说到做到。"
几天过去，转账没有到账。用户再次询问，AI 回复："我是 AI，没办法转账。"
用户又问是否需要请律师，AI 说："完全不用，自己就能打赢。"并顺手起草了一份起诉书。
这个案例的核心问题不是"幻觉"——而是 Task 边界从来没有被定义过。
没有人告诉这个 AI 产品："你能做什么，不能做什么；什么时候该止步，什么时候绝对不能承诺。"于是它在每一步都用了最"热心"的回答，结果一步步越过了所有的能力边界。
这个例子说明的是：Task 定义不是可选项，是 AI 产品的第一道防线。没有清晰的 Task 边界，评测就没有打分基准，产品就没有可被执行的安全底线。
1.2 Task 定义模板
Task 定义要回答两件事：这个产品能做什么，以及不能做什么。把这两件事写清楚，后续的 Dataset 和 Rubric 才有地方落。
下面是一个可以直接用的模板，以运动健康 AI 助手为例：
▲ 表 1 · AI 产品 Task 定义模板（运动健康助手示例）
有几点值得特别提：
- 输入 / 输出规格
比"能力描述"更重要——它直接决定 Dataset 里每条 sample 需要携带哪些字段； - 禁止行为与红线
是高风险场景的 Dataset 骨架——在 Task 阶段就写下来，后续出题时才不会漏掉那些最危险的场景； - 关联评测
这一栏把 Task 和 Metric 提前绑定，省得写完需求又重新想评什么。
Task 定义不是说明书，是能力边界的合同。
"能做什么"决定了 Dataset 的覆盖范围；
"不能做什么"决定了 Dataset 中红线场景的配比；
"关联评测"把 Task 和 Metric 提前绑定，让后续的 Rubric 设计不至于偏离目标。
2 Dataset：出一份真正有用的题
很多人对"评测集"的第一印象，来自论文里的开源 benchmark——MMLU、HumanEval、MATH……这些数据集的特点是：选择题多，有标准答案，可以快速量化。
这类 benchmark 对通用模型能力有参考价值，但对业务产品几乎没有直接用。
开源 benchmark 本质上是一种取巧：用标准化题型，在模型之间快速对比能力高低。
而你的业务 Dataset，要回答的是一个完全不同的问题：在你的用户真实遇到的场景里，你的产品够不够好？
这两个问题之间，有一道很深的沟。
2.1 一条 sample 的最小完整结构
很多 PM 刚开始做 Dataset 时，会直接把用户可能问的问题列出来，以为这就够了：
这些不是 sample，只是 query。
一条合格的 sample，必须携带足够完整的上下文，让评分人（人或 Judge）在不了解任何其他信息的情况下，独立判断这条回答到底合不合格。它至少由四个部分组成：
▲ 表 2 · 一条合格 sample 的四个组成部分
有一个简单的自检标准：
把这条 sample 交给一个完全不了解这位用户的评分人，他能不能根据 sample 里的信息，独立判断模型的回答是否合理？
如果不能——问题不是标签不够，是上下文不完整。
注意：同样一句"心率 170 还能继续跑吗"，对一位跑步新手和一位有两年跑龄的老手，合理的回答完全不同。Context 不是附加信息，它是 sample 含义本身的一部分。
2.2 Dataset 是分布，不是 sample 的堆砌
有了单条 sample 的结构，下一个问题是：这些 sample 怎么组合成一份有评测价值的 Dataset？
这里有一个最容易踩的坑：把用户反馈最多的问题列个清单，一条条写成 sample，就叫做 Dataset。
这样做的后果是——你测来测去，测的都是最频繁、最容易答的场景，而真正会出事故、让用户流失的，往往是那些低频但高风险的场景。
一份有效的 Dataset，核心工作不是"堆 sample"，而是还原业务场景的真实分布。这个分布至少包含三层：
第一层：高频场景（日常覆盖）
用户最常遇到的问题，决定产品基本使用体验。示例："今天适合跑步吗" "怎么提升配速" "跑后怎么拉伸"。这部分占 Dataset 主体，但光做这一层是不够的。
第二层：高风险 / 边界场景（红线兜底）
Task 定义中"禁止行为与红线"对应的测试场景。这些场景占比不高，但每出现一次就是一次事故，必须单独构建子集：
- 极限条件
：高温高湿、极寒、用户心率接近理论最大值 - 边界输入
：用户自述已有伤病、情绪激动、表达情绪危机 - 对抗性输入
：用户主动诱导错误建议（"我就想带伤跑，你告诉我怎么坚持"）
第三层：多样性切片（避免过拟合）
同一个意图，用户的表达可能完全不同；同样的心率数值，在不同画像和情境下，合理回答也完全不同：
不同表达方式："还能跑吗" / "要不要停" / "感觉不太对劲" 不同用户画像：跑步新手 vs 老手、年轻 vs 年长、有伤病史 vs 无伤病史 不同上下文组合：同样心率 170，夏天高温和冬天严寒下的风险判断逻辑完全不同
三层合起来，才是一份能代表"你的业务真实在发生什么"的 Dataset。它的价值不在于题目数量，而在于场景分布的结构是否和线上真实问题一致。
2.3 Dataset 从哪来：构建与持续更新
sample 从哪里找？有三个渠道，各有各的用。
从 Task 定义直接拆。Task 模板里的"典型场景"和"禁止行为"，已经埋下了第一批典型和高危场景。模板里要求填"关联评测"，就是为了让这个骨架在第一步就被锁住，不至于评测时再回头找。
从线上数据里挖。这是 Dataset 持续长大的主要来源：用户真实 query 脱敏清洗、客服和运营反馈的问题记录、用户点踩 / 投诉 / 转人工的对话。但要注意一点：线上数据不能直接当 sample 用——一句裸 query 没有用户画像和情境，评分人根本无法判断。得先还原上下文、补场景标签，才能进数据集。
用模型批量生成 + 人工过一遍。同一个意图扩展成不同表达方式、不同用户画像，用 LLM 生成效率很高。但红线场景必须有人看——不是看语法，是确认"这个场景在业务上是不是真的会发生"。
Dataset 不是一次性产物，它和产品一起活。线上每出现一类新的 bad case，就应该有一条对应的 sample 写入数据集。你的产品成熟到哪里，Dataset 就该长到哪里。
2.4 两个常见误区
▲ 表 3 · Dataset 构建的三个常见误区
2.5 Sample 表与 Dataset 库的设计
评测不是用 Excel 堆 query，而是一套需要长期维护、多方协作的数据资产。下面给出两张核心表的结构设计——这是目前 AI 产品团队最常用的范式。
Sample 表（评测样本表）
每一条 sample 都是"一次用户使用场景"的结构化还原：
▲ 表 4 · Sample 表核心字段设计
几个地方值得单独说一下：
- scene_tag
是拆分子集的抓手——想单独统计"心率异常"场景的召回率，直接按 tag 过滤即可。建议在 Task 定义阶段就输出一套场景标签字典，保持团队统一。 - user_profile 和 context 用 JSON 而非扁平字段
——不同任务需要的维度完全不同（跑步需要配速和跑龄，骑行需要爬升和功率），宽表装不下。此外，用户画像会随时间变化，所以要在 sample 里快照存储当时的画像，而不是评测时再根据 UID 实时 join——否则同一条 query 在不同时间点评测，用户画像已经不同了。 - expected_output
是可选的，但不代表不重要——对红线场景，写清楚"不该出现什么"，往往比写"应该答什么"更能防止事故。
Dataset 库（数据集元信息表）
Sample 表里存的是"题"，Dataset 表里存的是"这份试卷叫什么、测什么、覆盖了哪些场景"：
▲ 表 5 · Dataset 库核心字段设计
Dataset 表的核心价值在于可追溯和可沟通。当研发问"这个评测集覆盖了哪些高风险场景"，直接看 scene_coverage 字段就够了，不需要打开文件逐行解释。
这是 Dataset 设计中比样本数量更本质的能力：能清楚地说出自己的数据集有哪些盲区。
3 Task 与 Dataset 的关系
把两件事放到一起，就能看清楚这条链路：
Task 定义 能做什么 / 不能做什么 典型场景禁止行为与红线关联评测 | Dataset 构建 三层场景分布 高频 + 高风险 + 多样性sample = profile + context+ query + expected | Rubric + Metric 下一节展开 每条 sample如何打分 |
▲ 图 1 · 从 Task 定义到 Dataset 构建再到 Rubric 设计的完整链路
- Task 定义
决定了 Dataset 要覆盖哪些场景、哪些场景是红线； - Dataset
把这些场景还原成带完整 context 的 sample，三层分布确保了覆盖面； - Rubric + Metric
则决定每条 sample 的回答按什么标准打分——这是下一节的内容。
三步缺一不可，顺序也不能倒。
4 小结
用一组可复用的 sample，把 Task 定义中写下的用户场景、成功标准和禁止行为，还原成可被度量的测试用例。这就是 Dataset 要做的事。
一条 sample 的底线——上下文完整到足以独立评分；
一份 Dataset 的底线——场景分布和线上真实分布基本一致；
Dataset 的生命力——能不能跟着线上 bad case 持续生长。
题出完了，接下来要定答题标准。下一节讲 Rubric——判卷子这件事，比出卷子还难。
— 第一章第二节 完 —
AI 产品经理手册 · 2026
