Civitai 生成面板 Licensing Fee 显示方案多资源费用拆解、资源卡片设计与 ControlNet 计费缺陷排查【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai本篇技术指南基于仓库 docs/generation-panel-licensing-fee-display.md2026-07-22 由 Justin 与 Briant 在生成器 walkthrough 中产出的检查清单展开聚焦 Civitai 生成器civitai.com/generate中许可费用licensing fee的展示链路费用明细弹层的多资源拆解、模型/资源选择卡片上的费用呈现设计以及一个已上线的 ControlNet 相关计费缺陷。读完本文你将掌握该功能的现状实现以GenerationCostPopover与whatIf定价数据为核心、待办设计决策的完整脉络以及底层父级/继承费用模型对前端展示的约束。一、背景生成成本明细已经显示许可费用但展示正在走向多资源时代生成器页面底部的成本明细Generation Cost Breakdown当前已经支持展示每个资源的许可费用及它对应的是哪个模型且已上线。在 GenerationCostPopover.tsx 中可以看到这条链路的现有形态fixedFees与licensingFees被分别统计其中许可费用是对workflowCost.fees字典做聚合求和const licensingFees Object.values(workflowCost.fees ?? {}).reduce((sum, fee) sum fee, 0);当licensingFees 0时明细中出现一行 Licensing Fees行尾带一个 info 图标点击后打开一个Licensing Fees弹层modal弹层内容由LicensingFeeDetail组件渲染见 GenerationCostPopover.tsx。组件内的注释清楚地说明了whatIf定价数据的形状见 GenerationCostPopover.tsxPer-resource licensing fee breakdown. The whatIffeesdict is keyed by resource AIR with the total charged for that resource across the whole request; we parse each to its version id, batch-fetch the resources for their model/version name, and show the per-image cost (charged ÷ quantity, so the rows stay consistent with the aggregate).即whatIf返回的fees是一个以资源 AIR一种资源标识符为 key、以该资源在整次请求中的总收费为 value的字典。LicensingFeeDetail将其解析为版本 ID批量拉取资源元数据然后展示每张图per-image的费用总额 ÷ 数量从而与明细中的聚合数字保持一致解析不到资源的行则回退显示原始 AIR见 GenerationCostPopover.tsx。现状到未来的关键转折点以往一次生成通常只涉及单个收费资源展示一个总数足够而未来一次生成将普遍包含多个各自携带许可费用的资源例如同时使用多个 LoRA、或 Checkpoint LoRA ControlNet 的组合。因此明细breakdown的信息弹层info popover必须逐一列出每一个资源的许可费用而不能只显示一个合并后的数字。对应 walkthrough 记录T:979–1026这正是本文档的核心 todo 项也是后续各节设计决策的出发点。二、已发现缺陷添加 ControlNet 后许可费用从明细中消失在 walkthrough 演示过程中暴露了一个真实缺陷检查清单首项标签[bug]选择Anima并挂上ControlNet时明细breakdown中没有显示任何许可费用一旦移除 ControlNet费用又重新出现。该现象对应记录T:986–1009。需要调查的疑点被明确为添加 ControlNet或类似的辅助资源是否会导致许可费用从返回的定价数据中被剔除——也就是要核对 Anima ControlNet 组合下whatIf返回的定价数据里到底有没有费用字段。两条可能的根因路径也是检查清单开放问题 1数据层缺失服务端在组合了 ControlNet 后真的没有把许可费用写进返回的定价数据纯展示问题数据存在但前端明细渲染逻辑遗漏了该费用行。排查时应对照whatIf定价数据的原始返回逐项核对T:1003–1009要求Verify against the returned data而不是只凭 UI 判断。这条经验也适用于任何UI 看不到费用的汇报先确认数据是否到达再谈渲染。三、资源卡片上的许可费用展示设计决策全记录Briant 曾把许可费用加到生成表单的模型/资源选择器resource picker卡片上随后因为父级费用与子级费用混淆的问题又移除了它们。Justin 仍然希望费用在卡片上可见——人们一定会问这个。该节对应记录T:1018–1096检查清单为每个子问题都打了[design]标签要求在动工前先出 mockup。3.1 先出 Mockup再动手第一项设计任务T:1097–1110是让 Claude 先产出几版许可费用如何呈现在资源卡片上的 mockup供评审选择然后再进入实现。设计先行是为了避免再次出现上了线又因展示语义问题回滚的情况。3.2 卡片上只显示资源自己的费用展示在卡片上的费用必须是该资源自身收取的费用而不是与继承费用混在一起的合并总额T:1027–1058。举例说明其动机一个子模型如 Mio Mio Hara checkpoint自身收费 1如果被显示成它继承了 Anima 基础费用5看起来就像它贪心地收了 6。因此卡片上的费用 资源自己定价的费用不要因为显示合并总额而让子模型背上不属于它的费用印象。3.3 继承 / 基础ecosystem费用必须单独显示生态级或继承来的基础费用base fee应当与资源自身费用分开、明确地展示T:1059–1091。讨论中曾提出一个候选方案把基础费用放在**生态选择器ecosystem selector**上。该方案被否决理由有二Turbo 成本场景下会失效base fee 挂到 ecosystem selector 上无法表达 Turbo 的计费与计划中的层级式/继承式授权模型hierarchical/inheritance licensing model不契合——即微调之微调继承基础费用的场景。因此 ecosystem selector 不是基础费用的正确归宿需要另寻展示位。3.4 布局使用版本名下的第三行卡片上标题/版本名所在的两行从未发生溢出因此有空间容纳第三行T:1119–1135这正是许可费用可以落地的位置。3.5 视觉形态小的彩色文本而不是 Badge费用用带标签的小号彩色文本呈现比 badge 更紧凑标签例如base fee基础费用additional resource fee附加资源费用即使卡片内容变多也要保持卡片紧凑T:1143–1155。3.6 V1 规则最多两级父 子当前展示层级最多为两级T:1100–1155一个父级base许可费用一个子级资源自身费用。更深的继承链微调之微调、多层嵌套是真实存在的未来场景但现在属于极端边缘情况。V1 的处理规则是展平将更深的链折叠成单一的 base fee如有需要允许小数。四、多资源费用的弹层展示todo与资源卡片的设计并列检查清单为明细信息弹层单列了一个[todo]项T:1010–1026当一次生成包含多个携带许可费用的资源时明细的 info popover 必须逐个列出每个费用并标明其对应模型而不是只显示一个合并数字。从现有实现看LicensingFeeDetail已经具备逐资源解析与展示的基础按 AIR 解析版本、批量拉取模型/版本名、按 quantity 折算每图费用缺的正是与多资源语义对齐的完整列表形态——即把仅当licensingFees 0时显示一行聚合数字升级为每个资源一行。这也是 GenerationCostPopover.tsx 中reduce求和逻辑在演进过程中需要保留聚合行、同时新增明细行的原因。五、底层支撑父子费用模型与 fees[] 的向前兼容设计前文base fee 与资源自身费用分开显示并非孤立的 UI 决定它直接对应仓库中的费用模型设计。相关设计记录见 docs/creator-studio/licensing-lineage-parent-fee.md要点如下5.1 两种费用概念一次图像生成中每个资源可能产生Own fee自身费用——资源自己的定价如 LoRA 0.1、checkpoint 1、Anima 5Parent / ecosystem fee父级 / 生态费用——向上游基础模型base支付的费用。一次生成的总费用 所用各资源的费用之和货币不参与换算currencies never convert。5.2 V1 规则只有 Checkpoint 有父级费用只有 checkpoint / 扩散模型携带父级费用。LoRA以及 embedding、VAE 等只承担自身费用——它作为运行在 checkpoint 之上的 adaptercheckpoint 已经在向生态付费因此 LoRA 不再重复向生态付费版本类型父级血统父级费用发出的费用Checkpoint / diffusion其 ecosystem / base是own parent≤2LoRA — v1无否仅 own≤1LoRA — future另一个 LoRA可能own 沿祖先链遍历5.3 血统类型一致性一个版本的父级永远是同一种类型绝不跨类型LoRA 的父级绝不可能是 checkpoint如果 LoRA 有父级一定是 LoRA-of-a-LoRAcheckpoint 的父级是它的 ecosystem/base。5.4 fees[] 形状已经向前兼容fees[]数组的每个条目都携带自己的recipientUserId因此数组可以从 own 一个 parent 增长到 own N 个遍历祖先而无需改动 orchestrator遍历 fees[] 求和或收益读取侧的任何契约。当未来的 LoRA lineage 落地时费用发射端只需遍历 LoRA 的父链、为每个祖先 push 一个条目放开类型门控gate只是一个放宽 遍历的操作而不是重新设计。这条设计直接支撑了前文资源卡片最多两级、更深链展平为 base fee的 V1 决策数据契约已为多层留好余地前端 V1 先用父 子两级表达。5.5 费用继承的校验与回归测试费用继承通过licensingSourceVersionId字段实现——它让一个衍生版本继承某个 root 的按图许可费用每个使用该衍生版生成的人都会被收费费用结算给 root 的所有者。由于该字段来自表单会经过网络传输它必须在服务端被校验而非被信任。对应实现与测试见 model-version.schema.ts 与 model-version.controller.licensing-lineage.test.ts。schema 中与该功能直接相关的字段为licensingFee: z.number().min(0).max(maxLicensingFeeCeiling(video)).multipleOf(0.01).nullish(), licensingFeeType: z.enum(LicensingFeeType).nullish(), licensingFeeSettlementCurrency: z.enum(LicensingFeeSettlementCurrency).nullish(), // Inherit another versions licensing fee (a LicensingRoot for this baseModel). licensingSourceVersionId: z.number().nullish(),值得注意的历史教训见测试文件头部注释每一行LicensingRoot都是modelType: Checkpoint但早期守卫检查的是base model 而不是 model type导致一个 LoRA 能持有 checkpoint 的费用——对应的用户事件为CU 868kwf2fd / Freshdesk #69622报告者在一个月里每图多付 10 Buzz应为 5且站点上没有任何界面能清除它。这正是 model-version.controller.licensing-lineage.test.ts 以modelType而非baseModel做门控校验、并专门构造payload 的模型与被编辑版本实际所属模型是不同行这类用例的原因。对前端展示而言这提醒我们父级费用只能从被确认为 Checkpoint 的 root 继承展示层也应遵循只有 checkpoint 有 base fee的规则。此外civitai/buzz包承担了共享的许可费用模块licensing-fee module并在model-version.schema.ts中被 re-export 给既有 importer见 model-version.schema.ts说明费用常量与规则是跨 app 共享的。六、开放问题动工前必须敲定的三件事检查清单在收尾处列出三个开放问题要求在构建过程中/构建前解决ControlNet 定价缺陷T:1003–1009许可费用到底是被 ControlNet 加入后从返回的定价数据中真实剔除了还是仅展示层的问题必须对照返回的数据验证。Mockup 评审T:1097–1155资源卡片费用展示的 mockup 里最终上线哪一版base child 两级费用、小号彩色文本、版本名下方第三行。层级授权模型确认T:1069–1155parent→child 继承类比 HuggingFace 的 fine-tune lineage目前是暂定/未来方向。需要确认 V1 展平规则仅 parent child更深的链展平进 base fee可以被接受。七、总结与落地路径围绕 docs/generation-panel-licensing-fee-display.md 这份检查清单可以整理出清晰的落地路径先修缺陷核对 Anima ControlNet 的whatIf定价返回数据确定费用是被剔除还是渲染遗漏GenerationCostPopover.tsx 是排查渲染侧的第一现场。再出设计产出资源卡片费用展示的 mockup遵循只显示资源自身费用 base fee 分开显示 版本名下方第三行 小号彩色文本四条约束且 V1 最多两级。最后建设把LicensingFeeDetail从聚合一行升级为逐资源列出完成多资源费用的弹层展示并守住只有 checkpoint 携带 parent fee的模型规则docs/creator-studio/licensing-lineage-parent-fee.md。关联的扩展阅读还包括licensing-fee-owner-stamping.md收益读取侧、licensing-fee-revamp-checklist.md费用体系改造清单与 monetization-rules.md变现规则总览。展示层的每一次改动最终都要落回费用归属清晰、父子不混淆、每图费用可核算这三条产品原则。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Civitai 生成面板 Licensing Fee 显示方案：多资源费用拆解、资源卡片设计与 ControlNet 计费缺陷排查
Civitai 生成面板 Licensing Fee 显示方案多资源费用拆解、资源卡片设计与 ControlNet 计费缺陷排查【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai本篇技术指南基于仓库 docs/generation-panel-licensing-fee-display.md2026-07-22 由 Justin 与 Briant 在生成器 walkthrough 中产出的检查清单展开聚焦 Civitai 生成器civitai.com/generate中许可费用licensing fee的展示链路费用明细弹层的多资源拆解、模型/资源选择卡片上的费用呈现设计以及一个已上线的 ControlNet 相关计费缺陷。读完本文你将掌握该功能的现状实现以GenerationCostPopover与whatIf定价数据为核心、待办设计决策的完整脉络以及底层父级/继承费用模型对前端展示的约束。一、背景生成成本明细已经显示许可费用但展示正在走向多资源时代生成器页面底部的成本明细Generation Cost Breakdown当前已经支持展示每个资源的许可费用及它对应的是哪个模型且已上线。在 GenerationCostPopover.tsx 中可以看到这条链路的现有形态fixedFees与licensingFees被分别统计其中许可费用是对workflowCost.fees字典做聚合求和const licensingFees Object.values(workflowCost.fees ?? {}).reduce((sum, fee) sum fee, 0);当licensingFees 0时明细中出现一行 Licensing Fees行尾带一个 info 图标点击后打开一个Licensing Fees弹层modal弹层内容由LicensingFeeDetail组件渲染见 GenerationCostPopover.tsx。组件内的注释清楚地说明了whatIf定价数据的形状见 GenerationCostPopover.tsxPer-resource licensing fee breakdown. The whatIffeesdict is keyed by resource AIR with the total charged for that resource across the whole request; we parse each to its version id, batch-fetch the resources for their model/version name, and show the per-image cost (charged ÷ quantity, so the rows stay consistent with the aggregate).即whatIf返回的fees是一个以资源 AIR一种资源标识符为 key、以该资源在整次请求中的总收费为 value的字典。LicensingFeeDetail将其解析为版本 ID批量拉取资源元数据然后展示每张图per-image的费用总额 ÷ 数量从而与明细中的聚合数字保持一致解析不到资源的行则回退显示原始 AIR见 GenerationCostPopover.tsx。现状到未来的关键转折点以往一次生成通常只涉及单个收费资源展示一个总数足够而未来一次生成将普遍包含多个各自携带许可费用的资源例如同时使用多个 LoRA、或 Checkpoint LoRA ControlNet 的组合。因此明细breakdown的信息弹层info popover必须逐一列出每一个资源的许可费用而不能只显示一个合并后的数字。对应 walkthrough 记录T:979–1026这正是本文档的核心 todo 项也是后续各节设计决策的出发点。二、已发现缺陷添加 ControlNet 后许可费用从明细中消失在 walkthrough 演示过程中暴露了一个真实缺陷检查清单首项标签[bug]选择Anima并挂上ControlNet时明细breakdown中没有显示任何许可费用一旦移除 ControlNet费用又重新出现。该现象对应记录T:986–1009。需要调查的疑点被明确为添加 ControlNet或类似的辅助资源是否会导致许可费用从返回的定价数据中被剔除——也就是要核对 Anima ControlNet 组合下whatIf返回的定价数据里到底有没有费用字段。两条可能的根因路径也是检查清单开放问题 1数据层缺失服务端在组合了 ControlNet 后真的没有把许可费用写进返回的定价数据纯展示问题数据存在但前端明细渲染逻辑遗漏了该费用行。排查时应对照whatIf定价数据的原始返回逐项核对T:1003–1009要求Verify against the returned data而不是只凭 UI 判断。这条经验也适用于任何UI 看不到费用的汇报先确认数据是否到达再谈渲染。三、资源卡片上的许可费用展示设计决策全记录Briant 曾把许可费用加到生成表单的模型/资源选择器resource picker卡片上随后因为父级费用与子级费用混淆的问题又移除了它们。Justin 仍然希望费用在卡片上可见——人们一定会问这个。该节对应记录T:1018–1096检查清单为每个子问题都打了[design]标签要求在动工前先出 mockup。3.1 先出 Mockup再动手第一项设计任务T:1097–1110是让 Claude 先产出几版许可费用如何呈现在资源卡片上的 mockup供评审选择然后再进入实现。设计先行是为了避免再次出现上了线又因展示语义问题回滚的情况。3.2 卡片上只显示资源自己的费用展示在卡片上的费用必须是该资源自身收取的费用而不是与继承费用混在一起的合并总额T:1027–1058。举例说明其动机一个子模型如 Mio Mio Hara checkpoint自身收费 1如果被显示成它继承了 Anima 基础费用5看起来就像它贪心地收了 6。因此卡片上的费用 资源自己定价的费用不要因为显示合并总额而让子模型背上不属于它的费用印象。3.3 继承 / 基础ecosystem费用必须单独显示生态级或继承来的基础费用base fee应当与资源自身费用分开、明确地展示T:1059–1091。讨论中曾提出一个候选方案把基础费用放在**生态选择器ecosystem selector**上。该方案被否决理由有二Turbo 成本场景下会失效base fee 挂到 ecosystem selector 上无法表达 Turbo 的计费与计划中的层级式/继承式授权模型hierarchical/inheritance licensing model不契合——即微调之微调继承基础费用的场景。因此 ecosystem selector 不是基础费用的正确归宿需要另寻展示位。3.4 布局使用版本名下的第三行卡片上标题/版本名所在的两行从未发生溢出因此有空间容纳第三行T:1119–1135这正是许可费用可以落地的位置。3.5 视觉形态小的彩色文本而不是 Badge费用用带标签的小号彩色文本呈现比 badge 更紧凑标签例如base fee基础费用additional resource fee附加资源费用即使卡片内容变多也要保持卡片紧凑T:1143–1155。3.6 V1 规则最多两级父 子当前展示层级最多为两级T:1100–1155一个父级base许可费用一个子级资源自身费用。更深的继承链微调之微调、多层嵌套是真实存在的未来场景但现在属于极端边缘情况。V1 的处理规则是展平将更深的链折叠成单一的 base fee如有需要允许小数。四、多资源费用的弹层展示todo与资源卡片的设计并列检查清单为明细信息弹层单列了一个[todo]项T:1010–1026当一次生成包含多个携带许可费用的资源时明细的 info popover 必须逐个列出每个费用并标明其对应模型而不是只显示一个合并数字。从现有实现看LicensingFeeDetail已经具备逐资源解析与展示的基础按 AIR 解析版本、批量拉取模型/版本名、按 quantity 折算每图费用缺的正是与多资源语义对齐的完整列表形态——即把仅当licensingFees 0时显示一行聚合数字升级为每个资源一行。这也是 GenerationCostPopover.tsx 中reduce求和逻辑在演进过程中需要保留聚合行、同时新增明细行的原因。五、底层支撑父子费用模型与 fees[] 的向前兼容设计前文base fee 与资源自身费用分开显示并非孤立的 UI 决定它直接对应仓库中的费用模型设计。相关设计记录见 docs/creator-studio/licensing-lineage-parent-fee.md要点如下5.1 两种费用概念一次图像生成中每个资源可能产生Own fee自身费用——资源自己的定价如 LoRA 0.1、checkpoint 1、Anima 5Parent / ecosystem fee父级 / 生态费用——向上游基础模型base支付的费用。一次生成的总费用 所用各资源的费用之和货币不参与换算currencies never convert。5.2 V1 规则只有 Checkpoint 有父级费用只有 checkpoint / 扩散模型携带父级费用。LoRA以及 embedding、VAE 等只承担自身费用——它作为运行在 checkpoint 之上的 adaptercheckpoint 已经在向生态付费因此 LoRA 不再重复向生态付费版本类型父级血统父级费用发出的费用Checkpoint / diffusion其 ecosystem / base是own parent≤2LoRA — v1无否仅 own≤1LoRA — future另一个 LoRA可能own 沿祖先链遍历5.3 血统类型一致性一个版本的父级永远是同一种类型绝不跨类型LoRA 的父级绝不可能是 checkpoint如果 LoRA 有父级一定是 LoRA-of-a-LoRAcheckpoint 的父级是它的 ecosystem/base。5.4 fees[] 形状已经向前兼容fees[]数组的每个条目都携带自己的recipientUserId因此数组可以从 own 一个 parent 增长到 own N 个遍历祖先而无需改动 orchestrator遍历 fees[] 求和或收益读取侧的任何契约。当未来的 LoRA lineage 落地时费用发射端只需遍历 LoRA 的父链、为每个祖先 push 一个条目放开类型门控gate只是一个放宽 遍历的操作而不是重新设计。这条设计直接支撑了前文资源卡片最多两级、更深链展平为 base fee的 V1 决策数据契约已为多层留好余地前端 V1 先用父 子两级表达。5.5 费用继承的校验与回归测试费用继承通过licensingSourceVersionId字段实现——它让一个衍生版本继承某个 root 的按图许可费用每个使用该衍生版生成的人都会被收费费用结算给 root 的所有者。由于该字段来自表单会经过网络传输它必须在服务端被校验而非被信任。对应实现与测试见 model-version.schema.ts 与 model-version.controller.licensing-lineage.test.ts。schema 中与该功能直接相关的字段为licensingFee: z.number().min(0).max(maxLicensingFeeCeiling(video)).multipleOf(0.01).nullish(), licensingFeeType: z.enum(LicensingFeeType).nullish(), licensingFeeSettlementCurrency: z.enum(LicensingFeeSettlementCurrency).nullish(), // Inherit another versions licensing fee (a LicensingRoot for this baseModel). licensingSourceVersionId: z.number().nullish(),值得注意的历史教训见测试文件头部注释每一行LicensingRoot都是modelType: Checkpoint但早期守卫检查的是base model 而不是 model type导致一个 LoRA 能持有 checkpoint 的费用——对应的用户事件为CU 868kwf2fd / Freshdesk #69622报告者在一个月里每图多付 10 Buzz应为 5且站点上没有任何界面能清除它。这正是 model-version.controller.licensing-lineage.test.ts 以modelType而非baseModel做门控校验、并专门构造payload 的模型与被编辑版本实际所属模型是不同行这类用例的原因。对前端展示而言这提醒我们父级费用只能从被确认为 Checkpoint 的 root 继承展示层也应遵循只有 checkpoint 有 base fee的规则。此外civitai/buzz包承担了共享的许可费用模块licensing-fee module并在model-version.schema.ts中被 re-export 给既有 importer见 model-version.schema.ts说明费用常量与规则是跨 app 共享的。六、开放问题动工前必须敲定的三件事检查清单在收尾处列出三个开放问题要求在构建过程中/构建前解决ControlNet 定价缺陷T:1003–1009许可费用到底是被 ControlNet 加入后从返回的定价数据中真实剔除了还是仅展示层的问题必须对照返回的数据验证。Mockup 评审T:1097–1155资源卡片费用展示的 mockup 里最终上线哪一版base child 两级费用、小号彩色文本、版本名下方第三行。层级授权模型确认T:1069–1155parent→child 继承类比 HuggingFace 的 fine-tune lineage目前是暂定/未来方向。需要确认 V1 展平规则仅 parent child更深的链展平进 base fee可以被接受。七、总结与落地路径围绕 docs/generation-panel-licensing-fee-display.md 这份检查清单可以整理出清晰的落地路径先修缺陷核对 Anima ControlNet 的whatIf定价返回数据确定费用是被剔除还是渲染遗漏GenerationCostPopover.tsx 是排查渲染侧的第一现场。再出设计产出资源卡片费用展示的 mockup遵循只显示资源自身费用 base fee 分开显示 版本名下方第三行 小号彩色文本四条约束且 V1 最多两级。最后建设把LicensingFeeDetail从聚合一行升级为逐资源列出完成多资源费用的弹层展示并守住只有 checkpoint 携带 parent fee的模型规则docs/creator-studio/licensing-lineage-parent-fee.md。关联的扩展阅读还包括licensing-fee-owner-stamping.md收益读取侧、licensing-fee-revamp-checklist.md费用体系改造清单与 monetization-rules.md变现规则总览。展示层的每一次改动最终都要落回费用归属清晰、父子不混淆、每图费用可核算这三条产品原则。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考