cnboxing.

Rules

测试规则

生效日期:2026 年 4 月 22 日 版本:v1.0 适用范围:cnboxing.net Tier Test 全流程,包括排队、接单、测试、评分、finalize、申诉、S 级提名等

前言

本《测试规则》(以下简称"本规则")是 CN Boxing Tier Test 平台最核心的业务规则,定义了 Tier 测试从玩家排队到出具最终评级的全部流程、标准、义务与边界。

Tier 评级的价值完全依赖于本规则的严格执行。任何对本规则的例外、绕过或妥协,都会直接稀释评级的社区价值。请所有玩家、Tester、工作人员在参与流程前完整阅读并理解本规则。

本规则与《服务条款》《隐私政策》《社区守则》并行,若有冲突,以本规则对 Tier 测试场景的规定为准。

第一章 总则

1.1 适用对象

本规则适用于:

  • 所有申请、等待、参与 Tier 测试的玩家;
  • 所有接单、进行评分、执行 handoff、提名 S 级的 Tester;
  • 所有参与 Tier 测试管理的 Admin、Mod 等工作人员;
  • 与 Tier 测试相关的工单处理、争议仲裁与记录公开。

1.2 Tier 评级的性质

  • Tier 是对玩家在 1v1 拳击实战中综合表现的主观评估,覆盖打法风格(Style)与硬实力(Combat)两个维度;
  • Tier 评级不代表玩家在其他 PVP 模式、其他游戏版本、团队战、娱乐局中的水平;
  • Tier 评级是某一时期的评估,玩家成长或状态波动可能导致同一玩家在不同时段得到不同评级,这是正常现象;
  • 同一玩家由不同 Tester 评出不同档位差异是可接受的正常波动,平台通过多 Tester 评审、A+/S 手动 finalize、保险期等机制控制总体公允性。

1.3 状态机总览

一场 Tier 测试的生命周期遵循以下状态机:

queued → accepted → testing → reviewing → scoring → finalized

失败/特殊分支:

  • cancelled:测试被取消(Admin 作废未完成测试);
  • null:已 finalize 的测试被作废(不计入 current_tier,历史留存);
  • provisional:finalize 后 72h 保险期内的状态;
  • disputed:保险期内申诉成立、待复核的状态。

1.4 不变量

以下是任何迭代都不应打破的核心不变量:

  1. 每位玩家同一时间只能有一个活跃测试(queued/accepted/testing/reviewing/scoring 任一状态);
  2. A+、S、S+ 必须由 Admin 手动 finalize,算法只能自动 finalize 到 A 及以下;
  3. S+ 仅能通过 S 级提名流程产生,不能直接在普通测试中得出;
  4. 72 小时保险期内 current_tier 暂不锁定到 MC 账号;
  5. tier 枚举顺序不可打乱,新增 tier 只能追加;
  6. Tester bad_call_count >= 3 自动熔断接单资格;
  7. Tester 不得对评级收取任何对价。

第二章 测试资格

2.1 基本资格(玩家侧)

您需同时满足以下条件才可排队测试:

  1. 拥有有效平台账号并完成邮箱验证(email_verified = true);
  2. 已绑定合法 Minecraft 正版账号(minecraft_accounts.user_id IS NOT NULL);
  3. 本人没有活跃中的 Tier 测试(idx_tt_active_per_player 唯一索引会阻止并发排队);
  4. 未被平台施加"禁止排队"类处罚;
  5. 承诺遵守本规则全部内容。

未绑定 KOOK 账号不影响排队,KOOK 仅是便利的触达面,不是排队前置条件。

2.2 基本资格(Tester 侧)

您需同时满足以下条件才可接单:

  1. 账号持有 tester 角色(或更高);
  2. 当前在线状态(presence:tester:{user_id} 的 TTL 有效,通过 POST /v1/me/tester/online + 心跳 POST /v1/me/tester/heartbeat 维持);
  3. bad_call_count < 3;
  4. 未被平台施加"禁止接单"类处罚;
  5. 同一时间原则上只接一单。

2.3 回避

Tester 在以下情况下必须主动回避本单,不得接单或应及时 handoff:

  1. 被测玩家是 Tester 的近亲属;
  2. 与被测玩家近一个月内存在显著公开冲突或纠纷;
  3. 与被测玩家存在线下关系(队友、同学、工作同事等)且未向 Admin 披露;
  4. 与被测玩家存在任何对价关系(雇佣、合作、共同创作、财务);
  5. 存在其他合理被认为影响评分公正性的情形。

Tester 违反回避义务,相关测试可被 Admin 作废,并可能触发 bad_call_count 累加与处罚。

2.4 重测限制

为减少排队滥用,重测遵循冷却:

场景冷却时间
正常 finalize 的测试自上次 finalize 起 30 天内不再受理重测,除非评级变化明显(玩家自身水平大幅进步)
null 作废的测试无冷却,可立即重排
保险期内 disputed 撤销的无冷却,可立即重排
因玩家侧违规被取消的根据处罚另行决定,不少于 7 天

上述为原则性规定,Admin 可视具体情况调整。

第三章 排队规则

3.1 排队方式

玩家可通过以下途径进入队列:

  • 网站:POST /v1/me/tier-tests/queue,前端 /me/queue 按钮;
  • KOOK Bot:群内"队列卡"的"申请排队"按钮;
  • DM 驱动(Bot 端):部分场景下由 Bot 引导输入。

3.2 排队原则

  • 排队采用先到先服务(FIFO),同时 Tester 有权基于回避规则跳过特定单;
  • 玩家可在 GET /v1/me/tier-tests/queue/position 查询自己当前名次;
  • 公开快照位于 GET /v1/tier-tests/queue/public,KOOK 队列卡每 30 秒刷新;
  • 排队不保证等待时长,等待时长与在任 Tester 数、匹配情况、高峰段时间、回避情况相关。

3.3 取消排队

  • 玩家可通过 DELETE /v1/me/tier-tests/queue 主动取消;
  • KOOK 队列卡亦有"取消"按钮;
  • 取消不扣任何配额,但短期内频繁取消(24 小时内 5 次以上)可能触发临时禁排:
    • 首次触发:警告 + 24 小时禁排;
    • 再次触发:7 天禁排;
    • 持续触发:按《社区守则》第 3.8 条"滥用平台机制"处理。

3.4 Tester 接单

  • 在线 Tester 通过 POST /v1/tier-tests/:id/accept 接单,或点击 KOOK 卡"接单"按钮;
  • 接单后状态变为 accepted,记录 tester_user_id;
  • 接单 Tester 应在合理时间内与玩家对接并开始测试(一般不超过 30 分钟),超时且无合理说明可由 Admin 回收。

第四章 测试环境与公允条件

4.1 默认环境

除特别说明外,Tier 测试默认环境为:

  • Minecraft Java 版 1.8.9(或平台指定的主流 PVP 版本);
  • 官方指定测试服务器或 Tester 与玩家双方约定的中立服务器;
  • 无奖励、无物品持久化的 PVP 竞技房间;
  • ping 差异不显著(任何一方 ping > 200ms 或双方差距 > 150ms,可申请换服或延后)。

4.2 装备与模组

  • 测试中的装备由服务器预设(如锁甲 / 拳套 / 皮甲等 Boxing 常见配置),不得自备装备;
  • 允许的客户端与模组由运营团队公告,原则上仅公告白名单内的客户端(常见如 Lunar Client、Badlion、CheatBreaker、Minemen Client 等合规版本);
  • 严禁:任何形式的作弊模组(Autoclicker、Reach、KillAura、Velocity、Triggerbot、ToggleSprint 等)、画面外挂、非公告的修改版客户端;
  • 允许:光影(不影响战斗感知的合理范围)、动画包、UI 美化、自动全屏、屏幕坐标显示、FPS 显示等无竞技优势的模组;
  • 争议项:Old Animations 类模组(可能影响挥剑感知),以 Tester 与玩家赛前约定为准。

4.3 基础设施要求

  • 玩家在测试期间应保持网络稳定,稳定 FPS;
  • 建议 FPS ≥ 60 且稳定,若显著不足 Tester 有权暂停测试;
  • 玩家应关闭可能干扰的后台软件(直播推流、录制、语音等可保留,但不应影响性能)。

4.4 掉线与暂停

  • 轻微掉线(单次 < 10 秒):继续测试,Tester 记录;
  • 严重掉线(单次 ≥ 30 秒,或一局内两次以上):本局 void,重打;
  • 连续掉线(三次以上):Tester 可暂停测试,选择:
    • 择日继续(测试保持 testing 状态,但不得超过 72 小时);
    • Handoff 到其他 Tester;
    • Admin 介入 cancel;
  • 玩家恶意利用掉线规避不利局面,按违规处理。

第五章 评分系统

5.1 两维度评分

每位 Tester 对一场测试给出:

字段范围含义
style_score0–50打法风格(Style):节奏、选择、走位艺术、思路创造性、打法体系完整度
combat_score0–50硬实力(Combat):命中率、反应、极限操作、抗压、对位针对性、连刀(叠刀)与起手(FirstHit)质量
comment文本评语,对评分做支撑说明,建议 100–500 字

单个 Tester 的总分 = style_score + combat_score,范围 0–100。

5.2 多 Tester 平均

  • 同一场测试可有多个 Tester 提交 review(tier_test_reviews 按 (test_id, reviewer_user_id) 唯一);
  • 最终 tier 基于所有已提交 review 的平均总分(avg = AVG(style+combat))落档;
  • 主评 Tester(接单者)的评分权重目前与其他 Tester 相同,未来可能引入主评权重微调,变更时会公告;
  • 评分可修改但不可秘密修改:Tester 可在 finalize 前修订自己的 review,修订会留下审计记录。

5.3 总分 → Tier 映射

默认映射(可随社区迭代微调,变更会在公告与本文件版本号中体现):

总分区间映射 Tier
0–15D-
16–24D
25–32C-
33–39C
40–46C+
47–53B-
54–62B
63–71B+
72–81A
82–89A+(强制 Admin 手动 finalize)
90–100S(强制 Admin 手动 finalize)
—S+(仅能通过 S 级提名流程得出)
  • 边界分数(例如 A/A+ 之间)由自动算法处理至 A,A+ 以上必须走人工 finalize;
  • 平台内部 tier_value 枚举使用 snake_case(d_minus / c_minus / c_plus / b_minus / b_plus / a_plus / s),前端通过 tierfmt 映射成 D- / D / C- / ... / S / S+。

5.4 评分守则(Tester)

  • Style 评分考虑但不限于:
    • 节奏掌控与变速能力(慢打 / 快切 / 骗刀 / 控场);
    • 走位意识(距离管理、角度控制、Runner vs Styler 风格切换);
    • 选择合理性(HitSelect 判断质量、MidTrade 收益评估);
    • 打法辨识度、创造性、体系完整度;
    • 对手适应能力。
  • Combat 评分考虑但不限于:
    • 命中率、核心连招(叠刀)稳定性;
    • FirstHit 起手质量与控场能力;
    • 反应速度与抗压(被反打时的恢复);
    • 动作准度(瞄准、Tracking)与极限帧操作;
    • 对不同打法的正反调整。
  • 禁止以下打分动机:
    • 基于玩家的现实身份(性别、年龄、地区等)打分;
    • 基于玩家的社区人气、外部影响力打分;
    • 基于与玩家的私人关系(无论正面或负面)打分;
    • 基于"想让这个档位人少/多一点"的社区工程目的打分。

5.5 评分提交

  • Tester 通过 POST /v1/tier-tests/:id/score 提交 review;
  • 所有 Tester 提交完毕后,接单 Tester 调用 POST /v1/tier-tests/:id/finalize 触发 finalize 逻辑;
  • Tester 可以在 review 提交前查看其他 Tester 的已提交分数(匿名可选),避免极端偏离;
  • 若自己的分数与整体均值显著偏离(> 20 分),应在 comment 中详细说明理由。

第六章 Tier 档位定义

以下是对每个 Tier 的参考性描述,作为 Tester 评分与玩家自我认知的锚点。实际评分以综合表现为准,档位描述不构成排他性清单。

6.1 D- (d_minus)

刚接触 Boxing PVP,基本操作(跳劈、起手、移动)尚未形成。节奏混乱,命中率低。适合大量练习基础动作。

6.2 D

掌握基本操作,能完成简单起手与躲避。连刀不稳定,节奏未成型。

6.3 C- (c_minus)

开始有粗略打法意识,能识别常见起手,但选择和节奏仍不稳定。对高段位选手基本无抵抗。

6.4 C

具备稳定基础操作与基础叠刀。对同段位对手能打出大致均势。

6.5 C+ (c_plus)

出现清晰打法倾向(偏 Runner 或 Styler)。能主动用节奏变化取胜,而非单纯拼手速。

6.6 B- (b_minus)

打法开始体系化,能在不同对位选择合理策略。被压制时有一定挣脱能力。

6.7 B

成熟的 B 段玩家。Style 与 Combat 平衡,鲜明风格初现。对 C+ 及以下有稳定胜率。

6.8 B+ (b_plus)

自此档位起要求录像。风格极具辨识度,拥有一到两套拿手体系。能在节奏上压制同段位或 B 段对手。

6.9 A

必须提供录像。顶尖玩家行列。操作密度高、决策稳定、对位分析细致。能稳定赢下 B+ 段位选手。

6.10 A+ (a_plus)

必须提供录像,且由 Admin 手动 finalize。国内 Boxing PVP 的准顶尖水平。打法完整、风格独特、在多种对位下仍保持高胜率。处于 A+ 即意味着接近国内天花板。

6.11 S

必须提供录像,由 Admin 手动 finalize。国内最顶尖的 Boxing 玩家。在绝大多数对位中占优,拥有对本段玩家体系性的影响力(其打法可能被模仿、被研究)。国内 S 档名额稀少,社区对其期待与责任同样较高。

6.12 S+ (s_plus)

仅通过 S 级提名流程产生(见第九章)。S+ 代表具有跨时代影响力的玩家:不只是水平最高,还在技术体系、社区贡献、历史地位上具有持续影响力。S+ 一旦授予,除非重大违规,原则上不降档。

第七章 录像要求

7.1 录像档位

B+ / A / A+ / S / S+ 测试必须提交完整录像。B 及以下不强制但鼓励提交。

7.2 录像要求

  • 内容完整:包含本次测试的全部对局,无明显剪辑或跳过;
  • 分辨率:建议 1080p,不低于 720p;
  • 帧率:建议 60fps,不低于 30fps;
  • 声音:保留游戏音或至少保留时间戳可追溯性;
  • 第一视角:玩家第一视角为主,Tester 视角作为参考;
  • UI 可见:生命、ping、FPS、血条等关键 UI 元素清晰可见。

7.3 提交方式

  • Tester 或玩家通过 POST /v1/tier-tests/:id/set-recording 提交录像 URL;
  • 推荐平台:Bilibili、YouTube、Google Drive(需可访问)、对象存储直链;
  • 不接受:需要下载的大文件链接、已设密码不可看、要求关注/付费才可播放的链接;
  • 公开档案将包含录像 URL,玩家同意 Tier 测试即同意录像可被社区查看与引用。

7.4 录像与申诉

  • 录像是 tier-appeal 工单的核心证据;
  • 缺失录像的 B+ 及以上测试,在保险期内被申诉时,平台倾向于支持申诉、重测或下调,以鼓励录像规范;
  • 伪造、拼接、加速/减速录像属于重度违规。

第八章 Finalize、保险期与申诉

8.1 Finalize 条件

  • 接单 Tester 发起 POST /v1/tier-tests/:id/finalize;
  • 若所有指定 Tester(至少主评 Tester)已完成 review,且:
    • 总分落在 A 及以下:系统自动 finalize;
    • 总分落在 A+ 及以上:系统会拒绝自动 finalize,需改由 POST /v1/admin/tier-tests/:id/finalize 由 Admin 手动完成。

8.2 Finalize 后立即发生

  • tier_tests.status = 'finalized',final_tier 写入;
  • 冗余写回 minecraft_accounts.current_tier / current_total_score(带 provisional 标记,直到保险期结束正式锁定);
  • 写入 tier_test_history 一条记录,带 public_reason 字段说明理由;
  • 公开档案 /tier-tests/:id 立即生效;
  • 进入 72 小时 provisional 保险期。

8.3 72 小时保险期(provisional)

  • 期间 current_tier 在排行榜展示带 provisional 标签;
  • 期间内任何当事人(玩家、参与 Tester、旁观 Tester)均可通过 tier-appeal 工单申请复核;
  • tier-appeal 工单优先由非涉事 Admin 处理,保障中立;
  • 保险期内 Admin 可直接:
    • POST /v1/admin/tier-tests/:id/null — 作废评级,玩家 current_tier 清回前值;
    • 重测安排 — 由 Admin 协调安排新 Tester 与玩家再测;
    • 维持原判 — 明确说明理由;
    • 标记为 disputed — 状态延长,等待更多证据。
  • 保险期到达 72 小时且无悬而未决的争议时,评级正式锁定。

8.4 期后申诉

  • 期满后 Admin 仍可受理申诉,但举证门槛显著提高:
    • 需提供新证据(如作弊证据、录像证据、Tester 偏袒证据);
    • 单纯"我不服"不足以启动期后申诉;
  • 期后翻案的典型后果为 null + 重测,而非简单下调档位。

8.5 申诉流程要点

  1. 通过 /me/tickets/new 选 tier-appeal 模板开单;
  2. 工单应包含:
    • 涉及的测试 ID(/tier-tests/:id);
    • 您是玩家、Tester、还是旁观者;
    • 您的具体不满点(偏高 / 偏低 / 程序违规 / 评分偏袒等);
    • 证据(录像片段时间戳、聊天记录、对位对比等);
  3. Admin 可能要求您补充信息,请在合理时间内回复(3 天内);
  4. 最终结论会通过工单回复,并在必要时更新测试公开档案。

第九章 S 级提名流程

9.1 触发条件

S / S+ 档位的特殊性决定了其流程独立于普通 finalize:

  • 主评 Tester 在 A+ 测试 finalize 时,可发起 S 级提名(POST /v1/tier-tests/:id/s-nominate);
  • Admin 可直接开单手动提名(POST /v1/admin/s-tier-nominations),无需以 A+ 测试为前置(v9 新增);
  • 提名创建一行 s_tier_nominations status = 'pending'。

9.2 投票

  • 所有在任 Tester 可通过 POST /v1/s-tier-nominations/:id/vote 投票;
  • 投票选项:approve / reject / abstain;
  • 每位 Tester 仅一票,可修改;
  • Admin 通过 POST /v1/admin/s-tier-nominations/:id/convene 召集投票(系统 push 给所有在任 Tester);
  • 投票期一般为 7 个自然日(Admin 可根据重要性调整),到期后无论投票数量是否充分,进入 Admin 终裁;
  • S+ 级提名一般适用更高投票门槛(参考:在任 Tester 中超过 2/3 支持)。

9.3 Admin 终裁

  • Admin 通过 POST /v1/admin/s-tier-nominations/:id/decide 决议 approved / rejected;
  • Admin 决议时应同时给出公开说明,说明理由、权衡与证据;
  • 决议后:
    • approved:玩家 current_tier 授予 S / S+,写入历史;
    • rejected:回落为 A+ 或保持原 tier,玩家可在冷却期后再次提名。

9.4 S / S+ 降档

  • S / S+ 属荣誉档位,不会因一两次失利降档;
  • 但若发生以下情况,Admin 可启动降档复审:
    • 提名基础的证据被发现造假;
    • 玩家被查实严重违规(作弊、代打、恶意评级干预);
    • 长期不参与社区、玩家本人请求降档;
    • 水平明显下滑且有社区共识;
  • 降档需经 Admin 集体决议,且至少 48 小时公告期供玩家说明。

第十章 Handoff

10.1 概念

Tester 接单后发现自己不适合裁决,可使用 handoff 机制转交:

  • Handoff Up:交给段位更高的 Tester(例如接单 Tester 段位是 B,发现玩家明显 A 段,应上交);
  • Handoff Down:退回队列,由段位更低的 Tester 接手;
  • Handoff Sideways:交给同段位其他 Tester(用于回避、时间不可抗力等场景)。

10.2 操作

通过 POST /v1/tier-tests/:id/handoff 进行,可指定目标 Tester 或退回队列。

10.3 何时应 Handoff

  • 发现需回避(见 2.3 节);
  • 发现本人段位或经验不足以评估该玩家(例如:自己是 B 段 Tester,面对显著 A 段表现);
  • 发现自身临时状态不佳(身体、情绪、设备故障),无法做出公允评估;
  • 网络、设备或其他客观问题影响准确性。

10.4 何时不应 Handoff

  • 仅仅因为不想评分(例如怕得罪人);
  • 因为不喜欢该玩家(应走回避,不是 handoff);
  • 以 handoff 作为拖延手段;
  • 频繁 handoff 规避工作量(多次发生会计入 Tester 考核指标)。

10.5 Handoff 后的评分归属

  • Handoff Up/Sideways:新接单 Tester 作为主评 Tester;
  • 已离开 Tester 在离场前若已提交 review,其分数保留,除非主评或 Admin 决定作废;
  • 保留与否的决策会记录在测试档案中。

第十一章 Cancel 与 Null

11.1 Cancel(取消未完成测试)

  • 通过 POST /v1/admin/tier-tests/:id/cancel 由 Admin 执行;
  • 适用场景:
    • 双方持续掉线、无法继续;
    • 发现测试进行中存在严重违规(双方任一方作弊、恶意代打、测试环境不公允);
    • 测试因不可抗力中断且无法恢复;
  • Cancel 的测试状态置为 cancelled,不计入历史评级,公开档案标记为已取消。

11.2 Null(作废已 finalize 测试)

  • 通过 POST /v1/admin/tier-tests/:id/null 执行;
  • 适用场景:
    • 保险期内申诉成立,判定原评级不应保留;
    • 后期发现测试涉及作弊、代打、评级内定;
    • 录像证据证明结果存在显著错误;
  • Null 的测试:
    • 状态置为 null,原 final_tier 保留但不计入 current_tier;
    • minecraft_accounts.current_tier 回滚至 null 发生前的值(依历史链);
    • 公开档案标记为"已作废",保留供审计与警示。

11.3 Null 的影响面

  • Tester 的 bad_call_count 可能因此 +1(若 null 原因与该 Tester 评分错误相关);
  • 若涉及玩家违规,玩家可能受《社区守则》第七章处罚;
  • Null 不等于无记录,作为社区教训,其档案将被保留。

第十二章 Tester 申请与考核

12.1 申请条件

  • 账号持有有效网站 + MC + (推荐)KOOK 绑定;
  • 账号处于 good standing(未处罚);
  • 自身 Tier 不低于 B(建议,具体门槛可由 Admin 调整);
  • 拥有足够的社区活跃度与被识别度(无硬性天数,由投票 Tester 综合判断);
  • 熟悉本规则与《社区守则》。

12.2 申请流程

  1. POST /v1/me/tester/apply 提交申请,tester_applications.status = 'voting';
  2. 在任 Tester 在 GET /v1/tester-applications 看到 pending 列表;
  3. 投票期内,在任 Tester POST /v1/tester-applications/:id/vote 投 yes/no(唯一票,可改);
  4. Admin 查看票数与 Tester 评语,POST /v1/admin/tester-applications/:id/decide 决议:
    • approved:授予 tester 角色,建 tester_profiles 行,申请人收通知并同步 KOOK 身份组;
    • rejected:申请不通过,3 个月内不可再申请。

12.3 Tester 考核指标

指标来源用途
accepted_tests_count接单计数Tester 工作量
reviewed_tests_count提交 review 计数评分活跃度
bad_call_count错误评分累计硬熔断阈值
在线时长presence 心跳统计参考
被申诉命中率tier-appeal 工单占比公允度参考

12.4 Bad Call 判定

  • Bad Call 指某次评分在工单或复核中被判定为显著错误(不是简单的档位正常波动);
  • 判定由 Admin 按证据做出,相关 Tester 可抗辩;
  • bad_call_count = 3 触发自动熔断,Tester 不能再接新单;
  • 熔断后由 Admin 走专门流程(培训、降级 Tester、撤 Tester 角色之一);
  • 熔断后若经专门流程恢复,bad_call_count 可视情况重置。

12.5 自动熔断与 Tester 下线

  • 超过 30 天未提交任何 review 且未上线的 Tester,可能被自动置为 inactive,需重新申请或由 Admin 激活;
  • Tester 可主动 POST /v1/me/tester/offline 下线,或让心跳超时;在测试中的 Tester 不应直接下线,应先 handoff 或完成。

12.6 Tester 行为底线

Tester 若出现以下行为,一次即可撤销 tester 角色:

  • 收取评级对价(金钱、物品、账号等);
  • 与被测者合谋做假测试;
  • 未经 Admin 批准公开他人未公开测试内容;
  • 冒用主评权限进行强压 / 敷衍评分 / 随意填分;
  • 严重违反《社区守则》第三章任何一款。

第十三章 测试期间禁止行为

测试从 accepted 到 finalized 前,双方应专注于测试本身。以下行为违反本规则:

  1. 延误:Tester 接单后长时间不开始测试(> 30 分钟无说明);玩家在 Tester 通知后不响应(> 15 分钟);
  2. 拒绝公允对位:拒绝在标准环境、标准装备、约定服下测试;
  3. 人身攻击与挑衅:测试聊天或语音中辱骂、嘲讽、威胁;
  4. 操控舆论:在测试进行中同步直播/宣传并号召外部观众施压 Tester/玩家;
  5. 作弊准备:开启任何违规模组;
  6. 干扰行为:故意掉线、故意断电、故意送死以"做出更差的战况";
  7. 泄密:在测试未完成前公开未 finalize 信息(聊天、战况细节、Tester 个人评论);
  8. 行贿:向 Tester 或 Admin 提出任何形式的对价承诺。

违反上述任一款均可导致测试被 cancel / null,严重时触发《社区守则》处罚。

第十四章 Tester 专项守则

14.1 在线与心跳

  • 上线:POST /v1/me/tester/online;
  • 心跳:前端每 30 秒 POST /v1/me/tester/heartbeat,TTL 90 秒;
  • 下线:POST /v1/me/tester/offline;
  • KOOK 侧 Bot 维持独立心跳(60 秒);
  • 心跳断开期间 Tester 不出现在可接单列表,玩家由其他在线 Tester 服务;
  • 禁止伪造心跳(脚本持续 online 但人不在)—— 被发现视为 bad call 或直接撤角色。

14.2 评分诚信

  • 对不同段位玩家使用同一套评分标准;
  • 对同一玩家在不同对位下综合评估,避免单局定分;
  • 在 comment 中写下具体观察(至少 3 条事实依据);
  • 不得泄露其他 Tester 的独立评分以影响评分走向(review 提交前的讨论应避免分数锚定)。

14.3 与玩家的边界

  • Tester 不应在测试进程外与玩家建立可能影响评分公允的私下关系;
  • 不接受玩家的金钱、礼物、游戏物品、外部账号等任何对价;
  • 不应承诺某个档位的结果;
  • 对玩家的投诉保持开放姿态,可通过工单沟通。

14.4 与其他 Tester 的边界

  • Tester 之间可技术讨论,但不应在公开渠道以贬低方式评价其他 Tester 的评分;
  • 发现其他 Tester 评分存在问题时,走工单或 Admin 反馈,不在社区直接声讨;
  • 禁止 Tester 之间"投票互助"(互相通过申请而不看实际水平)。

14.5 公开立场

  • Tester 作为社区识别度较高的身份,其公开发言易被视为"半官方";
  • 在对个别玩家的公开评价、直播内容、社交媒体发言中应保持审慎;
  • 不应在外部平台对特定玩家做"未经评级的公开定档"(例如直播中声称"XX 肯定是 S 级")。

第十五章 争议、复核与仲裁

15.1 常见争议类型

  • 玩家对评级不服(偏高 / 偏低);
  • 玩家对 Tester 评分公允性质疑;
  • Tester 对 Admin 的 handoff/finalize 决定不满;
  • 玩家对测试对位(环境、装备、延迟)提出异议;
  • 对 bad_call 判定的抗辩。

15.2 复核原则

  • 以证据为准:录像 > 聊天记录 > 现场陈述 > 事后回忆;
  • 以规则为准:严格适用本规则与《社区守则》,不以个人好恶裁量;
  • 以平衡为准:既保护玩家权益,也保护 Tester 免于不当施压;
  • 以公开为准:对具有广泛影响的复核结论,在适当范围内公开说明,避免暗箱。

15.3 仲裁机关

  • 一线:工单处理 Admin(/v1/admin/tickets/:id);
  • 上诉:Admin 集体复核或 owner 终审;
  • 硬性门槛:涉及 A+/S/S+ 档位的争议,至少 2 位 Admin 共同处理;涉及对 Staff 的投诉,处理者应非被投诉者及其近亲。

15.4 决议的效力

  • 最终决议自公告之日起生效;
  • 未经决议变更,后续相同诉求的工单可按"已处理"回复;
  • 决议中如发现新规则漏洞或歧义,Admin 有责任推动规则更新。

第十六章 规则变更与版本化

16.1 变更原则

  • 本规则的重大变更(影响评分标准、档位映射、finalize gate、保险期、Tester 熔断阈值等)需经 Admin 集体评议,不少于 7 个自然日公告期;
  • 轻微调整(文字澄清、错别字修正、路径变更)可直接更新,在版本号补丁位(v1.0.x)体现;
  • 所有历史版本存档保留,便于追溯。

16.2 版本号

  • 主版本(v1 → v2):重大框架调整;
  • 次版本(v1.0 → v1.1):评分标准、流程、档位定义的实质变化;
  • 补丁版本(v1.0.0 → v1.0.1):文字修订与说明补充。

16.3 过渡

  • 新规则原则上从生效日起对新测试适用;
  • 正在进行中或保险期内的测试继续适用旧规则,除非新规则对用户更有利且明确允许立即适用。

第十七章 附则

17.1 与其他文档的关系

  • 本规则与《服务条款》《隐私政策》《社区守则》共同生效;
  • 冲突时,对 Tier 测试事项本规则优先,对社区行为一般事项《社区守则》优先;
  • 涉及用户个人信息保护,《隐私政策》优先。

17.2 解释权

  • 本规则的最终解释权在法律允许范围内归运营团队所有,行使解释权应以维护评级公允为依归;
  • 对未覆盖的情形,按规则精神与既有判例处理。

17.3 联系方式

场景渠道
Tier 评级申诉/me/tickets/new 选 tier-appeal 模板
Tester 投诉选 tester-complaint 模板
规则相关建议info@cnboxing.net
紧急事件help@cnboxing.net 或 KOOK 群内 @ Admin

最后更新日期:2026 年 4 月 22 日 版本号:v1.0

写在最后:Tier 不是定义玩家的全部,而是一次次认真测试的横截面。愿每一场 Tier Test 都能被公允对待,也愿每一个被评到的玩家,都因这套规则而感到被尊重。

暂未发布任何规则条目。

最后更新 2026/4/22 22:13:13