1. Demo 简介
是什么：
C盘智能管家（CleanGuard）是一款面向普通 Windows 用户的 C 盘智能清理与文件系统监控管理系统，以系统托盘常驻小工具的形态运行。
面向谁：
不懂技术的普通 Windows 用户 — 包括白领、学生用户等。他们日常使用电脑安装各种软件，但缺乏系统管理知识，需要一个「放心好用、一键搞定」的 C 盘清理工具。
主要功能：
- 多维度实时文件监控 — 通过 ReadDirectoryChangesW + RegNotifyChangeKeyValue + ETW 事件追踪，实时监控软件安装过程中写入 C 盘的所有位置（文件、注册表、缓存、日志、凭据），类似 IObit Uninstaller 的安装监控器，但覆盖面更广
- 智能卸载残留清理 — 软件卸载时，一键清除所有关联的残留文件和注册表项，所有删除默认先移到回收站，确保安全
- AI 智能安全分析 — 接入用户自带的大模型 API（支持 OpenAI、通义千问、豆包、DeepSeek、智谱 GLM 等），让 AI 分析每个文件的作用和安全性，给出清理建议，降低误删风险
- 基础清理 — 系统临时文件、软件缓存、浏览器缓存、回收站、缩略图缓存等常规清理一应俱全
- 托盘小工具形态 — 系统托盘常驻，点击弹出精美深色主题面板，CPU 空闲 ≤ 1%，内存 ≤ 100MB
2. Demo 创作思路
灵感来源：
我自己深受 C 盘空间不足的困扰。每次卸载软件后，C 盘依然被大量残留文件占据，但 Windows 自带的程序和功能面板只能看到「已安装」的软件，无法追踪那些散落在 AppData、ProgramData、注册表深处的残留。市面上的清理工具要么只做浅层缓存清理（治标不治本），要么功能复杂到需要技术背景才能用。
想解决的问题：
- 普通用户「不敢清理、不会清理」的困境 — 不知道哪些文件能删、删了会不会出问题
- 软件卸载残留无法彻底清除 — 散落在多个目录和注册表中的文件
- 现有工具缺乏智能判断 — 只能靠固定规则，无法理解文件的上下文含义
为什么做这个方向：
我认为「实时监控 + AI 智能分析」是解决上述问题的最佳方案。实时监控解决了「不知道软件写入了哪些文件」的问题，AI 分析解决了「不知道哪些文件能安全删除」的问题。两者结合，让普通用户也能安心清理系统空间。目前市面上没有产品将大语言模型应用于系统清理场景，这是一个真正的差异化创新点。
3. Demo 体验地址
GitHub 仓库地址： wuke3/CleanGuard
体验说明：
- 请使用 Windows 系统打开并运行
- 首次运行可能需要管理员权限（用于文件系统和注册表监控）
- AI 分析功能需要在设置面板中配置 API Key 后才能使用
- 建议先尝试「基础清理」功能，再体验「文件监控」和「AI 分析」
4. TRAE 实践过程
4.1 开发流程概览
整个 Demo 使用 TRAE IDE 从零开始开发，技术栈为 Electron + C++ N-API。开发过程大致分为以下阶段：
阶段一：项目初始化与架构设计
- 在 TRAE IDE 中创建项目，配置 Electron + C++ N-API 混合架构
- 搭建 CMake 构建系统，配置 N-API 模块编译环境
阶段二：C++ 后端核心引擎开发
- 实现文件系统监控引擎（基于 ReadDirectoryChangesW API，递归监控 C 盘关键目录）
- 实现注册表监控引擎（基于 RegNotifyChangeKeyValue，监控 HKLM/HKCU 下的软件注册表变化）
- 实现智能清理引擎（系统临时文件、缓存、浏览器缓存等扫描与清理）
- 实现软件生命周期检测（枚举 Uninstall 注册表键，对比前后列表检测安装/卸载事件）
- 所有引擎通过 N-API 暴露为 Node.js 可调用的接口
阶段三：Electron 前端 UI 开发
- 实现系统托盘图标和右键菜单
- 实现主面板 UI（仪表盘：磁盘用量、垃圾文件统计、监控状态）
- 实现监控面板 UI（文件变更记录、注册表变更记录、实时状态）
- 实现清理面板 UI（扫描结果列表、AI 安全标记、一键清理）
- 实现 AI 设置面板 UI（服务商选择、API Key 输入、模型配置）
阶段四：AI 智能分析集成
- 实现 OpenAI 兼容格式的多模型 API 调用模块
- 设计 AI Prompt 模板（让大模型分析文件安全性、判断删除影响）
- 实现流式返回和结果解析
- 将 AI 分析结果与清理面板联动（安全标记、自动取消勾选危险项）
阶段五：测试与优化
- 功能测试：各模块独立测试 + 联调测试
- 性能优化：确保 CPU 空闲 ≤ 1%，内存 ≤ 50MB
- UI 打磨：深色主题、毛玻璃效果、动画过渡
关键任务Session ID：
• Session 1：.1537579399266768:9f6984b1ac2907b0e724a1a4b8dde6ef_6a5624a411afbb530d96acf8.6a562656489b14e4c4c4bb15.6a5626551533f6413ffe7124:Trae CN.T(2026/7/14 20:06:46)
• Session 2：.1537579399266768:a2b3836227da0523fd3aa89864488faf_6a5624a411afbb530d96acf8.6a56f96e84577625d52702f9.6a56f96d11c94c624c3b9972:Trae CN.T(2026/7/15 11:07:26)
• Session 3：.1537579399266768:7671afd52cb9cc610ad6fc9d6e527421_6a5624a411afbb530d96acf8.6a571afd84577625d5271594.6a571afd11c94c624c3b9973:Trae CN.T(2026/7/15 13:30:37)
• Session 4：.1537579399266768:2f93fb549dd901bb5868dbc12d349868_6a5624a411afbb530d96acf8.6a57621684577625d52725c3.6a57621511c94c624c3b9975:Trae CN.T(2026/7/15 18:33:58)
4.2 开发关键步骤截图
4.3 开发中的踩坑与经验
踩坑 1：C++ N-API 模块编译
- CMake 配置 N-API 模块编译时，Node.js 的头文件路径和链接库配置容易出错。解决方案是在 CMakeLists.txt 中通过
node -p "require('path').join(process.execPath, '..', '..', 'include')"动态获取 Node.js 的 include 路径，避免硬编码。 - 另外需要注意 Electron 的 Node.js 版本和系统 Node.js 版本可能不同，需要用
electron --version确认后配置对应的NODE_RUNTIME和NODE_RUNTIME_VERSION。
踩坑 2：ReadDirectoryChangesW 的缓冲区溢出
- 当监控目录下有大量文件变化时（如软件安装过程），ReadDirectoryChangesW 的缓冲区可能不够大导致丢失事件。解决方案是将缓冲区设置为 64KB，并在回调中检查
ERROR_NOTIFY_ENUM_DIR错误码，如果触发则重新读取目录快照做增量对比。
踩坑 3：注册表监控的性能问题
- RegNotifyChangeKeyValue 只能监控单个注册表键，而 HKLM\SOFTWARE 下有大量子键需要分别注册监控。解决方案是只监控关键路径（Uninstall 键 + 少数常用软件键），对其他路径采用定时快照对比的方式做补充。
踩坑 4：AI API 调用的超时处理
- 大模型 API 响应时间不稳定，有时会超过 30 秒。解决方案是设置 30 秒超时 + 重试机制（最多重试 2 次），同时在前端显示流式的分析进度，避免用户长时间等待无反馈。
经验总结：
- TRAE 在生成 Electron 前端代码方面表现非常出色，HTML/CSS/JS 的质量很高，几乎不需要手动调整
- C++ 底层代码的生成质量中等偏上，但 Windows API 的细节（如缓冲区大小、错误处理）需要人工审查和调整
- 建议先让 TRAE 生成一个最小可用版本，跑通后再逐步添加功能，而不是一次性生成全部代码