Civitai Creator Shop 设计与实现复用 Cosmetic 体系构建创作者自主商城【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai导读本文围绕 docs/features/creator-shop-proposal.md 展开讲解 Civitai 如何让 Creator Program 成员在自己的资料页Profile上开设Shop标签页、以 Buzz 出售自制 cosmetics徽章、头像装饰、贴纸、资料背景等并引入创作者 70% 分成、提交审核、跨创作者转售与 IP 下架追回等完整闭环。这份提案的核心理念是不新建表——通过向现有Cosmetic/CosmeticShopItem表追加少量可空列、把店铺配置放进User.settingsJSON就复用了官方商城已有的购买、所有权、退款与打款链路。读完本文你将掌握该功能的完整数据模型、70/30 分成源码、审核生命周期、转售与下架的实现机制以及每一项设计决策背后的权衡依据。状态说明提案文档标注为Superseded已被接受并构建当前行为以 docs/features/creator-shop.md 为准70/30 分成已上线computeCreatorShopSplit。本文以提案为主线结合生活文档与源码creator-shop.schema.ts、creator-shop.service.ts、creator-shop.router.ts 等还原从提案到落地的事实。功能概览创作者在自己的资料页里开店Creator Shop 是一个内嵌在真实个人资料外壳左侧边栏 顶部 Tab 导航中的新Shop标签页而不是独立页面。店铺包含Featured / Cosmetics / Merch即将上线/ Models四个区块Cosmetics创作者提交并销售自己的化妆品类道具Merch作为独立商品类型设计Printful/Shopify 实物当前 UI 显示 coming soonModels不是提交的商品而是通过Shop Settings 开关自动聚合创作者已有的 early-access / paid-access 模型Featured在 Shop Settings 中多选上限 6 个、仅已发布项渲染为店铺顶部的醒目横幅条不支持拖拽排序。买家以 Buzz 支付创作者保留 70% 分成审核员在上线前审核提交。围绕它还有一批配套界面提交商品、店铺所有者管理、店铺设置含精选选择器、审核队列、购买弹窗、空店铺/非会员门控以及可复用的 Shop Item Card。所有 mockup 都在 designs/creator-shop.pen 中。锁定设计决策与原始 HackMD 计划不同处决策点结论提交类型仅CosmeticMerchMerch 显示为 coming soon无 Model 提交类型Models 区块非提交项由 Shop Settings 的showModels开关自动并入已有 early/paid-access 模型FeaturedShop Settings 多选上限 6仅已发布渲染为高亮条非拖拽排列区块展示每个区块展示全部商品 分区内筛选/排序如 Cosmetics 按类型筛选、按价格/名称/余量排序无独立 view all 页面数量/可用性复用官方/shop风格显示 X left / Sold out购买时通过count(purchases)强制校验已拥有/售罄状态复用现有CosmeticShop样式Owned 遮罩 售罄禁用 CTA不发明新遮罩数据模型扩展现有 cosmetic-shop 表而不是新建三张表直接复用零 schema 变更现有表在 Creator Shop 中的角色CosmeticShopItemunitAmount、availableFrom/To、availableQuantity、meta可售listing价格 数量/可用性购买时经count(purchases)强制校验CosmeticShopItem.meta.paidToUserIds官方商城的遗留打款路由创作者商品按Cosmetic.createdById付 70% 分成paidToUserIds仅对无创作者cosmetic creator 为 null的遗留官方商品仍按全额均分且平台不抽成见 cosmetic-shop.service.ts由 cosmetic-shop-payout.service.test.ts 锁定UserCosmetic、UserCosmeticShopPurchases所有权、购买记录、退款增量变更全部可空/带默认值官方/shop不受影响提案中给出的 Prisma 方案在落地时得到保留model Cosmetic { // ...existing fields... createdById Int? // NEW — 作者。null 官方/管理员化妆品 creator User? relation(CosmeticCreator, fields: [createdById], references: [id]) } enum CosmeticShopItemStatus { Draft PendingReview Published Rejected Archived } model CosmeticShopItem { // ...existing fields... status CosmeticShopItemStatus default(Published) // NEW — 存量项默认 Published无需回填 reviewedById Int? // NEW reviewedAt DateTime? // NEW rejectionReason String? // NEW // 提交费与最后批准价存放在 metaMVP 无需新列 }店铺设置则追加到User.settingsJSON不建新表// user.settings.creatorShop { // showModels: boolean // 并入 early/paid-access 模型 // featuredItemIds: number[] // 有序应用层强制上限 6 // description?: string // coverImageId?: number // }源码中的实际约束creator-shop.schema.ts与之完全对应export const CREATOR_SHOP_MAX_FEATURED 6; export const updateCreatorShopSettingsSchema z.object({ enabled: z.boolean().optional(), // 店铺公开开关默认关便于私下准备 showModels: z.boolean().optional(), featuredItemIds: z.array(z.number()).max(CREATOR_SHOP_MAX_FEATURED).optional(), description: z.string().max(1000).nullish(), coverImageId: z.number().nullish(), sections: z.array(creatorShopSectionSchema).optional(), // featured/cosmetics/resold/merch/models visible });updateCreatorShopSettings的实现值得注意creator-shop.service.ts它通过patchUserSettings(..., { mergeInto: { creatorShop: patch } })在 Postgres 内对存储列做合并而不是读整块 JSON → JS 里改 → 整块写回——后者会丢掉并发写入的其他 settings 键通知已读、功能开关、内容偏好。启用店铺时还校验addedById下至少存在一个商品避免发布一个空店铺提交后bustUserSettings失效 Redis 缓存因为 settings 缓存此前有 4 小时 TTL不失效会导致一直返回旧 blob。店铺查询逻辑已发布status Published且cosmetic.createdById user的CosmeticShopItem按 cosmetic 的type分组Featured 取自user.settings.creatorShop.featuredItemIdsshowModels为真时并入 Models。为什么不复用CosmeticShopSectionCosmeticShopSection是策展型 CMS 表banner 图、placement、published、由审核员添加。Creator Shop 的区块是派生的——Cosmetics/Merch/Models 只是按商品类型分组、Featured 是选中的集合、Models 是一个开关。若复用该表等于让策展内容表去干派生分组的活并会把userId IS NULL分支塞进官方商城的热路径查询。因此提案决定派生区块、保持CosmeticShopSection不动未来若创作者需要自定义区块可扩展一个可空CosmeticShopSection.userId作为分叉点当前设计不需要。净增量对比HackMD 原计划3 张新表CreatorShopItem、CreatorShop、CreatorShopListing。本提案现有表上 2 处增量列/enumCosmetic.createdById、CosmeticShopItem.status 审核字段User上的 JSON 店铺设置——零新表共享购买/打款路径活动部件更少。70/30 分成单一事实来源computeCreatorShopSplit是分账的唯一来源creator-shop.schema.ts同时驱动打款与提交表单的收益预览保证预览的数字就是实际支付的数字export const CREATOR_SHOP_CREATOR_SHARE 0.7; export const PRICE_REVIEW_THRESHOLD 0.25; export function computeCreatorShopSplit(price: number, sellerShare 0) { const creatorPool Math.floor(price * CREATOR_SHOP_CREATOR_SHARE); const share Math.min(70, Math.max(0, sellerShare)); const sellerAmount Math.floor(price * (share / 100)); const creatorAmount creatorPool - sellerAmount; const platformCut price - creatorPool; return { creatorPool, sellerAmount, creatorAmount, platformCut }; }要点创作者池floor(价格 × 0.7)平台保留剩余部分转售者分成sellerShare0–70为价格的百分比从创作者池里出绝不在其之上叠加路由依据Cosmetic.createdById而非paidToUserIds覆盖场景包括单商品、转售resold、Pack 捆绑包pack 无独立 cosmetic其池为完整 70%computeCreatorShopSplit(price)不带 sellerShare。购买记录cosmetic-shop.service.ts 中的purchaseCosmeticShopItem会在UserCosmeticShopPurchases.meta记录每次销售的payouts: [{ userId, amount, color, transactionId }]与platformCut为下架追回提供依据。分账逻辑由 cosmetic-shop-payout.service.test.ts 等测试锁定包括paidToUserIds遗留路径对无 creator 的官方商品按全额均分、无平台抽成。提交链路从价格下限到不可退的提交费价格下限与 sticker 经济学每种 cosmetic 类型都有类型相关的最低价默认 500 BuzzcosmeticPriceFloorsticker消耗品额外要求每次使用不低于 5 BuzzstickerPerUseFloor、STICKER_MIN_BUZZ_PER_USE且列表价必须覆盖uses × 5默认 uses 100。提交 schemasubmitCreatorShopItemSchema要求 sticker 必须给出uses每次购买授予的使用次数上限 100与pricePerUse补购单次使用的价格并附带quotedFee表单报价服务端校验一致性。服务端 artwork 校验可信来源validateArtwork用sharp服务端解析上传原图按cosmeticImageRequirements(type)生成AutoCheck[]检查项格式PNG 或 WebP尺寸按类型分exact/atLeast/freeform三种约束如 ProfileDecoration 至少 120×120 且要求透明通道ProfileBackground 至少 450×144 不要求透明Sticker 长边 256–512px、宽高比 ≤ 上限、要求透明透明度要求透明背景的类型检查hasAlpha动画限制最多 150 帧、峰值 30fps按帧间隔 33ms 比较重复作品sha256 图像哈希精确匹配阻止已在售的作品重复提交。同时计算感知哈希queueCosmeticPerceptualHash供审核员查询相似图cosmeticSimilarity功能开关控制。全部校验在扣费之前完成——付了不可退的提交费才发现 slug 被占用是最糟糕的体验。不可退的提交费按类型、存数据库提交费是perCosmeticType的外加 pack 单独一个数字存储在KeyValue的creatorShopFees键下形如{ submission: { Badge: 10000, … }, pack: 1000 }。缺失或畸形值逐值回退到 creator-shop.schema.ts 中的编译期默认每类型 10,000pack 1,000因此删除该行不会改变当前定价。费用上限CREATOR_SHOP_FEE_MAX 1_000_000超限一律回退默认防止错行进入资金路径。读取与设置通过/api/admin/creator-shop-feessrc/pages/api/admin/creator-shop-fees.tsGET /api/admin/creator-shop-fees?token$WEBHOOK_TOKEN # 返回 { submission: { CosmeticType: n }, pack: n } PUT /api/admin/creator-shop-fees?token$WEBHOOK_TOKEN # body: { submission?: { Sticker?: 5000, ... }, pack?: 1000 }一次读取同时服务扣费creator-shop.service.ts的getCreatorShopSubmissionFee与提交表单报价creatorShop.getFees→useCreatorShopFees客户端从不镜像常量因为创作者同意的数字与实扣数字是同一笔不可退 Buzz。提交 mutation 携带quotedFee服务端assertQuotedFee在费用已变化时拒绝提交——跨费用变更保持打开的表单不会被静默多收。实扣金额记录在meta.submissionFee此前提交的存量项显示无金额而非显示今天的配置值。提交事务submitCreatorShopItem的流程内容阻止名单检查throwOnBlockedUserContentsurfacecreatorShop→ 权利确认校验 → 类型价格下限 → sticker uses/per-use 下限 → artwork 校验 → 重复作品检查 → slug 校验 →扣提交费Buzz 交易externalTransactionId: creator-shop-submit-userId-ts→ 事务内创建Cosmeticsource: Purchase、createdById: userId与CosmeticShopItemstatus: PendingReview、meta 携带submissionTxId、submissionFee、autoChecks、imageMeta、imageHash、sellableByOthers/sellerShare、acceptsBlueBuzz、rightsAffirmation与首条history记录。若写库失败则原路退回提交费refundTransaction。权利确认Rights Affirmation提交必须勾选权利确认且不是前端复选框那么简单——服务记录meta.rightsAffirmationuserId、affirmedAt、version、statement原文后续下架争议可证明谁在何时同意了什么export const RIGHTS_AFFIRMATION_VERSION 1; export const RIGHTS_AFFIRMATION_STATEMENT I own this artwork, or otherwise hold the rights to sell it, and I accept responsibility for any claim arising from it being sold on Civitai.;措辞变更时 bump version存量记录保留其实际同意的原文。未发布商品更换 artwork 会重新确认并覆盖存储的确认描述的是它据以制作的图审核员替换 artwork不确认也不覆盖创作者记录。审核队列在自动化检查旁展示该确认。审核生命周期与历史日志状态机与 ±25% 价格变更重新审核CosmeticShopItemStatus为Draft / PendingReview / Published / Rejected / Archived默认Published官方存量项零回填。创作者商品从Draft/PendingReview起步公开/创作者查询加status Published过滤官方项天然满足扰动最小。价格编辑触发重新审核以meta.lastApprovedAmount审批时记录见reviewCreatorShopItem的reviewedMeta({ lastApprovedAmount: item.unitAmount })为基准|price - base| / base PRICE_REVIEW_THRESHOLD0.25即 ±25%时status → PendingReview并清空旧裁决rejectionReason/reviewedById/reviewedAt小幅改动保持在线。已发布项非审核员只允许改价格与数量名称/描述/artwork/offsets/slug 均受保护artwork 一旦售出即不可更换。Rejected 是终态的REJECTED_IS_FINAL是所有创作者可达路径编辑、上架、归档、恢复的统一措辞Rejected items are final — a moderator has to reopen it from the review queue first。reviewCreatorShopItem是moderatorProcedure允许审核员对已拒绝项再次裁决——这是错误拒绝的唯一回头路。归档曾可洗白拒绝状态Archived 覆盖 status因此wasLastReviewARejection从历史日志判断最后一次裁决是否为拒绝归档后再恢复会重新进入审核并清空裁决历史是区分二者的唯一途径。审核队列getCreatorShopReviewQueue支持按status默认 PendingReview、username/userId按创作者、cosmeticTypes含Pack伪类型过滤按oldest默认按创建时间升序/newest排序id打破平局避免分页丢行。审核动作reviewCreatorShopItemSchema四选一approve发布并记录lastApprovedAmount幂等授予创作者自己的 cosmeticsticker 授予 10× uses 余额、reject终态、request-changes创作者可编辑并重新提交、revert把已发布项拉回审核队列。每次裁决向创作者发送系统通知approve 按 item 去重其余带时间戳。审核员还可通过getSimilarCosmeticscosmeticSimilarity开关查看感知哈希相似图。审核历史meta.history编辑触发的重新审核会清空rejectionReason/reviewedById/reviewedAt若无日志审核员打开重新入队的商品将无法得知创作者改了什么、上次结论如何。CosmeticShopItemMeta.history就是这份日志——现有 JSON 列上有上限25 条最旧先丢的追加型数组无需迁移{ at, userId, kind: submitted | edited | reviewed | takedown, status?, action?, note?, changes?: [{ field, from?, to? }] }每个写入方都在其已有的cosmeticShopItem.update内追加appendItemHistorycreator-shop.data.ts——记录历史永不产生额外往返。updateCreatorShopItem为每个变更字段记一条changes名称、描述、artwork 携带换图前的data.url、fit offsets、slug、uses、pricePerUse、价格、数量强制重新审核时附上原因 notereviewCreatorShopItem记reviewedaction、审核员、note——这也是 note 能在下次编辑清空rejectionReason后存活的途径takedownCosmeticShopItem记takedown。审核队列已 selectmeta详情面板HistoryCard最新在前换图展示前后缩略图零查询变更即可渲染。跨创作者转售Resale一行即条款、即权限UserCosmeticShopItemResale (userId, shopItemId, sellerShare, index, createdAt)表承载转售关系。创作者标记商品meta.sellableByOthers并给出meta.sellerShare0–70转售者从创作者 70% 池中分得的百分比其他创作者在自己的店铺里按引用单一库存不复制列出该商品。每行 listing 是交易两半的记录它是条款purchaseCosmeticShopItem按listing.sellerShare付给转售者永不读取商品当前值单一主键查找userId_shopItemId无 settings blob。它是权限店铺从转售者的行直接 select Resold 区块读取时不再复查sellableByOthers——已存在的 listing 在创作者关闭转售后依然存活。sellableByOthers仍把关addResoldItem即新建listing。index是店铺顺序reorderResoldItemscreatedAt是上架时间。撤下商品即终结其转售 listing祖父条款grandfathering覆盖条款不覆盖商品的存续。下架/归档/takedown 会执行endResaleListings删除相关行并给每个受影响的创作者发送creator-shop-resale-ended通知——没人会留下无法售卖的卡片也没人持有对已停售商品的份额主张。回来需要重新审核setCreatorShopItemListed({ listed: true })与unarchiveCreatorShopItem都置PendingReview并清空旧裁决。若没有这条规则withdraw → re-list将成为一键清空所有转售者并以更差份额重新上架的诱饵调包通道——这正是该 ticket 要防的事。下架本身不动 status只有回归才动。addResoldItem相应拒绝当前未在售的商品行只可能在商品在售时创建转售选择器仍显示已下架商品打徽标、禁用 Add避免转售者之后还要回头找。两个方向都有索引因此是表而非User.settingsJSON我转售了什么——userId前缀主键getResoldItemsForManage、店铺。谁在转售我的商品——UserCosmeticShopItemResale_shopItemId_idxgetShopItemResellers 管理列表的_count。用旧的settings.creatorShop.resoldItemIds数组回答这个问题意味着扫描每个用户的 JSON。管理视图统计getCreatorShopResaleStats一次聚合覆盖两个方向展示Resellers转售你商品的去重创作者数 涉及商品数与You resell你上架了多少他人商品。安全边界原创作者可随时在编辑弹窗修改sellableByOthers/sellerShare它们与价格、acceptsBlueBuzz一样属于支付条款编辑保持在线、不重新审核但祖父条款使其仅对未来转售者生效关闭转售会把商品sellerShare清零与提交逻辑对称防止重新打开时静默恢复已退役的份额删除 listing 即删行级联重新上架视为对当时条款的新协议sellerShare永不作为 tRPC 输入——addResoldItem从商品上读取reorderResoldItems只写index客户端无法自我授权条款。下架TakedownIP / TOS 的一键撤销creatorShop.takedownItem是仅审核员非 flag 门控覆盖官方商城商品的一次性撤销对应takedownCosmeticShopItem先停售——status → Archived、listed false、meta.takedown { reason, moderatorId, at }、删除官方商城区块关联cosmeticShopSectionItem、释放精选位。被下架商品永远不能恢复上架。退款所有买家——对每条未退款UserCosmeticShopPurchases执行refundMultiAccountTransaction按买家支付的颜色退回翻转refunded true。买家只会被退款绝不会被反向扣款。收回卖家所得——purchaseCosmeticShopItem已把每次销售的打款记录在meta.payouts因此下架按 id 退掉每笔打款交易含转售者分成。无 id 的记录Buzz 服务未返回回退为对收款人按每人每颜色的追回扣款。结果报告owedBack/clawedBack与clawedBackPct。遗留销售打款列存在前的行meta NULL回退为从商品重新推导分成只追回创作者确定收到的那部分可转售商品的转售者份额报告为unrecoveredResellerShare供人工跟进从未记录谁拿走了它。Pack 无单一 creator 可推导整个池记入unrecoveredPackPool并进failures。剥离所有权——对该 cosmetic 的每条UserCosmetic买家、赠礼、创作者自己的审批授予执行revokeCosmeticsFromUsers同时卸载已装备项并刷新实体缓存/搜索索引。Pack 只撤销通过本次购买交易claimKey buzzTransactionId授予的成员。创作者的提交费绝不退还——下架即违反条款。资金操作按买家尽力而为每项重试 3 次间隔 1s后才放弃失败收集到failures阶段 用户 金额而不中断整轮。一切落到 Axiomname: cosmetic-takedown开始记录、每个放弃退款/追回的error携带人工完成所需的 id、带轮次合计的结束记录有失败则 error 级。另有打款撤销路径refundTransaction按原交易 id 退回Buzz 服务关联原单不会重复应用。代码触点与 API 端点提案列出的三个核心触点均已落地新增了 creator-shop 专属模块文件职责src/server/schema/creator-shop.schema.ts全部业务规则分成、价格下限、权利确认、费用、艺术约束、pack 定价与 zod 输入契约src/server/services/creator-shop.service.ts提交/编辑/归档/上架/恢复/删除、店铺读取、社区中心、转售、审核队列、下架、设置src/server/services/creator-shop.data.tsbuildCosmeticData/patchCosmeticData、历史追加上限 25、REJECTED_IS_FINAL、sticker 创作者授予10×src/server/services/creator-shop-fees.service.ts提交费读取/设置KeyValuecreatorShopFees与报价断言src/server/services/creator-shop-pack.service.tsPack 捆绑包2–20 成员、无子 pack、成员含 sticker 时拒绝购买src/server/routers/creator-shop.router.tstRPC 过程编排与权限门控src/server/schema/cosmetic-shop.schema.ts复用/扩展cosmeticShopItemMetafee、lastApprovedAmount、payouts、historytRPC router 中的关键端点与门控创作者侧creatorShopProcedure protectedProcedure.use(isFlagProtected(creatorShop))flag 回退[mod]且 Flipt 可控不部署即可解锁测试者submitItem、updateItem、archiveItem、setItemListed、unarchiveItem、deleteItem仅审核员硬删会级联清掉购买记录与转售行但Cosmetic行保留、买家保留所得、getManageItems、getResaleStats、getPublicShopItems、checkStickerSlug、getResoldItems/addResoldItem/removeResoldItem/reorderResoldItems、getItemResellers、getSettings/updateSettings。公开侧getShoppublicProcedure flag支持审核员preview采样数据、getFees刻意不缓存——表单报价与扣费必须一致、getEarlyAccessPrices早期访问模型下载价、getCommunityCosmetics/shop 社区中心服务端分页reviewedAt作为 Newest 排序依据、id破平局。审核员侧moderatorProceduregetReviewQueue、getReviewQueueCreators、getSimilarCosmeticscosmeticSimilarityflag、reviewItem、takedownItem不 flag 门控官方商品也可下架侵权内容不能等灰度。Sticker 与 Pack 在 mutation 处额外 flag 门控assertStickersEnabled/assertPacksEnabled持有 id 也无法绕过。未决问题与最终裁决提案中的五个开放问题在生活文档中均有落点分账比例——已答复70/30 确认并上线computeCreatorShopSplit为唯一事实来源创作者池floor(price × 0.7)平台保留其余创作者商品按Cosmetic.createdById路由paidToUserIds仅用于遗留官方商品。状态放 listing、作者放 asset——采纳status在CosmeticShopItemlisting作者在Cosmeticasset。Featured 存储——采纳有序数组featuredItemIds顺序有意义、上限 6、保持热表干净而非 listing 上的 flag。Models 开关数据源——落地为getEarlyAccessModelPrices查询早期访问模型PaidAccess关联ModelVersionendsAt NOW()店铺只聚合创作者当前 Early-Access 模型付费 tier 后续支持。Merch 建模——确认作为独立商品Printful/Shopify 实物不塞进Cosmetic店铺/listing 抽象为未来非 cosmetic 商品类型留出空间。已知边界与注意点打款不回滚购买成功后打款转账失败不会回滚购买记录到 Axiom。Buzz 场景可接受Merch 需重新审视pay-on-fulfilment。店铺隐私与拉黑enabled默认关闭非所有者/审核员访问返回 404浏览者与店主任一方拉黑则整店隐藏同样 404不泄露拉黑关系社区中心与转售画廊均过滤拉黑对。迁移手动应用相关 SQL migration如20260805120000_add_cosmetic_shop_item_resale、20260803220000_add_cosmetic_purchase_payout_meta提交供审核并手动应用——本项目不运行prisma migrate deploy转售 blob 迁移还需执行pnpm tsscript scripts/oneoffs/backfill-cosmetic-resale-listings.ts。界面清单mockupsdesigns/creator-shop.pen界面用途Shop Item Card组件可复用卡片cosmetic / merch / model 通过 overrides 渲染New / Owned / Sold-out / 余量状态Storefront资料页 Shop 标签Featured 条 Cosmetics / Merchsoon/ Models 分区 分区内筛选Owner — Manage Your Shop列表表格状态 审核拒绝原因 重新提交Shop Settings弹窗分区顺序、Models 开关、进入精选选择器Feature Picker弹窗选择要精选的 cosmetics上限 6、仅已发布、待审置灰Moderator — Review Queue双栏预览、价格/费用、自动化检查、关注标记、通过/拒绝Purchase ModalBuy-with-Buzz 购买流程Submit ItemCosmetic Merchsoon费用与收益预览Owner Empty / Non-member Gate首次运行与 Creator Program CTA 状态从 docs/features/creator-shop-proposal.md 到 docs/features/creator-shop.md再到src/server/下成体系的 service/router/schema 与十余个针对性测试提交费、下架、转售条款、权利确认、审核队列、历史、删除、pack、sticker 等Civitai Creator Shop 展示了复用存量商城体系 增量列 JSON 配置如何以最小 footprint 撑起一个含审核、分账、转售与下架的完整创作者经济闭环。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考