awesome-gpt-image-2 付费社群上线后运维：群码轮换、撤销资格与退款操作怎么做-平芜编程栈

awesome-gpt-image-2 付费社群上线后运维：群码轮换、撤销资格与退款操作怎么做

【免费下载链接】awesome-gpt-image-2Prompt as Code | GPT Image 2 / 2.5 提示词与案例库，530+ 个案例、20+ 套工业级模板与可复用 Skills，新增 2.5 同提示词对比专区，附完整提示词与生成记录，持续更新。项目地址: https://gitcode.com/GitHub_Trending/awe/awesome-gpt-image-2

awesome-gpt-image-2 的付费交流群（/community页面，支付宝一次性支付 ¥9.90）上线后，管理员日常会遇到三件事：微信社群二维码过期需要换新图、需要收回某个用户的长期资格、以及按“微信搜索苍何”人工审核后的原路退款。这三种操作都通过super_admin角色的管理面板完成，后端对应/api/admin/community/*一组接口，状态机定义在 Supabase 迁移脚本中（见 paid-community 迁移与上线手册）。本文按“查订单 → 换群码 → 撤销或退款 → 验证”的顺序，把这三个操作的入口、参数和判断结果讲清楚。

操作前提

必须以super_admin身份登录。前端在 src/community.jsx 中只有profile?.isSuperAdmin为真时才显示“管理后台”按钮，管理区块（CommunityAdminSection）会同时加载订单列表和当前群码。
三个管理接口（群码、退款、撤销）都要求 Same-Origin 请求，跨域直调会返回403 ORIGIN_NOT_ALLOWED；每个接口还有按管理员账号维度的限流（见 qr.js、refund.js），频繁重试会被限流挡下。
群码与退款都依赖订单状态：订单状态取值为PENDING、PAID、CLOSED、REFUNDED、REVOKED，退款处理状态取值为NONE、PROCESSING、SUCCEEDED、FAILED。资格规则是仅PAID有效。

先查订单：确认账号、订单号和当前状态

管理面板的数据来自GET /api/admin/community/orders（见 orders.js）。它返回每笔订单的id、userId、email、fullName、status、amountCents、alipayTradeNo、refundRequestNo、refundStatus、refundFailureCode以及各时间戳，默认按created_at倒序，最多 100 条，可用status查询参数筛选（例如只看PAID）。

在面板里，表格直接展示账号（邮箱 + 订单 ID）、状态、金额、付款时间、退款状态和操作按钮。退款和撤销操作都需要订单 ID，先在这里核对清楚要操作的是哪一笔。

群码轮换：原子替换当前二维码

触发条件是现有群二维码过期或需要更换入口。操作方式：

在管理面板的“替换群二维码”入口选择新图片（对应POST /api/admin/community/qr，请求体为图片原始字节，Content-Type为图片 MIME 类型）。
格式限制：仅 PNG、JPEG、WebP，且不超过 2 MB。超限返回413 COMMUNITY_QR_TOO_LARGE，类型不符返回400（见 qr.js 的前置校验与数据库函数replace_community_group_qr_asset的二次校验）。
服务端通过事务 RPC 原子替换：同一事务内把旧资产is_current置为false并写入retired_at，再插入新资产并标记为当前（迁移脚本），不会同时存在两张当前群码。
成功后响应返回新资产的id、mediaType、sizeBytes、createdAt；面板提示“群二维码已原子替换”。

验证方式：

管理端可请求GET /api/admin/community/qr?metadata=1，返回当前群码的元数据（不含字节），确认id、mediaType、sizeBytes是新上传的那张；面板也会立即刷新展示新图。
已付款用户访问GET /api/community/qr应拿到新图；未付款或资格已失效的账号得到403 COMMUNITY_PAYMENT_REQUIRED。

安全约束（手册明确要求）：不要把受保护群码上传到 GitHub、README、公开对象存储或前端静态目录；群码只存放在 Supabase 的bytea资源里。

撤销资格：收回某账号的群码访问权

适用场景是“不收钱也要把权限收回”，例如违规账号。注意它不会发起退款：

在订单行点击“撤销资格”（POST /api/admin/community/revoke，JSON 体为{ "orderId": "<订单ID>" }，orderId 必须是从订单列表拿到的 UUID）。前端执行前会弹确认框。
后端调用revoke_community_accessRPC（revoke.js）：只有订单当前状态为PAID且refund_status不是PROCESSING时才允许撤销，成功后状态改为REVOKED并写入revoked_at；对已REVOKED的订单重复调用是幂等的，返回REVOKED且transitioned为false。
不满足条件时返回409 COMMUNITY_ORDER_NOT_REVOKABLE——典型情况是退款正在处理中（PROCESSING）。此时应先走退款查询确认退款结束，再决定撤销。

判断结果：响应体为{ ok: true, status: 'REVOKED', transitioned: true }表示本次调用发生了状态迁移。撤销后该账号再请求群码会得到拒绝响应。

退款操作：人工审核后发起并跟踪原路退款

退款由“微信搜索苍何”人工审核，管理员操作前核对账号、订单号和退款状态（手册要求）。流程分三步：

1. 发起退款：对状态为PAID的订单点击“退款”（POST /api/admin/community/refund，JSON 体{ "orderId": "<订单ID>" }，执行前有确认框）。服务端逻辑（refund.js）：

幂等保护：订单已是REFUNDED时直接返回200 { refunded: true, refundStatus: 'SUCCEEDED' }，不会重复退款。
退款使用稳定退款请求号（order.refund_request_no，为空时按订单 ID 生成），并先通过prepare_community_refund把refund_status置为PROCESSING；处理中资格保持PAID有效。
调用支付宝alipay.trade.refund，out_trade_no为订单 ID，refund_reason固定为“付费交流群人工审核退款”。支付宝接受（code为10000）时：
- fund_change为Y：服务端核对trade_no、退款请求号、退款金额与订单金额一致后，写入REFUNDED，响应{ refunded: true, refundStatus: 'SUCCEEDED' }；
- 否则写入PROCESSING，响应{ refunded: false, refundStatus: 'PROCESSING', queryRequired: true }，需要继续查单。
支付宝拒绝时写入FAILED与失败码，响应502 COMMUNITY_REFUND_REQUEST_FAILED，refundStatus为FAILED，refundFailureCode可在订单列表中看到。

2. 查询退款进度：对refund_status为PROCESSING的订单点击“查询退款”（GET /api/admin/community/refund-query?orderId=<订单ID>）。注意两个限制：

退款发起后 10 秒内查询会返回409 COMMUNITY_REFUND_QUERY_TOO_EARLY，并给出retryAfterSeconds，按提示稍后再查即可；
尚未发起过退款（无refund_request_no或状态为NONE）时返回409 COMMUNITY_REFUND_NOT_PREPARED。

查单调用支付宝alipay.trade.fastpay.refund.query（refund-query.js），核对返回的out_trade_no、out_request_no、trade_no、退款金额与订单一致后才落库；核对不通过返回409 COMMUNITY_REFUND_RESULT_MISMATCH。

3. 确认结果：支付宝查询结果为REFUND_SUCCESS时，订单进入REFUNDED（refund_status为SUCCEEDED，写入refunded_at），此后该账号的群码访问失效；仍未完成则维持PROCESSING，稍后再查。

验证与故障处理

退款成功后的最终验证：用该账号访问GET /api/community/qr，应得到403 COMMUNITY_PAYMENT_REQUIRED（手册验收项“退款查询得到 REFUND_SUCCESS 后写入 REFUNDED，随后群码访问失效”）。
撤销后的验证同上：REVOKED状态不在可访问范围内，群码请求被拒。
金额核对是内置的：任何退款结果中的退款金额必须等于订单的amount_cents（固定 990 分，CNY），不一致会抛COMMUNITY_REFUND_RESULT_MISMATCH，这是服务端硬校验，不需要也不应人工改库。
手册的硬性要求：任何关键项失败时立即将COMMUNITY_PAYMENT_ENABLED改回false止血，再排查。

两条容易混淆的边界：