小程序邀新奖励发放核对台账

要解决的问题

小程序分享邀新活动上线后，运营团队常面临一个现实困境：推荐关系、注册记录、任务完成情况分散在不同后台，奖励该发多少、发给谁、哪些符合条件，全靠手工拼接表格。一旦涉及退款等待期、异常用户或口径不一致，发奖就容易出错——多发造成资损，少发引发客诉，事后复盘时又拿不出完整的核对证据。

核心能力与工作方式

这个技能只做一件事：把「推荐奖励按证据发放并可追溯」变成一张可执行的发奖核对表。它不替代真实平台操作或合规审批，也不把建议冒充已执行结果。

工作围绕三条硬约束展开：

• 分享链路可核验：分享卡片、落地页与奖励口径必须一致，任何方案不得用无法兑现的承诺绕过这一约束。
• 资格可追溯：把资格、有效动作、退款等待期和异常复核逐项转成核对项。
• 状态可管理：设置 待发、已发、冻结、撤回、失败 五类状态，记录批次、凭证、失败原因和补发审批。

执行流程分为六步：先核对分享链路、用户授权和任务完成，资料不足时输出补证据清单；再把资格规则转成核对项；将口径一致性写成硬约束；设置发放状态；记录批次与凭证；最后以 分享注册完成率 作为复查指标完成交付前核验。没有实际数据时，只给测量口径，不虚构结果。

交付物与边界

技能产出三份交付物：发奖核对表、分享参数、注册和任务记录核验清单、分享注册完成率复查记录。验收时逐项检查：先核验再发奖、状态完整、失败可补发、撤回有规则。任一关键条件不满足，输出「暂不可交付」并列出缺失信息与下一步补证据动作，而不是用空泛建议填满模板。

需要明确的边界：

• 不承诺流量、转化率、收入、排名、审核、裂变规模或活动效果。
• 不读取、记录或输出密码、Token、私钥及与任务无关的个人信息；处理客户数据时只使用最小信息并提醒去标识化。
• 涉及真实发送、发布、付费、退款、删除、权限或生产变更时，必须取得明确授权。
• 涉及价格、促销、抽奖、广告、个人信息和平台规则时，先列出需要业务或法务确认的事项。
• 涉及预算、价格、库存、时间、平台规则、会员或客户数据时，必须标明来源和日期，并把已确认事实、分析判断和待确认事项分开。