new-api 俄语翻译术语表本地化术语规范与多语言架构实现解读【免费下载链接】new-apiA unified AI model hub for aggregation distribution. It supports cross-converting various LLMs into OpenAI-compatible, Claude-compatible, or Gemini-compatible formats. A centralized gateway for personal and enterprise model management.项目地址: https://gitcode.com/gh_mirrors/ne/new-api导读本文以 new-api 仓库中的 俄语翻译术语表translation-glossary.ru.md 为核心系统梳理项目面向俄语及多语言本地化贡献者制定的核心术语标准、上下文变体翻译规则与语言特性约束并结合仓库中真实的 i18n 实现后端 go-i18n 消息包、中间件语言探测、前端 i18next展开源码级佐证。读完本文你将掌握 new-api 的术语一致性治理方法、俄语翻译的落地规范以及翻译贡献者如何将术语表与运行时本地化机制衔接。一、术语表的定位让翻译一致而不只是正确翻译技术文档时正确不等于一致。同一个中文术语可能在不同页面、不同开发者口中出现多个俄语译法最终导致用户在管理后台、计费报表、API 错误提示中看到互相矛盾的词汇。new-api 仓库在 docs/translation-glossary.ru.md另有 英文主版 与 法语版中为贡献者预先锁定了关键术语的标准译法其核心目标写在文档开篇Данный раздел предоставляет стандартные переводы ключевой терминологии проекта на русский язык для обеспечения согласованности и точности переводов. 本节为项目关键术语提供标准俄语翻译以确保翻译的一致性与准确性。术语表明确允许的三类翻译策略与软件本地化L10n行业惯例一致保留 Emoji如果原文中出现 Emoji译文中允许保留保留纯技术术语原文中的纯粹技术词汇不做强行意译保留通用英文技术词在俄语技术圈已被广泛使用的英文术语例如 API直接沿用。这一策略保证了译文既贴近俄语母语用户的阅读习惯又不会为了本土化而牺牲技术准确性。从仓库的本地化实现看这种原文优先、宽松允许的思路也体现在消息键的设计上后端将所有可翻译字符串抽象为稳定的消息键如common.invalid_params、token.invalid键名本身即英文语义翻译内容则完全交给各语言文件见 i18n/keys.go。二、本地化运行时架构术语表服务的实际对象在深入术语细节之前先明确术语表与代码的对应关系。new-api 的国际化由独立的i18n包承载消息包初始化i18n/i18n.go 中通过go-i18n库的i18n.NewBundle(language.Chinese)创建 bundle并以go:embed方式把locales/*.yaml三个语言文件zh-CN.yaml、zh-TW.yaml、en.yaml嵌入二进制语言探测中间件 middleware/i18n.go 在每个请求上执行detectLanguage优先级为用户设置已登录时→Accept-Language请求头 → 默认语言翻译入口GetLangFromContexti18n/i18n.go完整实现了四层回退链用户设置 → 按用户 ID 惰性加载 → 上下文语言 →Accept-Language头 → 默认英文消息键常量i18n/keys.go 集中定义全部消息键避免硬编码字符串业务侧调用common.TranslateMessage在 common/gin.go 中作为钩子被i18n.T注入业务代码只传键名与模板数据如{{.Max}}、{{.Prefix}}。值得注意的边界目前SupportedLanguages()返回的是zh-CN、zh-TW、en三种语言i18n/i18n.gonormalizeLang也仅归一化中英文前缀。也就是说俄语术语表当前属于面向贡献者的翻译规范尚未进入运行时语言集合。这恰恰体现了术语表的先导作用先定标准、再行翻译、最后接入locales/*.yaml与SupportedLanguages()即可完成语言上线。翻译贡献者提交俄语翻译时应参照术语表新建locales/ru.yaml并将ru纳入语言探测与支持列表——具体接入点在 i18n/i18n.go 的语言常量和 middleware/i18n.go 的探测逻辑。三、核心概念术语表Core Concepts以下为文档定义的最基础概念贯穿所有界面与计费逻辑中文俄语英语说明倍率КоэффициентRatio/Multiplier用于计算价格的乘数因子。重点在计价场景中始终使用 Коэффициент不要用 Множитель以保证术语一致性令牌ТокенTokenAPI 访问凭证或模型处理的文本单元渠道КаналChannelAPI 提供商的接入通道分组ГруппаGroup用户或令牌的分类额度КвотаQuota用户可用的服务额度其中倍率一词在计价链路中语义关键。从源码看倍率正是价格计算的乘数因子model.Ratio与model.CompletionRatio分别构成模型倍率与补全倍率model/pricing.go而计费表达式引擎pkg/billingexpr在 compile.go 与 run.go 中把这些系数编译为可执行表达式——因此术语表强调计价上下文必须统一为 Коэффициент正是为了避免乘数一词在计费语义中引发歧义。四、模型相关术语Model Related模型域是术语表最密集的部分直接对应relay链路中的输入输出转换与计费参数中文俄语英语说明提示Промпт/ВводPrompt输入给模型的内容补全ВыводCompletion模型的输出内容。重点不得使用 Дополнение 或 Завершение只能使用 Вывод以贴合技术术语输入ВводInput/Prompt发送给模型的内容输出ВыводOutput/Completion模型返回的内容模型倍率Коэффициент моделиModel Ratio不同模型的计费倍率补全倍率Коэффициент выводаCompletion Ratio针对输出内容的额外计费倍率固定价格Цена за запросPrice per call单次调用的固定价格按量计费Оплата по объемуPay-as-you-go基于实际使用量的计费方式按次计费Оплата за запросPay-per-view每次调用固定价格补全倍率在实现中对应 OpenAI 生态的completion_ratio语义当completion_ratio 1时输出 token 按ratio (ratio - 1) * completion_ratio之类的方式叠加计费具体公式见 relay/common/billing.go 与 common/quota_math.go。术语表把补全锁定为 Вывод恰好与输出共用一词也与英文Completion Output/Completion的等价标注形成对照——翻译时注意区分上下文即可这正是下一节上下文变体规则要解决的问题。五、用户管理与充值兑换术语用户管理User Management中文俄语英语说明超级管理员СуперадминистраторRoot User拥有最高权限的管理员管理员АдминистраторAdmin User系统管理员普通用户Обычный пользовательNormal User标准权限用户这三个角色在权限模型中有明确映射RootUser是最初创建的超级管理员AdminUser拥有系统管理权限NormalUser为普通用户。仓库中权限判定分布在 service/authz 目录与 model/authz_role.go术语表为这些角色在管理后台界面的俄语显示提供了统一口径。充值兑换Recharge Redemption中文俄语英语说明充值ПополнениеTop Up为账户增加额度兑换码Код купонаRedemption Code可兑换为额度的代码兑换码在实现中由 model/redemption.go 承载支持批量生成、兑换额度、设置过期时间其相关的错误提示键如redemption.invalid、redemption.used、redemption.expired集中在 i18n/locales/en.yaml。术语表选用 Код купона优惠券代码而非直译的兑换代码是为了让俄语用户更直观理解其兑换抵扣的产品语义。六、渠道管理与安全术语渠道管理Channel Management中文俄语英语说明渠道КаналChannelAPI 提供商通道API 密钥API ключAPI KeyAPI 访问密钥。重点使用 API ключ 而非 API токен。理由术语ключ钥匙更准确表达资源访问功能而токен在语言模型语境中更常与文本单元关联容易与令牌/Токен混淆优先级ПриоритетPriority渠道选择优先级权重ВесWeight负载均衡权重代理ПроксиProxy代理服务器地址模型重定向Перенаправление моделиModel Mapping请求体中模型名称的替换供应商ПоставщикProvider/Vendor服务或 API 的提供方这组术语直接对应 model/channel.go 中Channel模型的关键字段Priority优先级、Weight权重参与负载均衡选择相关逻辑见 service/channel_select.go、Proxy代理地址见 common/proxy_url.go以及ModelMapping请求体模型名替换见 service/convert.go 与 relay/common/override.go。特别注意 API ключ 与 Токен 的区分new-api 中用户的 API 访问凭证在管理界面称为令牌Токен而渠道侧接入上游供应商的凭证称为API 密钥API ключ。术语表刻意用两个不同俄语词区分这两个概念避免俄语用户混淆自己的访问凭证与上游服务商的密钥——这在多语言界面中是一个非常实用的设计。安全相关Security Related中文俄语英语说明两步验证Двухфакторная аутентификацияTwo-Factor Authentication为账户提供的额外安全验证方式2FA2FATwo-Factor Authentication两步验证的缩写两步验证在仓库中由 model/twofa.go、model/twofa_enrollment.go 与 common/totp.go 实现TOTP 时间基一次性密码登录流程要求输入 2FA 码的提示键为user.require_2fa见 i18n/locales/en.yaml。七、上下文变体规则一词多义的翻译决策树术语表最重要的一节是Контекстуальные варианты перевода上下文变体翻译它解决了一词多义问题给出了可执行的决策规则Промпт / Ввод提示 / 输入Промпт用于与 LLM 交互的场景、用户界面文案、描述与模型互动的语境Ввод用于计费、技术文档、描述数据处理过程的语境规则如果谈论的是用户体验和与 AI 的交互 → Промпт如果谈论的是技术流程或计算 → Ввод。ТокенTokenAPI 访问令牌API Token——用户调用网关时出示的凭证模型处理的文本单元Text Token——计费与 token 计数场景系统访问令牌Access Token——系统内部鉴权场景。这三类 Token 在代码中都有对应物前者是sk-开头的用户令牌见 model/token.go 与 service/auth_token.go中者是 service/token_counter.go 统计的计费单元后者是管理接口鉴权用的 Access Token。同一个英文词、三种俄语语境翻译时必须按场景取舍。Квота额度用户的可用服务额度标准译法有时也译作 Кредит信用额度——术语表将其列为允许的变体。八、俄语语言特性与翻译约束术语表单独列出了俄语翻译必须注意的语言学特性这些要求在代码的 i18n 框架中同样有迹可循复数形式Множественные формы俄语名词复数分为_one、_few、_many、_other四类如 1 个/2-4 个/5 个的变格而go-i18n与 i18next 等框架均支持按复数类别选择译文翻译时需为同一消息键提供多套复数形式格结尾Падежные окончания技术术语在俄语中同样需要随格变化主格、属格、与格等译文应保证介词短语、复合名词的格一致语法性别Грамматический род技术名词需要正确匹配性别——例如 модель模型为阴性канал渠道为阳性修饰语与形容词需随之变格。九、标准化术语速查与贡献指南术语表在结尾给出了四组标准答案翻译时可直接套用ВыводCompletion模型的输出内容КоэффициентRatio用于计算价格的乘数因子Код купонаRedemption Code替代Код обмена更贴近产品语义ПоставщикProvider/Vendor提供 API 或 AI 模型的组织或服务。文档同时向贡献者开放了反馈渠道При обнаружении несогласованности в переводах терминологии или наличии лучших предложений по переводу, не стесняйтесь создавать Issue или Pull Request. 若发现术语翻译不一致或对翻译有更好的建议欢迎提交 Issue 或 Pull Request。结合 i18n/i18n.go 的实现俄语本地化的完整落地路径可以归纳为四步① 按本文术语表建立i18n/locales/ru.yaml并逐一翻译消息键② 为俄语复数形式提供_one/_few/_many/_other多套译文③ 在i18n包的语言常量与SupportedLanguages()中加入ru④ 在前端web/src基于 i18next日期组件等已内置ru区域同步接入俄语资源。这样从术语规范到运行时渲染的整条本地化链路便完整贯通。十、小结new-api 的俄语翻译术语表是一份先定标准、再行翻译的本地化治理文档它不仅给出了 5 大类 20 余个核心术语的标准俄语译法还通过重点提醒如 Коэффициент/Вывод/API ключ主动消除歧义通过上下文变体规则解决一词多义通过语言特性清单约束复数、格与性别的正确性。配合仓库中 i18n 包、middleware/i18n.go 与 locales 文件的实际实现这份术语表既是翻译贡献者的工作手册也是理解 new-api 多语言架构的一把钥匙——任何语言的本地化贡献者都可以参照 英文主版术语表 与 法语术语表 的同一套框架为项目贡献高质量、高一致性的翻译。【免费下载链接】new-apiA unified AI model hub for aggregation distribution. It supports cross-converting various LLMs into OpenAI-compatible, Claude-compatible, or Gemini-compatible formats. A centralized gateway for personal and enterprise model management.项目地址: https://gitcode.com/gh_mirrors/ne/new-api创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 new-api 俄语翻译术语表：本地化术语规范与多语言架构实现解读
new-api 俄语翻译术语表本地化术语规范与多语言架构实现解读【免费下载链接】new-apiA unified AI model hub for aggregation distribution. It supports cross-converting various LLMs into OpenAI-compatible, Claude-compatible, or Gemini-compatible formats. A centralized gateway for personal and enterprise model management.项目地址: https://gitcode.com/gh_mirrors/ne/new-api导读本文以 new-api 仓库中的 俄语翻译术语表translation-glossary.ru.md 为核心系统梳理项目面向俄语及多语言本地化贡献者制定的核心术语标准、上下文变体翻译规则与语言特性约束并结合仓库中真实的 i18n 实现后端 go-i18n 消息包、中间件语言探测、前端 i18next展开源码级佐证。读完本文你将掌握 new-api 的术语一致性治理方法、俄语翻译的落地规范以及翻译贡献者如何将术语表与运行时本地化机制衔接。一、术语表的定位让翻译一致而不只是正确翻译技术文档时正确不等于一致。同一个中文术语可能在不同页面、不同开发者口中出现多个俄语译法最终导致用户在管理后台、计费报表、API 错误提示中看到互相矛盾的词汇。new-api 仓库在 docs/translation-glossary.ru.md另有 英文主版 与 法语版中为贡献者预先锁定了关键术语的标准译法其核心目标写在文档开篇Данный раздел предоставляет стандартные переводы ключевой терминологии проекта на русский язык для обеспечения согласованности и точности переводов. 本节为项目关键术语提供标准俄语翻译以确保翻译的一致性与准确性。术语表明确允许的三类翻译策略与软件本地化L10n行业惯例一致保留 Emoji如果原文中出现 Emoji译文中允许保留保留纯技术术语原文中的纯粹技术词汇不做强行意译保留通用英文技术词在俄语技术圈已被广泛使用的英文术语例如 API直接沿用。这一策略保证了译文既贴近俄语母语用户的阅读习惯又不会为了本土化而牺牲技术准确性。从仓库的本地化实现看这种原文优先、宽松允许的思路也体现在消息键的设计上后端将所有可翻译字符串抽象为稳定的消息键如common.invalid_params、token.invalid键名本身即英文语义翻译内容则完全交给各语言文件见 i18n/keys.go。二、本地化运行时架构术语表服务的实际对象在深入术语细节之前先明确术语表与代码的对应关系。new-api 的国际化由独立的i18n包承载消息包初始化i18n/i18n.go 中通过go-i18n库的i18n.NewBundle(language.Chinese)创建 bundle并以go:embed方式把locales/*.yaml三个语言文件zh-CN.yaml、zh-TW.yaml、en.yaml嵌入二进制语言探测中间件 middleware/i18n.go 在每个请求上执行detectLanguage优先级为用户设置已登录时→Accept-Language请求头 → 默认语言翻译入口GetLangFromContexti18n/i18n.go完整实现了四层回退链用户设置 → 按用户 ID 惰性加载 → 上下文语言 →Accept-Language头 → 默认英文消息键常量i18n/keys.go 集中定义全部消息键避免硬编码字符串业务侧调用common.TranslateMessage在 common/gin.go 中作为钩子被i18n.T注入业务代码只传键名与模板数据如{{.Max}}、{{.Prefix}}。值得注意的边界目前SupportedLanguages()返回的是zh-CN、zh-TW、en三种语言i18n/i18n.gonormalizeLang也仅归一化中英文前缀。也就是说俄语术语表当前属于面向贡献者的翻译规范尚未进入运行时语言集合。这恰恰体现了术语表的先导作用先定标准、再行翻译、最后接入locales/*.yaml与SupportedLanguages()即可完成语言上线。翻译贡献者提交俄语翻译时应参照术语表新建locales/ru.yaml并将ru纳入语言探测与支持列表——具体接入点在 i18n/i18n.go 的语言常量和 middleware/i18n.go 的探测逻辑。三、核心概念术语表Core Concepts以下为文档定义的最基础概念贯穿所有界面与计费逻辑中文俄语英语说明倍率КоэффициентRatio/Multiplier用于计算价格的乘数因子。重点在计价场景中始终使用 Коэффициент不要用 Множитель以保证术语一致性令牌ТокенTokenAPI 访问凭证或模型处理的文本单元渠道КаналChannelAPI 提供商的接入通道分组ГруппаGroup用户或令牌的分类额度КвотаQuota用户可用的服务额度其中倍率一词在计价链路中语义关键。从源码看倍率正是价格计算的乘数因子model.Ratio与model.CompletionRatio分别构成模型倍率与补全倍率model/pricing.go而计费表达式引擎pkg/billingexpr在 compile.go 与 run.go 中把这些系数编译为可执行表达式——因此术语表强调计价上下文必须统一为 Коэффициент正是为了避免乘数一词在计费语义中引发歧义。四、模型相关术语Model Related模型域是术语表最密集的部分直接对应relay链路中的输入输出转换与计费参数中文俄语英语说明提示Промпт/ВводPrompt输入给模型的内容补全ВыводCompletion模型的输出内容。重点不得使用 Дополнение 或 Завершение只能使用 Вывод以贴合技术术语输入ВводInput/Prompt发送给模型的内容输出ВыводOutput/Completion模型返回的内容模型倍率Коэффициент моделиModel Ratio不同模型的计费倍率补全倍率Коэффициент выводаCompletion Ratio针对输出内容的额外计费倍率固定价格Цена за запросPrice per call单次调用的固定价格按量计费Оплата по объемуPay-as-you-go基于实际使用量的计费方式按次计费Оплата за запросPay-per-view每次调用固定价格补全倍率在实现中对应 OpenAI 生态的completion_ratio语义当completion_ratio 1时输出 token 按ratio (ratio - 1) * completion_ratio之类的方式叠加计费具体公式见 relay/common/billing.go 与 common/quota_math.go。术语表把补全锁定为 Вывод恰好与输出共用一词也与英文Completion Output/Completion的等价标注形成对照——翻译时注意区分上下文即可这正是下一节上下文变体规则要解决的问题。五、用户管理与充值兑换术语用户管理User Management中文俄语英语说明超级管理员СуперадминистраторRoot User拥有最高权限的管理员管理员АдминистраторAdmin User系统管理员普通用户Обычный пользовательNormal User标准权限用户这三个角色在权限模型中有明确映射RootUser是最初创建的超级管理员AdminUser拥有系统管理权限NormalUser为普通用户。仓库中权限判定分布在 service/authz 目录与 model/authz_role.go术语表为这些角色在管理后台界面的俄语显示提供了统一口径。充值兑换Recharge Redemption中文俄语英语说明充值ПополнениеTop Up为账户增加额度兑换码Код купонаRedemption Code可兑换为额度的代码兑换码在实现中由 model/redemption.go 承载支持批量生成、兑换额度、设置过期时间其相关的错误提示键如redemption.invalid、redemption.used、redemption.expired集中在 i18n/locales/en.yaml。术语表选用 Код купона优惠券代码而非直译的兑换代码是为了让俄语用户更直观理解其兑换抵扣的产品语义。六、渠道管理与安全术语渠道管理Channel Management中文俄语英语说明渠道КаналChannelAPI 提供商通道API 密钥API ключAPI KeyAPI 访问密钥。重点使用 API ключ 而非 API токен。理由术语ключ钥匙更准确表达资源访问功能而токен在语言模型语境中更常与文本单元关联容易与令牌/Токен混淆优先级ПриоритетPriority渠道选择优先级权重ВесWeight负载均衡权重代理ПроксиProxy代理服务器地址模型重定向Перенаправление моделиModel Mapping请求体中模型名称的替换供应商ПоставщикProvider/Vendor服务或 API 的提供方这组术语直接对应 model/channel.go 中Channel模型的关键字段Priority优先级、Weight权重参与负载均衡选择相关逻辑见 service/channel_select.go、Proxy代理地址见 common/proxy_url.go以及ModelMapping请求体模型名替换见 service/convert.go 与 relay/common/override.go。特别注意 API ключ 与 Токен 的区分new-api 中用户的 API 访问凭证在管理界面称为令牌Токен而渠道侧接入上游供应商的凭证称为API 密钥API ключ。术语表刻意用两个不同俄语词区分这两个概念避免俄语用户混淆自己的访问凭证与上游服务商的密钥——这在多语言界面中是一个非常实用的设计。安全相关Security Related中文俄语英语说明两步验证Двухфакторная аутентификацияTwo-Factor Authentication为账户提供的额外安全验证方式2FA2FATwo-Factor Authentication两步验证的缩写两步验证在仓库中由 model/twofa.go、model/twofa_enrollment.go 与 common/totp.go 实现TOTP 时间基一次性密码登录流程要求输入 2FA 码的提示键为user.require_2fa见 i18n/locales/en.yaml。七、上下文变体规则一词多义的翻译决策树术语表最重要的一节是Контекстуальные варианты перевода上下文变体翻译它解决了一词多义问题给出了可执行的决策规则Промпт / Ввод提示 / 输入Промпт用于与 LLM 交互的场景、用户界面文案、描述与模型互动的语境Ввод用于计费、技术文档、描述数据处理过程的语境规则如果谈论的是用户体验和与 AI 的交互 → Промпт如果谈论的是技术流程或计算 → Ввод。ТокенTokenAPI 访问令牌API Token——用户调用网关时出示的凭证模型处理的文本单元Text Token——计费与 token 计数场景系统访问令牌Access Token——系统内部鉴权场景。这三类 Token 在代码中都有对应物前者是sk-开头的用户令牌见 model/token.go 与 service/auth_token.go中者是 service/token_counter.go 统计的计费单元后者是管理接口鉴权用的 Access Token。同一个英文词、三种俄语语境翻译时必须按场景取舍。Квота额度用户的可用服务额度标准译法有时也译作 Кредит信用额度——术语表将其列为允许的变体。八、俄语语言特性与翻译约束术语表单独列出了俄语翻译必须注意的语言学特性这些要求在代码的 i18n 框架中同样有迹可循复数形式Множественные формы俄语名词复数分为_one、_few、_many、_other四类如 1 个/2-4 个/5 个的变格而go-i18n与 i18next 等框架均支持按复数类别选择译文翻译时需为同一消息键提供多套复数形式格结尾Падежные окончания技术术语在俄语中同样需要随格变化主格、属格、与格等译文应保证介词短语、复合名词的格一致语法性别Грамматический род技术名词需要正确匹配性别——例如 модель模型为阴性канал渠道为阳性修饰语与形容词需随之变格。九、标准化术语速查与贡献指南术语表在结尾给出了四组标准答案翻译时可直接套用ВыводCompletion模型的输出内容КоэффициентRatio用于计算价格的乘数因子Код купонаRedemption Code替代Код обмена更贴近产品语义ПоставщикProvider/Vendor提供 API 或 AI 模型的组织或服务。文档同时向贡献者开放了反馈渠道При обнаружении несогласованности в переводах терминологии или наличии лучших предложений по переводу, не стесняйтесь создавать Issue или Pull Request. 若发现术语翻译不一致或对翻译有更好的建议欢迎提交 Issue 或 Pull Request。结合 i18n/i18n.go 的实现俄语本地化的完整落地路径可以归纳为四步① 按本文术语表建立i18n/locales/ru.yaml并逐一翻译消息键② 为俄语复数形式提供_one/_few/_many/_other多套译文③ 在i18n包的语言常量与SupportedLanguages()中加入ru④ 在前端web/src基于 i18next日期组件等已内置ru区域同步接入俄语资源。这样从术语规范到运行时渲染的整条本地化链路便完整贯通。十、小结new-api 的俄语翻译术语表是一份先定标准、再行翻译的本地化治理文档它不仅给出了 5 大类 20 余个核心术语的标准俄语译法还通过重点提醒如 Коэффициент/Вывод/API ключ主动消除歧义通过上下文变体规则解决一词多义通过语言特性清单约束复数、格与性别的正确性。配合仓库中 i18n 包、middleware/i18n.go 与 locales 文件的实际实现这份术语表既是翻译贡献者的工作手册也是理解 new-api 多语言架构的一把钥匙——任何语言的本地化贡献者都可以参照 英文主版术语表 与 法语术语表 的同一套框架为项目贡献高质量、高一致性的翻译。【免费下载链接】new-apiA unified AI model hub for aggregation distribution. It supports cross-converting various LLMs into OpenAI-compatible, Claude-compatible, or Gemini-compatible formats. A centralized gateway for personal and enterprise model management.项目地址: https://gitcode.com/gh_mirrors/ne/new-api创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考