开发者社区 Referral 控制：同意归因、反作弊证据与可申诉奖励

Referral URL 看似只是 ?ref=alice，实际承担了三件不同的事：帮助新成员找到社区、判断一次注册与哪个触点有关、决定邀请者是否获得奖励。若系统把这三件事绑定到长期 cookie 和设备指纹，用户拒绝营销测量可能无法注册，同一公司 NAT 下的正常同事会被当成团伙，链接重放又可能重复发奖。AI 应用数据隐私给出一般原则，本篇把用途限制落实到每个 referral 决策。

奖励结算也必须与增长判断分开。这里最多输出一条“满足某 offer 的奖励资格”指令，不直接修改余额、过期时间或退款；预付 Credits 账本负责幂等入账与补偿。这样反作弊规则回滚不会偷偷重写财务历史，账本也不会反过来决定谁是可疑成员。

三份合同，不让 token 变成身份

运营先发布不可变的 community.referralOffer.v1，固定 offer ID、条款摘要、适用人群、每位邀请者上限、合格动作、成熟窗口、奖励类型、禁止关系和申诉时限。规则变化生成新版本；点击时绑定当时版本，不能在动作完成后套用更苛刻的新条款。

schema: community.referralOffer.v1
offerId: oss-sdk-july
version: 3
qualifyingAction: first-sandbox-api-success
maturity: 14d
inviterCap: 20
termsDigest: sha256:9d1...

分享端签发短期、不含账号明文的 referralToken，内容只有随机 token ID、offer version、issuer key generation、到期时间和允许的目标 origin，并由服务端签名。点击产生 referral.touch.v1；同一公开 token 可以带来多个不同成员。被邀请账号首次接受合格触点时，以 (offerVersion, inviteeAccountRef) 做 CAS 锁定 inviter 与 token，后续 token 只留审计痕迹，不能抢占归属；注册和合格动作分别有幂等 event ID。密钥轮换保留验证旧 generation 的只读 key 到最长成熟窗口结束，泄漏时用 revocation generation 阻断尚未接受的 token。

同意状态单独记录 consentSnapshotId、用途、policy revision、capturedAt、expiry 与 withdrawal generation。营销归因需要对应用途的肯定选择；拒绝后仍允许注册和使用公开社区。Global Privacy Control 不能被解释为肯定同意，对其适用的出售或共享用途必须按站点政策执行，并保留处理回执。撤回会停止后续用户级关联并删除可删除映射，但不会伪造一条“从未发生过”的安全审计记录。

WebAuthn 可以证明同一账号当前持有已注册凭证，Passkey 实战说明认证流程；它不能证明现实世界里只有一个人或一个组织，因此不能作为唯一的反女巫证明。Privacy Pass 可以在不暴露可链接身份的情况下携带某类授权 token，也不等于“此人从未注册过”。系统必须明确每项信号能证明什么，未知就进入 INSUFFICIENT_EVIDENCE。

决策基于证据引用，不保存万能画像

成熟窗口到达后，referral.decision.v1 引用 offer、已锁定 touch、邀请关系、服务端合格动作和规则集摘要，输出 ELIGIBLE、QUARANTINED、REJECTED 或 REVERSED 及稳定 reason code。营销归因分支另引用同意快照；拒绝营销测量不会取消依据计划条款已取得的奖励资格。资格与奖励指令以 (offerVersion, inviteeAccountRef, qualifyingActionId) 唯一；创建指令时在同一串行化事务中 CAS 预留 inviter cap，最后一个名额并发只能有一个成功。检测器使用账号内速度、签名 token 重放、明确自邀、循环关系、同一支付工具的已授权一致性等最小信号；IP 和共享设备只能增加不确定性，不能单独拒绝。原始网络标识短期保存，分析层只接收按日限幅的风险特征。API 限流策略处理请求洪峰，反作弊决策仍需完整证据链。

高风险候选先隔离奖励，不自动封禁核心账号。人工审阅看到规则版本、证据摘要和反事实说明，例如“若移除共享 IP 信号，结论是否改变”，但看不到无关私密活动。成员可以在时限内申诉；复核产生新 decision generation 和补偿指令，禁止覆盖原拒绝。所有状态变化作为事件发布，事件驱动架构的消费者必须按 decision ID 去重并拒绝旧 generation。

攻击套件覆盖：邀请者自开新账号、A 邀 B 再由 B 邀 A、同一 token 并发兑换、同一 invitee 并发提交多个 token 与多个 inviter、多个候选争抢 inviter cap 最后一个名额、截获链接改写 origin、注册后更换邀请者、一次合格动作重复上报、一次性邮箱、自动脚本低速分散、企业同事共享 NAT、家庭共用设备、客户端时钟快两天、合格事件晚于水位、offer 过期与密钥轮换竞态，以及点击后撤回同意。还要注入真实共享网络样本，证明系统不会为了拦截合成攻击而误伤正常团队。

上线门要求：签名篡改、过期、错误 origin 和确定性自邀的测试检出率 100%；同一 invitee 用任意数量 token 重放同一合格动作时资格指令最多 1 条；一百个并发候选争抢最后一个 cap 名额时成功预留恰为 1；无有效同意的营销用户级归因为 0；规则输入缺失时自动批准为 0；已人工标注正常样本的错误隔离率低于 0.5%；成熟水位后 99% 决策在 10 分钟内完成；撤回传播 p99 不超过 24 小时；资格指令与奖励账本接收总量逐项守恒。准确率必须附已审样本分母，不能拿合成攻击通过率冒充线上召回率。

新规则先 shadow 计算四周，不影响奖励，只比较旧、新 decision 和申诉结果；随后对 5% 新 offer 启用隔离而非自动拒绝。若错误隔离超过门槛、证据缺失率高于 1%、撤回超时或守恒失败，将 activeRuleset alias 切回旧摘要，停止新 token 签发，并继续按签发时条款处理在途候选。回滚用新的补偿 decision 恢复误拒奖励，同时保留旧证据供审计；不能删除失败案例来让规则看起来更准。