civitai 生成器头部重新设计form-graph 通道的 Above the Prompt 落地实战【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai导读本文基于仓库中 generator-header-redesign.md 设计文档深入剖析 civitai 生成器Generator头部的一次架构级重构将原来散落在头部的工作流模式条mode strip、基础模型选择胶囊pill与资源选择器整合为「工作流选择器 一体化资源/检查点选择弹窗」。全文以form-graph生成通道FormGraphGenerator为唯一作用域其余通道data-graph 的GenerationFormV2、App Blocks、Challenge 等行为保持不变。读完本文你将掌握这次改动的安全边界划分依据、四条落地阶段Phases的实现细节、共享资源选择器如何以「角色role 插槽slot」方式扩展而不破坏既有消费者以及「待定切换 后果页脚」这套把生态切换代价前置到决策时刻的交互机制并可直接在仓库源码中逐文件核对每一处实现。为什么限定在 form-graph 通道是安全的双通道并行的现状civitai 的生成表单存在两条平行通道data-graph 通道的GenerationFormV2与 form-graph 通道的FormGraphGenerator。二者的切换由特性开关formGraphGenerator决定——见 GenerationTabs.tsx 中features.formGraphGenerator ? FormGraphGenerator : GenerationFormV2的挂载逻辑且该 flag 是动态加载dynamic import的。天然的发布闸门关键的安全前提是开关的可用范围formGraphGenerator: { availability: [mod], fliptKey: form-graph-generator }定义在 feature-flags.service.ts注释明确它是「THE form-graph cutover flag」。这意味着新头部只对审核员moderator可见普通用户继续使用旧头部从源码注释feature-flags.service.ts可以看出flag 与「shadow 对比解析」shadow-parse.ts中的影子解析配合使用——每个提交都会被新旧两套解析器同时解析对比为将来放量提供数据支撑拓宽放量只需通过 Flipt keyform-graph-generator调整无需任何代码改动发布闸门天然存在。改动分层的「接缝」策略文档给出了一张三层的接缝表仓库中的文件分布与之完全吻合层文件处理方式外壳 / 头部BaseGenerationForm.tsx本就是 form-graph 私有直接修改头部输入控件generation_v2/inputs/WorkflowInput、BaseModelInput分叉Fork到form-graph/generation/inputs/因为改动的是契约而非样式选择器内部ImageGeneration/GenerationForm/ResourceSelect*加法扩展Extend additively新 props 默认保持旧行为选择器内部是重构成本最高的部分目录查询、卡片、过滤、无限列表分叉会让需要保持正确的表面积翻倍而分叉两个头部输入控件约产生 1.7k 行分歧代码且这些代码会随 v2 通道下线而消亡——这是文档拍板「外壳直接改、输入控件分叉、选择器内部加法扩展」的成本依据。三个关键决策版本、生态轴、输入切换决策一版本是选择的「下一步」而非选择的一部分挑选模型时立即取最新版本版本退化为模型行下方的一个字段仅当存在多个版本时才渲染VersionGroupSelector位于 form-helpers.tsx本就是 form-graph 私有组件且已经在模型行下方渲染——保留它卡片内的分段控件segmented control不再是版本切换机制该组件是层级式版本选择器父层级用紧凑下拉VersionLevelDropdown叶子层级用按钮组同时通过ResourceDataProvider批量注册所有版本 id 用于数据水合。allIds.size 1时直接返回null与「仅当多个版本时显示」的决策一致。决策二生态选择用「轨rail」取代「胶囊pill」BaseModelInput从 form-graph 通道的头部完全移除头部同时保留胶囊和轨会让「生态」这一轴出现在两个地方这正是本次重构要解决的根源问题生态选择迁移到资源选择弹窗左侧的轨中见form-graph/generation/inputs/EcosystemRail.tsx特别地轨内不提供输出类型范围控制——BaseModelListContent自带 compatible/recent/all 三个标签页两个范围控制即重复被移除。决策三输入切换代价一个点击模式条mode strip折叠进工作流选择器成为一个过滤条件由于通道仅对审核员开放切换成本直接暴露给「能撤销它的人」因此先不加遥测门控。Phase 01把模式条折叠进工作流选择器新组件WorkflowPickerWorkflowPicker.tsx 是本次改造第一个落地的产物其设计要点每个工作流只列一次输入类型from text/from image/from video作为行的属性展示源码中INPUT_TYPES常量与每行的InputIcon input.label渲染顶部提供All / From-text / From-image / From-video过滤条带计数徽标count 为 0 的过滤项自动隐藏过滤即输入轴而非第二套控件行内支持三类状态普通可选行、memberOnly会员专属行用RequireMembership包裹、disabled规则禁用行保持可点选但变暗因为「点选它」正是让表单解释为何无法生成的方式生态相关展示若某工作流的ecosystemIds不包含当前生态会显示橙色 Switches model 徽标别名alias工作流通过与父级相同的graphKey关联选中态优先精确 id 匹配、再匹配当前生态的别名工作流可见性应用了三层过滤生态 gate 规则 → 特性开关 → 工作流级 gate 规则与 v2 选择器一致被隐藏的 key 永远不会渲染。头部收缩BaseGenerationForm.tsx 中ButtonGroupInput模式条及其getWorkflowModes()调用被移除替换为始终可见的WorkflowPicker芯片chip并支持增强工作流场景的返回箭头onBackgetWorkflowModes仍保留导出v2 通道仍在使用只是 form-graph 的调用点消失——定义位于 workflows.ts。测试背书WorkflowPicker.browser.test.tsx 直接以 Phase 01 的两个核心声明为断言目标输入轴是「属性 过滤」而非第二个控件——过滤到 From image 必须隐藏txt2imgCreate Image而保留img2imgImage Variations这正是旧模式条的两端选中行发出的是工作流graph key与模式条设置的是同一个 key。若回退到四段式选择器测试会在过滤按钮缺失与 key 不一致两处作为断言失败暴露而非超时——这是对该改造的回归守护。Phase 02教会选择器它的「角色」role属性的加法扩展ResourceSelectProvider新增role?: checkpoint | resource默认undefined即完全保持旧行为见 ResourceSelectProvider.tsx。两种角色的语义checkpoint移除卡片内的版本下拉——版本已成为表单模型行下的字段呼应决策一resource对每张卡片按当前检查点的生态做兼容性徽标判定、支持多选、底部出现批次暂存托盘footer tray。资源模式的托盘不编辑单项强度——表单自身的资源列表已经拥有强度这一值第二个控件写入同一个值正是本次重构要消除的重复。关于「轨」的一次反复文档明确记录了一个被构建又移除的方案资源模式曾有一个「轨」把资源类型从过滤器下拉中提升出来但移除原因是它是写入同一个filters.types的第二个控件且语义不同轨单选、下拉多选两者会对「选中了什么」产生分歧。最终结论沉淀在 PickerRail.tsx 的注释中有轨 目录的 SCOPE 可选无轨 目录已确定范围工具栏负责收窄。布局变更惠及所有消费者弹窗布局的改动影响每一个消费者而不仅是带 role 的头部带header band横跨全宽轨与目录并排页脚横跨全宽宽度 1200 → 1500源码中体现为 index.tsx 的CATALOG_WIDTH 1276加上RAIL_WIDTH 224有轨时弹窗加宽网格填满所在面板而非居中固定宽度列——ResourceHitList.tsx 的FillingMasonryGrid通过ResizeObserver测量面板宽度、以MIN_COLUMN_WIDTH 240与MAX_COLUMN_COUNT 4反推列数把列宽精确整除面板消除居中布局在弹窗里造成的约 150px 死区。无 role 时行为不变共享的镀铬chrome结构变了。三带布局header / railcatalog / footer在 ResourceSelectModalContent.tsx 有明确注释描述且不同角色有独立的标题文案ROLE_COPY。Phase 03目录Catalog或名册RosterResourceHitList依据目录规模分叉渲染托管型供应商Kling、Veo、Sora、ACE、Hunyuan3D渲染版本名册而非搜索网格搜索、排序、过滤直接隐藏而不是「死着摆在那儿」不设价格列——TransformedModel不携带成本数据所以「每秒 N 个」的计价展示被推迟而非伪造网格加载通过keepPreviousData保留上一份目录在屏直到新目录加载完成ResourceHitList.tsx且该注释明确说明这一逻辑在「轨可以重新瞄准目录」之后依然成立。Phase 04轨 后果页脚生态选择迁移进弹窗生态选择进入选择器左侧的轨带搜索取代 form-graph 头部里的BaseModelInput轨的列表本身复用BaseModelListContentuseBaseModelPickerState——与旧头部胶囊用的是同一对组件见 EcosystemRail.tsx 注释页脚按真实的兼容性检查统计一次切换实际会丢弃多少个资源且此时选择仍可取消——即ResourceAlerts的信息被前置到提交之前这两者必须一起上线把控件移进来的目的就是让「切换的代价」在切换决策的那一刻可见。「待定pending」选择机制轨中的选择是待定选择而非立即提交点击轨中的生态 → 写入checkpoint-picker.store.ts的pendingEcosystem通过setOptionsOverride用getResourceSelectOptions(ecosystemKey, types)重新瞄准目录——该函数定义于 defs.ts纯函数、按生态键缓存因此预览一个生态族不需要写任何 store页脚同时统计「若提交会丢弃多少资源」提交发生在按下 Use或选中一个检查点时——后者会先写生态commitSelection中先onEcosystemChange(pendingEcosystem)再onSelect(resource)保证模型写入是最终在表单图graph协调reconciliation中存活的写入。为什么待定状态住在 zustand store 里checkpoint-picker.store.ts 的注释给出了精确理由轨和页脚渲染在共享资源弹窗的两个不同插槽中是没有共同祖先的兄弟节点组件状态无法承载。store 同时解决了另一个问题dialogStore只捕获一次弹窗 props弹窗打开时的生态值会在页脚提交不同生态后过期——闭包变量无法触发重渲染而两个插槽都订阅同一个 store一次提交即可同步更新轨的高亮与页脚的文案。每次打开弹窗前调用resetCheckpointPicker(ecosystem.value)重置待定状态。轨如何触达目录插槽设计共享弹窗新增rail与footer两个插槽类型是组件Component而非节点Node——这样它们渲染在ResourceSelectProvider内部可以调用setOptionsOverride。弹窗本身不包含任何生态概念form-graph 通道的openCheckpointPickeropenCheckpointPicker.tsx负责填充两个插槽弹窗大小也随之自适应有轨时CATALOG_WIDTH RAIL_WIDTH。移动端与收尾细节移动端把三个面板拆成两个屏幕且打开时落在目录而非生态列表轨在md断点以下折叠为弹窗内的一步InlineRail见 PickerRail.tsx并有配套文案卡片不再有「已选中」勾选浮层、不再有 Early Access 徽标模式条的modeLabel文案Text to Image在本通道停止渲染——选择器改为展示工作流label加每行输入类型行对应 WorkflowPicker.tsx 中芯片上label · input.label的渲染。不在范围内data-graph v2 通道、App Blocks 的 checkpoint/resource 选择器、Challenge 多选、通配符集合、Resource/FilesPrompt 以下的一切Compose、Output、Tuning保持原样。从源码结构看本次改造的边界纪律是「共享弹窗只加插槽与角色、头部输入只分叉不改样式、外壳自由编辑」这保证了所有既有消费者ResourceSelect.tsx、ResourceSelectMultiple.tsx 等在未传入新 props 时行为完全不变而 form-graph 通道则拿到了一套把「版本、生态、资源、工作流」四个轴重新排布的统一交互。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 civitai 生成器头部重新设计：form-graph 通道的 “Above the Prompt“ 落地实战
civitai 生成器头部重新设计form-graph 通道的 Above the Prompt 落地实战【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai导读本文基于仓库中 generator-header-redesign.md 设计文档深入剖析 civitai 生成器Generator头部的一次架构级重构将原来散落在头部的工作流模式条mode strip、基础模型选择胶囊pill与资源选择器整合为「工作流选择器 一体化资源/检查点选择弹窗」。全文以form-graph生成通道FormGraphGenerator为唯一作用域其余通道data-graph 的GenerationFormV2、App Blocks、Challenge 等行为保持不变。读完本文你将掌握这次改动的安全边界划分依据、四条落地阶段Phases的实现细节、共享资源选择器如何以「角色role 插槽slot」方式扩展而不破坏既有消费者以及「待定切换 后果页脚」这套把生态切换代价前置到决策时刻的交互机制并可直接在仓库源码中逐文件核对每一处实现。为什么限定在 form-graph 通道是安全的双通道并行的现状civitai 的生成表单存在两条平行通道data-graph 通道的GenerationFormV2与 form-graph 通道的FormGraphGenerator。二者的切换由特性开关formGraphGenerator决定——见 GenerationTabs.tsx 中features.formGraphGenerator ? FormGraphGenerator : GenerationFormV2的挂载逻辑且该 flag 是动态加载dynamic import的。天然的发布闸门关键的安全前提是开关的可用范围formGraphGenerator: { availability: [mod], fliptKey: form-graph-generator }定义在 feature-flags.service.ts注释明确它是「THE form-graph cutover flag」。这意味着新头部只对审核员moderator可见普通用户继续使用旧头部从源码注释feature-flags.service.ts可以看出flag 与「shadow 对比解析」shadow-parse.ts中的影子解析配合使用——每个提交都会被新旧两套解析器同时解析对比为将来放量提供数据支撑拓宽放量只需通过 Flipt keyform-graph-generator调整无需任何代码改动发布闸门天然存在。改动分层的「接缝」策略文档给出了一张三层的接缝表仓库中的文件分布与之完全吻合层文件处理方式外壳 / 头部BaseGenerationForm.tsx本就是 form-graph 私有直接修改头部输入控件generation_v2/inputs/WorkflowInput、BaseModelInput分叉Fork到form-graph/generation/inputs/因为改动的是契约而非样式选择器内部ImageGeneration/GenerationForm/ResourceSelect*加法扩展Extend additively新 props 默认保持旧行为选择器内部是重构成本最高的部分目录查询、卡片、过滤、无限列表分叉会让需要保持正确的表面积翻倍而分叉两个头部输入控件约产生 1.7k 行分歧代码且这些代码会随 v2 通道下线而消亡——这是文档拍板「外壳直接改、输入控件分叉、选择器内部加法扩展」的成本依据。三个关键决策版本、生态轴、输入切换决策一版本是选择的「下一步」而非选择的一部分挑选模型时立即取最新版本版本退化为模型行下方的一个字段仅当存在多个版本时才渲染VersionGroupSelector位于 form-helpers.tsx本就是 form-graph 私有组件且已经在模型行下方渲染——保留它卡片内的分段控件segmented control不再是版本切换机制该组件是层级式版本选择器父层级用紧凑下拉VersionLevelDropdown叶子层级用按钮组同时通过ResourceDataProvider批量注册所有版本 id 用于数据水合。allIds.size 1时直接返回null与「仅当多个版本时显示」的决策一致。决策二生态选择用「轨rail」取代「胶囊pill」BaseModelInput从 form-graph 通道的头部完全移除头部同时保留胶囊和轨会让「生态」这一轴出现在两个地方这正是本次重构要解决的根源问题生态选择迁移到资源选择弹窗左侧的轨中见form-graph/generation/inputs/EcosystemRail.tsx特别地轨内不提供输出类型范围控制——BaseModelListContent自带 compatible/recent/all 三个标签页两个范围控制即重复被移除。决策三输入切换代价一个点击模式条mode strip折叠进工作流选择器成为一个过滤条件由于通道仅对审核员开放切换成本直接暴露给「能撤销它的人」因此先不加遥测门控。Phase 01把模式条折叠进工作流选择器新组件WorkflowPickerWorkflowPicker.tsx 是本次改造第一个落地的产物其设计要点每个工作流只列一次输入类型from text/from image/from video作为行的属性展示源码中INPUT_TYPES常量与每行的InputIcon input.label渲染顶部提供All / From-text / From-image / From-video过滤条带计数徽标count 为 0 的过滤项自动隐藏过滤即输入轴而非第二套控件行内支持三类状态普通可选行、memberOnly会员专属行用RequireMembership包裹、disabled规则禁用行保持可点选但变暗因为「点选它」正是让表单解释为何无法生成的方式生态相关展示若某工作流的ecosystemIds不包含当前生态会显示橙色 Switches model 徽标别名alias工作流通过与父级相同的graphKey关联选中态优先精确 id 匹配、再匹配当前生态的别名工作流可见性应用了三层过滤生态 gate 规则 → 特性开关 → 工作流级 gate 规则与 v2 选择器一致被隐藏的 key 永远不会渲染。头部收缩BaseGenerationForm.tsx 中ButtonGroupInput模式条及其getWorkflowModes()调用被移除替换为始终可见的WorkflowPicker芯片chip并支持增强工作流场景的返回箭头onBackgetWorkflowModes仍保留导出v2 通道仍在使用只是 form-graph 的调用点消失——定义位于 workflows.ts。测试背书WorkflowPicker.browser.test.tsx 直接以 Phase 01 的两个核心声明为断言目标输入轴是「属性 过滤」而非第二个控件——过滤到 From image 必须隐藏txt2imgCreate Image而保留img2imgImage Variations这正是旧模式条的两端选中行发出的是工作流graph key与模式条设置的是同一个 key。若回退到四段式选择器测试会在过滤按钮缺失与 key 不一致两处作为断言失败暴露而非超时——这是对该改造的回归守护。Phase 02教会选择器它的「角色」role属性的加法扩展ResourceSelectProvider新增role?: checkpoint | resource默认undefined即完全保持旧行为见 ResourceSelectProvider.tsx。两种角色的语义checkpoint移除卡片内的版本下拉——版本已成为表单模型行下的字段呼应决策一resource对每张卡片按当前检查点的生态做兼容性徽标判定、支持多选、底部出现批次暂存托盘footer tray。资源模式的托盘不编辑单项强度——表单自身的资源列表已经拥有强度这一值第二个控件写入同一个值正是本次重构要消除的重复。关于「轨」的一次反复文档明确记录了一个被构建又移除的方案资源模式曾有一个「轨」把资源类型从过滤器下拉中提升出来但移除原因是它是写入同一个filters.types的第二个控件且语义不同轨单选、下拉多选两者会对「选中了什么」产生分歧。最终结论沉淀在 PickerRail.tsx 的注释中有轨 目录的 SCOPE 可选无轨 目录已确定范围工具栏负责收窄。布局变更惠及所有消费者弹窗布局的改动影响每一个消费者而不仅是带 role 的头部带header band横跨全宽轨与目录并排页脚横跨全宽宽度 1200 → 1500源码中体现为 index.tsx 的CATALOG_WIDTH 1276加上RAIL_WIDTH 224有轨时弹窗加宽网格填满所在面板而非居中固定宽度列——ResourceHitList.tsx 的FillingMasonryGrid通过ResizeObserver测量面板宽度、以MIN_COLUMN_WIDTH 240与MAX_COLUMN_COUNT 4反推列数把列宽精确整除面板消除居中布局在弹窗里造成的约 150px 死区。无 role 时行为不变共享的镀铬chrome结构变了。三带布局header / railcatalog / footer在 ResourceSelectModalContent.tsx 有明确注释描述且不同角色有独立的标题文案ROLE_COPY。Phase 03目录Catalog或名册RosterResourceHitList依据目录规模分叉渲染托管型供应商Kling、Veo、Sora、ACE、Hunyuan3D渲染版本名册而非搜索网格搜索、排序、过滤直接隐藏而不是「死着摆在那儿」不设价格列——TransformedModel不携带成本数据所以「每秒 N 个」的计价展示被推迟而非伪造网格加载通过keepPreviousData保留上一份目录在屏直到新目录加载完成ResourceHitList.tsx且该注释明确说明这一逻辑在「轨可以重新瞄准目录」之后依然成立。Phase 04轨 后果页脚生态选择迁移进弹窗生态选择进入选择器左侧的轨带搜索取代 form-graph 头部里的BaseModelInput轨的列表本身复用BaseModelListContentuseBaseModelPickerState——与旧头部胶囊用的是同一对组件见 EcosystemRail.tsx 注释页脚按真实的兼容性检查统计一次切换实际会丢弃多少个资源且此时选择仍可取消——即ResourceAlerts的信息被前置到提交之前这两者必须一起上线把控件移进来的目的就是让「切换的代价」在切换决策的那一刻可见。「待定pending」选择机制轨中的选择是待定选择而非立即提交点击轨中的生态 → 写入checkpoint-picker.store.ts的pendingEcosystem通过setOptionsOverride用getResourceSelectOptions(ecosystemKey, types)重新瞄准目录——该函数定义于 defs.ts纯函数、按生态键缓存因此预览一个生态族不需要写任何 store页脚同时统计「若提交会丢弃多少资源」提交发生在按下 Use或选中一个检查点时——后者会先写生态commitSelection中先onEcosystemChange(pendingEcosystem)再onSelect(resource)保证模型写入是最终在表单图graph协调reconciliation中存活的写入。为什么待定状态住在 zustand store 里checkpoint-picker.store.ts 的注释给出了精确理由轨和页脚渲染在共享资源弹窗的两个不同插槽中是没有共同祖先的兄弟节点组件状态无法承载。store 同时解决了另一个问题dialogStore只捕获一次弹窗 props弹窗打开时的生态值会在页脚提交不同生态后过期——闭包变量无法触发重渲染而两个插槽都订阅同一个 store一次提交即可同步更新轨的高亮与页脚的文案。每次打开弹窗前调用resetCheckpointPicker(ecosystem.value)重置待定状态。轨如何触达目录插槽设计共享弹窗新增rail与footer两个插槽类型是组件Component而非节点Node——这样它们渲染在ResourceSelectProvider内部可以调用setOptionsOverride。弹窗本身不包含任何生态概念form-graph 通道的openCheckpointPickeropenCheckpointPicker.tsx负责填充两个插槽弹窗大小也随之自适应有轨时CATALOG_WIDTH RAIL_WIDTH。移动端与收尾细节移动端把三个面板拆成两个屏幕且打开时落在目录而非生态列表轨在md断点以下折叠为弹窗内的一步InlineRail见 PickerRail.tsx并有配套文案卡片不再有「已选中」勾选浮层、不再有 Early Access 徽标模式条的modeLabel文案Text to Image在本通道停止渲染——选择器改为展示工作流label加每行输入类型行对应 WorkflowPicker.tsx 中芯片上label · input.label的渲染。不在范围内data-graph v2 通道、App Blocks 的 checkpoint/resource 选择器、Challenge 多选、通配符集合、Resource/FilesPrompt 以下的一切Compose、Output、Tuning保持原样。从源码结构看本次改造的边界纪律是「共享弹窗只加插槽与角色、头部输入只分叉不改样式、外壳自由编辑」这保证了所有既有消费者ResourceSelect.tsx、ResourceSelectMultiple.tsx 等在未传入新 props 时行为完全不变而 form-graph 通道则拿到了一套把「版本、生态、资源、工作流」四个轴重新排布的统一交互。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考