尧图网站建设 
Baserow 可折叠网格分组视图Collapsible Grid Group-by架构深入解析【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow本技术指南系统讲解 Baserow 网格视图中可折叠分组collapsible group-by功能的完整设计如何在浏览器中渲染和滚动一张超大分组表格却无需加载每一个分组与每一行数据。读完本文你将理解其分组元数据层 行数据层的双层分页架构、row_offset/sibling_index/truncated三个跨层契约字段的语义、三种坐标空间的关系以及乐观更新、分组聚合与后端有界扇出bounded fan-out的实现约束。该设计的目标是保持扁平网格的行窗口化row-windowing行为——按绝对偏移量与 limit 抓取行——并将其应用到分组树上使行与分组都能扩展到远超完整加载分组行列表所能支撑的规模。本文刻意不罗列端点参数清单、字段级 schema、函数名与 store 内部实现因为这些内容随版本漂移直接阅读代码更准确。要定位当前实现请在代码库中搜索以下持久概念group-by-data、row_offset、sibling_index、truncated。核心设计原则两个独立分页的数据层该功能由两个数据层构建分组元数据层由专用端点按页返回分组而非行。每个分组告诉客户端它包含多少行、它在兄弟分组中的位置、是否还有子分组以及它的第一个后代行在完整分组行顺序中的位置。行数据层现有的网格行端点仍按 offset 与 limit 返回行与扁平网格完全一致。连接两层的桥梁是row_offset——某个分组的首行叶子行在完全展开分组行顺序中的绝对零基位置。由于该偏移由服务端计算客户端可以仅凭普通行端点抓取叶子分组的可见行而行端点完全不需要知道哪些分组被折叠或展开。在源码中这一契约清晰可见。后端序列化器 serializers.py 中定义了sibling_index该分组在其兄弟中的零基索引与row_offset该分组首个后代行在完整分组行顺序中的绝对偏移两者在aggregations_only模式下会被省略因为该模式不返回窗口化布局。前端服务层 grid.js 中请求路径为group-by-data/或public/group-by-data/而分组与行的消费逻辑分布在 gridGroupBy.js 与 gridGroupByRender.js 中。三个坐标空间实现必须严格区分三种偏移空间兄弟空间Sibling-space分组元数据层按父分组分页兄弟分组其偏移量与sibling_index都是兄弟中的分组索引。绝对行空间Absolute-row-spacerow_offset是完整展开分组行流中的索引客户端直接将其用作行端点的 offset 参数。可见布局空间Visible layout-space用户滚动经过的是当前可见布局其中被折叠的子树只贡献一个分组表头不贡献任何行。把兄弟空间与绝对行空间混为一谈是分组滚动行为出错的最常见原因。稀疏树与稀疏行客户端不应为了显示正确的滚动条或滚动到深层区域而加载完整的分组树。已加载的分组页构成一棵稀疏树未加载的分组区间用占位符表示占位符尺寸由已知的分组计数推算。叶子行同样是稀疏的行只为可见行窗口抓取然后按绝对行偏移缓存使一次行响应即可满足包含这些偏移的区块。行不作为独立的布局节点参与分组滚动区域的计算。一个叶子分组可被表示为一个带有行数的行区块只有可见视口内的行槽位才会被具体化。这使得布局规模与已加载的分组元数据量成正比而非与总行数成正比。紧凑的折叠状态模型折叠状态建模为模式 例外展开模式且无例外 所有分组均展开折叠模式且无例外 所有分组均折叠例外路径对特定分组反转当前模式。这使得全部展开 / 全部折叠成为常量级状态变更与分组数量无关。全部折叠只显示顶层表头因此只需按深度depth-based加载单个可见深度的分组元数据。全部展开与混合状态则按父分组加载逐层展开每个可见父分组的子树直到叶子让一次请求返回视口所需的全部内容而不是每个深度各发一次请求。视口驱动的抓取滚动应只抓取与可见视口重叠的内容外加网格常规所需的缓冲。客户端将视口映射为两类缺失项按父分组或按深度缺失的分组页可见叶子区块缺失的绝对行区间。可见父分组的请求可以合并为一次分组元数据调用缺失的行区间在调用行端点前先去重。如果请求发出后分组方式、折叠状态、排序、过滤或乐观行计数发生了变化在途响应必须被忽略。乐观变更与服务端对账创建、更新、删除与移动操作可以在服务端响应前更新可见分组 UI。本地更新必须保持分组行计数、行位置与可见区块的一致性。当一行在分组间移动时源分组与目标分组都需要更新计数。在客户端无法本地确定最终分组归属的情况下例如公式支持的分组、仅后端生效的影响、缺失的分组页、需要回滚的错误响应服务端保持权威。一旦服务端通过只读或公式支持的分组字段解析了分组变更行会立即移动到该分组——即使该行正处于选中状态。选中行移动警告占位符仅对可直接写入的分组字段有用因为此类字段进行中的编辑必须在取消选中前保持可见。组内行排序分组行在叶子分组内部保持表格的手动行顺序作为最终排序键。当没有显式视图排序时可见行插入槽位可以将一行移动到同一叶子分组内另一行之前或移动到该分组的末尾。移动到另一个叶子分组时先替换该行由完整目标分组路径所表示的行值再更新其顺序。这是两次独立 API 请求但属于同一动作组action group因此一次撤销/重做即可同时还原两次变更。如果顺序请求在值更新成功后失败该行会以原有顺序留在目标分组中。跨组移动仅在所有生效的分组字段都可写时可用只要存在只读分组字段行就只能在其当前叶子分组内重排。折叠分组与未加载的行占位符不是拖放目标因为它们不提供明确无歧义的可见插入槽位。有界扇出Bounded Fan-Out包含后代的请求必须有上限。宽或深的分组树绝不能把一次请求变成无界的服务端工作或无界的响应。当后代响应被上限截断时API 会通过truncated标志发出信号客户端据此惰性加载剩余部分。后端序列化器 serializers.py 对truncated的说明为后代加载是否因达到响应页或分组上限而提前停止。分组元数据 API只读的分组元数据端点含对应的公共视图变体按页返回分组元数据某个父分组下有哪些分组、每个分组有多少行与多少子分组、每个分组在其兄弟中的位置以及其首行叶子行的绝对行偏移。它还可以在同一次往返中打包页脚总计并预加载有界切片的后代。具体参数、响应结构与字段名见序列化器与视图代码。端点的实际请求形态与参数可在视图代码 views.py 中确认GridViewGroupByDataView通过 OpenAPI 声明了parents、depth、include_descendants、descendant_limit、descendant_row_budget、aggregations_only、include_totals、offset、limit以及可选的group_by参数后者允许无视图更新权限的用户——例如只读者——临时按任意字段分组。响应结构见 serializers.pyGridViewGroupByDataPageSerializer携带parent、groups、offset、limit、group_count最外层GridViewGroupByDataSerializer携带pages、truncated与表级aggregations总计。端点支持三种请求形态由视口需求决定单个父分组的子分组页请求某一父分组下的一页子分组多个父分组的页合并为一次往返当同一深度的多个可见父分组都需要子分组时使用跨所有父分组的整深度页服务统一的展开/折叠状态避免每个可见父分组各发一次请求。两个不变量保证其正确性分组元数据查询与行查询必须应用完全相同的过滤、搜索、排序与分组排序。若二者不一致按某个分组的row_offset抓取行会将其放错分组。后端在处理逻辑utils.py 中的get_group_by_data_pages含include_descendants、descendant_limit、descendant_row_budget参数中基于视图过滤后的同一 queryset 计算分组正是为了维护这一一致性。后代预加载必须有界当上限截断响应时API 发出truncated信号客户端据此惰性加载剩余部分。分组路径中的分组值使用各字段类型的 group-by 序列化规则序列化前端必须将其视为API 值而非原始数据库值。序列化器中的display字段专门用于参考字段如协作者名称或关联行的主值的可渲染显示值仅在分组值为客户端无法自行渲染的 id 或 id 列表时出现。服务端职责服务端拥有客户端无法可靠推导的全部事实应用生效排序与分组规则后的分组排序经过过滤与搜索后每个分组的行数非叶子分组的子分组计数兄弟索引完全展开分组顺序中的绝对行偏移有上限的后代展开与截断信号。这些值必须基于与行端点相同的逻辑行集合计算。若行端点与分组元数据层在过滤、搜索、排序顺序或分组顺序上不一致按row_offset抓取行就会把行放到错误的分组。视图 views.py 还提供了PublicGridViewGroupByDataView供公共匿名分享网格视图使用其分组与偏移语义与登录视图完全相同。客户端职责客户端通过遵循上述 API 契约实现该功能保持已加载分组页的稀疏性并以父路径/深度为键缓存将未加载的分组区间渲染为占位符尺寸由已知兄弟计数与几何推算使用row_offset将可见叶子行区块映射为绝对行区间从普通行端点抓取缺失行初始全部展开加载时第一页行offset 0与分组骨架并行抓取因为全部展开时行按排序顺序渲染、与树结构无关按绝对偏移缓存抓取的行并放入拥有该偏移的可见区块尽可能批量合并可见分组元数据请求在分组方式、过滤、排序、折叠状态或乐观行计数变化后忽略过期响应乐观更新可见计数与行位置再与服务端响应对账。公共网格必须使用公共分组元数据端点与公共行端点但偏移与分组语义完全相同。扩展性特征与已知限制行层与扁平网格的扩展方式相同行按真实 offset/limit 抓取渲染对视口保持虚拟化。分组层通过加载分组元数据窗口而非完整分组树来实现扩展。每个视口的查询次数应与可见分组数及深度成正比而不是与总行数或总分组数成正比。全部折叠使用深度加载处理其唯一的可见层级全部展开在一次请求中按叶子行预算加载每个可见父分组的子树直到叶子因此初始视口只需一次往返而非每层各一次。需要注意的已知成本分组元数据页在返回一页之前服务端仍可能需要推算该层级的所有兄弟分组。页大小限制的是响应而不一定是排序与统计兄弟所需的数据库工作量。当请求已携带父分组的绝对行偏移时计算子偏移成本更低。后代加载应保留并复用该信息。客户端缓存已加载分组页与已抓取行在长滚动会话中会增长。渲染保持虚拟化但保留的元数据与行对象仍占用内存。布局计算应与已加载分组元数据及可见行成正比而非与总行数成正比。契约不变量少量跨层字段——绝对行偏移、兄弟索引、行数、子分组数与总兄弟数——构成前后端的契约。重命名或改变其语义需要后端与前端协同变更。行端点与分组元数据层必须应用相同的视图约束与排序。用于占位符、分组表头、行区块与新增行线的几何尺寸必须与渲染 UI 的实际尺寸一致否则滚动计算会发生漂移。乐观更新必须在下一次服务端对账前保持行计数与行位置索引一致。跨组行移动必须先更新完整的目标分组路径再改变顺序。顺序请求失败不会回滚成功的分组值更新。分组聚合Group Aggregations当某列配置了页脚汇总Summarize聚合时每个分组表头都会显示该分组各行计算出的聚合值且在每个深度都生效。这些值随分组元数据响应一并传输页脚总计也可打包进同一次请求因此分组模式下永远不会调用独立的聚合端点。更新被合并且以后端为权威一次分组元数据请求同时刷新已加载的分组窗口与页脚总计所有编辑路径与实时realtime回显都汇聚到同一个分组感知的刷新流程。行编辑静默刷新只有修改某列的聚合函数时才显示加载动画。排序无需刷新因为这些聚合与顺序无关。总结可折叠分组视图是 Baserow 网格虚拟化能力向分组树维度的自然延伸。理解分组元数据层与行层独立分页、row_offset作为跨层桥梁、三种坐标空间不可混淆、稀疏树 稀疏行、紧凑折叠状态、有界扇出这六条主线即可把握其全部行为边界。想要深入验证或调试具体行为建议从 views.py后端分组元数据视图、serializers.py响应契约与 gridGroupBy.js前端分组坐标与缓存逻辑三条路径入手。【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Baserow 可折叠网格分组视图（Collapsible Grid Group-by）架构深入解析
Baserow 可折叠网格分组视图Collapsible Grid Group-by架构深入解析【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow本技术指南系统讲解 Baserow 网格视图中可折叠分组collapsible group-by功能的完整设计如何在浏览器中渲染和滚动一张超大分组表格却无需加载每一个分组与每一行数据。读完本文你将理解其分组元数据层 行数据层的双层分页架构、row_offset/sibling_index/truncated三个跨层契约字段的语义、三种坐标空间的关系以及乐观更新、分组聚合与后端有界扇出bounded fan-out的实现约束。该设计的目标是保持扁平网格的行窗口化row-windowing行为——按绝对偏移量与 limit 抓取行——并将其应用到分组树上使行与分组都能扩展到远超完整加载分组行列表所能支撑的规模。本文刻意不罗列端点参数清单、字段级 schema、函数名与 store 内部实现因为这些内容随版本漂移直接阅读代码更准确。要定位当前实现请在代码库中搜索以下持久概念group-by-data、row_offset、sibling_index、truncated。核心设计原则两个独立分页的数据层该功能由两个数据层构建分组元数据层由专用端点按页返回分组而非行。每个分组告诉客户端它包含多少行、它在兄弟分组中的位置、是否还有子分组以及它的第一个后代行在完整分组行顺序中的位置。行数据层现有的网格行端点仍按 offset 与 limit 返回行与扁平网格完全一致。连接两层的桥梁是row_offset——某个分组的首行叶子行在完全展开分组行顺序中的绝对零基位置。由于该偏移由服务端计算客户端可以仅凭普通行端点抓取叶子分组的可见行而行端点完全不需要知道哪些分组被折叠或展开。在源码中这一契约清晰可见。后端序列化器 serializers.py 中定义了sibling_index该分组在其兄弟中的零基索引与row_offset该分组首个后代行在完整分组行顺序中的绝对偏移两者在aggregations_only模式下会被省略因为该模式不返回窗口化布局。前端服务层 grid.js 中请求路径为group-by-data/或public/group-by-data/而分组与行的消费逻辑分布在 gridGroupBy.js 与 gridGroupByRender.js 中。三个坐标空间实现必须严格区分三种偏移空间兄弟空间Sibling-space分组元数据层按父分组分页兄弟分组其偏移量与sibling_index都是兄弟中的分组索引。绝对行空间Absolute-row-spacerow_offset是完整展开分组行流中的索引客户端直接将其用作行端点的 offset 参数。可见布局空间Visible layout-space用户滚动经过的是当前可见布局其中被折叠的子树只贡献一个分组表头不贡献任何行。把兄弟空间与绝对行空间混为一谈是分组滚动行为出错的最常见原因。稀疏树与稀疏行客户端不应为了显示正确的滚动条或滚动到深层区域而加载完整的分组树。已加载的分组页构成一棵稀疏树未加载的分组区间用占位符表示占位符尺寸由已知的分组计数推算。叶子行同样是稀疏的行只为可见行窗口抓取然后按绝对行偏移缓存使一次行响应即可满足包含这些偏移的区块。行不作为独立的布局节点参与分组滚动区域的计算。一个叶子分组可被表示为一个带有行数的行区块只有可见视口内的行槽位才会被具体化。这使得布局规模与已加载的分组元数据量成正比而非与总行数成正比。紧凑的折叠状态模型折叠状态建模为模式 例外展开模式且无例外 所有分组均展开折叠模式且无例外 所有分组均折叠例外路径对特定分组反转当前模式。这使得全部展开 / 全部折叠成为常量级状态变更与分组数量无关。全部折叠只显示顶层表头因此只需按深度depth-based加载单个可见深度的分组元数据。全部展开与混合状态则按父分组加载逐层展开每个可见父分组的子树直到叶子让一次请求返回视口所需的全部内容而不是每个深度各发一次请求。视口驱动的抓取滚动应只抓取与可见视口重叠的内容外加网格常规所需的缓冲。客户端将视口映射为两类缺失项按父分组或按深度缺失的分组页可见叶子区块缺失的绝对行区间。可见父分组的请求可以合并为一次分组元数据调用缺失的行区间在调用行端点前先去重。如果请求发出后分组方式、折叠状态、排序、过滤或乐观行计数发生了变化在途响应必须被忽略。乐观变更与服务端对账创建、更新、删除与移动操作可以在服务端响应前更新可见分组 UI。本地更新必须保持分组行计数、行位置与可见区块的一致性。当一行在分组间移动时源分组与目标分组都需要更新计数。在客户端无法本地确定最终分组归属的情况下例如公式支持的分组、仅后端生效的影响、缺失的分组页、需要回滚的错误响应服务端保持权威。一旦服务端通过只读或公式支持的分组字段解析了分组变更行会立即移动到该分组——即使该行正处于选中状态。选中行移动警告占位符仅对可直接写入的分组字段有用因为此类字段进行中的编辑必须在取消选中前保持可见。组内行排序分组行在叶子分组内部保持表格的手动行顺序作为最终排序键。当没有显式视图排序时可见行插入槽位可以将一行移动到同一叶子分组内另一行之前或移动到该分组的末尾。移动到另一个叶子分组时先替换该行由完整目标分组路径所表示的行值再更新其顺序。这是两次独立 API 请求但属于同一动作组action group因此一次撤销/重做即可同时还原两次变更。如果顺序请求在值更新成功后失败该行会以原有顺序留在目标分组中。跨组移动仅在所有生效的分组字段都可写时可用只要存在只读分组字段行就只能在其当前叶子分组内重排。折叠分组与未加载的行占位符不是拖放目标因为它们不提供明确无歧义的可见插入槽位。有界扇出Bounded Fan-Out包含后代的请求必须有上限。宽或深的分组树绝不能把一次请求变成无界的服务端工作或无界的响应。当后代响应被上限截断时API 会通过truncated标志发出信号客户端据此惰性加载剩余部分。后端序列化器 serializers.py 对truncated的说明为后代加载是否因达到响应页或分组上限而提前停止。分组元数据 API只读的分组元数据端点含对应的公共视图变体按页返回分组元数据某个父分组下有哪些分组、每个分组有多少行与多少子分组、每个分组在其兄弟中的位置以及其首行叶子行的绝对行偏移。它还可以在同一次往返中打包页脚总计并预加载有界切片的后代。具体参数、响应结构与字段名见序列化器与视图代码。端点的实际请求形态与参数可在视图代码 views.py 中确认GridViewGroupByDataView通过 OpenAPI 声明了parents、depth、include_descendants、descendant_limit、descendant_row_budget、aggregations_only、include_totals、offset、limit以及可选的group_by参数后者允许无视图更新权限的用户——例如只读者——临时按任意字段分组。响应结构见 serializers.pyGridViewGroupByDataPageSerializer携带parent、groups、offset、limit、group_count最外层GridViewGroupByDataSerializer携带pages、truncated与表级aggregations总计。端点支持三种请求形态由视口需求决定单个父分组的子分组页请求某一父分组下的一页子分组多个父分组的页合并为一次往返当同一深度的多个可见父分组都需要子分组时使用跨所有父分组的整深度页服务统一的展开/折叠状态避免每个可见父分组各发一次请求。两个不变量保证其正确性分组元数据查询与行查询必须应用完全相同的过滤、搜索、排序与分组排序。若二者不一致按某个分组的row_offset抓取行会将其放错分组。后端在处理逻辑utils.py 中的get_group_by_data_pages含include_descendants、descendant_limit、descendant_row_budget参数中基于视图过滤后的同一 queryset 计算分组正是为了维护这一一致性。后代预加载必须有界当上限截断响应时API 发出truncated信号客户端据此惰性加载剩余部分。分组路径中的分组值使用各字段类型的 group-by 序列化规则序列化前端必须将其视为API 值而非原始数据库值。序列化器中的display字段专门用于参考字段如协作者名称或关联行的主值的可渲染显示值仅在分组值为客户端无法自行渲染的 id 或 id 列表时出现。服务端职责服务端拥有客户端无法可靠推导的全部事实应用生效排序与分组规则后的分组排序经过过滤与搜索后每个分组的行数非叶子分组的子分组计数兄弟索引完全展开分组顺序中的绝对行偏移有上限的后代展开与截断信号。这些值必须基于与行端点相同的逻辑行集合计算。若行端点与分组元数据层在过滤、搜索、排序顺序或分组顺序上不一致按row_offset抓取行就会把行放到错误的分组。视图 views.py 还提供了PublicGridViewGroupByDataView供公共匿名分享网格视图使用其分组与偏移语义与登录视图完全相同。客户端职责客户端通过遵循上述 API 契约实现该功能保持已加载分组页的稀疏性并以父路径/深度为键缓存将未加载的分组区间渲染为占位符尺寸由已知兄弟计数与几何推算使用row_offset将可见叶子行区块映射为绝对行区间从普通行端点抓取缺失行初始全部展开加载时第一页行offset 0与分组骨架并行抓取因为全部展开时行按排序顺序渲染、与树结构无关按绝对偏移缓存抓取的行并放入拥有该偏移的可见区块尽可能批量合并可见分组元数据请求在分组方式、过滤、排序、折叠状态或乐观行计数变化后忽略过期响应乐观更新可见计数与行位置再与服务端响应对账。公共网格必须使用公共分组元数据端点与公共行端点但偏移与分组语义完全相同。扩展性特征与已知限制行层与扁平网格的扩展方式相同行按真实 offset/limit 抓取渲染对视口保持虚拟化。分组层通过加载分组元数据窗口而非完整分组树来实现扩展。每个视口的查询次数应与可见分组数及深度成正比而不是与总行数或总分组数成正比。全部折叠使用深度加载处理其唯一的可见层级全部展开在一次请求中按叶子行预算加载每个可见父分组的子树直到叶子因此初始视口只需一次往返而非每层各一次。需要注意的已知成本分组元数据页在返回一页之前服务端仍可能需要推算该层级的所有兄弟分组。页大小限制的是响应而不一定是排序与统计兄弟所需的数据库工作量。当请求已携带父分组的绝对行偏移时计算子偏移成本更低。后代加载应保留并复用该信息。客户端缓存已加载分组页与已抓取行在长滚动会话中会增长。渲染保持虚拟化但保留的元数据与行对象仍占用内存。布局计算应与已加载分组元数据及可见行成正比而非与总行数成正比。契约不变量少量跨层字段——绝对行偏移、兄弟索引、行数、子分组数与总兄弟数——构成前后端的契约。重命名或改变其语义需要后端与前端协同变更。行端点与分组元数据层必须应用相同的视图约束与排序。用于占位符、分组表头、行区块与新增行线的几何尺寸必须与渲染 UI 的实际尺寸一致否则滚动计算会发生漂移。乐观更新必须在下一次服务端对账前保持行计数与行位置索引一致。跨组行移动必须先更新完整的目标分组路径再改变顺序。顺序请求失败不会回滚成功的分组值更新。分组聚合Group Aggregations当某列配置了页脚汇总Summarize聚合时每个分组表头都会显示该分组各行计算出的聚合值且在每个深度都生效。这些值随分组元数据响应一并传输页脚总计也可打包进同一次请求因此分组模式下永远不会调用独立的聚合端点。更新被合并且以后端为权威一次分组元数据请求同时刷新已加载的分组窗口与页脚总计所有编辑路径与实时realtime回显都汇聚到同一个分组感知的刷新流程。行编辑静默刷新只有修改某列的聚合函数时才显示加载动画。排序无需刷新因为这些聚合与顺序无关。总结可折叠分组视图是 Baserow 网格虚拟化能力向分组树维度的自然延伸。理解分组元数据层与行层独立分页、row_offset作为跨层桥梁、三种坐标空间不可混淆、稀疏树 稀疏行、紧凑折叠状态、有界扇出这六条主线即可把握其全部行为边界。想要深入验证或调试具体行为建议从 views.py后端分组元数据视图、serializers.py响应契约与 gridGroupBy.js前端分组坐标与缓存逻辑三条路径入手。【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考