平台规则台账 (platform-rules-ledger)

当用户说「会不会被限流 / 为什么没流量 / 我的内容发不出去 / 账号被处罚了 / 平台规则 / 流量池 / 等级权益 / 违规红线 / 平台又改规则了 / 这个平台怎么起号」时触发。

支付宝 AI 按量付费（A2M / HTTP 402）工作流

本技能基于 A2M（HTTP 402 Payment Required）按量付费协议对外提供服务：未付费请求一律返回 402 与 Payment-Needed 账单头，付费后携带 Payment-Proof 重试才返回核查结果。支付环节交由支付宝官方 alipay-payment-skill（底层 alipay-bot）完成，本技能只负责账单下发、验付、生成核查单与履约确认。

1. 402 账单下发

未携带有效 Payment-Proof 时，服务端返回 HTTP 402，并在 Payment-Needed 响应头中返回 Base64URL 编码账单。响应体仅用于调试，智能体支付依据是 Payment-Needed 头。

返回 402 前必须先持久化订单（见第 5 节），Payment-Needed.protocol 携带：out_trade_no、amount、currency=CNY、resource_id、pay_before、seller_signature、seller_sign_type=RSA2、seller_unique_id；Payment-Needed.method 携带：seller_name、seller_id、seller_app_id、goods_name、seller_unique_id_key=seller_id、service_id。商家账单签名按 key 字典序拼接 amount / currency / goods_name / out_trade_no / pay_before / resource_id / seller_id / service_id，签名只在本地完成，不请求支付宝服务端。

resource_id 取 platform-rules-ledger:<平台代号>:<查询主题>，同一用户对同一平台同一主题的重复查询视为同一资源，便于幂等与防串。

2. 携带凭证重试（支付 + 重试）

Agent 收到 402 后，将整个 402 响应（尤其 Payment-Needed 头）交给 alipay-payment-skill（alipay-bot 402-buyer-pay），引导用户完成付款，并展示订单号 out_trade_no。用户支付完成后，alipay-bot 会自动携带 Payment-Proof 重新请求原始资源地址。重试请求必须原样保留首次的 method / body / 业务 header，仅通过 Payment-Proof 头传递支付凭证，body 不得改动。

3. 验付调用（验付）

收到 Payment-Proof 后，必须调用 alipay.aipay.agent.payment.verify（入参 trade_no、payment_proof、可选 client_session）校验凭证。验付成功不能只看接口返回成功，还必须同时校验：

• active = true；
• 返回 amount 等于本地订单金额；
• 返回 out_trade_no 等于本地订单号；
• 返回 resource_id 等于当前请求资源；
• trade_no 未被重复履约；
• 本地订单处于允许的支付/履约状态（首次进入履约前仍在 pay_before 内且未取消）。

任一校验失败返回 402，让智能体重新支付；不得返回资源。

4. 履约确认

验付通过并生成核查单后，必须调用 alipay.aipay.agent.fulfillment.confirm（入参仅 trade_no）确认履约。确认成功后才将订单标记为最终 FULFILLED 并返回核查单；确认失败允许同一 Payment-Proof 重试确认，避免资源已生成但平台未记录履约。

5. 订单持久化与幂等

返回 Payment-Needed 前，必须持久化 out_trade_no、resource_id、金额、状态、过期时间，确保付款后携带 Payment-Proof 回来时能映射回本地订单。同一订单重复携带 Payment-Proof 时不得重复发放资源：已原子进入待确认或已完成状态的同一订单，只重试确认或返回已保存结果。严格执行幂等履约，防止金额篡改、资源防串（resource_id 必须与验付结果一致）与重复履约。

> 支付相关的协议细节以 alipay-aipay 技能的 aipay-interface-contract.md 与 checklist.md「AI 按量付费专项校验」为准；本技能只实现 402 / Payment-Needed / Payment-Proof / payment.verify / fulfillment.confirm，不混入网页/移动应用收款的 notify_url 体系。

适用场景

平台规则不公开成一份文档，散在创作者中心公告、社区公约、处罚通知和一堆更新日志里。真出事的时候是在内容发出去之后——流量忽然没了，或者收到一条不知道扣在哪的处罚。这个技能把六个平台的分发机制、限流红线、等级权益、处罚梯度和规则变更整理成一份可以逐个对照的台账，让“我到底踩了哪条”变成可以查的事。

它解决的具体困境：

• 笔记或视频发出去几个小时没什么播放，不知道是内容不行还是被限流了
• 收到平台的处罚通知，看不懂是哪一档、会不会降权、多久恢复
• 从别的平台搬内容过来，不知道哪些做法在这个平台算违规
• 简介里留了联系方式，不确定算不算导流
• 想知道平台最近改了什么规则，翻不到一个按时间排列的清单
• 想开新号，不知道新号有哪些扶持、哪些动作会把新号做废

输入规范（问全再答，少一项结论就不准）

必填：

• 平台：小红书 / 抖音 / 视频号 / 公众号 / 今日头条 / B站
• 要查什么：分发机制 / 限流红线 / 等级权益 / 处罚梯度 / 规则变更，可多选

选填（有就结合，结论会精确很多）：

• 账号类型与当前状态：个人号 / 企业号 / 专业号，粉丝量级，是否已被处罚
• 具体内容形态：图文 / 短视频 / 长文 / 直播
• 已经发生的事实：什么时间发了什么、出现了什么结果（没流量 / 收到通知 / 功能被限制）
• 用户自己的判断：怀疑踩了哪条

输出规范（每次按这个结构）

1. 平台与查询主题确认：一句话复述查的是哪个平台的什么问题，避免答偏
2. 分发机制说明：这条内容在这个平台会怎么被推、卡在哪一环最可能
3. 逐条对照：相关红线逐条列「行为 → 后果 → 判定依据」，命中的排前面
4. 处罚梯度定位：如果已经收到处罚，指明落在哪一档、影响范围和恢复路径
5. 变更提示：近一年该平台与本次问题相关的规则调整，按时间排列
6. 自查清单：给一份这次能直接照着打勾的清单
7. 口径与免责：标明数据截止日期、哪些是平台公开说明哪些是行业通行认知

输出必须是逐条对照，不能只给一段结论——用户需要知道是哪一条、为什么、怎么改。

成果物（这是本技能的交付重点）

查询完成后，运行 scripts/rules_ledger.py 的 to_html_report() 生成一份《平台规则核查单》：

• A4 版式的自包含 HTML 文件，含查询条件、逐条对照表、处罚梯度定位、变更时间线、自查清单、报告编号与生成时间
• 浏览器打开后按 Ctrl+P 选择「另存为 PDF」，即得一份可保存、可打印、可对照执行的正式核查单
• 也支持 to_report() 直接输出纯文本版，方便粘贴到工单或群里

给用户结果时，务必告诉他核查单文件在哪、怎么转 PDF。规则这种东西是要拿出来对着改的，一份能存下来的核查单比一段聊天记录有用。

引擎说明

scripts/rules_ledger.py 是可运行的查询引擎（Python 3.8+，纯标准库，零依赖）：

python scripts/rules_ledger.py --platform xiaohongshu --topic 限流
python scripts/rules_ledger.py --list-platforms
python scripts/rules_ledger.py --check

代码内调用：

from rules_ledger import preflight, lookup, build_report, to_report, to_html_report
ok, err = preflight({"platform": "xiaohongshu", "topics": ["限流"]})
result = build_report({"platform": "xiaohongshu", "topics": ["限流", "等级权益"]})
print(to_report(result))
to_html_report(result)

输入结构化参数即返回 JSON，便于封装为按次调用的服务（per_call）。平台数据存放在 references/ 下的六份台账文件里，按平台代号索引，新增平台只需加一份同结构文件，引擎无需改动。

数据更新与版本节奏

平台规则是活的，这份台账的价值取决于它跟得上变化。台账里每份文件头部都带 data_as_of 字段标注数据截止日期。发新版本时：

1. 更新对应平台的台账文件，并把该次变更补进第五节的变更台账
2. 提升 data_as_of 与技能版本号
3. 在版本说明里写明本次更新了哪个平台、改了哪几条

查询时若发现用户问到的事晚于 data_as_of，必须在结论里明确提示“这项可能已有更新，建议以平台官方最新公告为准”，不得默认台账一定是最新的。

红线提醒

• 本台账是公开信息的整理与结构化，不是平台官方发布，不构成平台官方解释
• 平台规则随时调整，任何结论都必须带上数据截止日期，并提示以官方最新公告为准
• 不提供规避审核、绕过限流、刷量养号、多账号规避处罚的具体手法
• 不承诺“照做一定能上热门”，只回答规则怎么规定的、哪条可能踩到了
• 涉及账号已被封禁、收益被冻结等既成处罚时，如实说明台账能做什么、不能做什么，建议走平台官方申诉通道

用户说出平台和问题即可，我给出对应的规则对照，并生成一份可保存的核查单。