当推荐奖励被自荐、假账号或优惠券论坛刷取时…

为B2C/B2B SaaS推荐计划定义奖励上限、速度限制、冷却期、奖励持有窗口、资格规则、身份验证门槛、执行阶梯与滥用监控信号，输出可发布的护栏规范。

适用场景

解决思路

1. 先做访谈：逐条询问项目机制与奖励结构（单双边、奖励类型与金额、发放触发条件）、B2B还是B2C、账号与身份模型（是否仅邮箱注册、是否需手机、合格事件前是否已有支付工具）、现有验证能力（邮箱确认、短信、一次性域名拦截、设备信号、账单 webhook）、可查询数据（推荐事件、注册元数据、支付记录、退款/拒付记录、按队列的留存）、已发现的滥用及发现方式、单次与每月风险奖励金额、底层购买的退款/拒付窗口长度、对摩擦与漏损的容忍度、现有条款对上限/资格/拒发奖励的规定、上线截止日期、是一次性修复还是可持续控制集、工程与审核人力上限以及合格事件是否可改。
2. 确认范围边界：奖励结构（单双边、类型、大小、触发条件）是既定前提，本技能只保护它、不重新设计；若问题出在奖励结构本身，转交 referral-incentive-design。
3. 依据 abuse-patterns 参考映射该项目的滥用面：判断奖励金额、身份模型与合格事件实际暴露了哪些滥用模式。
4. 按控制阶梯排序六类控制（事件、上限、持有、资格、验证、审核），默认第一轮总是做上限、持有与已发布的资格规则；当合格事件是裸注册或未付费行为时，必须升级到事件重设计，因为事件可免费伪造时下层控制都站不住。
5. 按效率排序：event > caps == hold > eligibility > verification > review；按价值排序：event > eligibility > hold > verification > caps > review；按工作量排序：review > event > verification > eligibility > caps == hold；按合规成本排序：verification > eligibility > event == caps == hold > review。
6. 根据访谈答案重新排序并在规范中注明哪条答案移动了哪个控制：硬性上线日期提升 caps、hold、eligibility（配置化、一个冲刺）并把事件重设计排到下个周期但绝不删除；持续复利要求提升事件设计与资格记忆；低工作量上限则直接从规范中删除人工审核与高摩擦验证档，并记录删除项与原因。
7. 再按已知项目情况重排：合格事件前已收集支付工具则大幅提升验证（最强门槛已付费）；已有信任与安全团队则审核工作量塌缩；受监管项目已做身份检查则最高档验证边际成本为零。
8. B2B与B2C分开处理：caps、hold、eligibility 记忆对两者相同；B2B 差异在于推荐人与被推荐人的域名重叠检查（仅查工作邮箱太弱，空壳公司有真实域名）、发放前人工审核（B2B 中 ROI 为正、B2C 中不为正）、默认以公司账户额度发放（向员工个人付款首先是采购/礼品政策问题而非欺诈问题）。
9. 从 detection-signals 参考选择监控信号，效率排序为：payment-reuse == cohort-quality > velocity > email-similarity > graph > fingerprint；cookie 与 IP 关联不参与排序（价值已到底，排序是虚假精确）；graph 信号在此排序中被饿死，需按参考中的条件才提升。
10. 依据 enforcement-and-compliance 参考设计执行阶梯：已发布的档位、每次拒发给出具体原因字符串、可用的申诉路径——先建原因字符串与申诉路径，再建检测器；法律约束作为设计约束，实际法律问题转交律师。
11. 逐条验证规则可发布性：任何未写入现行条款的规则标记为在发布前不可执行，条款起草转交 affiliate-program-terms。
12. 若能查询项目事件数据，用用户自身合法推荐人分布（如每周推荐量的 p95–p99）推导速度与标记阈值；否则标记为示例默认值，并在首个复核周期内替换为推导基线。
13. 按 Output Shape 逐节输出护栏规范供用户确认，并匹配 worked-examples 中对应的 B2C 或 B2B 示例。
14. 附上 Pass Threshold 中的校准计划并迭代至满足：用留出组（holdout）在更宽松规则下与严格规则对比，三项条件全部满足才算通过——严格组每 1,000 名暴露推荐人的 90 天队列价值不低于留出组（该条件为承重条件，绝不可用每注册均值替代）、被推荐队列在留存/退款率/90 天收入上优于自然流量、按公式计算的净收益为正。
15. 用同一单位同时计算漏损与摩擦：Leakage =（无效奖励支付额）×（奖励成本）；Friction =（错误扣留奖励数）×（奖励成本 + 支持成本 + P(churn) × LTV）；摩擦项带 LTV 乘数而漏损项没有，因此 1:1 错误率权衡几乎从不打平，存疑时放宽。
16. 若被推荐队列即使有合理护栏仍输给自然流量，说明项目在买注册而非获客，缺陷在奖励结构，转交 referral-incentive-design 而不是继续收紧。
17. 若尚无校准数据，在交付物中说明并把留出组安排为首个上线后复核关卡。
18. 若运行环境有持久记忆，记住已决定的阈值、持有窗口与执行档位，使后续调参从这些值开始而非重新访谈。
19. 按规范模板输出：合格事件（奖励触发 + 为何伪造代价高 + 可逆性说明）、上限（每位推荐人的周期与终身上限、每位被推荐人上限、项目预算天花板，沿用现有奖励设计中的值并记为既定）、速度（每位推荐人每窗口的推荐/领取数 + 爆发后冷却）、持有策略（持有长度 = 退款/拒付窗口 + 处理时间，含待定状态展示）、资格（新客户定义、自我/家庭排除、跨推荐人冷却、B2B 域名重叠规则）、验证（按摩擦档位的门槛、每档升级条件、永不设门槛的项）、监控（观察信号、预期标记基线、队列质量看板）、执行（已发布档位、原因字符串、申诉路径与响应 SLA）、条款状态（每条规则发布位置；未发布即不可执行）、校准（留出单元设计、复核节奏、漏损/摩擦计算）。
20. 每条阈值行标注来源（已发布条款、学术结果、厂商经验法则或用户自数据基线），绝不把厂商启发式当作行业常数；每条规则行注明可能触发它的合法行为。
21. 避开两个流传数字：『推荐欺诈占电商欺诈 21%』是厂商循环引用，『$443B 误拒 vs $48B 欺诈』是不可验证的精确度；只引用机制——误报成本高于欺诈，因为附带 LTV 损失。
22. 区分真实滥用者与激进薅羊毛者：前者走执行阶梯，后者只需调整规则且通常值得留存。
23. 确保每条规则在推荐发生前已发布在项目条款中，否则对该推荐不可执行；设计规则时同步设计其发布方式。
24. 跟踪 KPI：无效奖励率（漏损）、申诉改判的错误扣留率（摩擦）、被推荐与自然流量队列在留存/退款率/90 天收入上的差值、标记率对照预期多账号基线、持有到释放时间、预算天花板消耗、拒发奖励的支持工单。
25. 当申诉改判率上升（规则过紧）、队列质量下降而标记率持平（推荐团伙在雷达下）、合格事件退款率上升（事件太廉价）时，升级规范本身。
26. 常见失败模式及修复：护栏过紧杀死合法推荐（用漏损/摩擦公式放宽至每 1,000 名暴露推荐人的队列价值恢复；每注册均值上升而量下降正是此缺陷特征）；有上限无速度检查（每个上限配每窗口速度限制与爆发冷却）；忽略设备与支付工具复用（先查支付工具复用，这是已持有的最强信号）；静默拒发奖励（先建具体原因字符串与已发布申诉路径）；追溯收紧规则（先发布后执行，已赚奖励不追溯）；持有窗口短于退款窗口（持有 = 退款/拒付窗口 + 处理时间，按产品线设定）；把热情推荐人当团伙（需图结构之外的佐证：奖励拆分、退款、队列崩塌）；人工审核成本超过奖励价值（仅对高于审核成本的奖励保留审核，B2B 默认、B2C 例外）；对低价值消费者奖励做完整 KYC（止步于支付工具验证，KYC 留给受监管项目）。

适用边界 · 注意事项

• 不用于专业联盟流量欺诈——应使用 affiliate-fraud-detection。
• 不用于重新设计奖励结构（单双边、类型、大小、发放触发、分层）——应使用 referral-incentive-design。
• 不用于起草消费者推荐条款措辞——应使用 affiliate-program-terms。