Civitai 的 Blue Buzz 付费访问方案：让不可提现的积分进入早期访问购买

Civitai 的 Blue Buzz 付费访问方案让不可提现的积分进入早期访问购买【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai本篇技术指南围绕 blue-buzz-paid-access-plan.md 这份方案文档展开它要解决的核心问题是——如何让创作者选择性接受 Blue Buzz生成积分不可提现来购买模型的早期访问early access权限同时堵住免费积分兑换可提现资金的资金漏洞。读完本文你将掌握 Buzz 多币种账本模型的配置语义、单币种购买的设计约束、PaidAccess.terms开关的存储取舍以及从方案到earlyAccessPurchase源码落地的完整对照。需要说明该文档自身标注为proposal, nothing implemented是一份方案稿而当前仓库中方案描述的绝大部分改动已经实现源码中可见acceptsBlueBuzz(terms)校验、toAccountType: buzzType的同币结算与蓝色购买专项测试。下文先完整继承方案的设计论证再用仓库源码印证每一处落地情况。定位一个价格多一种可接受的币种方案的第一原则来自产品侧的原始要求文档原文引述Blue and yellow prices would be the same number. Really, were asking if the creator is open to receiving generation credit (blue buzz). They should still be able to accept green/yellow as they normally would.因此这不是双轨定价也不是替代而是一个价格 一个额外可接受币种Green/Yellow 的行为完全不动Blue 是增量且可选opt-in。这个增量的边界由币种配置表硬性决定。在 src/shared/constants/buzz.constants.ts 中buzzTypeConfig为每种消耗型币种定义了bankable可提现/入银行与purchasable可用真金购买两个 UX 标志const buzzTypeConfig: RecordBuzzAccountType, BuzzTypeConfig { blue: { type: spend, value: clientToApiAccountType.blue }, green: { type: spend, value: clientToApiAccountType.green, bankable: true, purchasable: true }, yellow: { type: spend, value: clientToApiAccountType.yellow, nsfw: true, bankable: true, purchasable: true, }, // red / creatorProgramBank / cashPending / cashSettled / club ... };Blue 是唯一一个既没有bankable也没有purchasable的消耗型币种——它只能靠奖励/发放获得方案文档指出奖励路径base.reward.ts默认铸造 blue且 Stripe 购买也会附带赠送。由此推出创作者实际在做的交易选择以不可提现的生成积分收款。方案强调 UI 必须把这个事实说清楚not withdrawable否则会产生大量客服工单。从源码结构看仓库还据此派生了几个关键集合与类型buzz.constants.tsbuzzBankTypes只保留bankable: true的币种即green与yellow并生成buzzBankTypesSql用于 ClickHouse 账单查询的IN (...)子句PurchasableBuzzType类型层面就写死为ExtractBuzzSpendType, green | yellow注释明确Notably excludesblue, which is freederiveDomainBuzzType(domain)domain green ? green : yellow服务端据此重新推导真金购买应入账的币种防止被篡改的客户端自行选色。这些派生逻辑意味着即使 Blue 进入购买流程所有银行/收入侧的口径在数据结构上就已天然把它排除在外——这正是方案blue 是增量而非替代的代码保障。关键风险点目的地账户的默认值方案全文的题眼是buzz.service.ts中的默认目的地逻辑方案引用的是当时快照input.toAccountType input.toAccountType ?? yellow; // Default to bank if not provided危险在于目的地与买家花的什么颜色无关默认落到 yellow可提现。如果照搬这条默认值把 blue 接进付费访问就等于造出一台免费积分 → 现金的转换器——从奖励里刷 blue花在合作创作者的版本上创作者再提现 yellow。方案指出自购虽有拦截但双账户即可绕过。结论买家付 blue创作者就收 blue。toAccountType是每次调用可显式指定的参数??只负责兜底因此修复只是一个参数而非服务重构。在当前仓库中这条链路已经演进为更严格的形态。multi-account 交易入口 现在的守卫是if (input.toAccountId ! 0 !input.toAccountType) throw throwBadRequestError( toAccountType is required when paying account ${input.toAccountId}; only the bank (account 0) may omit it ); const data await buzzService.createMultiTransaction( { ...input, toAccountType: input.toAccountType ?? BANK_LEDGER_ACCOUNT_TYPE }, opts );也就是说向某个用户账户非银行账本 0打款时必须显式声明toAccountType未声明的兜底目的地是银行账本而非任何消耗型币种——方案所警惕的隐式换色在默认值层面被进一步收紧了。现状盘点哪些能力已经就位方案文档给出了一张已有能力清单逐项对应到仓库组件方案所述状态当前仓库印证按指定币种扣款earlyAccessPurchase已传fromAccountTypes: [buzzType]已实现见下文 购买实现按调用指定目的地createMultiAccountBuzzTransaction接受toAccountType已实现且有必填守卫客户端币种 UIBuzzTransactionButton接受accountTypes并渲染分配方案所述组件行为拉取余额、计算分配Creator Program 排除收益查询过滤toAccountType IN (yellow,green)blue 天然被排除当前由buzzBankTypes/buzzBankTypesSql从bankable: true派生口径一致方案还指出当时的阻断点是一行显式守卫model-version.service.tsif (buzzType blue) throw throwBadRequestError(You cannot use Blue Buzz for early access purchases.);当时它是双保险控制器传入的getAllowedAccountTypes(ctx.features)[0]按域名只能解析出 green 或 yellowblue 根本不会出现在购买选项里。当前源码中这一硬编码禁令已被替换为基于条款的动态校验——earlyAccessPurchase内改为model-version.service.tsif (buzzType blue !acceptsBlueBuzz(terms)) { throw throwBadRequestError(This model version does not accept Blue Buzz.); }即 blue 不再被全局禁止而是逐版本取决于PaidAccess.terms是否开启acceptsBlueBuzz——这正是方案Work第 2 条服务端必须对照条款重新校验永不信任客户端选择的落地。已定案买家选且只选一种币种产品侧拍板文档原文users can select to pay with blue or green on civitai.com, and blue or yellow on civitai.red.因此选择空间是blue 或 域名币种——不混合、不回退。仓库中与之一致的域名驱动规则是deriveDomainBuzzTypebuzz.constants.ts域名买家用什么付civitai.comgreen 域名blue或greencivitai.redred 域名blue或yellow这从构造上堵死了漏洞一种源币种进、同一种币种出toAccountType等于fromAccountTypes[0]、一笔交易无拆分支付、无部分转换。方案特别记录了两个显而易见的实现会踩进的坑值得逐条保留不要在扣款路径上复用getAllowedAccountTypes。该辅助函数对features加上[blue]会返回[blue, green]这样的数组而消耗是按数组顺序扣的——所有买家会静默地先花光 blue既无 opt-in 也无选择权。它仍然是客户端可以展示什么的正确决策工具但不应出现在扣款参数里。BuzzTransactionButton是分配不是选择。它接收accountTypes、拉取余额并用getBuzzTypeDistribution计算跨币种扣款分配传入[blue,green]它会扣而不是问。所以购买弹窗的正确做法是两种币种各一个按钮、每个按钮只含一个元素的accountTypesPay with Blue Buzz / Pay with Green Buzz原样复用组件已有的单币种余额展示与余额不足处理。每种被接受的币种渲染一个按钮就是整个 UI 改动。开关存哪里PaidAccess.terms方案的存储决策把acceptsBlueBuzz?: boolean放进PaidAccess.terms与download/generation并列。选型理由是读成本terms本来就在earlyAccessPurchase的读取路径上源码印证purchased 流程先getPaidAccess再取termsterms已经通过useModelVersionPermission到达客户端开关在两侧都是免费的若是创作者级列购买路径上需要一次新查询加一份新缓存自价格上限移除后没有任何读取路径会回写termsgatePrices也只读两个 grant无需改动。方案还记录了一条 ai 意见存储按版本per-version但是否愿意接受生成积分这个立场本质是全目录catalog-wide的。按版本存储意味着创作者要给每个 gate 都编辑一遍所以做法是在 Creator Studio 设置里给一个创作者级默认值 批量应用——这恰好是为 批量网格计划 设计的字段形态。存储仍留在 per-version默认值只是 UX 层。当前仓库印证了该形态已落地acceptsBlueBuzz同时出现在 model-version.schema.ts请求/响应 schema、站内表单与 Creator Studio 抽屉的编辑器组件如 ModelVersionUpsertForm.tsx、model-version-submit.ts客户端购买组件 ModelVersionEarlyAccessPurchase.tsx 也依据该开关决定是否提供 blue 选项。工作分解从方案到落地方案列出的六项工作与当前源码逐条对照条款 写入路径acceptsBlueBuzz进入ModelVersionTermsbuildModelVersionTerms接收该字段站内表单 Creator Studio 抽屉两个编辑器都加勾选框配不可提现的显式文案。——仓库中 schema、两处编辑器组件均已含该字段。购买入参modelVersionEarlyAccessPurchase原输入仅{ modelVersionId, type }增加buzzType服务端对照 terms 重新校验。——当前 earlyAccessPurchase 签名即为{ userId, modelVersionId, type, buzzType: BuzzSpendType }并在 L2349 处做 terms 校验。扣款 入账删除旧守卫买家付 blue 时传toAccountType: blue。——当前实现更进一步统一同币结算const data await createMultiAccountBuzzTransaction({ fromAccountId: userId, toAccountId: modelVersion.model.userId, amount, type: TransactionType.Purchase, fromAccountTypes: [buzzType], // Paid in kind. Naming the buyers own account is what stops the buzz // service applying its yellow default, which had converted every green // purchase into yellow for the seller since green became spendable. toAccountType: buzzType, // ... });源码注释直接呼应了方案的one line that matters显式命名买家自己的账户正是为了阻止服务层默认值把卖家侧换色。退款退回到买家当初消耗的同种账户类型。客户端仅当条款允许时才在弹窗中提供 blue并展示 blue 余额。账务盘点见下一节。账务三处必须核对的口径Creator Program——方案判断已经是对的收益查询过滤toAccountType IN (yellow,green)blue 收入无需额外工作就被排除当前仓库中这一口径由bankable: true派生的buzzBankTypes统一表达结构上同样排除 blue。方案仍建议补一条显式测试防止回归。捐赠目标donation goals——earlyAccessPurchase会向版本绑定的 EA 目标挂一条捐赠记录blue 购买若推进一个创作者当现金看的目标语义上很可能是错的。当前源码已按blue 不计入落地且注释把动机写得很直白model-version.service.ts// A completed goal ends the early-access window early, so a blue purchase must not advance one: // blue is granted by rewards, which would let farmed credit close a paid window for everyone. const ownerGoal buzzType blue ? null : (await getOwnerDonationGoals(ModelVersion, [modelVersionId]))[modelVersionId];因为 blue 可由奖励刷取若允许它推进目标等于让用户用免费积分提前关闭所有人的付费窗口——方案决定 blue 是否计入的开放问题代码选择了不计入。Creator Studio 收益页——必须把 blue 与可提现收入分开展示否则恰恰高报了那些主动 opt-in 的创作者的收入。风险清单与回归测试方案的风险章节值得原样保留漏洞即全部风险。任何blue 进、yellow 出的路径都在把免费积分变成可提现货币。值得一条回归测试断言购买时toAccountType fromAccountType而不是依赖仔细的人工评审。当前仓库已有专门的蓝色购买测试文件 model-version.blue-buzz-purchase.service.test.ts 覆盖该校验路径另有测试端点 blue-buzz-paid-access.ts 供联调验证。创作者预期管理。Accept Blue Buzz在 UI 不说明的情况下会被读成收到钱文案必须前置。Blue 供给充裕。它由奖励发放、且随 Stripe 购买捆绑赠送因此 opt-in 很可能把真实购买量从可提现币种挪到不可提现币种。这是创作者自己的商业判断但收益界面应在 opt-in 前与收款后都让这个蓝/可提现的拆分可见。小结这份方案的工程价值在于把多一种币种这件看似一行配置的事拆解成了一条完整的不变式链条币种配置层bankable/purchasable标志与PurchasableBuzzType类型收窄保证 blue 不混入真金路径服务层toAccountType必填守卫 购买侧toAccountType: buzzType同币结算保证资金不换色条款层PaidAccess.terms.acceptsBlueBuzz 服务端强校验保证 opt-in 语义账务层Creator Program 银行口径、捐赠目标跳过 blue、收益页拆分展示保证报表不失真。从源码看方案提出的六项工作已全部可见落地证据这套单币种进出、同币结算的约束可以作为 Civitai 后续任何新币种接入付费场景时的检查模板。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考