深入解读 .NET Runtime 仓库的 Issue 与 PR 自动化治理Policy Service Bot、区域订阅与工作流配置【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime导读本篇文章围绕 docs/infra/automation.md 展开系统讲解 .NET Runtimedotnet/runtime仓库如何借助 Policy Service Bot 实现 Issue 与 Pull Request 的自动化管理包括全部自动化规则的定义位置、mentionees区域订阅机制、area-*标签如何驱动通知机器人以及配套的标签预测、依赖更新和 Issue 搬迁等自动化工作流。读完本文你将掌握该仓库自动化治理的整体骨架理解如何通过提交 PR 修改策略 YAML 来订阅或退订某个技术领域的通知并能够把同样的 Policy Service 配置模式复用到自己的仓库中。一、自动化治理总览Policy Service Bot 的角色在 dotnet/runtime 这样拥有海量 Issue、PR 与多团队协作的大型仓库中纯粹依靠人工维护 Issue/PR 是行不通的。仓库采用Policy Service Bot策略服务机器人来承担日常的 Issue 与 Pull Request 管理任务其核心设计是所有自动化规则不是散落在各个 Workflow 里而是统一定义在.github/policies目录下的策略 YAML 文件中由 Policy Service 定期加载并执行。当前仓库中该目录包含两个策略文件.github/policies/resourceManagement.yml主策略文件约 2100 行包含绝大部分的资源管理规则定时任务 事件响应任务.github/policies/binaryformatter-migration.yml针对binaryformatter-migration标签的专项提及规则。策略文件本身采用 GitOps 方式维护任何规则变更都通过 PR 合入天然具备版本化、可评审、可回滚的能力。二、策略文件结构剖析2.1 顶层结构与通用字段以.github/policies/binaryformatter-migration.yml为例一个策略文件的基本骨架如下id: binaryformatter-migration name: BinaryFormatter migration label automation owner: jeffhandley resource: repository disabled: false configuration: resourceManagementConfiguration: eventResponderTasks: - description: Mention for binaryformatter-migration if: - or: - payloadType: Issues - payloadType: Pull_Request - labelAdded: label: binaryformatter-migration then: - mentionUsers: mentionees: - adamsitnik - bartonjs - jeffhandley - JeremyKuhne replyTemplate: - Tagging subscribers to binaryformatter-migration: ${mentionees} assignMentionees: False关键字段解读字段含义id/name策略的唯一标识与人类可读名称owner该策略的负责人通常是相关领域维护者resource: repository策略作用的资源类型这里是仓库级disabled: false是否启用resourceManagementConfigurationPolicy Service 的资源管理配置入口eventResponderTasks事件响应任务当仓库发生指定事件如 Issue/PR 被打标签时触发scheduledSearches定时搜索任务按固定频率扫描符合条件的 Issue/PR 并执行动作2.2 条件if与动作then模型每个任务由if条件块和then动作块构成支持or/not组合。常见条件谓词包括payloadType: Issues/payloadType: Pull_Request事件载荷类型labelAdded: { label: ... }是否刚被加上某标签hasLabel/isNotLabeledWith当前是否带有/不带某标签isOpen/isIssue/isPullRequest/isDraftPullRequestIssue/PR 状态noActivitySince: { days: N }距上次活跃超过 N 天isActivitySender: { issueAuthor: True }动作发送者是否为 Issue/PR 作者isAction: { action: Created }事件动作类型Created/Closed 等。常见动作包括mentionUsers提及用户、addReply回复评论、addLabel/removeLabel添加/移除标签、closeIssue关闭 Issue/PR。三、Notifications区域订阅mentionees机制docs/infra/automation.md的核心内容是Notifications区域通知订阅任何社区成员都可以为自己启用一个或多个技术领域的通知。只要某个领域有新的 Issue 或 PR你就会被打上标签被提及。你不需要拥有该仓库的提交权限。订阅方式非常简单通过提交一个 PR编辑对应领域的策略 YAML 文件中的mentionees值即可添加或移除自己。3.1 区域标签如何驱动通知以主策略文件.github/policies/resourceManagement.yml为例其主体是一个巨大的eventResponderTasks当事件载荷是 Issue 或 PR第 121-123 行并且被添加了任意一个area-*标签如area-AssemblyLoader、area-CodeGen-coreclr、area-System.Collections等覆盖 coreclr、mono、libraries 全仓库则触发对应领域的mentionUsers任务例如- if: - hasLabel: label: area-CodeGen-coreclr then: - mentionUsers: mentionees: - JulieLeeMSFT - jakobbotsch replyTemplate: - Tagging subscribers to this area: ${mentionees} See info in [area-owners.md](https://link.gitcode.com/i/29ef746af10d6b9b860acd1157dd4752) if you want to be subscribed. assignMentionees: False这里的replyTemplate使用${mentionees}占位符运行时由机器人替换为实际的被提及者列表assignMentionees: False表示只提及、不把用户指派为负责人。通知评论中会附带 docs/area-owners.md 的指引告诉订阅者如何进一步参与。从该文件结构可以看出第 118-337 行每个area-*标签对应一个独立的mentionUsers分支第 342 行起的连续 if/then 块形成一张标签 → 订阅者列表的映射表。3.2 mentionees 支持的三种实体类型从源码配置可以观察到mentionees列表中不仅允许单个 GitHub 用户名还支持GitHub Team引用例如单个用户agocke、elinor-fung、JulieLeeMSFT、jakobbotsch团队引用dotnet/jit-contrib、dotnet/dotnet-diag、dotnet/area-dependencymodel等见 第 460-466 行 等处的dotnet/area-system-datetime。这意味着当一个领域需要一大组维护者时可以用团队引用代替逐人列举既便于维护也便于社区成员被团队覆盖。3.3 如何给自己添加订阅结合 docs/area-owners.md 第 11 行的说明社区成员的操作路径是在.github/policies/resourceManagement.yml中找到自己关心的area-*标签对应的mentionUsers任务在该任务的mentionees:列表中加入自己的 GitHub 用户名提交 PR 合入后机器人配置即更新此后该领域的 Issue/PR 会通过replyTemplate提及你。注意area-owners.md中的表格仅用于人工查阅领域负责人机器人通知使用的映射以resourceManagement.yml为准二者并不自动同步GitHub Team 成员的通知订阅由团队维护而个人用户可以通过上述 PR 方式加入mentionees列表。3.4 退订退订同样简单再次提交 PR将自己的用户名从对应mentionees:列表中移除即可。整个过程无需任何提交权限完全开放给社区。四、定时任务Issue/PR 的自动清理闭环除了事件驱动主策略文件还定义了多个scheduledSearches定时任务构成完整的无活跃清理闭环第 10-117 行定时任务频率触发条件动作Automated Issue cleanup每小时hour: 6无活跃 1644 天、是 Issue、处于打开状态、未打backlog-cleanup-candidate等标签回复说明、打backlog-cleanup-candidate与no-recent-activity标签给 Issue 打 no-recent-activity每小时打开、带needs-author-action、14 天无活跃打no-recent-activity标签并回复给 PR 打 no-recent-activity每小时打开、带needs-author-action、14 天无活跃同上关闭无活跃 Issue每小时打开、带no-recent-activity、14 天仍无活跃回复说明后closeIssue关闭无活跃 PR每小时打开、带no-recent-activity、14 天仍无活跃同上关闭无活跃 Draft PR每小时Draft PR 打开、30 天无活跃closeIssue并回复这套机制实现了提醒 → 标记 → 关闭的三段式生命周期先在评论中给出宽限期说明任何新评论不限于作者都会取消流程之后若无进一步活动则自动关闭关闭后若继续长期无活跃还会被加锁策略评论中提示如果再过 30 天仍无活跃Issue 将被锁定。4.1 事件驱动的标签自愈策略文件中还包含大量事件响应任务来维持标签状态的一致性例如第 2038-2136 行PR 分支有推送 → 移除needs-author-action作者在 PR 中评论 / 提交 review → 移除needs-author-actionIssue/PR 被修改、被评论、有新 review → 移除no-recent-activity与backlog-cleanup-candidate。这些规则保证只要作者或审阅者有任何新动作清理流程立即复活不会误伤仍在推进的工作。五、配套自动化工作流从标签预测到依赖更新Policy Service 只是仓库自动化的一部分.github目录下还配置了多项互补工作流共同构成完整治理体系5.1 自动打标Issue-Labeler根据.github/labeler-readme.md仓库使用dotnet/issue-labeler自动为 Issue/PR 预测area-*标签LABEL_PREFIX设为area-预测置信度高于阈值的打上area-*标签低于阈值的打上默认标签needs-area-label可通过仓库变量ISSUE_LABELER_PREDICTION_THRESHOLD调整预测阈值默认0.05对应的工作流模板位于.github/workflows如labeler-predict-issues.yml、labeler-predict-pulls.yml、labeler-train.yml等。自动打出的area-*标签正是上一节 Policy Service 区域通知的输入信号二者形成自动分类 → 自动通知的流水线。5.2 依赖更新Dependabot.github/dependabot.yml配置了 GitHub Actions 生态系统的每日依赖检查package-ecosystem: github-actionsschedule.interval: daily排除.github/workflows/*.lock.yml并忽略actions/checkout的 patch/minor 更新及github/gh-aw-actions由 gh-aw 编译器锁定版本不可随意升级更新 PR 上限为 5自动打上area-codeflow标签便于 Policy Service 与人工分流。5.3 Issue 搬迁Move Issues.github/move.yml基于dessant/move-issues提供 Issue 跨仓库搬迁能力关键配置deleteCommand: true # 命令评论若不含其他内容则删除 closeSourceIssue: true # 迁移后关闭源 Issue lockSourceIssue: false # 不锁定源 Issue mentionAuthors: true # 在目标 Issue 中提及原 Issue 与评论作者 keepContentMentions: false # 不保留原 Issue 内容中的提及 moveLabels: false # 不迁移标签同时.github/CODEOWNERS、.github/ISSUE_TEMPLATE与.github/PULL_REQUEST_TEMPLATE分别承担代码所有权路由、Issue/PR 模板规范等配套职能。六、实践要点如何为你的仓库复刻这套自动化基于上述源码配置可以将这套模式提炼为可复用的清单规则集中管理将 Policy Service 规则统一放在.github/policies/*.yml用 Git 管理变更历史标签即路由设计好area-*标签体系让自动打标 → 事件响应 → 通知形成数据流闭环订阅开放允许社区成员通过 PR 修改mentionees自选订阅降低维护者负担生命周期自动化用scheduledSearchesnoActivitySince实现 Issue/PR 的提醒—标记—关闭三段清理并配套事件驱动的标签自愈规则组合互补工具Issue-Labeler 负责分类、Dependabot 负责依赖、move-issues 负责跨仓流转各司其职。需要留意的是Policy Service 的规则语法与行为以.github/policies中当前配置为准实际运行效果还会受机器人服务版本与仓库事件类型影响社区在提交订阅 PR 时应确保自己的用户名拼写正确且修改的是与目标area-*标签严格对应的mentionUsers任务避免影响其他领域的通知列表。七、小结dotnet/runtime 通过Policy Service Bot 集中式策略 YAML构建了高效的 Issue/PR 自动化治理体系scheduledSearches负责定时清理无活跃条目eventResponderTasks负责按area-*标签实时提及订阅者并维护标签状态社区成员无需提交权限即可通过 PR 修改mentionees实现区域订阅。配套的 Issue-Labeler、Dependabot 与 move-issues 工作流则补齐了自动分类、依赖更新与跨仓搬迁能力。理解这套机制无论是作为贡献者订阅通知还是作为维护者为自己的仓库设计自动化都能直接参照.github/policies中的真实配置落地实践。参考文件索引docs/infra/automation.md —— 本文主题文档.github/policies/resourceManagement.yml —— 主策略文件区域通知 定时清理.github/policies/binaryformatter-migration.yml —— 专项提及策略示例docs/area-owners.md —— 区域负责人对照表与订阅说明.github/labeler-readme.md —— Issue-Labeler 自动打标配置说明.github/dependabot.yml —— 依赖更新配置.github/move.yml —— Issue 搬迁配置【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深入解读 .NET Runtime 仓库的 Issue 与 PR 自动化治理：Policy Service Bot、区域订阅与工作流配置
深入解读 .NET Runtime 仓库的 Issue 与 PR 自动化治理Policy Service Bot、区域订阅与工作流配置【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime导读本篇文章围绕 docs/infra/automation.md 展开系统讲解 .NET Runtimedotnet/runtime仓库如何借助 Policy Service Bot 实现 Issue 与 Pull Request 的自动化管理包括全部自动化规则的定义位置、mentionees区域订阅机制、area-*标签如何驱动通知机器人以及配套的标签预测、依赖更新和 Issue 搬迁等自动化工作流。读完本文你将掌握该仓库自动化治理的整体骨架理解如何通过提交 PR 修改策略 YAML 来订阅或退订某个技术领域的通知并能够把同样的 Policy Service 配置模式复用到自己的仓库中。一、自动化治理总览Policy Service Bot 的角色在 dotnet/runtime 这样拥有海量 Issue、PR 与多团队协作的大型仓库中纯粹依靠人工维护 Issue/PR 是行不通的。仓库采用Policy Service Bot策略服务机器人来承担日常的 Issue 与 Pull Request 管理任务其核心设计是所有自动化规则不是散落在各个 Workflow 里而是统一定义在.github/policies目录下的策略 YAML 文件中由 Policy Service 定期加载并执行。当前仓库中该目录包含两个策略文件.github/policies/resourceManagement.yml主策略文件约 2100 行包含绝大部分的资源管理规则定时任务 事件响应任务.github/policies/binaryformatter-migration.yml针对binaryformatter-migration标签的专项提及规则。策略文件本身采用 GitOps 方式维护任何规则变更都通过 PR 合入天然具备版本化、可评审、可回滚的能力。二、策略文件结构剖析2.1 顶层结构与通用字段以.github/policies/binaryformatter-migration.yml为例一个策略文件的基本骨架如下id: binaryformatter-migration name: BinaryFormatter migration label automation owner: jeffhandley resource: repository disabled: false configuration: resourceManagementConfiguration: eventResponderTasks: - description: Mention for binaryformatter-migration if: - or: - payloadType: Issues - payloadType: Pull_Request - labelAdded: label: binaryformatter-migration then: - mentionUsers: mentionees: - adamsitnik - bartonjs - jeffhandley - JeremyKuhne replyTemplate: - Tagging subscribers to binaryformatter-migration: ${mentionees} assignMentionees: False关键字段解读字段含义id/name策略的唯一标识与人类可读名称owner该策略的负责人通常是相关领域维护者resource: repository策略作用的资源类型这里是仓库级disabled: false是否启用resourceManagementConfigurationPolicy Service 的资源管理配置入口eventResponderTasks事件响应任务当仓库发生指定事件如 Issue/PR 被打标签时触发scheduledSearches定时搜索任务按固定频率扫描符合条件的 Issue/PR 并执行动作2.2 条件if与动作then模型每个任务由if条件块和then动作块构成支持or/not组合。常见条件谓词包括payloadType: Issues/payloadType: Pull_Request事件载荷类型labelAdded: { label: ... }是否刚被加上某标签hasLabel/isNotLabeledWith当前是否带有/不带某标签isOpen/isIssue/isPullRequest/isDraftPullRequestIssue/PR 状态noActivitySince: { days: N }距上次活跃超过 N 天isActivitySender: { issueAuthor: True }动作发送者是否为 Issue/PR 作者isAction: { action: Created }事件动作类型Created/Closed 等。常见动作包括mentionUsers提及用户、addReply回复评论、addLabel/removeLabel添加/移除标签、closeIssue关闭 Issue/PR。三、Notifications区域订阅mentionees机制docs/infra/automation.md的核心内容是Notifications区域通知订阅任何社区成员都可以为自己启用一个或多个技术领域的通知。只要某个领域有新的 Issue 或 PR你就会被打上标签被提及。你不需要拥有该仓库的提交权限。订阅方式非常简单通过提交一个 PR编辑对应领域的策略 YAML 文件中的mentionees值即可添加或移除自己。3.1 区域标签如何驱动通知以主策略文件.github/policies/resourceManagement.yml为例其主体是一个巨大的eventResponderTasks当事件载荷是 Issue 或 PR第 121-123 行并且被添加了任意一个area-*标签如area-AssemblyLoader、area-CodeGen-coreclr、area-System.Collections等覆盖 coreclr、mono、libraries 全仓库则触发对应领域的mentionUsers任务例如- if: - hasLabel: label: area-CodeGen-coreclr then: - mentionUsers: mentionees: - JulieLeeMSFT - jakobbotsch replyTemplate: - Tagging subscribers to this area: ${mentionees} See info in [area-owners.md](https://link.gitcode.com/i/29ef746af10d6b9b860acd1157dd4752) if you want to be subscribed. assignMentionees: False这里的replyTemplate使用${mentionees}占位符运行时由机器人替换为实际的被提及者列表assignMentionees: False表示只提及、不把用户指派为负责人。通知评论中会附带 docs/area-owners.md 的指引告诉订阅者如何进一步参与。从该文件结构可以看出第 118-337 行每个area-*标签对应一个独立的mentionUsers分支第 342 行起的连续 if/then 块形成一张标签 → 订阅者列表的映射表。3.2 mentionees 支持的三种实体类型从源码配置可以观察到mentionees列表中不仅允许单个 GitHub 用户名还支持GitHub Team引用例如单个用户agocke、elinor-fung、JulieLeeMSFT、jakobbotsch团队引用dotnet/jit-contrib、dotnet/dotnet-diag、dotnet/area-dependencymodel等见 第 460-466 行 等处的dotnet/area-system-datetime。这意味着当一个领域需要一大组维护者时可以用团队引用代替逐人列举既便于维护也便于社区成员被团队覆盖。3.3 如何给自己添加订阅结合 docs/area-owners.md 第 11 行的说明社区成员的操作路径是在.github/policies/resourceManagement.yml中找到自己关心的area-*标签对应的mentionUsers任务在该任务的mentionees:列表中加入自己的 GitHub 用户名提交 PR 合入后机器人配置即更新此后该领域的 Issue/PR 会通过replyTemplate提及你。注意area-owners.md中的表格仅用于人工查阅领域负责人机器人通知使用的映射以resourceManagement.yml为准二者并不自动同步GitHub Team 成员的通知订阅由团队维护而个人用户可以通过上述 PR 方式加入mentionees列表。3.4 退订退订同样简单再次提交 PR将自己的用户名从对应mentionees:列表中移除即可。整个过程无需任何提交权限完全开放给社区。四、定时任务Issue/PR 的自动清理闭环除了事件驱动主策略文件还定义了多个scheduledSearches定时任务构成完整的无活跃清理闭环第 10-117 行定时任务频率触发条件动作Automated Issue cleanup每小时hour: 6无活跃 1644 天、是 Issue、处于打开状态、未打backlog-cleanup-candidate等标签回复说明、打backlog-cleanup-candidate与no-recent-activity标签给 Issue 打 no-recent-activity每小时打开、带needs-author-action、14 天无活跃打no-recent-activity标签并回复给 PR 打 no-recent-activity每小时打开、带needs-author-action、14 天无活跃同上关闭无活跃 Issue每小时打开、带no-recent-activity、14 天仍无活跃回复说明后closeIssue关闭无活跃 PR每小时打开、带no-recent-activity、14 天仍无活跃同上关闭无活跃 Draft PR每小时Draft PR 打开、30 天无活跃closeIssue并回复这套机制实现了提醒 → 标记 → 关闭的三段式生命周期先在评论中给出宽限期说明任何新评论不限于作者都会取消流程之后若无进一步活动则自动关闭关闭后若继续长期无活跃还会被加锁策略评论中提示如果再过 30 天仍无活跃Issue 将被锁定。4.1 事件驱动的标签自愈策略文件中还包含大量事件响应任务来维持标签状态的一致性例如第 2038-2136 行PR 分支有推送 → 移除needs-author-action作者在 PR 中评论 / 提交 review → 移除needs-author-actionIssue/PR 被修改、被评论、有新 review → 移除no-recent-activity与backlog-cleanup-candidate。这些规则保证只要作者或审阅者有任何新动作清理流程立即复活不会误伤仍在推进的工作。五、配套自动化工作流从标签预测到依赖更新Policy Service 只是仓库自动化的一部分.github目录下还配置了多项互补工作流共同构成完整治理体系5.1 自动打标Issue-Labeler根据.github/labeler-readme.md仓库使用dotnet/issue-labeler自动为 Issue/PR 预测area-*标签LABEL_PREFIX设为area-预测置信度高于阈值的打上area-*标签低于阈值的打上默认标签needs-area-label可通过仓库变量ISSUE_LABELER_PREDICTION_THRESHOLD调整预测阈值默认0.05对应的工作流模板位于.github/workflows如labeler-predict-issues.yml、labeler-predict-pulls.yml、labeler-train.yml等。自动打出的area-*标签正是上一节 Policy Service 区域通知的输入信号二者形成自动分类 → 自动通知的流水线。5.2 依赖更新Dependabot.github/dependabot.yml配置了 GitHub Actions 生态系统的每日依赖检查package-ecosystem: github-actionsschedule.interval: daily排除.github/workflows/*.lock.yml并忽略actions/checkout的 patch/minor 更新及github/gh-aw-actions由 gh-aw 编译器锁定版本不可随意升级更新 PR 上限为 5自动打上area-codeflow标签便于 Policy Service 与人工分流。5.3 Issue 搬迁Move Issues.github/move.yml基于dessant/move-issues提供 Issue 跨仓库搬迁能力关键配置deleteCommand: true # 命令评论若不含其他内容则删除 closeSourceIssue: true # 迁移后关闭源 Issue lockSourceIssue: false # 不锁定源 Issue mentionAuthors: true # 在目标 Issue 中提及原 Issue 与评论作者 keepContentMentions: false # 不保留原 Issue 内容中的提及 moveLabels: false # 不迁移标签同时.github/CODEOWNERS、.github/ISSUE_TEMPLATE与.github/PULL_REQUEST_TEMPLATE分别承担代码所有权路由、Issue/PR 模板规范等配套职能。六、实践要点如何为你的仓库复刻这套自动化基于上述源码配置可以将这套模式提炼为可复用的清单规则集中管理将 Policy Service 规则统一放在.github/policies/*.yml用 Git 管理变更历史标签即路由设计好area-*标签体系让自动打标 → 事件响应 → 通知形成数据流闭环订阅开放允许社区成员通过 PR 修改mentionees自选订阅降低维护者负担生命周期自动化用scheduledSearchesnoActivitySince实现 Issue/PR 的提醒—标记—关闭三段清理并配套事件驱动的标签自愈规则组合互补工具Issue-Labeler 负责分类、Dependabot 负责依赖、move-issues 负责跨仓流转各司其职。需要留意的是Policy Service 的规则语法与行为以.github/policies中当前配置为准实际运行效果还会受机器人服务版本与仓库事件类型影响社区在提交订阅 PR 时应确保自己的用户名拼写正确且修改的是与目标area-*标签严格对应的mentionUsers任务避免影响其他领域的通知列表。七、小结dotnet/runtime 通过Policy Service Bot 集中式策略 YAML构建了高效的 Issue/PR 自动化治理体系scheduledSearches负责定时清理无活跃条目eventResponderTasks负责按area-*标签实时提及订阅者并维护标签状态社区成员无需提交权限即可通过 PR 修改mentionees实现区域订阅。配套的 Issue-Labeler、Dependabot 与 move-issues 工作流则补齐了自动分类、依赖更新与跨仓搬迁能力。理解这套机制无论是作为贡献者订阅通知还是作为维护者为自己的仓库设计自动化都能直接参照.github/policies中的真实配置落地实践。参考文件索引docs/infra/automation.md —— 本文主题文档.github/policies/resourceManagement.yml —— 主策略文件区域通知 定时清理.github/policies/binaryformatter-migration.yml —— 专项提及策略示例docs/area-owners.md —— 区域负责人对照表与订阅说明.github/labeler-readme.md —— Issue-Labeler 自动打标配置说明.github/dependabot.yml —— 依赖更新配置.github/move.yml —— Issue 搬迁配置【免费下载链接】runtime.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.项目地址: https://gitcode.com/GitHub_Trending/runtime6/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考