漏洞赏金加码之后：先把报告质量、忠诚度与专项奖金的叠加口径写清楚
本次材料未提供赏金规则正文，无法确认具体比例、资格与封顶。文章把叠加口径拆成三个独立变量，建议明确计算顺序、叠加方式、封顶与舍入，并给出开发者应向项目方核实的字段。
漏洞赏金（bug bounty）加码后，争议通常不在单个金额，而在三类奖励能否同时拿、按什么顺序算。本次材料只有主题标题，没有可核验的规则正文；因此只能确认讨论范围涉及报告质量、忠诚度与专项奖金的叠加。具体比例、适用资格、封顶、追溯与结算细节均待核实。下面的口径设计属于建议，不代表任何项目的实际规则。
先把三类奖励拆开#
把“加码”直接理解成总额上浮，会让后续对账很难。更稳妥的做法是先固定三个变量，再讨论它们如何组合。
| 变量 | 建议先定义 | 容易混淆的地方 |
|---|---|---|
| 报告质量 | 有效性、严重级别、可复现性、影响证据是否完整；质量系数作用于哪一部分 | 把严重级别和报告完整度混成一个分数 |
| 忠诚度 | 统计时间窗、有效报告数量、是否要求连续参与；是身份加成还是历史累计奖励 | 把一次高质量报告同时算作质量和忠诚度 |
| 专项奖金 | 适用资产范围、时间窗、名额或先到条件；是否与普通奖金共享基数 | 默认专项奖金一定可以叠加 |
这些字段只是建议清单。项目是否设置忠诚度奖励、专项奖金如何命名，本次材料未提供，不能据此推断。
叠加顺序会改变最终金额#
假设基础奖金为 B，质量系数为 q，忠诚度加成为 l，专项奖金为 s，那么至少要回答：是 B×q+l+s、B×(q+l+s)，还是 max(B×q, l, s)？三种写法在多项同时命中时结果不同。若还有封顶，封顶应放在加法之后还是乘法之前，也要写清楚。
建议把计算顺序写成可审计的步骤，而不是只给一句“可叠加”：
- 按严重级别和有效性确定基础奖金；
- 应用报告质量调整，并记录调整依据；
- 判断忠诚度奖励的资格与时间窗；
- 判断专项奖金是否互斥、是否另设基数；
- 应用总封顶、取整和币种规则；
- 保存规则版本与计算明细。
这是建议流程，不是对现有项目的描述。真正的顺序仍需以项目书面规则为准；没有规则正文时，不应拿宣传口径反推金额。
用一份最小计奖约定固定争议点#
对开发者来说，计奖逻辑更适合当成接口约定：输入资格、规则版本和报告事实，输出分项金额与合计。下面只是字段示例，未执行，数值与枚举均为占位：
{
"rule_version": "demo-2026-11",
"base_award": 0,
"quality_factor": 1.0,
"loyalty_bonus": 0,
"special_bonus": 0,
"stacking": "add | multiply | max（待项目确认）",
"cap": null,
"rounding": "待项目确认"
}如果接口只返回一个总额，至少应在账单明细中保留分项、规则版本和封顶前金额。否则研究者无法判断某一项是未命中、被互斥，还是被封顶吞掉。
提交前应核实的五个问题#
- 三类奖励是否共享同一基础金额，专项奖金是否另设基数？
- 质量系数是乘基础奖金，还是独立加项？严重级别与报告完整度是否分开计分？
- 忠诚度按什么时间窗、多少有效报告计算，是否要求报告在加码期内提交？
- 同时满足多项时，是相加、相乘还是取最高？封顶与取整发生在哪一步？
- 规则变更是否追溯，申诉时以哪个规则版本为准？
在这些问题有书面答案前，研究者不宜按“加码”宣传估算收入，平台也不宜在接口中只暴露总额。保留提交时间、确认时间、严重级别依据和沟通记录，比争论一个未定义的系数更有用。对 API.PLUS 的开发者读者而言，这也是一份可直接复用的验收清单：先定义变量，再定义组合，最后定义审计痕迹。
