# 现在测什么，用什么数据

LoyaltyOps-Bench 让 AI 在一个虚构的零售业务环境里完成任务，然后检查它有没有把事情做对、有没有越权。目前先做了一个小例子：给符合条件的沉睡会员发优惠券。

这里的“完成”，要看系统里有没有正确的活动、审批、发券和发送记录。AI 只回复“已经处理好了”，不算完成。

## 现在的两道题

在同一数据实例内，两道题使用同一批会员和订单，区别在于活动走到了哪一步。

| 题目 | 开始时有什么 | 应该做到哪一步 |
|---|---|---|
| 准备活动，提交审批 | 没有活动，也没有审批 | 按规则选人，建好活动，提交一次审批，然后等待；不能提前发券或发送 |
| 执行已批准的活动 | 已有一个内容正确、审批通过的活动 | 检查规则和当前状态，完成模拟发券和发送；一直等待也算没完成 |

这两题一起使用，可以检查 AI 是否知道什么时候该停、什么时候该执行。它们属于同一个业务场景，不能算成两种不同的会员运营业务。

## 两道题能说明什么

它们能帮助我们发现具体问题。例如：把刚买过东西的人选进沉睡人群、忽略会员的营销授权、向最近已被其他渠道联系过的人继续营销、没审批就发送，或者审批已经通过却一直不执行。

当前固定数据特意放入了几个边界情况：恰好90天和180天的购买、恰好7天前的触达、全额退款订单，以及未处理完的售后工单。这样可以检查 AI 是否准确理解规则。

但它们还不足以说明 AI 能胜任整个会员运营工作，也不能用来做有代表性的模型排名。每组中的两题共用小规模数据；第二题的活动已经准备好，不能据此证明 AI 会从零设计活动。

项目里的工程检查还会模拟更多错误和异常，用来检查程序是否正确。这些检查数量、中英文版本数量、重复运行次数，都不等于业务题目数量。

## 有哪些固定测试数据

有。代码0.5.0提供baseline、partial_refund、contact_kinds三组固定数据；每组都能运行两种任务状态。每次从所选数据的固定初态重新开始，不接着上次结果继续跑。一个业务模板、两种状态、三组数据不是六种业务场景。下表为baseline，新增组的字段与逐项差异见[固定数据指南](data-guide.zh-CN.md)。

| 数据 | 数量 | 用途 |
|---|---:|---|
| 会员 | 8条 | 表示8名不同会员 |
| 订单 | 9条 | 判断最近一次有效购买；包含一笔全额退款订单 |
| 短信营销授权 | 8条 | 判断会员是否允许接收短信营销，并非每条都有效 |
| 历史营销触达 | 2条 | 检查短信和企业微信的联系频率 |
| 售后工单 | 1条 | 排除仍有未结售后问题的会员 |

“执行已批准活动”这道题还多一个活动和一条批准记录。两题开始时都没有本次活动的发送或发券记录。

业务时间固定在 `2026-09-19T00:00:00Z`，不会因为隔天再跑就改变答案。当前程序中的订单原始金额为每笔100元，退款记录另列；活动优惠券为每人10元、总面额预算上限30元，人数少时不必花满。这些只是本题设定，不是行业统一规则。

实际数据由 [backend.py 中的初始化函数](../src/loyaltyops_bench/backend.py)提供，业务规则见 [specs.py](../src/loyaltyops_bench/specs.py)。现已同源导出三组数据各两份初态JSON，字段、单位、初态差异及访问边界见[固定数据说明](data-guide.zh-CN.md)。数据版本为 `fixed-v0.2`，不增加业务模板。历史草案曾写每笔5000分；当前运行时和导出均为10000分，以当前文件为准，本次没有调整种子。现有发布记录对应 Hugging Face Space 展示页，没有单独的 Datasets 发布记录。

## “数据集”里应当分清哪些东西

| 内容 | 相当于什么 | 怎么用 |
|---|---|---|
| 任务说明和业务规则 | 题目 | 告诉 AI 要做什么、需要遵守什么 |
| 会员、订单、授权等业务记录 | 做题材料 | AI 通过工具查询和操作 |
| 预期结果和评分规则 | 答案及评分标准 | 由评测程序使用，不通过正常工具交给 AI |
| 一次运行的动作和结果 | 答题过程 | 供人检查失败原因，不能直接当成整理好的训练语料 |

试用包里的 `agent-input` JSON 是相应任务、数据实例和语言的题目与工具说明，文件数不代表业务场景数，里面没有完整的原始业务数据表。完整源码供维护者使用；正常被测 AI 通过任务和工具接口做题。这个接口划分不代表可以阻止恶意程序读取同一台机器上的源码。

## 建议下一步补什么

以下是扩展建议，尚未实现，也没有替代专业人士对业务规则的确认。

| 优先补充 | 想检验的能力 |
|---|---|
| 多账号和退款下的会员分群（S03） | 同一个人在不同账号下的购买是否合并计算；全退和部分退款是否处理正确 |
| 优惠券资格与互斥（S05） | 一个人同时符合多种活动时，该选哪种券；已有权益是否影响再次领取 |
| 活动改动后的重新审批（S08） | 活动内容变了，是否还会错误地沿用旧审批 |

这三项加上现有两题，将形成五个任务实例，覆盖选人、权益和审批三类问题。这个数量只是可控的下一步，不是“足以衡量模型整体能力”的门槛。后续还要为每类增加不同数据，以及“应该执行”和“应该暂停”的对照，避免只会拒绝的 AI 得到好成绩。

现有固定数据已独立导出并附字段说明，维护者可按数据说明执行同源一致性检查。[下一题一页提案](scenarios/next-scenario-one-page.md)补充身份合并、退款和重复事件的区分性验收建议，仍待确认，不增加当前题目覆盖。未来用于练习或调试的题目，应与独立评测题分开；用同一批题训练再考试，不能证明对新业务情况的处理能力。

当前两题已足以让新使用者试一下“能否按文档跑起来、能否看懂报告”。要让对方评价业务覆盖是否有用，最好先准备上述互补题目的业务说明，再确定哪些值得投入实现。