现在测什么，用什么数据

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

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

现在的两道题

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

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

两道题能说明什么

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

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

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

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

有哪些固定测试数据

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

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

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

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

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

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

建议下一步补什么

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

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

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

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