TensorZero 配置系统深度解析快照持久化、字段弃用与历史兼容性保障【免费下载链接】tensorzeroTensorZero is an open-source LLMOps platform that unifies an LLM gateway, observability, evaluation, optimization, and experimentation.项目地址: https://gitcode.com/GitHub_Trending/te/tensorzero导读本文聚焦 TensorZero 开源 LLMOps 平台中配置系统的核心工程挑战配置快照Config Snapshot必须被持久化到数据库、并在未来任意时刻都能被成功反序列化。围绕这一约束TensorZero 在crates/tensorzero-core/src/config目录中建立了一整套双轨兼容机制——弃用deprecate一个配置字段时既要保证从 TOML 加载的新配置能正确告警又要保证从数据库加载的历史快照永不失败。读完本文你将掌握 TensorZero 配置字段的生命周期管理规范、StoredConfig与UninitializedConfig两套类型的职责划分以及如何编写历史快照测试来守护长期运行系统的配置兼容性。为什么配置快照必须永远可反序列化TensorZero 的配置系统并非一次性读取 TOML 文件后就完事。根据 config/snapshot/README.md 的说明该目录存放的是完整 TensorZero 配置的静态快照static snapshots of the full TensorZero config用于历史推理回放historical inference replay。这意味着每当一次推理发生时当时生效的完整配置会被冻结成一个快照存入数据库。当你在 UI 或 API 上回溯一条历史 inference、查看它当时用了什么模型、什么 variant、什么参数时系统需要把这个快照重新加载出来。由于推理数据会长期保留任何旧版本写入的快照都必须能被当前版本以及未来版本的代码成功解析——否则历史数据就变成不可读的死数据。这正是配置弃用deprecation之所以棘手的根源弃用一个字段本质上是对数据格式的一次变更而存储的数据不会因为代码升级而自动重写。TensorZero 因此规定了严格的弃用纪律下文展开。弃用配置字段的双轨策略config/AGENTS.md 明确要求当弃用一个配置字段时必须同时处理两条路径Fresh configs从 TOML 文件新加载的配置Stored snapshots从数据库加载的已存储快照。这两条路径对弃用字段的容忍度完全不同路径数据来源对弃用字段的处理Fresh config开发者手写的tensorzero.toml可以给出弃用警告甚至对新旧字段同时设置的情况报错Stored snapshot数据库中的历史快照必须静默兼容绝不能因为字段已弃用而解析失败为什么两条路径不能混为一谈如果弃用警告逻辑在加载快照时也执行会出现两个问题误报噪音历史快照里几乎必然包含当时合法、如今已弃用的字段用户每次回放历史数据都会看到一堆过时警告升级即破坏如果快照加载路径对新版本代码严格校验未知字段那么当 Gateway 先升级写入新格式快照、后又回滚到旧版本时旧版本会因遇到不认识的字段而反序列化失败。因此 TensorZero 在架构上就把这两条路径彻底分开让警告只作用于新鲜配置让快照路径永远宽容。弃用警告机制UninitializedConfig::warn_on_deprecations()弃用警告的入口位于crates/tensorzero-core/src/config/mod.rs的UninitializedConfig::warn_on_deprecations()pub(crate) fn warn_on_deprecations(mut self) - Result(), Error { self.resolve_clickhouse_config_deprecation()?; self.warn_variant_weight_deprecation(); self.warn_evaluation_evaluators_deprecation(); self.warn_gepa_evaluation_name_deprecation()?; Ok(()) }该方法的文档注释明确了两条原则只负责校验与告警不负责迁移值This does NOT migrate values from old fields to new ones。值的迁移由FromStored*Config实现针对快照和消费方针对 TOML 配置各自完成只对新鲜配置运行which only runs for fresh configs so snapshot users wont see spurious warnings——快照用户不会看到虚假警告。真实弃用案例一ClickHouse 配置迁移resolve_clickhouse_config_deprecation()展示了弃用警告 冲突报错的完整模式见 mod.rsfn resolve_clickhouse_config_deprecation(mut self) - Result(), Error { let old self.gateway.as_ref() .and_then(|g| g.observability.as_ref()) .and_then(|o| o.disable_automatic_migrations); let new self.clickhouse.as_ref() .and_then(|c| c.disable_automatic_migrations); // 新旧字段同时设置 - 直接报错强制用户清理 if old Some(true) new Some(true) { return Err(Error::new(ErrorDetails::Config { message: disable_automatic_migrations is set in both [clickhouse] and [gateway.observability]. Remove it from [gateway.observability]..to_string(), })); } // 仅旧字段被设置 - 输出弃用警告 if old Some(true) { deprecation_warning( gateway.observability.disable_automatic_migrations is deprecated. Use clickhouse.disable_automatic_migrations instead., ); } Ok(()) }这个案例展示了两种处理粒度冲突时用 Error 阻止启动避免新旧配置并存导致行为不确定单边使用旧字段时仅打警告给用户迁移缓冲期。真实弃用案例二Variant 权重字段warn_variant_weight_deprecation()mod.rs遍历所有 chat / json 类型函数的 variants若发现仍在使用weight字段则输出警告并列出受影响函数名提示改用[functions.name.experimentation]区块deprecation_warning(format!( The weight field on variants is deprecated and will be removed in a future release (2026.6). \ Use the [functions.name.experimentation] section instead. \ Affected functions: {}, functions_with_weight.join(, ) ));注意这里给出的废弃时间线2026.6说明 TensorZero 的弃用策略是先警告、后移除给用户明确的迁移窗口。类似的还有顶层evaluations区块迁移到[functions.name.evaluators]warn_evaluation_evaluators_deprecation以及 GEPA 优化器evaluation_name的迁移warn_gepa_evaluation_name_deprecation。Stored*Config类型的设计原则快照兼容性的根基是crates/tensorzero-core/src/config/snapshot目录中的Stored*Config类型族。snapshot/AGENTS.md 给出了第一条铁律Stored*Config类型禁止使用#[serde(deny_unknown_fields)]。原因是回滚场景如果新版 Gateway 写入了带新字段的快照随后应用回滚到旧版本旧版本的严格反序列化会因未知字段直接失败。去掉deny_unknown_fields后旧版本会忽略它不认识的字段从而保住兼容性。顶层StoredConfig的字段结构在 snapshot/mod.rs 中顶层StoredConfig的字段注释详细解释了策略字段子树可能演化的部分使用独立的Stored*包装类型如StoredGatewayConfig、StoredEmbeddingModelConfig、StoredObservabilityConfig、StoredCacheConfig、StoredOptimizerInfo其余字段直接复用Uninitialized*类型如models、functions、metrics、tools这些部分的形状被认定为稳定结构体末尾还专门留了一条注释// The following names should **not** be reused: - evaluators保护字段命名空间——evaluators这个名字已被历史版本占用过未来新增字段时不得复用避免与新格式冲突。同时每个字段都标注#[serde(default)]保证旧快照缺失该字段时能优雅地填充默认值。双向转换的编译期安全网StoredConfig与UninitializedConfig之间的转换snapshot/mod.rs采用了显式解构explicit destructuringimpl FromUninitializedConfig for StoredConfig { fn from(config: UninitializedConfig) - Self { let UninitializedConfig { gateway, clickhouse, postgres, ... } config; // ... } }正如模块头注释snapshot/mod.rs所强调的The From implementations use explicit destructuring to ensure compile-time errors when fields are added or removed from either the stored or uninitialized types。这意味着只要任何一侧新增或删除字段编译器就会立刻报错迫使开发者意识到这里有一对转换需要同步更新避免用..Default::default()之类的写法悄悄吞掉字段变更把兼容性问题推迟到运行时。历史快照测试守护数据库中的旧数据config/AGENTS.md 要求的第二项配套工作是在快照模块中新增历史测试每当配置形状发生变化增删改字段、重命名或重构就要写一个测试把旧版本的配置 TOML 解析为StoredConfig再转换为UninitializedConfig并断言转换后的值正确。这样能保证已经持久化在数据库中的旧快照在改动之后依然可加载、且语义不变。测试案例一顶层 evaluators 的静默兼容test_historical_stored_config_with_top_level_evaluatorssnapshot/mod.rs验证历史上合法的顶层[evaluators]区块在新版本中应当静默忽略而非报错#[test] fn test_historical_stored_config_with_top_level_evaluators() { let toml_str r# [evaluators.exact_match] type exact_match #; let stored: StoredConfig toml::from_str(toml_str).expect(old config with top-level evaluators should parse); let _uninit: UninitializedConfig stored .try_into() .expect(should convert to UninitializedConfig); }测试案例二OTLP traces 新增字段的向前兼容test_historical_stored_otlp_traces_without_include_contentsnapshot/mod.rs验证在include_content字段被引入之前写入的快照加载后该字段应为None且配置完整可用let toml_str r# [gateway.export.otlp.traces] enabled true format opentelemetry #; let stored: StoredConfig toml::from_str(toml_str).expect(legacy OTLP traces config should parse from snapshot); let uninit: UninitializedConfig stored .try_into() .expect(should convert to UninitializedConfig); let traces uninit.gateway.as_ref() .and_then(|g| g.export.as_ref()) .and_then(|e| e.otlp.as_ref()) .and_then(|o| o.traces.as_ref()) .expect(traces config should be present); assert_eq!(traces.enabled, Some(true)); assert!(traces.include_content.is_none());测试案例三GEPA 优化器字段重命名test_historical_stored_gepa_optimizer_with_evaluation_namesnapshot/mod.rs验证旧字段evaluation_name的语义在新结构evaluator_names下被正确保留let toml_str r# [optimizers.test_gepa] type gepa function_name basic_test evaluation_name test_evaluation analysis_model openai::gpt-4.1-mini mutation_model openai::gpt-4.1-mini #; // ... assert_eq!(gepa.evaluation_name.as_deref(), Some(test_evaluation)); assert!(gepa.evaluator_names.is_none());此外snapshot/observability_config.rs 中还有test_historical_no_write_queue_capacity、test_historical_no_async_writes_defaults_to_disabled等测试专门验证旧快照缺少某字段时默认值行为正确。整个快照模块还配套了 snapshot/fixtures/ 目录如kitchen_sink.toml、empty.toml、multi_variant_types.toml用于验证跨区块交互时的规范化与往返一致性。明确不写往返测试snapshot/AGENTS.md 还特别规定不要添加 round-trip 测试即先序列化再反序列化再比较。理由是这类测试无法捕获真实的兼容性 bug只会增加噪音。历史测试的价值在于锚定旧输入 - 新代码这个真实的生产场景而不是自证自洽。弃用一个配置字段的完整操作清单综合 config/AGENTS.md 与 snapshot/AGENTS.md 两份规范弃用一个字段的标准工作流如下更新Uninitialized*类型将字段从新鲜配置的解析类型中移除或标为弃用新鲜配置将不再接受或开始警告保留Stored*类型中的字段确保数据库中已存在的快照仍能反序列化实现迁移逻辑在FromStored*Config for UninitializedConfig中把旧字段的值迁移到新结构值的迁移只在这里发生添加弃用警告在UninitializedConfig::warn_on_deprecations()中新增警告逻辑仅影响新鲜配置若新旧字段同时出现则考虑直接报错新增历史快照测试在 snapshot/mod.rs 中添加test_historical_*测试用包含旧字段的 TOML 字符串走通StoredConfig反序列化 -UninitializedConfig转换 - 值断言全流程不要写往返测试避免无效噪音。这套流程的精髓在于新鲜配置走严格警告路径帮助用户平滑迁移历史快照走宽容迁移路径保证数据永不失效两条路径由StoredConfig与UninitializedConfig的类型边界严格隔离并由显式解构的From/TryFrom实现提供编译期保障。相关文件索引弃用规范总纲crates/tensorzero-core/src/config/AGENTS.md快照类型设计规范crates/tensorzero-core/src/config/snapshot/AGENTS.md快照类型实现StoredConfig与转换crates/tensorzero-core/src/config/snapshot/mod.rs弃用警告实现warn_on_deprecationscrates/tensorzero-core/src/config/mod.rs快照测试夹具含完整配置示例crates/tensorzero-core/src/config/snapshot/fixtures/kitchen_sink.toml快照目录说明crates/tensorzero-core/src/config/snapshot/README.md【免费下载链接】tensorzeroTensorZero is an open-source LLMOps platform that unifies an LLM gateway, observability, evaluation, optimization, and experimentation.项目地址: https://gitcode.com/GitHub_Trending/te/tensorzero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/15 17:41:37 · 阅读 1.2k TensorZero 配置系统深度解析：快照持久化、字段弃用与历史兼容性保障
TensorZero 配置系统深度解析快照持久化、字段弃用与历史兼容性保障【免费下载链接】tensorzeroTensorZero is an open-source LLMOps platform that unifies an LLM gateway, observability, evaluation, optimization, and experimentation.项目地址: https://gitcode.com/GitHub_Trending/te/tensorzero导读本文聚焦 TensorZero 开源 LLMOps 平台中配置系统的核心工程挑战配置快照Config Snapshot必须被持久化到数据库、并在未来任意时刻都能被成功反序列化。围绕这一约束TensorZero 在crates/tensorzero-core/src/config目录中建立了一整套双轨兼容机制——弃用deprecate一个配置字段时既要保证从 TOML 加载的新配置能正确告警又要保证从数据库加载的历史快照永不失败。读完本文你将掌握 TensorZero 配置字段的生命周期管理规范、StoredConfig与UninitializedConfig两套类型的职责划分以及如何编写历史快照测试来守护长期运行系统的配置兼容性。为什么配置快照必须永远可反序列化TensorZero 的配置系统并非一次性读取 TOML 文件后就完事。根据 config/snapshot/README.md 的说明该目录存放的是完整 TensorZero 配置的静态快照static snapshots of the full TensorZero config用于历史推理回放historical inference replay。这意味着每当一次推理发生时当时生效的完整配置会被冻结成一个快照存入数据库。当你在 UI 或 API 上回溯一条历史 inference、查看它当时用了什么模型、什么 variant、什么参数时系统需要把这个快照重新加载出来。由于推理数据会长期保留任何旧版本写入的快照都必须能被当前版本以及未来版本的代码成功解析——否则历史数据就变成不可读的死数据。这正是配置弃用deprecation之所以棘手的根源弃用一个字段本质上是对数据格式的一次变更而存储的数据不会因为代码升级而自动重写。TensorZero 因此规定了严格的弃用纪律下文展开。弃用配置字段的双轨策略config/AGENTS.md 明确要求当弃用一个配置字段时必须同时处理两条路径Fresh configs从 TOML 文件新加载的配置Stored snapshots从数据库加载的已存储快照。这两条路径对弃用字段的容忍度完全不同路径数据来源对弃用字段的处理Fresh config开发者手写的tensorzero.toml可以给出弃用警告甚至对新旧字段同时设置的情况报错Stored snapshot数据库中的历史快照必须静默兼容绝不能因为字段已弃用而解析失败为什么两条路径不能混为一谈如果弃用警告逻辑在加载快照时也执行会出现两个问题误报噪音历史快照里几乎必然包含当时合法、如今已弃用的字段用户每次回放历史数据都会看到一堆过时警告升级即破坏如果快照加载路径对新版本代码严格校验未知字段那么当 Gateway 先升级写入新格式快照、后又回滚到旧版本时旧版本会因遇到不认识的字段而反序列化失败。因此 TensorZero 在架构上就把这两条路径彻底分开让警告只作用于新鲜配置让快照路径永远宽容。弃用警告机制UninitializedConfig::warn_on_deprecations()弃用警告的入口位于crates/tensorzero-core/src/config/mod.rs的UninitializedConfig::warn_on_deprecations()pub(crate) fn warn_on_deprecations(mut self) - Result(), Error { self.resolve_clickhouse_config_deprecation()?; self.warn_variant_weight_deprecation(); self.warn_evaluation_evaluators_deprecation(); self.warn_gepa_evaluation_name_deprecation()?; Ok(()) }该方法的文档注释明确了两条原则只负责校验与告警不负责迁移值This does NOT migrate values from old fields to new ones。值的迁移由FromStored*Config实现针对快照和消费方针对 TOML 配置各自完成只对新鲜配置运行which only runs for fresh configs so snapshot users wont see spurious warnings——快照用户不会看到虚假警告。真实弃用案例一ClickHouse 配置迁移resolve_clickhouse_config_deprecation()展示了弃用警告 冲突报错的完整模式见 mod.rsfn resolve_clickhouse_config_deprecation(mut self) - Result(), Error { let old self.gateway.as_ref() .and_then(|g| g.observability.as_ref()) .and_then(|o| o.disable_automatic_migrations); let new self.clickhouse.as_ref() .and_then(|c| c.disable_automatic_migrations); // 新旧字段同时设置 - 直接报错强制用户清理 if old Some(true) new Some(true) { return Err(Error::new(ErrorDetails::Config { message: disable_automatic_migrations is set in both [clickhouse] and [gateway.observability]. Remove it from [gateway.observability]..to_string(), })); } // 仅旧字段被设置 - 输出弃用警告 if old Some(true) { deprecation_warning( gateway.observability.disable_automatic_migrations is deprecated. Use clickhouse.disable_automatic_migrations instead., ); } Ok(()) }这个案例展示了两种处理粒度冲突时用 Error 阻止启动避免新旧配置并存导致行为不确定单边使用旧字段时仅打警告给用户迁移缓冲期。真实弃用案例二Variant 权重字段warn_variant_weight_deprecation()mod.rs遍历所有 chat / json 类型函数的 variants若发现仍在使用weight字段则输出警告并列出受影响函数名提示改用[functions.name.experimentation]区块deprecation_warning(format!( The weight field on variants is deprecated and will be removed in a future release (2026.6). \ Use the [functions.name.experimentation] section instead. \ Affected functions: {}, functions_with_weight.join(, ) ));注意这里给出的废弃时间线2026.6说明 TensorZero 的弃用策略是先警告、后移除给用户明确的迁移窗口。类似的还有顶层evaluations区块迁移到[functions.name.evaluators]warn_evaluation_evaluators_deprecation以及 GEPA 优化器evaluation_name的迁移warn_gepa_evaluation_name_deprecation。Stored*Config类型的设计原则快照兼容性的根基是crates/tensorzero-core/src/config/snapshot目录中的Stored*Config类型族。snapshot/AGENTS.md 给出了第一条铁律Stored*Config类型禁止使用#[serde(deny_unknown_fields)]。原因是回滚场景如果新版 Gateway 写入了带新字段的快照随后应用回滚到旧版本旧版本的严格反序列化会因未知字段直接失败。去掉deny_unknown_fields后旧版本会忽略它不认识的字段从而保住兼容性。顶层StoredConfig的字段结构在 snapshot/mod.rs 中顶层StoredConfig的字段注释详细解释了策略字段子树可能演化的部分使用独立的Stored*包装类型如StoredGatewayConfig、StoredEmbeddingModelConfig、StoredObservabilityConfig、StoredCacheConfig、StoredOptimizerInfo其余字段直接复用Uninitialized*类型如models、functions、metrics、tools这些部分的形状被认定为稳定结构体末尾还专门留了一条注释// The following names should **not** be reused: - evaluators保护字段命名空间——evaluators这个名字已被历史版本占用过未来新增字段时不得复用避免与新格式冲突。同时每个字段都标注#[serde(default)]保证旧快照缺失该字段时能优雅地填充默认值。双向转换的编译期安全网StoredConfig与UninitializedConfig之间的转换snapshot/mod.rs采用了显式解构explicit destructuringimpl FromUninitializedConfig for StoredConfig { fn from(config: UninitializedConfig) - Self { let UninitializedConfig { gateway, clickhouse, postgres, ... } config; // ... } }正如模块头注释snapshot/mod.rs所强调的The From implementations use explicit destructuring to ensure compile-time errors when fields are added or removed from either the stored or uninitialized types。这意味着只要任何一侧新增或删除字段编译器就会立刻报错迫使开发者意识到这里有一对转换需要同步更新避免用..Default::default()之类的写法悄悄吞掉字段变更把兼容性问题推迟到运行时。历史快照测试守护数据库中的旧数据config/AGENTS.md 要求的第二项配套工作是在快照模块中新增历史测试每当配置形状发生变化增删改字段、重命名或重构就要写一个测试把旧版本的配置 TOML 解析为StoredConfig再转换为UninitializedConfig并断言转换后的值正确。这样能保证已经持久化在数据库中的旧快照在改动之后依然可加载、且语义不变。测试案例一顶层 evaluators 的静默兼容test_historical_stored_config_with_top_level_evaluatorssnapshot/mod.rs验证历史上合法的顶层[evaluators]区块在新版本中应当静默忽略而非报错#[test] fn test_historical_stored_config_with_top_level_evaluators() { let toml_str r# [evaluators.exact_match] type exact_match #; let stored: StoredConfig toml::from_str(toml_str).expect(old config with top-level evaluators should parse); let _uninit: UninitializedConfig stored .try_into() .expect(should convert to UninitializedConfig); }测试案例二OTLP traces 新增字段的向前兼容test_historical_stored_otlp_traces_without_include_contentsnapshot/mod.rs验证在include_content字段被引入之前写入的快照加载后该字段应为None且配置完整可用let toml_str r# [gateway.export.otlp.traces] enabled true format opentelemetry #; let stored: StoredConfig toml::from_str(toml_str).expect(legacy OTLP traces config should parse from snapshot); let uninit: UninitializedConfig stored .try_into() .expect(should convert to UninitializedConfig); let traces uninit.gateway.as_ref() .and_then(|g| g.export.as_ref()) .and_then(|e| e.otlp.as_ref()) .and_then(|o| o.traces.as_ref()) .expect(traces config should be present); assert_eq!(traces.enabled, Some(true)); assert!(traces.include_content.is_none());测试案例三GEPA 优化器字段重命名test_historical_stored_gepa_optimizer_with_evaluation_namesnapshot/mod.rs验证旧字段evaluation_name的语义在新结构evaluator_names下被正确保留let toml_str r# [optimizers.test_gepa] type gepa function_name basic_test evaluation_name test_evaluation analysis_model openai::gpt-4.1-mini mutation_model openai::gpt-4.1-mini #; // ... assert_eq!(gepa.evaluation_name.as_deref(), Some(test_evaluation)); assert!(gepa.evaluator_names.is_none());此外snapshot/observability_config.rs 中还有test_historical_no_write_queue_capacity、test_historical_no_async_writes_defaults_to_disabled等测试专门验证旧快照缺少某字段时默认值行为正确。整个快照模块还配套了 snapshot/fixtures/ 目录如kitchen_sink.toml、empty.toml、multi_variant_types.toml用于验证跨区块交互时的规范化与往返一致性。明确不写往返测试snapshot/AGENTS.md 还特别规定不要添加 round-trip 测试即先序列化再反序列化再比较。理由是这类测试无法捕获真实的兼容性 bug只会增加噪音。历史测试的价值在于锚定旧输入 - 新代码这个真实的生产场景而不是自证自洽。弃用一个配置字段的完整操作清单综合 config/AGENTS.md 与 snapshot/AGENTS.md 两份规范弃用一个字段的标准工作流如下更新Uninitialized*类型将字段从新鲜配置的解析类型中移除或标为弃用新鲜配置将不再接受或开始警告保留Stored*类型中的字段确保数据库中已存在的快照仍能反序列化实现迁移逻辑在FromStored*Config for UninitializedConfig中把旧字段的值迁移到新结构值的迁移只在这里发生添加弃用警告在UninitializedConfig::warn_on_deprecations()中新增警告逻辑仅影响新鲜配置若新旧字段同时出现则考虑直接报错新增历史快照测试在 snapshot/mod.rs 中添加test_historical_*测试用包含旧字段的 TOML 字符串走通StoredConfig反序列化 -UninitializedConfig转换 - 值断言全流程不要写往返测试避免无效噪音。这套流程的精髓在于新鲜配置走严格警告路径帮助用户平滑迁移历史快照走宽容迁移路径保证数据永不失效两条路径由StoredConfig与UninitializedConfig的类型边界严格隔离并由显式解构的From/TryFrom实现提供编译期保障。相关文件索引弃用规范总纲crates/tensorzero-core/src/config/AGENTS.md快照类型设计规范crates/tensorzero-core/src/config/snapshot/AGENTS.md快照类型实现StoredConfig与转换crates/tensorzero-core/src/config/snapshot/mod.rs弃用警告实现warn_on_deprecationscrates/tensorzero-core/src/config/mod.rs快照测试夹具含完整配置示例crates/tensorzero-core/src/config/snapshot/fixtures/kitchen_sink.toml快照目录说明crates/tensorzero-core/src/config/snapshot/README.md【免费下载链接】tensorzeroTensorZero is an open-source LLMOps platform that unifies an LLM gateway, observability, evaluation, optimization, and experimentation.项目地址: https://gitcode.com/GitHub_Trending/te/tensorzero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考