我平时折腾 Windows 系统比较多最近系统里装了太多软件右键菜单被各种“用XX打开”、“发送到XX”、“管理XX”塞得满满当当找个“新建文件夹”都要翻半天。本来想找个现成的右键管理工具但要么要付费要么界面看着就别扭。正好手头在体验 Gemini 3.8 Flash就突发奇想——能不能直接用这个模型帮我写一个 Windows 右键菜单管理工具结果比我预想的顺利得多从出方案到跑通主要功能只花了一个晚上速度确实快效果也真不错。这篇就把我的完整思路、实操过程和踩过的坑都分享出来。这工具解决的是 Windows 用户一个很普遍的痛点右键菜单的清理、备份和还原。市面上的工具要么收费要么不够透明而自己用 AI 辅助生成一个不仅成本低代码完全可控还能照着个人习惯定制功能。如果你也经常被臃肿的右键菜单困扰或者想试试用 AI 写点实用的小工具这篇的内容应该能给你不少参考。1. 整体设计先想清楚要做什么再去问 AI1.1 右键菜单到底“乱”在哪Windows 的右键菜单主要分两类一类是传统右键菜单就是你 CtrlShift 右键或者从 Win32 程序里看到的那个完整菜单另一类是 Windows 10 1809 以后引入的新版紧凑菜单默认只显示部分常见操作要再点一次“显示更多选项”才能看到全部。通常我们打开右键菜单感觉“卡”和“乱”问题多数出在传统菜单那一大串不常用的项上。从注册表层面看右键菜单项主要存在这几个位置HKEY_CLASSES_ROOT*\shell对所有文件类型生效的菜单项HKEY_CLASSES_ROOT\Directory\shell 和 HKEY_CLASSES_ROOT\Directory\Background\shell分别对应右键点击文件夹、右键点击文件夹空白处的菜单HKEY_CLASSES_ROOT*\shell\AppName 下的 command 子键存放具体的执行命令而新版 Windows 11 的紧凑菜单很多时候是一部分工具通过专门的包或者应用扩展注册的所以单纯删注册表不一定能去掉反过来我们自己加的自定义菜单项如果不走官方注册逻辑也可能不会显示在紧凑菜单里。这个差异对工具的设计影响很大我在初版方案里就明确了先实现传统右键菜单的管理和备份恢复再考虑优化 Windows 11 的紧凑菜单展示。1.2 为什么选 Gemini 3.8 Flash 来辅助开发我选 Gemini 3.8 Flash不是因为它名字里带“Flash”听起来快而是因为这类轻量级模型在几个方面确实适合生成系统工具类的小软件推理响应速度好生成简单窗口、注册表操作这类常规代码时基本是我这边问题刚敲完那边代码就出来了开发节奏不会被等结果打断。对 Windows 注册表和 .NET/C# 的语法掌握得比较扎实实测下来它直接生成的 Registry 操作、ListView 绑定逻辑比较靠谱不像通用聊天模型那样容易给一堆过时的 API。对话上下文理解不错我中途把初始方案优化了两次它都能记得前面对话里的定义不会出现改一处丢一处的毛病。当然这里不是让大家盲目全信 AI 的输出。模型是辅助核心设计还得自己把住尤其是注册表相关的操作必须理解清楚了再执行。我的角色更像“产品经理 测试员”把需求拆清楚让 AI 去写代码跑完再自己审查。1.3 工具核心功能拆解我给这个工具定的核心功能就四个枚举扫描常见注册表路径下的右键菜单项区分文件右键、文件夹右键、目录背景右键等场景。管理支持禁用/启用而不是直接删除。禁用只是重命名或移除 Shell 键的默认值备份容易、恢复也安全。备份/恢复一键导出当前右键菜单项的注册表信息方便改坏时还原。清理建议用一组内置的“常见安全项”清单标出哪些建议保留、哪些可以禁用。实际做下来这个功能范围刚刚好既解决了主要痛点又不会因为过度设计让 AI 生成庞大的工程。如果一上来就要求“做个完整的右键菜单全功能管理软件”生成结果大概率是散装代码跑都跑不起来。2. 核心细节解析注册表操作里的门道2.1 枚举菜单项时的关键选择最开始我让模型直接枚举 HKEY_CLASSES_ROOT 下的所有键结果代码跑一遍要半天而且列出来的项跟右键菜单实际显示的内容对不上。后来我梳理清楚了必须优先枚举这几个场景路径别贪多对所有文件HKEY_CLASSES_ROOT*\shell对文件夹HKEY_CLASSES_ROOT\Folder\shell和 HKEY_CLASSES_ROOT\Directory\shell 效果类似对目录背景HKEY_CLASSES_ROOT\Directory\Background\shell对磁盘分区HKEY_CLASSES_ROOT\Drive\shell枚举命令时注意默认值是关键子键的默认值等于显示在菜单上的名称command 键里的默认值等于程序执行路径。有的菜单项显示名称会带 前缀比如Open with VSCode这表示字母 O 是键盘快捷键在工具显示名称时要记得去掉 不然用户看着很奇怪。在工具界面上我会用场景分组来展示每个菜单项显示“显示名称”、“命令路径”、“所在注册表路径”、“状态启用/禁用”。这里有个很实用的技巧如果不清楚某个项对应什么软件就把命令路径拿到设备管理器或者文件管理器里看看指向哪里。cmd /c或 PowerShell 开头的命令通常是一键脚本禁用前建议先查一下用途。2.2 禁用与启用重命名比删除安全很多右键菜单工具提供“删除”功能但我不建议直接删。注册表项删了虽然简单但如果是某个软件还在用的项重启后软件可能会重新写回要么报错更麻烦的是你删的时候没备份想找回就难了。我在设计里让 Gemini 生成的是重命名方案把目标子键重命名为原名_Disabled_时间戳不让它叫shell下的合法项右键菜单就不会显示。启用时再把名字改回来。好处有三个操作可逆随时恢复不改动 command 里的内容避免命令路径丢失不用管理员权限也能对 HKCU 下的项生效当然 HKLM 下还是需要管理员生成代码时我特意加了约束“必须先检查源键是否存在再重命名重命名失败时回滚并给出错误信息”。实际测试了几次误操作程序都能很好地报错不会崩溃或产生半修改状态。2.3 备份导出不仅是.reg文件最早的备份功能我只是让 AI 生成一个reg export命令后来发现不够用。reg export导出的文件虽然能双击恢复但无法选择性恢复某一个菜单项而且对编码敏感容易乱。最终版本我做成了两种备份完整导出把四个关键分支导出为.reg文件适合整体恢复。单项导出针对当前选中的菜单项只导出它对应的注册表分支适合只恢复某一条。此外工具每次做“禁用”操作时自动在当前目录的backup文件夹里生成一条 JSON 记录记录原文位置、原名称和操作时间。这样就算界面里没有“恢复”我也能从日志里捞回旧配置。这个细节 Gemin 最初没设计是我在实测中发现“还得自己抠注册表”太麻烦才让 AI 加的。3. 实操过程从需求到可运行工具的完整记录3.1 环境准备与前置条件开发工具建议选 C# .NET 6 的 WPF 或 WinForms原因是操作注册表的 API 在 .NET 里封装得最成熟生成出来的代码结构清晰也容易改成单文件发布。我自己用的是WinForms .NET 6因为生成的 UI 代码更简单调试方便。如果你没有安装 .NET SDK提前装好另外因为要操作 HKLM建议“以管理员身份运行”开发环境和编译后的工具否则你会发现枚举没问题但禁用某些项时直接报 Access Denied。我第一次跑的时候没注意权限点“禁用”就报错。后来在项目里加了清单文件app.manifest设置requestedExecutionLevel levelrequireAdministrator重新编译后就顺滑了。3.2 用 Gemini 3.8 Flash 生成初始版本的对话范式很多人让 AI 写代码失败多半是问题描述太笼统。我分享一下我用的提示词模板基本是“角色 任务 约束 输出格式”你是一位熟悉 Windows 注册表和 C# WinForms 开发的工程师。 请写一个 Windows 右键菜单管理小工具具备以下功能 1. 枚举 HKEY_CLASSES_ROOT\*\shell、HKEY_CLASSES_ROOT\Directory\shell、HKEY_CLASSES_ROOT\Directory\Background\shell 下的所有菜单项 2. 对每个菜单项读取显示名称默认值、命令command 键的默认值 3. 支持禁用、启用重命名实现不直接删除 4. 支持导出当前列表为 reg 文件和 JSON 备份 5. UI 使用 ListView列分别为显示名称、命令、注册表路径、状态。 要求优先使用 Microsoft.Win32.Registry 类错误处理完整代码结构清晰关键步骤注释中文。Gemini 3.8 Flash 第一次输出的代码大概 400 行结构基本正确但问题也不少。比如枚举时没有递归处理shell和shell\open的差异导致部分子功能读取不到。我没有重新整个给它而是直接贴出错误片段问它“这段逻辑哪里有问题如何修”它就给了补丁代码。以“补丁式对话”的方式迭代比让它反复生成完整项目高效得多。3.3 参数计算与注册表路径校验示例在开发“备份 JSON 记录”功能时我让 AI 把菜单项的 KeyPath 做了标准化。因为HKEY_CLASSES_ROOT本质上是HKEY_LOCAL_MACHINE\Software\Classes的一个映射视图所以备份记录里最好存完整路径而不是只存HKCR\*\shell\xxx。这样以后恢复时可选择的 handler 更多。我梳理的映射规则是这样的界面显示路径实际注册表路径作用范围所有文件HKLM\Software\Classes*\shell右键普通文件时显示文件夹HKLM\Software\Classes\Directory\shell右键文件夹时显示目录背景HKLM\Software\Classes\Directory\Background\shell在文件夹空白处右键显示磁盘分区HKLM\Software\Classes\Drive\shell右键 C 盘、D 盘等分区时显示生成工具时界面里展示路径不要直接用HKCR而是显示成HKLM\Software\Classes\*\shell。这样做的好处是手动打开注册表编辑器核对时可以直接用 regedit 的地址栏粘贴路径跳转不会被HKCR这种伪根键绕晕。其实这一步是我在测试时发现“按 HKCR 路径去 regedit 找不到”才修正的新手尤其容易踩。3.4 界面布局与交互细节WinForms 界面我没让 AI 自由发挥而是给了明确的布局要求顶部一个工具栏扫描菜单、禁用选中项、启用选中项、导出备份、恢复备份中间一个 ListView勾选复选框CheckBoxes true状态列显示已启用/已禁用底部一个状态栏显示扫描出来的菜单项数量、当前选中的路径实测中有一个很细节的问题选中 ListView 的一行再点“禁用”和勾选复选框再点“禁用”是两个逻辑。早期版本只处理了选中行导致用户想批量禁用时只能一行行点。我后来让 Gemin 改成“优先收集所有勾选项如果没有勾选则使用当前选中行”这才符合用户直觉。还有一个小优化是“搜索过滤框”。当菜单项超过 100 个时滚列表找太久我加了一个文本框按显示名称实时过滤。这个功能我自己觉得比花哨的图标自定义实用得多。3.5 编译、部署与运行测试在项目目录下执行dotnet build -c Release然后把生成的 exe 从bin\Release\net6.0复制出来测试。我加了一个参数--scan-only表示只扫描并打印结果不做任何修改方便首次运行时快速确认工具是否正常工作右键菜单管理器.exe --scan-only扫描结果如果能看到几十条菜单项说明注册表读取逻辑正常。接着我先拿一条不太重要的菜单项试禁用比如某次安装后残留的Edit with 记事本测试项重启资源管理器后确认菜单消失了再试启用确认能恢复。整个流程走完工具才算基本可用。资源管理器重启命令是这样的taskkill /f /im explorer.exe start explorer.exe右键菜单刷新可能会遇到 explorer.exe 被杀后桌面图标短暂消失这正常不用慌。4. 常见问题与排查技巧实录4.1 扫描结果为空或项很少最常见原因是权限不足。程序没有以管理员身份运行时读取 HKLM 权限有限自然漏项。我统一推荐在主程序加app.manifest强制管理员权限。另一个原因是注册表路径不对——比如原软件把菜单项写在HKEY_CURRENT_USER\Software\Classes\*\shell而工具只扫了 HKLM导致漏掉当前用户的自定义项。所以工具同时扫描 HKCU 和 HKLM 两个根键下的 Classes 视图并且 UI 上标注“当前用户项”还是“全局项”。4.2 禁用后菜单还在有些项目的命令写在HKEY_CLASSES_ROOT\*\shell\xxx\command里重命名是有效的但有些软件注册的是静态扩展比如用 COM 组件方式注册即HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers光靠重命名 shell 子键是删不掉菜单的。这种情况我已经在工具的提示里写明“对于 ContextMenuHandlers 类的菜单建议直接禁用 CLSID 对应的 InprocServer32或用第三方软件状态管理本工具在 1.0 版不处理以免误删系统组件。”4.3 恢复时提示“注册表路径不存在”这是因为备份记录里存的路径是“显示名 时间戳”对应的路径但用户关闭工具后某条项被 Windows 清理或软件卸载时删掉了。我的经验是恢复功能要做存在性检查如果目标不存在直接提示用户手动检查不要贸然创建一堆空的 shell 键那样反而污染注册表。这里给个排查表方便照着走现象可能原因处理方法扫描项少未用管理员运行加 app.manifest 或右键管理员启动禁用无效菜单项是 shellex 扩展工具提示不支持另行手动处理启用后菜单没回来原路径已丢查看 backup 下的 JSON手动 regedit 对照导出 reg 文件双击没效果编码不对用 reg export 命令导出而不是手动写文本文件4.4 AI 生成代码的常见坑Gemini 3.8 Flash 生成代码有个我很欣赏的点它不太会擅自加额外的弹窗或没用的功能。但它在处理RegistryKey.OpenSubKey返回 null 时偶尔会漏判导致NullReferenceException。跑扫描时遇到没有 command 子键的菜单项就崩了。我在迭代时要求它“所有对子键的访问前必须判空每个可能返回 null 的地方都要过滤。”之后稳定性大幅提升。另外是“运行你的工具前建议先开虚拟机或有一个恢复点”。Windows 注册表不像改配置可以热回滚某些项删错了可能导致系统异常。我自己的测试环境是 VMware 里跑 Windows 11出了问题直接快照恢复。虽然我们做的是可逆操作但多一道保险总没错。5. 经验沉淀AI 辅助开发工具的效率从哪来5.1 提问越具体产出的代码越可靠我统计了一下整个项目里我给 Gemini 3.8 Flash 发的大概 40 多条消息其中有效改动需求的字符串可以拆成几个类别类型示例占比功能新增增加单项导出功能25%边界修复command 为空时跳过40%界面调整ListView 增加状态列15%逻辑补全批量禁用时优先取勾选项20%边界修复占大头也印证了一个规律AI 的初稿通常能实现主流程但边界条件和异常处理需要我们模拟真实场景去逼出来。5.2 善用“负例”引导与其告诉 AI “要有错误处理”不如直接给它错误场景。我会说“假如一次只导出选中的单个菜单项但该菜单项的 command 键缺失程序应该怎么处理”然后让它针对这个场景给出修复代码。这样产出的逻辑是“所见即所得”而不是它自己脑补的错误处理。5.3 后续扩展空间当前版本已经能帮我解决右键菜单清理的问题但还有不少可延展的方向比如支持 Windows 11 紧凑菜单的配置与备份直接修改 V2 的扩展配置。增加一键策略模板比如“清理所有显卡右键项”、“恢复 Windows 经典菜单”。把备份上传到本地或远端做成“配置同步”能力。如果这篇内容有人感兴趣我下个版本会做其中一个方向到时候再来分享。至少从这次经历来看用 Gemini 3.8 Flash 辅助写系统小工具的路子是走得通的关键是别把它当“全自动开发者”而是当一个特别熟悉 Windows API 的结对编程同伴——你问得越细它越能帮上忙。