尧图网站建设 
Warp 文档自动化定制指南深入 Sphinx autosummary 模板 base.rst 的原理与实战【免费下载链接】warpA Python framework for GPU-accelerated simulation, robotics, and machine learning.项目地址: https://gitcode.com/GitHub_Trending/warp/warp本篇技术指南围绕 NVIDIA WarpGPU 加速的仿真、机器人与机器学习 Python 框架文档系统中用于生成 API 参考手册的 Sphinx autosummary 基础模板 base.rst 展开。通过阅读本文你将理解 Warp 数百个公开 API 符号是如何被批量渲染为独立文档页面的掌握 Jinja2 模板变量fullname、module、objtype、objname与wp_annotation_override自定义注解机制的运作方式并学会如何在 Warp 的文档构建流水线中定制自己的 autosummary 模板与注解覆盖规则。一、base.rst 在 Warp 文档体系中的定位Warp 的文档并非手写数百个 API 页面而是通过一条生成 模板渲染的自动化流水线构建的脚本 generate_reference.py 在构建开始时扫描warp包及其子模块的公开符号为每个模块生成一份浓缩的.rst清单如 warp.rst、builtins.rst清单内使用.. autosummary::指令列出符号Sphinx 的sphinx.ext.autosummary扩展遇到这些指令后为每个符号渲染一个独立的 stub 页面每个 stub 页面的排版由docs/_templates/下的模板决定——其中对绝大多数符号生效的就是本篇文章的主角base.rst。该目录下共存放两类 autosummary 模板见 docs/_templates/autosummary/模板文件作用范围base.rst默认通用模板覆盖函数、类、数据等所有autosummary符号的 stub 页面class.rst专用于类符号额外生成Methods / Attributes成员汇总表builtins.rst专用于warp._src.lang内置函数渲染多重重载签名与属性标签由:template:选项指定base.rst 全文仅有 7 行却承担了整个 Warp API 参考手册最核心的渲染职责是一份小而精的模板范本。二、逐行拆解 base.rst 模板模板全文如下docs/_templates/autosummary/base.rst{{ fullname | escape | underline }} .. currentmodule:: {{ module }} .. auto{{ objtype }}:: {{ objname }}{% if wp_annotation_override %} :annotation: {{ wp_annotation_override }} {% endif %}2.1 页面标题{{ fullname | escape | underline }}fullname符号的完整限定名例如warp.array、warp.launch、warp.fem.Quad。Sphinx 在渲染 stub 页面时会将该变量注入模板上下文| escapeJinja2 过滤器对可能包含特殊字符的符号名做转义避免破坏 reStructuredText 语法| underlineSphinx autosummary 提供的 Jinja2 过滤器根据标题文本长度生成匹配的 RST 下划线等使该行成为合法的文档章节标题。2.2 模块上下文.. currentmodule:: {{ module }}module是符号所属模块的完整导入路径。该指令将后续所有:class:、:func:等交叉引用的解析基准设置为当前模块保证 stub 页内相对简写的引用能够被正确解析到 Warp 的真实模块上。例如在warp._src.lang下内置函数的内部路径会被统一改写为公开的warp.*路径见后文第六节。2.3 动态指令.. auto{{ objtype }}:: {{ objname }}这是 base.rst 的核心机制——利用 Jinja2 的插值动态生成 autodoc 指令objtype符号类型Sphinx autosummary 支持class、function、data、method、attribute、module等取值。模板渲染时它会被替换成对应的.. autoclass::、.. autofunction::、.. autodata::指令objname符号的短名称不含模块前缀。也就是说一个模板同时承担了类、函数、常量等所有符号类型的渲染这正是 base.rst 能够以 7 行代码覆盖 Warp 全部公开 API 的原因。autodoc 随后会读取该符号的 docstring并结合 conf.py 中的autodoc_default_options展开成员文档autodoc_default_options { members: True, # 包含所有公开成员 member-order: bysource, # 按源码定义顺序排列成员 undoc-members: False, # 跳过没有 docstring 的成员 exclude-members: __weakref__, autosummary: True, # 为类成员生成汇总表 }同时autoclass_content bothconf.py会把__init__的 docstring 合并进类描述——因为许多 Warp 类如warp.array、warp.Mesh、warp.fem几何类型把构造参数文档写在__init__上而class.rst模板有意省略.. automethod:: __init__因此该配置正是这些构造参数能出现在渲染文档中的关键。2.4 自定义注解wp_annotation_override与:annotation:wp_annotation_override是 Warp 文档工程为 base.rst 注入的自定义上下文变量。当它在模板上下文中存在且非空时模板会为 autodoc 指令追加:annotation:选项用于覆盖或补充符号在摘要列表中的展示注解。该变量由conf.py中的AUTOSUMMARY_ANNOTATION_OVERRIDES字典驱动见第三节。三、模板变量的来源AutosummaryRenderer 上下文注入base.rst 中的变量并非凭空产生。Warp 在 conf.py 中通过子类化 Sphinx 的AutosummaryRenderer来注入自定义上下文class AutosummaryRenderer(AutosummaryRenderer): def render(self, template_name, context): context[wp_annotation_override] AUTOSUMMARY_ANNOTATION_OVERRIDES.get(context.get(fullname)) ... return super().render(template_name, context) sphinx.ext.autosummary.generate.AutosummaryRenderer AutosummaryRenderer其中AUTOSUMMARY_ANNOTATION_OVERRIDES定义了需要特殊展示注解的符号AUTOSUMMARY_ANNOTATION_OVERRIDES { warp.config.enable_mempools_at_init: : bool True, warp.config.launch_array_access_mode: ( : warp.config.LaunchArrayAccessMode warp.config.LaunchArrayAccessMode.RELAXED ), warp.config.log_level: : int warp.LOG_INFO, }由此可以看出该机制的使用场景对于warp.config中一批仅靠类型注解无法表达默认值的模块级配置常量通过注解覆盖在文档中直接显示其默认值如bool True、枚举成员RELAXED、LOG_INFO等让读者无需跳转源码即可获得完整信息。四、与 class.rst 的协同类成员的Methods / Attributes汇总当objtype为class时autosummary 会改用 class.rst 模板。该模板在 base.rst 的思路上进一步扩展class.rst.. autoclass:: {{ objname }} {% block methods %} {%- set documented_methods [] %} {%- for item in methods if item ! __init__ %} {%- set _ documented_methods.append(item) %} {%- endfor %} {% if documented_methods %} .. rubric:: {{ _(Methods) }} ... {% endif %} {% endblock %}其设计要点包括排除__init__循环中显式过滤掉item ! __init__。正如 conf.py 注释所说明的对动态生成的 ctypes 类型vec/mat/quat 等渲染__init__的automethod会解析失败因此模板层直接规避~{{ name }}.{{ item }}使用~前缀让汇总表只显示成员短名配合currentmodule保持可点击rubric 分节分别输出Methods与Attributes两个小标题形成与 Warp 官方文档一致的类成员布局。五、内置函数特例builtins.rst 与 wp_builtin_tags 扩展Warp 内置的数百个内核函数warp.abs、warp.dot、warp.launch等具有多重重载、可导性标记等特殊属性普通 autosummary 模板无法表达。为此 Warp 提供了专用模板 builtins.rst通过:template: builtins.rst选项在生成阶段绑定见 generate_reference.py 中module_name BUILTINS_MODULE时追加:template:选项的逻辑.. function:: {{ fullname }}({{ overload.args }}) - {{ overload.return_type }} :noindex: .. wp-builtin-tags:: :kernel: true :python: {{ true if overload.is_exported else false }} :differentiable: {{ true if overload.is_differentiable else false }}该模板依赖conf.py的_get_builtin_overloads_info()预处理遍历warp._src.context.builtin_functions中的每个符号过滤隐藏重载、按input_types渲染参数注解与默认值_with_defaults、求值返回类型最终把wp_display_name与wp_overloads注入模板上下文。模板中的.. wp-builtin-tags::指令由 Warp 自研 Sphinx 扩展 wp_builtin_tags.py 实现。该扩展将kernel、python、differentiable三个布尔标签渲染为带data-wp-tag/data-wp-value属性的 HTML 列表wp_builtin_tags.py未成立的属性使用visually-hidden类保留在 DOM 中使屏幕阅读器与文档提取工具仍能获取完整属性信息在 text 输出中则合并为label: true/false文本。同时该扩展显式声明parallel_read_safe与parallel_write_safe以兼容 Sphinx 的并行构建。六、实战在 Warp 中定制 API 文档输出基于以上机制你可以从四个层面定制 Warp 的 API 文档1. 新增自定义 autosummary 模板在docs/_templates/下新建.rst模板然后在任意 autosummary 指令上通过:template:指定例如generate_reference.py对内置函数模块的处理方式generate_reference.py。模板内可访问fullname、module、objname、objtype、name、members、attributes等 Sphinx 注入的上下文变量以及 Warp 通过AutosummaryRenderer.render()注入的自定义变量。2. 追加注解覆盖规则向conf.py的AUTOSUMMARY_ANNOTATION_OVERRIDES字典增加条目即可让 base.rst 输出:annotation:选项。注意render()是以context.get(fullname)精确匹配的键必须写完整的限定名。3. 调整 stub 文件名conf.py中的autosummary_filename_mapconf.py负责将符号映射到唯一文件名以规避大小写不敏感文件系统的冲突例如warp.pi与warp.PI、warp.kernel与warp.kernel_decorator。内置函数还通过循环将内部路径warp._src.lang.func统一改写为公开路径warp.func保证最终 URL 使用公开 API 命名。4. 控制构建行为文档构建入口为 build_docs.py常用命令如下# 构建 HTML 文档默认动作 python build_docs.py --html # 同时运行文档内嵌的 doctest 代码块 python build_docs.py --html --doctest # CI 严格模式将 Sphinx 警告视为错误 python build_docs.py --warnings-as-errors --verbose构建前需要保证warp可导入否则 conf.py 会在导入阶段报错依赖说明见 conf.py 与 build_docs.py 中的提示pip install warp-lang[docs]。build_docs.py还会在构建前通过export_stubs重新生成warp/__init__.pyi类型桩build_docs.py并经 ruff 格式化以保持与 IDE 提示一致。stub 页面默认输出到各.rst文件旁的_generated/子目录TOCTREE_DIR _generated见 generate_reference.py该目录被 git 忽略。七、构建链路与质量保障综合来看Warp API 文档的完整渲染链路是generate_reference.pybuilder-inited 钩子触发扫描符号生成模块 .rst → sphinx.ext.autosummary解析 .. autosummary:: 指令 → AutosummaryRenderer.render()注入 wp_annotation_override / wp_overloads → base.rst / class.rst / builtins.rstJinja2 渲染 stub 页面 → autodoc读取 docstring 并展开 auto* 指令 → HTML / doctest 输出该流水线还配套了多项质量保障机制均可在 conf.py 中找到证据nitpicky True启用严格交叉引用检查配合nitpick_ignore_regex屏蔽 Warp 动态类型ctypes 几何类型、内部_src路径、mock 依赖等造成的预期内告警conf.py多级文本规范化钩子autodoc-process-docstring过滤 Python 内置类型继承的 docstring、把文档中的wp.别名改写为可解析的warp.doctree-resolved阶段统一替换内部模块路径并剥离对象内存地址保证 HTML 输出跨构建字节稳定conf.pymissing-reference处理resolve_wp_aliases与resolve_public_builtin_aliases在引用解析阶段把wp.*目标重写为warp.*并把公开warp.builtin引用重定向到内部模板生成的文档conf.pyautosummary_generate True语义下的自动 stub 生成正如 generate_reference.py 文档字符串所说明的autosummary 会在构建时自动为清单中的每个符号创建 stub 页面开发者无需手工维护数百个 API 文件。总结base.rst虽只有 7 行却是 Warp 整个 API 参考手册的渲染引擎。它通过fullname / module / objtype / objname四个 Jinja2 变量实现了一个模板渲染所有符号类型的通用能力通过wp_annotation_override这一自定义注入变量打通了与 conf.py 配置层的协作并与 class.rst、builtins.rst 及 wp_builtin_tags.py 扩展共同构成了 Warp 文档的模板体系。理解了这套机制你既可以为 Warp 贡献新的文档定制也可以将其迁移到自己的 Sphinx 项目中为大规模 Python 框架构建同样高效、可维护的 API 文档流水线。【免费下载链接】warpA Python framework for GPU-accelerated simulation, robotics, and machine learning.项目地址: https://gitcode.com/GitHub_Trending/warp/warp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Warp 文档自动化定制指南：深入 Sphinx autosummary 模板 base.rst 的原理与实战
Warp 文档自动化定制指南深入 Sphinx autosummary 模板 base.rst 的原理与实战【免费下载链接】warpA Python framework for GPU-accelerated simulation, robotics, and machine learning.项目地址: https://gitcode.com/GitHub_Trending/warp/warp本篇技术指南围绕 NVIDIA WarpGPU 加速的仿真、机器人与机器学习 Python 框架文档系统中用于生成 API 参考手册的 Sphinx autosummary 基础模板 base.rst 展开。通过阅读本文你将理解 Warp 数百个公开 API 符号是如何被批量渲染为独立文档页面的掌握 Jinja2 模板变量fullname、module、objtype、objname与wp_annotation_override自定义注解机制的运作方式并学会如何在 Warp 的文档构建流水线中定制自己的 autosummary 模板与注解覆盖规则。一、base.rst 在 Warp 文档体系中的定位Warp 的文档并非手写数百个 API 页面而是通过一条生成 模板渲染的自动化流水线构建的脚本 generate_reference.py 在构建开始时扫描warp包及其子模块的公开符号为每个模块生成一份浓缩的.rst清单如 warp.rst、builtins.rst清单内使用.. autosummary::指令列出符号Sphinx 的sphinx.ext.autosummary扩展遇到这些指令后为每个符号渲染一个独立的 stub 页面每个 stub 页面的排版由docs/_templates/下的模板决定——其中对绝大多数符号生效的就是本篇文章的主角base.rst。该目录下共存放两类 autosummary 模板见 docs/_templates/autosummary/模板文件作用范围base.rst默认通用模板覆盖函数、类、数据等所有autosummary符号的 stub 页面class.rst专用于类符号额外生成Methods / Attributes成员汇总表builtins.rst专用于warp._src.lang内置函数渲染多重重载签名与属性标签由:template:选项指定base.rst 全文仅有 7 行却承担了整个 Warp API 参考手册最核心的渲染职责是一份小而精的模板范本。二、逐行拆解 base.rst 模板模板全文如下docs/_templates/autosummary/base.rst{{ fullname | escape | underline }} .. currentmodule:: {{ module }} .. auto{{ objtype }}:: {{ objname }}{% if wp_annotation_override %} :annotation: {{ wp_annotation_override }} {% endif %}2.1 页面标题{{ fullname | escape | underline }}fullname符号的完整限定名例如warp.array、warp.launch、warp.fem.Quad。Sphinx 在渲染 stub 页面时会将该变量注入模板上下文| escapeJinja2 过滤器对可能包含特殊字符的符号名做转义避免破坏 reStructuredText 语法| underlineSphinx autosummary 提供的 Jinja2 过滤器根据标题文本长度生成匹配的 RST 下划线等使该行成为合法的文档章节标题。2.2 模块上下文.. currentmodule:: {{ module }}module是符号所属模块的完整导入路径。该指令将后续所有:class:、:func:等交叉引用的解析基准设置为当前模块保证 stub 页内相对简写的引用能够被正确解析到 Warp 的真实模块上。例如在warp._src.lang下内置函数的内部路径会被统一改写为公开的warp.*路径见后文第六节。2.3 动态指令.. auto{{ objtype }}:: {{ objname }}这是 base.rst 的核心机制——利用 Jinja2 的插值动态生成 autodoc 指令objtype符号类型Sphinx autosummary 支持class、function、data、method、attribute、module等取值。模板渲染时它会被替换成对应的.. autoclass::、.. autofunction::、.. autodata::指令objname符号的短名称不含模块前缀。也就是说一个模板同时承担了类、函数、常量等所有符号类型的渲染这正是 base.rst 能够以 7 行代码覆盖 Warp 全部公开 API 的原因。autodoc 随后会读取该符号的 docstring并结合 conf.py 中的autodoc_default_options展开成员文档autodoc_default_options { members: True, # 包含所有公开成员 member-order: bysource, # 按源码定义顺序排列成员 undoc-members: False, # 跳过没有 docstring 的成员 exclude-members: __weakref__, autosummary: True, # 为类成员生成汇总表 }同时autoclass_content bothconf.py会把__init__的 docstring 合并进类描述——因为许多 Warp 类如warp.array、warp.Mesh、warp.fem几何类型把构造参数文档写在__init__上而class.rst模板有意省略.. automethod:: __init__因此该配置正是这些构造参数能出现在渲染文档中的关键。2.4 自定义注解wp_annotation_override与:annotation:wp_annotation_override是 Warp 文档工程为 base.rst 注入的自定义上下文变量。当它在模板上下文中存在且非空时模板会为 autodoc 指令追加:annotation:选项用于覆盖或补充符号在摘要列表中的展示注解。该变量由conf.py中的AUTOSUMMARY_ANNOTATION_OVERRIDES字典驱动见第三节。三、模板变量的来源AutosummaryRenderer 上下文注入base.rst 中的变量并非凭空产生。Warp 在 conf.py 中通过子类化 Sphinx 的AutosummaryRenderer来注入自定义上下文class AutosummaryRenderer(AutosummaryRenderer): def render(self, template_name, context): context[wp_annotation_override] AUTOSUMMARY_ANNOTATION_OVERRIDES.get(context.get(fullname)) ... return super().render(template_name, context) sphinx.ext.autosummary.generate.AutosummaryRenderer AutosummaryRenderer其中AUTOSUMMARY_ANNOTATION_OVERRIDES定义了需要特殊展示注解的符号AUTOSUMMARY_ANNOTATION_OVERRIDES { warp.config.enable_mempools_at_init: : bool True, warp.config.launch_array_access_mode: ( : warp.config.LaunchArrayAccessMode warp.config.LaunchArrayAccessMode.RELAXED ), warp.config.log_level: : int warp.LOG_INFO, }由此可以看出该机制的使用场景对于warp.config中一批仅靠类型注解无法表达默认值的模块级配置常量通过注解覆盖在文档中直接显示其默认值如bool True、枚举成员RELAXED、LOG_INFO等让读者无需跳转源码即可获得完整信息。四、与 class.rst 的协同类成员的Methods / Attributes汇总当objtype为class时autosummary 会改用 class.rst 模板。该模板在 base.rst 的思路上进一步扩展class.rst.. autoclass:: {{ objname }} {% block methods %} {%- set documented_methods [] %} {%- for item in methods if item ! __init__ %} {%- set _ documented_methods.append(item) %} {%- endfor %} {% if documented_methods %} .. rubric:: {{ _(Methods) }} ... {% endif %} {% endblock %}其设计要点包括排除__init__循环中显式过滤掉item ! __init__。正如 conf.py 注释所说明的对动态生成的 ctypes 类型vec/mat/quat 等渲染__init__的automethod会解析失败因此模板层直接规避~{{ name }}.{{ item }}使用~前缀让汇总表只显示成员短名配合currentmodule保持可点击rubric 分节分别输出Methods与Attributes两个小标题形成与 Warp 官方文档一致的类成员布局。五、内置函数特例builtins.rst 与 wp_builtin_tags 扩展Warp 内置的数百个内核函数warp.abs、warp.dot、warp.launch等具有多重重载、可导性标记等特殊属性普通 autosummary 模板无法表达。为此 Warp 提供了专用模板 builtins.rst通过:template: builtins.rst选项在生成阶段绑定见 generate_reference.py 中module_name BUILTINS_MODULE时追加:template:选项的逻辑.. function:: {{ fullname }}({{ overload.args }}) - {{ overload.return_type }} :noindex: .. wp-builtin-tags:: :kernel: true :python: {{ true if overload.is_exported else false }} :differentiable: {{ true if overload.is_differentiable else false }}该模板依赖conf.py的_get_builtin_overloads_info()预处理遍历warp._src.context.builtin_functions中的每个符号过滤隐藏重载、按input_types渲染参数注解与默认值_with_defaults、求值返回类型最终把wp_display_name与wp_overloads注入模板上下文。模板中的.. wp-builtin-tags::指令由 Warp 自研 Sphinx 扩展 wp_builtin_tags.py 实现。该扩展将kernel、python、differentiable三个布尔标签渲染为带data-wp-tag/data-wp-value属性的 HTML 列表wp_builtin_tags.py未成立的属性使用visually-hidden类保留在 DOM 中使屏幕阅读器与文档提取工具仍能获取完整属性信息在 text 输出中则合并为label: true/false文本。同时该扩展显式声明parallel_read_safe与parallel_write_safe以兼容 Sphinx 的并行构建。六、实战在 Warp 中定制 API 文档输出基于以上机制你可以从四个层面定制 Warp 的 API 文档1. 新增自定义 autosummary 模板在docs/_templates/下新建.rst模板然后在任意 autosummary 指令上通过:template:指定例如generate_reference.py对内置函数模块的处理方式generate_reference.py。模板内可访问fullname、module、objname、objtype、name、members、attributes等 Sphinx 注入的上下文变量以及 Warp 通过AutosummaryRenderer.render()注入的自定义变量。2. 追加注解覆盖规则向conf.py的AUTOSUMMARY_ANNOTATION_OVERRIDES字典增加条目即可让 base.rst 输出:annotation:选项。注意render()是以context.get(fullname)精确匹配的键必须写完整的限定名。3. 调整 stub 文件名conf.py中的autosummary_filename_mapconf.py负责将符号映射到唯一文件名以规避大小写不敏感文件系统的冲突例如warp.pi与warp.PI、warp.kernel与warp.kernel_decorator。内置函数还通过循环将内部路径warp._src.lang.func统一改写为公开路径warp.func保证最终 URL 使用公开 API 命名。4. 控制构建行为文档构建入口为 build_docs.py常用命令如下# 构建 HTML 文档默认动作 python build_docs.py --html # 同时运行文档内嵌的 doctest 代码块 python build_docs.py --html --doctest # CI 严格模式将 Sphinx 警告视为错误 python build_docs.py --warnings-as-errors --verbose构建前需要保证warp可导入否则 conf.py 会在导入阶段报错依赖说明见 conf.py 与 build_docs.py 中的提示pip install warp-lang[docs]。build_docs.py还会在构建前通过export_stubs重新生成warp/__init__.pyi类型桩build_docs.py并经 ruff 格式化以保持与 IDE 提示一致。stub 页面默认输出到各.rst文件旁的_generated/子目录TOCTREE_DIR _generated见 generate_reference.py该目录被 git 忽略。七、构建链路与质量保障综合来看Warp API 文档的完整渲染链路是generate_reference.pybuilder-inited 钩子触发扫描符号生成模块 .rst → sphinx.ext.autosummary解析 .. autosummary:: 指令 → AutosummaryRenderer.render()注入 wp_annotation_override / wp_overloads → base.rst / class.rst / builtins.rstJinja2 渲染 stub 页面 → autodoc读取 docstring 并展开 auto* 指令 → HTML / doctest 输出该流水线还配套了多项质量保障机制均可在 conf.py 中找到证据nitpicky True启用严格交叉引用检查配合nitpick_ignore_regex屏蔽 Warp 动态类型ctypes 几何类型、内部_src路径、mock 依赖等造成的预期内告警conf.py多级文本规范化钩子autodoc-process-docstring过滤 Python 内置类型继承的 docstring、把文档中的wp.别名改写为可解析的warp.doctree-resolved阶段统一替换内部模块路径并剥离对象内存地址保证 HTML 输出跨构建字节稳定conf.pymissing-reference处理resolve_wp_aliases与resolve_public_builtin_aliases在引用解析阶段把wp.*目标重写为warp.*并把公开warp.builtin引用重定向到内部模板生成的文档conf.pyautosummary_generate True语义下的自动 stub 生成正如 generate_reference.py 文档字符串所说明的autosummary 会在构建时自动为清单中的每个符号创建 stub 页面开发者无需手工维护数百个 API 文件。总结base.rst虽只有 7 行却是 Warp 整个 API 参考手册的渲染引擎。它通过fullname / module / objtype / objname四个 Jinja2 变量实现了一个模板渲染所有符号类型的通用能力通过wp_annotation_override这一自定义注入变量打通了与 conf.py 配置层的协作并与 class.rst、builtins.rst 及 wp_builtin_tags.py 扩展共同构成了 Warp 文档的模板体系。理解了这套机制你既可以为 Warp 贡献新的文档定制也可以将其迁移到自己的 Sphinx 项目中为大规模 Python 框架构建同样高效、可维护的 API 文档流水线。【免费下载链接】warpA Python framework for GPU-accelerated simulation, robotics, and machine learning.项目地址: https://gitcode.com/GitHub_Trending/warp/warp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考