Cutter 发布流程完全指南从功能冻结到正式 Release 的全链路操作手册【免费下载链接】cutterFree and Open Source Reverse Engineering Platform powered by rizin项目地址: https://gitcode.com/gh_mirrors/cu/cutter导读本文以 Cutter基于 rizin 的自由开源逆向工程平台官方发布流程文档为骨架系统梳理从功能冻结、版本锁定、版本号更新、RC 预发布、全平台回归测试到正式 Release 发布与公告的完整操作链。无论你是 Cutter 的维护者、打包者还是希望理解开源桌面应用发布工程实践的开发者读完本文都能掌握如何管理 translations 子模块与 Crowdin 同步、如何将 dev 合并到 stable 实现功能冻结、如何在多个文件中同步更新版本号、如何正确创建 RC 标签与 GitHub Release以及如何在发布前执行一份快速但有效的冒烟测试清单。1. 发布流程总览Cutter 的发布流程见 release-procedure.rst是一条从「翻译同步」到「正式公告」的流水线核心目标是在保证 stable 分支质量的同时让 dev 分支的开发不被发布工作阻断。整体可以划分为五个阶段发布前准备同步翻译、合并 dev 到 stable功能冻结、锁定第三方组件版本、更新版本号。候选版本RC打 RC 标签、创建 pre-release、等待各平台打包产物。回归测试在所有操作系统上执行基础测试流程Basic testing procedure。正式发布更新版本号、打正式标签、填写 Release Notes、发布公告、关闭里程碑。Bugfix 发布从 dev 中 cherry-pick 修复到 stable并递增第三位版本号。流程文档中强调功能冻结feature-freeze可以提前发生即在 dev 分支继续开发的同时把当前状态并入 stable这样发布准备工作与日常开发可以并行推进互不阻塞。2. 发布前准备翻译、分支合并与版本锁定2.1 更新 translations 子模块Cutter 的界面翻译通过 Crowdin 平台协作完成翻译文件以 git submodule 的形式嵌入仓库。发布前的第一步是确保翻译处于最新状态确认最新翻译归档已在仓库中Crowdin 的自动化 Pull Request 通常会自动合入翻译更新例如cutter-translations仓库中的自动 PR。若尚未合入需要先手动合并。更新 Cutter 仓库中的子模块指针将translations子模块指向最新的翻译提交。仓库中 deploy_translations.sh 展示了翻译子模块的双向工作流脚本执行git submodule update translations随后将 Cutter 生成的翻译文件如cutter_fr.ts整理为 Crowdin 可识别的单一文件并推送回cutter-translations仓库。也就是说发布前从 Crowdin 拉取翻译、发布后向 Crowdin 推送新字符串构成了翻译的完整闭环。2.2 合并 dev 到 stable功能冻结将 dev 分支的当前状态合并进 stable这一步骤允许提前执行提前合并可以在功能冻结时就把 dev 合并到 stable之后 dev 继续接受新功能开发而 stable 只接受 bugfix 与发布相关改动。子模块指针约束stable 分支上的rizin 子模块应指向 rizin 仓库的 stable 分支提交dev 分支上的 rizin 子模块应指向 rizin 的 dev 分支提交。这保证了发布分支始终基于稳定的 rizin 版本而不是未发布的开发版本。2.3 锁定 rzghidra 与 rzdec 版本打包脚本packaging scripts会从外部仓库拉取反编译器插件源码。发布前必须锁定这些依赖的具体版本指定 tag 或 commit hash避免发布包中混入非预期的上游变更rzghidra即 Ghidra 反编译器的 rizin 原生集成插件。在 dist/CMakeLists.txt 中它通过ExternalProject_Add拉取其中GIT_TAG字段控制版本源码中注释给出了v0.3.0标签与某个 commit hash 的示例当前默认指向dev分支发布打包时需将其改为具体的 tag 或 commit。rzdecRetDec 反编译器的 rizin 插件同样需要在打包配置中锁定版本。注意源码注释中提醒「disable this line when using commit hash」——当使用 commit hash 锁定时应关闭GIT_SHALLOW ON以免浅克隆无法获取指定提交。从源码结构看dist/CMakeLists.txt这正是发布流程第 3 步对应的实现位置。3. 更新版本号全仓库同步版本号不是只改一个文件而需要在整个代码库中保持一致。发布流程文档列出的更新清单如下部分文件在当前仓库中的实际路径已发生变化以仓库实际内容为准原文档列举项当前仓库中的实际位置说明appveyor.yml当前仓库根目录未见该文件早期 Windows CI 配置以当前 CI 实际文件为准docs/sourc/conf.pydocs/conf.pySphinx 文档配置含version/release字段docs/source/index.rstdocs/source/index.rst文档首页中的版本号展示CMakeLists.txtCMakeLists.txt核心版本定义处见下文Cutter.appdata.xmlsrc/re.rizin.cutter.appdata.xmlAppData 元数据中的releases版本信息保险起见建议全代码库搜索旧版本号避免遗漏任何硬编码位置。3.1 CMakeLists.txt 中的版本定义机制版本号的核心来源是根目录 CMakeLists.txtset(CUTTER_VERSION_MAJOR 2) set(CUTTER_VERSION_MINOR 5) set(CUTTER_VERSION_PATCH 0) set(CUTTER_VERSION ${CUTTER_VERSION_MAJOR}.${CUTTER_VERSION_MINOR}.${CUTTER_VERSION_PATCH})围绕这一主版本号还有两个配套机制值得发布维护者注意CUTTER_VERSION_SUFFIXCMakeLists.txt供打包者附加构建号或补丁标识例如 RPM 包名与源码版本相同但携带额外补丁时可通过该变量区分。CUTTER_INCLUDE_GIT_HASHCMakeLists.txt默认开启会将 git 提交哈希与分支名拼入完整版本号set(CUTTER_VERSION_FULL ${CUTTER_VERSION}${CUTTER_VERSION_SUFFIX}-${GIT_BRANCH}-${GIT_REV})也就是说构建产物显示的2.5.0-dev-abc1234这种版本串即来源于此。正式发布时需确保该机制与预期的发布版本一致例如从 tag 检出时GIT_BRANCH会是HEAD打包前需确认CUTTER_VERSION_FULL的最终形态。4. 发布候选版本RC打标签与创建 pre-release以v1.11.0为例流程文档原始示例当前仓库版本体系为2.x此处仅演示 tag 命名约定RC 阶段的操作如下4.1 创建 RC 标签git tag v1.11.0-rc1 git push origin v1.11.0-rc1原文档中的git tag push origin v1.11.0-rc1应为git push origin属于笔误正确写法是先git tag再git push origin tagname。另外注意当前仓库的版本体系已演进为2.x见 CMakeLists.txt实际打标签时应使用真实的版本号。4.2 创建 GitHub Releasepre-release 草稿在 GitHub Releases 页面创建 Release标记为 pre-release预发布保存为 draft草稿将 tag 设置为v1.11.0-rc1。先存为草稿的目的是在打包产物尚未全部完成、测试尚未通过之前不让 RC 面向普通用户公开打包完成后、确认无误后再编辑并正式发布草稿。4.3 等待各平台打包产物Release 创建后CI 流水线会为 Windows、macOS、Linux 等平台构建安装包。此阶段需要等待打包完成随后进入全平台测试。5. 回归测试Basic testing procedure流程文档明确指出这不是穷尽式测试而是一组「确保没有严重损坏」的快速冒烟检查建议在多个不同偏移量处重复操作并随意点击以提高发现偶发性问题的概率。测试项如下测试项操作要点预期结果打开简单可执行文件如/bin/ls或calc.exe正常加载布局升级打开应用检查界面布局升级后的布局未被破坏反汇编视图打开 Disassembly widget显示正确的反汇编内置插件rzghidra打开反编译器并选择ghidra至少对部分函数显示 C 代码内置插件rzdec在反编译器中选择 rzdec正常显示反编译代码样例 Python 插件加载 sample python plugin正常工作调试器在main下断点 → 开始调试 → 通过函数列表跳转到 main重定位正确看到代码而非未映射内存断点位于预期位置继续执行能命中main断点干净启动删除 Cutter 设置文件后启动全新启动正常布局未损坏5.1 测试项对应的仓库依据rzghidra 为默认反编译器在 DecompilerWidget.cpp 中若用户未选择过反编译器代码会将ghidra设为默认项这解释了为何测试清单把「打开 decompiler 并选择 ghidra」列为首要插件测试项。打包选项开关CUTTER_PACKAGE_RZ_GHIDRA、CUTTER_PACKAGE_RZ_LIBYARA、CUTTER_PACKAGE_RZ_SILHOUETTE、CUTTER_PACKAGE_JSDEC等选项定义于 CMakeLists.txt对应打包阶段是否编入各类 rizin 插件。样例插件C 样例位于 src/plugins/sample-cpp/Python 样例位于 src/plugins/sample-python/sample_python.py是测试插件机制的现成素材。5.2 测试失败时的处理路径若发现重大问题在 issue 跟踪器中提交 issue在dev 分支修复然后cherry-pick 到 release 分支不要直接在 stable 上改若改动量足够大则回到第 3 步版本锁定重新走一遍流程并递增 RC 编号rc1→rc2→ …。6. 正式发布版本号、标签与 Release NotesRC 全部通过测试后进入正式发布阶段6.1 正式版本号与标签将版本号更新为正式版本如1.11.0同步更新第 3 节列出的所有文件创建正式标签如v1.11.0创建正式 Release。6.2 编写 Release NotesRelease Notes 是整个发布流程中最需要「内容运营功底」的环节文档给出的指导原则非常具体尽早开始撰写不必等发布时才写可在发布过程中持续积累素材对比分支差异将当前 dev 分支与上一次发布进行比较找出全部变更只挑最重要的不要重复 commit logRelease Notes 是给「不想读完整提交历史的人」看的摘要按主题分组使用类似New features新特性、Bug Fixes缺陷修复、Decompiler反编译器、Rizin等标题对相关变更分组让读者能快速定位自己关心的领域。6.3 公告与里程碑收尾准备发布公告推文并发送到 Telegram 群组、reddit 等社区渠道若本次发布对应有 GitHub milestone在发布完成后关闭该 milestone。7. Bugfix 发布流程Bugfix 发布补丁版本与常规流程相似但有两个关键差异cherry-pick 而非合并将必要的 bugfix 从 devcherry-pick 到 stable只挑选修复不带入新功能递增第三位版本号x.y.n→x.y.(n1)即补丁版本只改 patch 位例如2.5.0→2.5.1对应 CMakeLists.txt 中的CUTTER_VERSION_PATCH变量。其余步骤翻译同步、版本号全仓库更新、打标签、创建 Release、测试与正式发布一致。8. 发布流程速查清单阶段关键动作命令 / 文件翻译合入 Crowdin 自动 PR更新子模块git submodule update translations见 deploy_translations.sh冻结dev 合并进 stablerizin 子模块指向对应分支git merge锁定锁定 rzghidra / rzdec 为 tag 或 commitdist/CMakeLists.txt 中的GIT_TAG版本号全仓库搜索旧版本号并同步更新CMakeLists.txt、docs/conf.py、src/re.rizin.cutter.appdata.xml 等RC打标签 pre-release 草稿git tag vX.Y.Z-rcNgit push origin vX.Y.Z-rcN测试全平台执行 Basic testing procedure见第 5 节清单正式发布更新正式版本号、创建 Release、填写分组 Release NotesGitHub Releases公告推文、Telegram、reddit 等渠道关闭 milestone—Bugfixdev 中 cherry-pick 到 stablepatch 位 1git cherry-pick9. 结语Cutter 的发布流程是一套典型的「双分支 子模块 版本锁定 RC 迭代」开源桌面应用发布工程实践translations 子模块保证了多语言同步的自动化dev/stable 分支分离实现了功能冻结与持续开发并行rzghidra 等插件版本锁定确保了发布产物的可复现性而「全代码库版本号同步 RC 草稿 冒烟测试清单」则把人为失误的概率降到最低。对于维护者而言遵循本文梳理的 14 步流程与 Bugfix 变体即可稳定、可预测地完成每一个版本的交付。提示发布流程属于维护工程范畴实际执行时请以当前仓库的 CI 配置如.github/workflows、appveyor.yml等是否存在、CMakeLists.txt 中的实际版本号当前为2.5.0系列以及 release-procedure.rst 的最新修订为准避免沿用文档中已过时的文件路径与版本示例。【免费下载链接】cutterFree and Open Source Reverse Engineering Platform powered by rizin项目地址: https://gitcode.com/gh_mirrors/cu/cutter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Cutter 发布流程完全指南从功能冻结到正式 Release 的全链路操作手册【免费下载链接】cutterFree and Open Source Reverse Engineering Platform powered by rizin项目地址: https://gitcode.com/gh_mirrors/cu/cutter导读本文以 Cutter基于 rizin 的自由开源逆向工程平台官方发布流程文档为骨架系统梳理从功能冻结、版本锁定、版本号更新、RC 预发布、全平台回归测试到正式 Release 发布与公告的完整操作链。无论你是 Cutter 的维护者、打包者还是希望理解开源桌面应用发布工程实践的开发者读完本文都能掌握如何管理 translations 子模块与 Crowdin 同步、如何将 dev 合并到 stable 实现功能冻结、如何在多个文件中同步更新版本号、如何正确创建 RC 标签与 GitHub Release以及如何在发布前执行一份快速但有效的冒烟测试清单。1. 发布流程总览Cutter 的发布流程见 release-procedure.rst是一条从「翻译同步」到「正式公告」的流水线核心目标是在保证 stable 分支质量的同时让 dev 分支的开发不被发布工作阻断。整体可以划分为五个阶段发布前准备同步翻译、合并 dev 到 stable功能冻结、锁定第三方组件版本、更新版本号。候选版本RC打 RC 标签、创建 pre-release、等待各平台打包产物。回归测试在所有操作系统上执行基础测试流程Basic testing procedure。正式发布更新版本号、打正式标签、填写 Release Notes、发布公告、关闭里程碑。Bugfix 发布从 dev 中 cherry-pick 修复到 stable并递增第三位版本号。流程文档中强调功能冻结feature-freeze可以提前发生即在 dev 分支继续开发的同时把当前状态并入 stable这样发布准备工作与日常开发可以并行推进互不阻塞。2. 发布前准备翻译、分支合并与版本锁定2.1 更新 translations 子模块Cutter 的界面翻译通过 Crowdin 平台协作完成翻译文件以 git submodule 的形式嵌入仓库。发布前的第一步是确保翻译处于最新状态确认最新翻译归档已在仓库中Crowdin 的自动化 Pull Request 通常会自动合入翻译更新例如cutter-translations仓库中的自动 PR。若尚未合入需要先手动合并。更新 Cutter 仓库中的子模块指针将translations子模块指向最新的翻译提交。仓库中 deploy_translations.sh 展示了翻译子模块的双向工作流脚本执行git submodule update translations随后将 Cutter 生成的翻译文件如cutter_fr.ts整理为 Crowdin 可识别的单一文件并推送回cutter-translations仓库。也就是说发布前从 Crowdin 拉取翻译、发布后向 Crowdin 推送新字符串构成了翻译的完整闭环。2.2 合并 dev 到 stable功能冻结将 dev 分支的当前状态合并进 stable这一步骤允许提前执行提前合并可以在功能冻结时就把 dev 合并到 stable之后 dev 继续接受新功能开发而 stable 只接受 bugfix 与发布相关改动。子模块指针约束stable 分支上的rizin 子模块应指向 rizin 仓库的 stable 分支提交dev 分支上的 rizin 子模块应指向 rizin 的 dev 分支提交。这保证了发布分支始终基于稳定的 rizin 版本而不是未发布的开发版本。2.3 锁定 rzghidra 与 rzdec 版本打包脚本packaging scripts会从外部仓库拉取反编译器插件源码。发布前必须锁定这些依赖的具体版本指定 tag 或 commit hash避免发布包中混入非预期的上游变更rzghidra即 Ghidra 反编译器的 rizin 原生集成插件。在 dist/CMakeLists.txt 中它通过ExternalProject_Add拉取其中GIT_TAG字段控制版本源码中注释给出了v0.3.0标签与某个 commit hash 的示例当前默认指向dev分支发布打包时需将其改为具体的 tag 或 commit。rzdecRetDec 反编译器的 rizin 插件同样需要在打包配置中锁定版本。注意源码注释中提醒「disable this line when using commit hash」——当使用 commit hash 锁定时应关闭GIT_SHALLOW ON以免浅克隆无法获取指定提交。从源码结构看dist/CMakeLists.txt这正是发布流程第 3 步对应的实现位置。3. 更新版本号全仓库同步版本号不是只改一个文件而需要在整个代码库中保持一致。发布流程文档列出的更新清单如下部分文件在当前仓库中的实际路径已发生变化以仓库实际内容为准原文档列举项当前仓库中的实际位置说明appveyor.yml当前仓库根目录未见该文件早期 Windows CI 配置以当前 CI 实际文件为准docs/sourc/conf.pydocs/conf.pySphinx 文档配置含version/release字段docs/source/index.rstdocs/source/index.rst文档首页中的版本号展示CMakeLists.txtCMakeLists.txt核心版本定义处见下文Cutter.appdata.xmlsrc/re.rizin.cutter.appdata.xmlAppData 元数据中的releases版本信息保险起见建议全代码库搜索旧版本号避免遗漏任何硬编码位置。3.1 CMakeLists.txt 中的版本定义机制版本号的核心来源是根目录 CMakeLists.txtset(CUTTER_VERSION_MAJOR 2) set(CUTTER_VERSION_MINOR 5) set(CUTTER_VERSION_PATCH 0) set(CUTTER_VERSION ${CUTTER_VERSION_MAJOR}.${CUTTER_VERSION_MINOR}.${CUTTER_VERSION_PATCH})围绕这一主版本号还有两个配套机制值得发布维护者注意CUTTER_VERSION_SUFFIXCMakeLists.txt供打包者附加构建号或补丁标识例如 RPM 包名与源码版本相同但携带额外补丁时可通过该变量区分。CUTTER_INCLUDE_GIT_HASHCMakeLists.txt默认开启会将 git 提交哈希与分支名拼入完整版本号set(CUTTER_VERSION_FULL ${CUTTER_VERSION}${CUTTER_VERSION_SUFFIX}-${GIT_BRANCH}-${GIT_REV})也就是说构建产物显示的2.5.0-dev-abc1234这种版本串即来源于此。正式发布时需确保该机制与预期的发布版本一致例如从 tag 检出时GIT_BRANCH会是HEAD打包前需确认CUTTER_VERSION_FULL的最终形态。4. 发布候选版本RC打标签与创建 pre-release以v1.11.0为例流程文档原始示例当前仓库版本体系为2.x此处仅演示 tag 命名约定RC 阶段的操作如下4.1 创建 RC 标签git tag v1.11.0-rc1 git push origin v1.11.0-rc1原文档中的git tag push origin v1.11.0-rc1应为git push origin属于笔误正确写法是先git tag再git push origin tagname。另外注意当前仓库的版本体系已演进为2.x见 CMakeLists.txt实际打标签时应使用真实的版本号。4.2 创建 GitHub Releasepre-release 草稿在 GitHub Releases 页面创建 Release标记为 pre-release预发布保存为 draft草稿将 tag 设置为v1.11.0-rc1。先存为草稿的目的是在打包产物尚未全部完成、测试尚未通过之前不让 RC 面向普通用户公开打包完成后、确认无误后再编辑并正式发布草稿。4.3 等待各平台打包产物Release 创建后CI 流水线会为 Windows、macOS、Linux 等平台构建安装包。此阶段需要等待打包完成随后进入全平台测试。5. 回归测试Basic testing procedure流程文档明确指出这不是穷尽式测试而是一组「确保没有严重损坏」的快速冒烟检查建议在多个不同偏移量处重复操作并随意点击以提高发现偶发性问题的概率。测试项如下测试项操作要点预期结果打开简单可执行文件如/bin/ls或calc.exe正常加载布局升级打开应用检查界面布局升级后的布局未被破坏反汇编视图打开 Disassembly widget显示正确的反汇编内置插件rzghidra打开反编译器并选择ghidra至少对部分函数显示 C 代码内置插件rzdec在反编译器中选择 rzdec正常显示反编译代码样例 Python 插件加载 sample python plugin正常工作调试器在main下断点 → 开始调试 → 通过函数列表跳转到 main重定位正确看到代码而非未映射内存断点位于预期位置继续执行能命中main断点干净启动删除 Cutter 设置文件后启动全新启动正常布局未损坏5.1 测试项对应的仓库依据rzghidra 为默认反编译器在 DecompilerWidget.cpp 中若用户未选择过反编译器代码会将ghidra设为默认项这解释了为何测试清单把「打开 decompiler 并选择 ghidra」列为首要插件测试项。打包选项开关CUTTER_PACKAGE_RZ_GHIDRA、CUTTER_PACKAGE_RZ_LIBYARA、CUTTER_PACKAGE_RZ_SILHOUETTE、CUTTER_PACKAGE_JSDEC等选项定义于 CMakeLists.txt对应打包阶段是否编入各类 rizin 插件。样例插件C 样例位于 src/plugins/sample-cpp/Python 样例位于 src/plugins/sample-python/sample_python.py是测试插件机制的现成素材。5.2 测试失败时的处理路径若发现重大问题在 issue 跟踪器中提交 issue在dev 分支修复然后cherry-pick 到 release 分支不要直接在 stable 上改若改动量足够大则回到第 3 步版本锁定重新走一遍流程并递增 RC 编号rc1→rc2→ …。6. 正式发布版本号、标签与 Release NotesRC 全部通过测试后进入正式发布阶段6.1 正式版本号与标签将版本号更新为正式版本如1.11.0同步更新第 3 节列出的所有文件创建正式标签如v1.11.0创建正式 Release。6.2 编写 Release NotesRelease Notes 是整个发布流程中最需要「内容运营功底」的环节文档给出的指导原则非常具体尽早开始撰写不必等发布时才写可在发布过程中持续积累素材对比分支差异将当前 dev 分支与上一次发布进行比较找出全部变更只挑最重要的不要重复 commit logRelease Notes 是给「不想读完整提交历史的人」看的摘要按主题分组使用类似New features新特性、Bug Fixes缺陷修复、Decompiler反编译器、Rizin等标题对相关变更分组让读者能快速定位自己关心的领域。6.3 公告与里程碑收尾准备发布公告推文并发送到 Telegram 群组、reddit 等社区渠道若本次发布对应有 GitHub milestone在发布完成后关闭该 milestone。7. Bugfix 发布流程Bugfix 发布补丁版本与常规流程相似但有两个关键差异cherry-pick 而非合并将必要的 bugfix 从 devcherry-pick 到 stable只挑选修复不带入新功能递增第三位版本号x.y.n→x.y.(n1)即补丁版本只改 patch 位例如2.5.0→2.5.1对应 CMakeLists.txt 中的CUTTER_VERSION_PATCH变量。其余步骤翻译同步、版本号全仓库更新、打标签、创建 Release、测试与正式发布一致。8. 发布流程速查清单阶段关键动作命令 / 文件翻译合入 Crowdin 自动 PR更新子模块git submodule update translations见 deploy_translations.sh冻结dev 合并进 stablerizin 子模块指向对应分支git merge锁定锁定 rzghidra / rzdec 为 tag 或 commitdist/CMakeLists.txt 中的GIT_TAG版本号全仓库搜索旧版本号并同步更新CMakeLists.txt、docs/conf.py、src/re.rizin.cutter.appdata.xml 等RC打标签 pre-release 草稿git tag vX.Y.Z-rcNgit push origin vX.Y.Z-rcN测试全平台执行 Basic testing procedure见第 5 节清单正式发布更新正式版本号、创建 Release、填写分组 Release NotesGitHub Releases公告推文、Telegram、reddit 等渠道关闭 milestone—Bugfixdev 中 cherry-pick 到 stablepatch 位 1git cherry-pick9. 结语Cutter 的发布流程是一套典型的「双分支 子模块 版本锁定 RC 迭代」开源桌面应用发布工程实践translations 子模块保证了多语言同步的自动化dev/stable 分支分离实现了功能冻结与持续开发并行rzghidra 等插件版本锁定确保了发布产物的可复现性而「全代码库版本号同步 RC 草稿 冒烟测试清单」则把人为失误的概率降到最低。对于维护者而言遵循本文梳理的 14 步流程与 Bugfix 变体即可稳定、可预测地完成每一个版本的交付。提示发布流程属于维护工程范畴实际执行时请以当前仓库的 CI 配置如.github/workflows、appveyor.yml等是否存在、CMakeLists.txt 中的实际版本号当前为2.5.0系列以及 release-procedure.rst 的最新修订为准避免沿用文档中已过时的文件路径与版本示例。【免费下载链接】cutterFree and Open Source Reverse Engineering Platform powered by rizin项目地址: https://gitcode.com/gh_mirrors/cu/cutter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
