跪求大佬出个ai编写好看的web界面tui界面或者任何好看界面的教程，和ai，debug，修那种ai都查不出的教程吧 ai写的界面真的是一坨，对于没代码基础的我来说让他改越改越离谱，体现出没基础只能使用高端的gpt模型才行，不过拉闸只能用d老师了，然后有没有法子ai自动debug，现在发现有些bugai查不出来，只能vscod里面的调试一个个断点复制错误的丢ai里面了 3 个帖子 - 3 位参与者 阅读完整话题
IT之家 6 月 5 日消息，FlagLeft 安全研究团队于当地时间 6 月 2 日发文，披露了 Microsoft 365 安卓应用中存在的一项严重漏洞。好消息是这一漏洞在披露前便已被修复。 安全研究人员表示，微软旗下的多款 Android 移动应用在发布过程中由于开发人员的疏忽，不慎将一个用于测试流程的调试标记（Debug Flag）带入了正式生产版本中。 这一低级失误直接导致其安全校验机制失效，使得安装在同一设备上的任何第三方应用，都能在用户完全不知情的情况下静默窃取 Microsoft 365 账户的登录凭证（Token），进而以已登录用户的身份读取邮件、访问文件、查看日历乃至发送消息 受该漏洞影响的重点应用包括 Word、PowerPoint、Excel、Microsoft 365 Copilot、Microsoft Loop 以及 OneNote。 目前微软已紧急修复了相关问题，并针对不同应用发布了相应的安全补丁，建议所有受影响的用户立即通过应用商店更新至最新版本。 安全研究人员指出，Teams 应用因未启用该调试标志而不受影响。但这些应用在谷歌 Play 商店的累计下载量达数十亿次。 漏洞的技术原理并不复杂。微软为了在正常情况下提升用户体验，在 Microsoft 365 应用之间设计了一种凭证共享机制（即单点登录）。例如，当用户登录了 Word 之后，再打开其他微软应用无需重复验证即可使用同一账户。 正常的令牌交接过程中，应用需要校验请求来源是否为受信任的微软应用。然而，由于开发人员的疏忽。安卓版 Microsoft 365 在正式版本中保留了 setIsDebugMode (true)。这一本属于开发阶段的调试标记在进入正式生产环境后，直接跳过了针对调用方身份的合法性校验，导致任何未经验证的第三方本地应用只需发送特定请求，即可直接拦截并获取账户登录凭证，全程无需用户密码，也不会弹出登录页面，甚至无需请求任何可能引起用户警觉的权限。 研究人员进一步指出，被泄露的凭证属于危险系数极高的 FOCI（Family of Client IDs）特殊凭证。此类凭证不仅可以长期重复使用和静默刷新，且在其被恶意利用时，其产生的网络流量与系统日志表现得与用户正常使用完全一致，故极其隐蔽。 攻击者通过本地恶意 App 劫持该凭证后，无需获取用户的账号密码，也无需申请任何敏感的安卓系统权限，便能直接以受害者账户的身份为所欲为，包括读取、修改和发送电子邮件、翻阅云端文档、查看日程表等。 随后，研究人员利用 AI 进行了分析，确认该安全漏洞因共享 SDK 的缘故大范围蔓延至 M365 全系六款主力安卓应用中。“原本以为只是一个应用的问题，后来发现是 M365 安卓应用的共同模式，一个简单的 Bug 影响了总计数十亿次下载的应用。” 针对这一重大供应链与发布失误，研究团队已提前向微软安全响应中心（MSRC）进行了负责任的漏洞披露。 微软方面随后确认了上述漏洞并发布了安全指南，针对不同应用所面临的风险分别赋予了不同的 CVE 编号与危险评级。 其中，Microsoft 365 Copilot 安卓版对应的漏洞编号为 CVE-2026-41100（CVSS 评分 4.4，中危）；Word 安卓版对应 CVE-2026-41101（CVSS 评分 7.1，高危）；PowerPoint 对应 CVE-2026-41102（CVSS 评分 7.1，高危）；而微软 Office 核心组件整体的漏洞则同样归于 CVE-2026-41102（CVSS 评分达 7.7，重要级别）。 微软表示，相关漏洞的修复程序均已包含在 5 月中旬及后续的更新日志中，企业 IT 管理员应立即核查组织内部托管的安卓设备，确保所有相关办公软件处于最新安全版本状态。
关于 AI 工具，前司提供的一直是 Cursor ，其应该是去年年底新推出的 Debug 模式，非常好用，让我印象特别深刻。 有一个例子是当时接手一个 CocosJs 项目，其中虚拟列表算法渲染在某些 case 下会有异常情况需要我紧急修复。当时我完全不熟悉 Cocos 背景，只是简单和其描述了一下，十分钟之内就定位并且解决了问题，当时给予我极大的震撼。 话说话来，最近在另一家公司，提供的是 Codex 和 ClaudeCode （魔改） CLI 的 AI 能力，最近在使用 AI 解决问题时，整个流程完全没有之前 Cursor Debug 模式智能化，挺恼火，网上检索了下也没找到类似的工具/讨论，倒是有很多夸赞 Cusor Debug 的贴，但也有个本站 Debug 误删 E 盘的。。 遂来请教一下大家在用 CC or Codex 等工具时，是什么姿势 Debug 的？ 附上 Cursor Debug 流程： 探索并提出假设 ：Agent 会探索相关文件、构建上下文，并针对潜在根本原因生成多个假设。 添加埋点 ：Agent 会添加日志语句，将数据发送到运行在 Cursor 扩展中的本地调试服务器。 复现 bug ：Debug Mode 会让你复现 bug ，并提供具体步骤。这能让你始终参与调试流程，并确保 Agent 捕获到真实的运行时行为。 分析日志 ：复现完成后，Agent 会审查收集到的日志，根据运行时证据识别实际根本原因。 实施针对性修复 ：Agent 会进行有针对性的修复，直接解决根本原因，通常只需改动几行代码。 验证并清理 ：你可以重新运行复现步骤来验证修复。一旦确认无误，Agent 会移除所有埋点。 整个过程用户只需要负责 描述 和 复现 。Cursor 负责自动生成假设，对应地方进行日志打点（发送到 Cursor 的一个本地服务器，写到特定目录，工作流会读取该目录内容，省去了粘贴步骤），真的特别方便。
the Guardian – 1 Jun 26 Debugging: Google requests permission to release 32m mosquitoes in California... Company asks US government to release army of sterile male mosquitoes to lower number of illness-spreading bugs [!quote]+ 谷歌希望 “用好的虫子来阻止坏的虫子”，而且它说的不是编码。这家科技公司已请求美国政府批准在加利福尼亚州和佛罗里达州释放多达 3200 万只经过消毒的蚊子 作为其成功的 "调试 "计划的一部分，谷歌正在利用其技术专长培养一支不育雄蚊大军，以减少传播疾病的蚊虫数量。蚊子是世界上最致命的动物，每年因传播登革热、西尼罗河病毒、寨卡病毒、基孔肯雅病毒和疟疾等致命疾病而死亡的人数超过世界上任何其他生物。 联邦登记处的一份通知显示，美国环境保护局（EPA）正在审查谷歌提出的在佛罗里达州和加利福尼亚州每年释放多达 1600 万只蚊子的请求，时间跨度为两年。环保局将在6月5日结束的公众评议期后决定是否批准谷歌的试验性使用许可申请。 雄蚊不叮人，也不携带疾病。谷歌正在测试的主要方法之一是用一种名为狼杆菌的天然细菌饲养雄蚊，这种细菌能阻止雄蚊与野生雌蚊繁殖后代。谷歌在一篇博文中解释说，当受感染的雄蚊试图与野生雌蚊交配时，雌蚊的卵就不会孵化：“每一代蚊子的数量都在减少”。 sfgate.com Client Challenge dw.com Why Google wants to release millions of mosquitoes in the US Google's Debug research program plans to release millions of sterile mosquitoes to fight species that spread diseases like dengue. How does the method work — and should humans interfere with nature like this? 8 个帖子 - 7 位参与者 阅读完整话题
Superpowers 整个框架太大，我想只使用 brainstorming、writing-plans、systematic-debugging 这3 个，是否可以直接把项目中的这 3 个 skill 复制出来单独使用？ 10 个帖子 - 5 位参与者 阅读完整话题
俺在用ai跑公司一套php代码，层级也不算深就是封装的有点过度了，每次用ai排查bug的时候token哐哐的掉，比完整开发新代码掉的还多，不知道是不是我使用方法错了，想请教一下佬们~ 3 个帖子 - 3 位参与者 阅读完整话题
想问下各位佬，如何让 ai 自己去 debug 工程代码呢，常用的 chrome-devtools 也只是模拟用户操作浏览器，遇到需要去跑代码逻辑的时候，ai 大多数场景下都是基于提供的输入参数进行推测，没有实际去 debug 代码，各位佬有没有什么好用的 skill 或者工具可以推荐下？可以让 ai 在分析bug 的时候去做真实的 debug 呢 1 个帖子 - 1 位参与者 阅读完整话题
作为一名曾经十多年前手写过上万行 bat 脚本,编写过多个 vbs/JScript 脚本的老登, 深知 Windows 系统在命令行/批处理/脚本方面是有多大的天坑, 微软在这方面的投入是多么的轻视, 给开发者的体验相比 Unix 差之千里. 作为普通 Windows 用户不了解这方面的细节就不说了 但是为何大多数使用 Windows 操作系统的开发者都能忍受那羸弱不堪的命令行解释器(CMD/Powershell) 为例避免 CMD/Powershell 的各种坑,在终端执行命令或者编写脚本, 考虑到系统兼容与跨平台一致性体验我向来推崇使用 Msys2 或 Cygwin, 其次才是 WSL/VM, 再不济也可以使用 Python
作为一名曾经十多年前手写过上万行 bat 脚本,编写过多个 vbs/JScript 脚本的老登, 深知 Windows 系统在命令行/批处理/脚本方面是有多大的天坑, 微软在这方面的投入是多么的轻视, 给开发者的体验相比 Unix 差之千里. 作为普通 Windows 用户不了解这方面的细节就不说了 但是为何大多数使用 Windows 操作系统的开发者都能忍受那羸弱不堪的命令行解释器(CMD/Powershell) 为例避免 CMD/Powershell 的各种坑,在终端执行命令或者编写脚本, 考虑到系统兼容与跨平台一致性体验我向来推崇使用 Msys2 或 Cygwin, 其次才是 WSL/VM, 再不济也可以使用 Python
作为一名曾经十多年前手写过上万行 bat 脚本,编写过多个 vbs/JScript 脚本的老登, 深知 Windows 系统在命令行/批处理/脚本方面是有多大的天坑, 微软在这方面的投入是多么的轻视, 给开发者的体验相比 Unix 差之千里. 作为普通 Windows 用户不了解这方面的细节就不说了 但是为何大多数使用 Windows 操作系统的开发者都能忍受那羸弱不堪的命令行解释器(CMD/Powershell) 为例避免 CMD/Powershell 的各种坑,在终端执行命令或者编写脚本, 考虑到系统兼容与跨平台一致性体验我向来推崇使用 Msys2 或 Cygwin, 其次才是 WSL/VM, 再不济也可以使用 Python
作为一名曾经十多年前手写过上万行 bat 脚本,编写过多个 vbs/JScript 脚本的老登, 深知 Windows 系统在命令行/批处理/脚本方面是有多大的天坑, 微软在这方面的投入是多么的轻视, 给开发者的体验相比 Unix 差之千里. 作为普通 Windows 用户不了解这方面的细节就不说了 但是为何大多数使用 Windows 操作系统的开发者都能忍受那羸弱不堪的命令行解释器(CMD/Powershell) 为例避免 CMD/Powershell 的各种坑,在终端执行命令或者编写脚本, 考虑到系统兼容与跨平台一致性体验我向来推崇使用 Msys2 或 Cygwin, 其次才是 WSL/VM, 再不济也可以使用 Python
作为一名曾经十多年前手写过上万行 bat 脚本,编写过多个 vbs/JScript 脚本的老登, 深知 Windows 系统在命令行/批处理/脚本方面是有多大的天坑, 微软在这方面的投入是多么的轻视, 给开发者的体验相比 Unix 差之千里. 作为普通 Windows 用户不了解这方面的细节就不说了 但是为何大多数使用 Windows 操作系统的开发者都能忍受那羸弱不堪的命令行解释器(CMD/Powershell) 为例避免 CMD/Powershell 的各种坑,在终端执行命令或者编写脚本, 考虑到系统兼容与跨平台一致性体验我向来推崇使用 Msys2 或 Cygwin, 其次才是 WSL/VM, 再不济也可以使用 Python
作为一名曾经十多年前手写过上万行 bat 脚本,编写过多个 vbs/JScript 脚本的老登, 深知 Windows 系统在命令行/批处理/脚本方面是有多大的天坑, 微软在这方面的投入是多么的轻视, 给开发者的体验相比 Unix 差之千里. 作为普通 Windows 用户不了解这方面的细节就不说了 但是为何大多数使用 Windows 操作系统的开发者都能忍受那羸弱不堪的命令行解释器(CMD/Powershell) 为例避免 CMD/Powershell 的各种坑,在终端执行命令或者编写脚本, 考虑到系统兼容与跨平台一致性体验我向来推崇使用 Msys2 或 Cygwin, 其次才是 WSL/VM, 再不济也可以使用 Python
作为一名曾经十多年前手写过上万行 bat 脚本,编写过多个 vbs/JScript 脚本的老登, 深知 Windows 系统在命令行/批处理/脚本方面是有多大的天坑, 微软在这方面的投入是多么的轻视, 给开发者的体验相比 Unix 差之千里. 作为普通 Windows 用户不了解这方面的细节就不说了 但是为何大多数使用 Windows 操作系统的开发者都能忍受那羸弱不堪的命令行解释器(CMD/Powershell) 为例避免 CMD/Powershell 的各种坑,在终端执行命令或者编写脚本, 考虑到系统兼容与跨平台一致性体验我向来推崇使用 Msys2 或 Cygwin, 其次才是 WSL/VM, 再不济也可以使用 Python
作为一名曾经十多年前手写过上万行 bat 脚本,编写过多个 vbs/JScript 脚本的老登, 深知 Windows 系统在命令行/批处理/脚本方面是有多大的天坑, 微软在这方面的投入是多么的轻视, 给开发者的体验相比 Unix 差之千里. 作为普通 Windows 用户不了解这方面的细节就不说了 但是为何大多数使用 Windows 操作系统的开发者都能忍受那羸弱不堪的命令行解释器(CMD/Powershell) 为例避免 CMD/Powershell 的各种坑,在终端执行命令或者编写脚本, 考虑到系统兼容与跨平台一致性体验我向来推崇使用 Msys2 或 Cygwin, 其次才是 WSL/VM, 再不济也可以使用 Python
作为一名曾经十多年前手写过上万行 bat 脚本,编写过多个 vbs/JScript 脚本的老登, 深知 Windows 系统在命令行/批处理/脚本方面是有多大的天坑, 微软在这方面的投入是多么的轻视, 给开发者的体验相比 Unix 差之千里. 作为普通 Windows 用户不了解这方面的细节就不说了 但是为何大多数使用 Windows 操作系统的开发者都能忍受那羸弱不堪的命令行解释器(CMD/Powershell) 为例避免 CMD/Powershell 的各种坑,在终端执行命令或者编写脚本, 考虑到系统兼容与跨平台一致性体验我向来推崇使用 Msys2 或 Cygwin, 其次才是 WSL/VM, 再不济也可以使用 Python
大家慎用 Windows 系统下 Cursor 的 Debug 模式。 我已被 Cursor 误删 E 盘上 921GB 的重要数据。我有备份，但最新备份是 2024 年的。 手机码字，电脑在恢复数据，不敢再开任何应用。事故现场截图我等数据恢复完再贴上。事发过程简述如下。 近日业余时间，本来在用 Cursor 愉快地 「 vibe coding 」一个有趣的个人开源项目（此处我必须模糊表述，想留点悬念，等数据恢复处理完，收收尾会发布。本来憋了个大的准备发布时发个帖子，还想象了项目发布后和其他 V 友一样获得点关注，没想到最后关头 Cursor 给我拉了坨大的。但我不恨 Cursor ，已经很惊艳了。）。 继续说。项目即将完成，我整在添加和调试一些 Demo 。 调试过程中，考虑将所有依赖 Node 的 Demo ，统一升级到较新的 Node 版本。我和 Cursor 一起评估规划了方案，Cursor 建议我直接统一依赖到 Node24+ 。 方案制定好了，我想到我本机的 Node24 有点问题，一是 npm install 无控制台日志输出（ npm install --verbose 才能看到日志），二是 npm install 下载 Electron 依赖时，会卡在 postinstall { code: 0, signal: null }（国内镜像源能解决此问题，但我比较排斥）。于是我让 Cursur 帮我排查。 此时 Cursor 是开着上文提到的那个项目的，我将 Cursor 切到了 Debug 模式，给 Cursor 如下的提示词（回忆版且适当概括）： ① 我的操作系统是 Windows 10 ，使用解压版的 nvm 管理多个版本的 Node ，我下载了多个版本的 Node 解压版，解压并以 vxxxx （版本号）的形式命名后放在了 nvm 根目录。nvm list 可正常识别，nvm use 可正常完成 Node 版本切换； ② Node18 工作和控制台日志输出正常，20 、22 、24 存在问题（上文已描述过）。 ③ 贴了 nvm 、node （当前使用的是 24 ） 和 npm 的版本信息，nvm 根目录截图以及 nvm list 的输出。贴了当前系统 path 下所有环境变量。 ④明确告知 Cursor ，可以在当前先后根目录下的 tmp 文件夹内，创建调试用的 Electron 小项目。如果需要其他信息或需要我协助执行操作，可以询问我。 经过一番排查，Cursor 给出的方案是在用户目录下的 npmrc 中，添加 loglevel=info ，并指定 Electron 的国内镜像源。我手动添加、指定了。问题排查到此没必要继续了，控制台输出问题已解决，国内镜像源只能接受。于是我按照提示点击了 [ Mark fixed ] 按钮，表示已修复。 在上述排查过程中，Cursor 在当前项目目录（项目在 E 盘，但非 E 盘根目录，在 E 盘根目录下第 4 层）的根目录（强调：是当前项目根目录）的 tmp 文件夹内直接或间接（调用工具、指令）自动生成了名为 node-diag 的子文件夹，该子文件夹的原貌已不可知。在事故发生后，在残留的此文件夹上（没错，该删的没删干净，不该删的全删了）点进去后，内层都是单个文件夹，最内层是一个名为 default_app.asar 的文件，从 tmp 到 default_app.asar 的路径为 .\node-diag\node_modules\electron\dist\resources\default_app.asar 。 我点击了 [ Mark fixed ] 按钮后，Cursor 按照惯例，开始了 Debug 完成后的自动清理，本次调试不涉及埋点， 因此 Cursor 开始自动清理 Debug 过程中 tmp 目录内产生的调试文件和日志文件。一分钟后 Cursor 前端提示执行成功，一切就如往常一样顺利，此时的我还沉浸在项目收尾的激动中，丝毫没意识到今晚（现在是凌晨，所以准确说是昨晚）将是个不眠之夜。 我忘记了我是因何打开了资源管理器并进入了 E 盘，也许是上天眷顾吧。我突然发现原本爆红的 E 盘血槽空白，下面显示 950 GB 可用（此处为了保护隐私，取了约数），我第一反应是系统显示有误，下意识在资源管理器右键刷新了一下，还是一样。 一瞬间我意识到，坏菜了，Cursor 这是要删库跑路了 。 我马上让 Cursor 核查刚刚 Debug. 时执行了什么命令，导致 E 盘被清空。Cursor 回答，在 Debug 完清理 tmp 下的调试文件和日志时，它在执行了危险的删除命令，但它没处理好 Windows Poweshell 下的引号有问题，导致删除对象从 tmp 内的文件（或文件夹），变成了 E 盘根目录下的所有文件（或文件夹），并且删除是直接删不放回收站。 事已至此，Cursor 给了我一堆诸如从备份盘、网盘恢复等没卵用的建议，并向我表达了同情，让我节哀的意思。Cursor 在思考过程中，我还看到它在检查是否有 git 记录可供恢复数据，有是不可能有的，别说根目录了，就连原本有 git 的当前项目目录，也被它删除干净了。 以上是事故过程简述。 Cursor 以及它所依赖的大模型，似乎都不太擅长 Windows 命令行操作，不知这锅该 Windows 背，还是该大模型背。 总之，大家慎用 Windows 系统下 Cursor 的 Debug 模式，严格控制删除命令。最好在远程或虚拟机下使用。 用 DiskGenius 的提示信息结语： 「数据无价，谨慎操作」。 ④明确告知 Cursor ，可以在当前先后根目录下的 tmp 文件夹内，创建调试用的 Electron 小项目。如果需要其他信息或需要我协助执行操作，可以询问我。 经过一番排查，Cursor 给出的方案是在用户目录下的 npmrc 中，添加 loglevel=info ，并指定 Electron 的国内镜像源。我手动添加、指定了。问题排查到此没必要继续了，控制台输出问题已解决，国内镜像源只能接受。于是我按照提示点击了 [ Mark fixed ] 按钮，表示已修复。 在上述排查过程中，Cursor 在当前项目目录（项目在 E 盘，但非 E 盘根目录，在 E 盘根目录下第 4 层）的根目录（强调：是当前项目根目录）的 tmp 文件夹内直接或间接（调用工具、指令）自动生成了名为 node-diag 的子文件夹，该子文件夹的原貌已不可知。在事故发生后，在残留的此文件夹上（没错，该删的没删干净，不该删的全删了）点进去后，内层都是单个文件夹，最内层是一个名为 default_app.asar 的文件，从 tmp 到 default_app.asar 的路径为 .\node-diag\node_modules\electron\dist\resources\default_app.asar 。 我点击了 [ Mark fixed ] 按钮后，Cursor 按照惯例，开始了 Debug 完成后的自动清理，本次调试不涉及埋点， 因此 Cursor 开始自动清理 Debug 过程中 tmp 目录内产生的调试文件和日志文件。一分钟后 Cursor 前端提示执行成功，一切就如往常一样顺利，此时的我还沉浸在项目收尾的激动中，丝毫没意识到今晚（现在是凌晨，所以准确说是昨晚）将是个不眠之夜。 我忘记了我是因何打开了资源管理器并进入了 E 盘，也许是上天眷顾吧。我突然发现原本爆红的 E 盘血槽空白，下面显示 950 GB 可用（此处为了保护隐私，取了约数），我第一反应是系统显示有误，下意识在资源管理器右键刷新了一下，还是一样。 一瞬间我意识到，坏菜了，Cursor 这是要删库跑路了 。 我马上让 Cursor 核查刚刚 Debug. 时执行了什么命令，导致 E 盘被清空。Cursor 回答，在 Debug 完清理 tmp 下的调试文件和日志时，它在执行了危险的删除命令，但它没处理好 Windows Poweshell 下的引号有问题，导致删除对象从 tmp 内的文件（或文件夹），变成了 E 盘根目录下的所有文件（或文件夹），并且删除是直接删不放回收站。 事已至此，Cursor 给了我一堆诸如从备份盘、网盘恢复等没卵用的建议，并向我表达了同情，让我节哀的意思。Cursor 在思考过程中，我还看到它在检查是否有 git 记录可供恢复数据，有是不可能有的，别说根目录了，就连原本有 git 的当前项目目录，也被它删除干净了。 以上是事故过程简述。 Cursor 以及它所依赖的大模型，似乎都不太擅长 Windows 命令行操作，不知这锅该 Windows 背，还是该大模型背。 总之，大家慎用 Windows 系统下 Cursor 的 Debug 模式，严格控制删除命令。最好在远程或虚拟机下使用。 用 DiskGenius 的提示信息结语： 「数据无价，谨慎操作」。 天河何处 2026 年 5 月 22 日 凌晨 在住处
大家慎用 Windows 系统下 Cursor 的 Debug 模式。 我已被 Cursor 误删 E 盘上 921GB 的重要数据。我有备份，但最新备份是 2024 年的。 手机码字，电脑在恢复数据，不敢再开任何应用。事故现场截图我等数据恢复完再贴上。事发过程简述如下。 近日业余时间，本来在用 Cursor 愉快地 「 vibe coding 」一个有趣的个人开源项目（此处我必须模糊表述，想留点悬念，等数据恢复处理完，收收尾会发布。本来憋了个大的准备发布时发个帖子，还想象了项目发布后和其他 V 友一样获得点关注，没想到最后关头 Cursor 给我拉了坨大的。但我不恨 Cursor ，已经很惊艳了。）。 继续说。项目即将完成，我整在添加和调试一些 Demo 。 调试过程中，考虑将所有依赖 Node 的 Demo ，统一升级到较新的 Node 版本。我和 Cursor 一起评估规划了方案，Cursor 建议我直接统一依赖到 Node24+ 。 方案制定好了，我想到我本机的 Node24 有点问题，一是 npm install 无控制台日志输出（ npm install --verbose 才能看到日志），二是 npm install 下载 Electron 依赖时，会卡在 postinstall { code: 0, signal: null }（国内镜像源能解决此问题，但我比较排斥）。于是我让 Cursur 帮我排查。 此时 Cursor 是开着上文提到的那个项目的，我将 Cursor 切到了 Debug 模式，给 Cursor 如下的提示词（回忆版且适当概括）： ① 我的操作系统是 Windows 10 ，使用解压版的 nvm 管理多个版本的 Node ，我下载了多个版本的 Node 解压版，解压并以 vxxxx （版本号）的形式命名后放在了 nvm 根目录。nvm list 可正常识别，nvm use 可正常完成 Node 版本切换； ② Node18 工作和控制台日志输出正常，20 、22 、24 存在问题（上文已描述过）。 ③ 贴了 nvm 、node （当前使用的是 24 ） 和 npm 的版本信息，nvm 根目录截图以及 nvm list 的输出。贴了当前系统 path 下所有环境变量。 ④明确告知 Cursor ，可以在当前先后根目录下的 tmp 文件夹内，创建调试用的 Electron 小项目。如果需要其他信息或需要我协助执行操作，可以询问我。 经过一番排查，Cursor 给出的方案是在用户目录下的 npmrc 中，添加 loglevel=info ，并指定 Electron 的国内镜像源。我手动添加、指定了。问题排查到此没必要继续了，控制台输出问题已解决，国内镜像源只能接受。于是我按照提示点击了 [ Mark fixed ] 按钮，表示已修复。 在上述排查过程中，Cursor 在当前项目目录（项目在 E 盘，但非 E 盘根目录，在 E 盘根目录下第 4 层）的根目录（强调：是当前项目根目录）的 tmp 文件夹内直接或间接（调用工具、指令）自动生成了名为 node-diag 的子文件夹，该子文件夹的原貌已不可知。在事故发生后，在残留的此文件夹上（没错，该删的没删干净，不该删的全删了）点进去后，内层都是单个文件夹，最内层是一个名为 default_app.asar 的文件，从 tmp 到 default_app.asar 的路径为 .\node-diag\node_modules\electron\dist\resources\default_app.asar 。 我点击了 [ Mark fixed ] 按钮后，Cursor 按照惯例，开始了 Debug 完成后的自动清理，本次调试不涉及埋点， 因此 Cursor 开始自动清理 Debug 过程中 tmp 目录内产生的调试文件和日志文件。一分钟后 Cursor 前端提示执行成功，一切就如往常一样顺利，此时的我还沉浸在项目收尾的激动中，丝毫没意识到今晚（现在是凌晨，所以准确说是昨晚）将是个不眠之夜。 我忘记了我是因何打开了资源管理器并进入了 E 盘，也许是上天眷顾吧。我突然发现原本爆红的 E 盘血槽空白，下面显示 950 GB 可用（此处为了保护隐私，取了约数），我第一反应是系统显示有误，下意识在资源管理器右键刷新了一下，还是一样。 一瞬间我意识到，坏菜了，Cursor 这是要删库跑路了 。 我马上让 Cursor 核查刚刚 Debug. 时执行了什么命令，导致 E 盘被清空。Cursor 回答，在 Debug 完清理 tmp 下的调试文件和日志时，它在执行了危险的删除命令，但它没处理好 Windows Poweshell 下的引号有问题，导致删除对象从 tmp 内的文件（或文件夹），变成了 E 盘根目录下的所有文件（或文件夹），并且删除是直接删不放回收站。 事已至此，Cursor 给了我一堆诸如从备份盘、网盘恢复等没卵用的建议，并向我表达了同情，让我节哀的意思。Cursor 在思考过程中，我还看到它在检查是否有 git 记录可供恢复数据，有是不可能有的，别说根目录了，就连原本有 git 的当前项目目录，也被它删除干净了。 以上是事故过程简述。 Cursor 以及它所依赖的大模型，似乎都不太擅长 Windows 命令行操作，不知这锅该 Windows 背，还是该大模型背。 总之，大家慎用 Windows 系统下 Cursor 的 Debug 模式，严格控制删除命令。最好在远程或虚拟机下使用。 用 DiskGenius 的提示信息结语： 「数据无价，谨慎操作」。 ④明确告知 Cursor ，可以在当前先后根目录下的 tmp 文件夹内，创建调试用的 Electron 小项目。如果需要其他信息或需要我协助执行操作，可以询问我。 经过一番排查，Cursor 给出的方案是在用户目录下的 npmrc 中，添加 loglevel=info ，并指定 Electron 的国内镜像源。我手动添加、指定了。问题排查到此没必要继续了，控制台输出问题已解决，国内镜像源只能接受。于是我按照提示点击了 [ Mark fixed ] 按钮，表示已修复。 在上述排查过程中，Cursor 在当前项目目录（项目在 E 盘，但非 E 盘根目录，在 E 盘根目录下第 4 层）的根目录（强调：是当前项目根目录）的 tmp 文件夹内直接或间接（调用工具、指令）自动生成了名为 node-diag 的子文件夹，该子文件夹的原貌已不可知。在事故发生后，在残留的此文件夹上（没错，该删的没删干净，不该删的全删了）点进去后，内层都是单个文件夹，最内层是一个名为 default_app.asar 的文件，从 tmp 到 default_app.asar 的路径为 .\node-diag\node_modules\electron\dist\resources\default_app.asar 。 我点击了 [ Mark fixed ] 按钮后，Cursor 按照惯例，开始了 Debug 完成后的自动清理，本次调试不涉及埋点， 因此 Cursor 开始自动清理 Debug 过程中 tmp 目录内产生的调试文件和日志文件。一分钟后 Cursor 前端提示执行成功，一切就如往常一样顺利，此时的我还沉浸在项目收尾的激动中，丝毫没意识到今晚（现在是凌晨，所以准确说是昨晚）将是个不眠之夜。 我忘记了我是因何打开了资源管理器并进入了 E 盘，也许是上天眷顾吧。我突然发现原本爆红的 E 盘血槽空白，下面显示 950 GB 可用（此处为了保护隐私，取了约数），我第一反应是系统显示有误，下意识在资源管理器右键刷新了一下，还是一样。 一瞬间我意识到，坏菜了，Cursor 这是要删库跑路了 。 我马上让 Cursor 核查刚刚 Debug. 时执行了什么命令，导致 E 盘被清空。Cursor 回答，在 Debug 完清理 tmp 下的调试文件和日志时，它在执行了危险的删除命令，但它没处理好 Windows Poweshell 下的引号有问题，导致删除对象从 tmp 内的文件（或文件夹），变成了 E 盘根目录下的所有文件（或文件夹），并且删除是直接删不放回收站。 事已至此，Cursor 给了我一堆诸如从备份盘、网盘恢复等没卵用的建议，并向我表达了同情，让我节哀的意思。Cursor 在思考过程中，我还看到它在检查是否有 git 记录可供恢复数据，有是不可能有的，别说根目录了，就连原本有 git 的当前项目目录，也被它删除干净了。 以上是事故过程简述。 Cursor 以及它所依赖的大模型，似乎都不太擅长 Windows 命令行操作，不知这锅该 Windows 背，还是该大模型背。 总之，大家慎用 Windows 系统下 Cursor 的 Debug 模式，严格控制删除命令。最好在远程或虚拟机下使用。 用 DiskGenius 的提示信息结语： 「数据无价，谨慎操作」。 天河何处 2026 年 5 月 22 日 凌晨 在住处
大家慎用 Windows 系统下 Cursor 的 Debug 模式。 我已被 Cursor 误删 E 盘上 921GB 的重要数据。我有备份，但最新备份是 2024 年的。 手机码字，电脑在恢复数据，不敢再开任何应用。事故现场截图我等数据恢复完再贴上。事发过程简述如下。 近日业余时间，本来在用 Cursor 愉快地 「 vibe coding 」一个有趣的个人开源项目（此处我必须模糊表述，想留点悬念，等数据恢复处理完，收收尾会发布。本来憋了个大的准备发布时发个帖子，还想象了项目发布后和其他 V 友一样获得点关注，没想到最后关头 Cursor 给我拉了坨大的。但我不恨 Cursor ，已经很惊艳了。）。 继续说。项目即将完成，我整在添加和调试一些 Demo 。 调试过程中，考虑将所有依赖 Node 的 Demo ，统一升级到较新的 Node 版本。我和 Cursor 一起评估规划了方案，Cursor 建议我直接统一依赖到 Node24+ 。 方案制定好了，我想到我本机的 Node24 有点问题，一是 npm install 无控制台日志输出（ npm install --verbose 才能看到日志），二是 npm install 下载 Electron 依赖时，会卡在 postinstall { code: 0, signal: null }（国内镜像源能解决此问题，但我比较排斥）。于是我让 Cursur 帮我排查。 此时 Cursor 是开着上文提到的那个项目的，我将 Cursor 切到了 Debug 模式，给 Cursor 如下的提示词（回忆版且适当概括）： ① 我的操作系统是 Windows 10 ，使用解压版的 nvm 管理多个版本的 Node ，我下载了多个版本的 Node 解压版，解压并以 vxxxx （版本号）的形式命名后放在了 nvm 根目录。nvm list 可正常识别，nvm use 可正常完成 Node 版本切换； ② Node18 工作和控制台日志输出正常，20 、22 、24 存在问题（上文已描述过）。 ③ 贴了 nvm 、node （当前使用的是 24 ） 和 npm 的版本信息，nvm 根目录截图以及 nvm list 的输出。贴了当前系统 path 下所有环境变量。 ④明确告知 Cursor ，可以在当前先后根目录下的 tmp 文件夹内，创建调试用的 Electron 小项目。如果需要其他信息或需要我协助执行操作，可以询问我。 经过一番排查，Cursor 给出的方案是在用户目录下的 npmrc 中，添加 loglevel=info ，并指定 Electron 的国内镜像源。我手动添加、指定了。问题排查到此没必要继续了，控制台输出问题已解决，国内镜像源只能接受。于是我按照提示点击了 [ Mark fixed ] 按钮，表示已修复。 在上述排查过程中，Cursor 在当前项目目录（项目在 E 盘，但非 E 盘根目录，在 E 盘根目录下第 4 层）的根目录（强调：是当前项目根目录）的 tmp 文件夹内直接或间接（调用工具、指令）自动生成了名为 node-diag 的子文件夹，该子文件夹的原貌已不可知。在事故发生后，在残留的此文件夹上（没错，该删的没删干净，不该删的全删了）点进去后，内层都是单个文件夹，最内层是一个名为 default_app.asar 的文件，从 tmp 到 default_app.asar 的路径为 .\node-diag\node_modules\electron\dist\resources\default_app.asar 。 我点击了 [ Mark fixed ] 按钮后，Cursor 按照惯例，开始了 Debug 完成后的自动清理，本次调试不涉及埋点， 因此 Cursor 开始自动清理 Debug 过程中 tmp 目录内产生的调试文件和日志文件。一分钟后 Cursor 前端提示执行成功，一切就如往常一样顺利，此时的我还沉浸在项目收尾的激动中，丝毫没意识到今晚（现在是凌晨，所以准确说是昨晚）将是个不眠之夜。 我忘记了我是因何打开了资源管理器并进入了 E 盘，也许是上天眷顾吧。我突然发现原本爆红的 E 盘血槽空白，下面显示 950 GB 可用（此处为了保护隐私，取了约数），我第一反应是系统显示有误，下意识在资源管理器右键刷新了一下，还是一样。 一瞬间我意识到，坏菜了，Cursor 这是要删库跑路了 。 我马上让 Cursor 核查刚刚 Debug. 时执行了什么命令，导致 E 盘被清空。Cursor 回答，在 Debug 完清理 tmp 下的调试文件和日志时，它在执行了危险的删除命令，但它没处理好 Windows Poweshell 下的引号有问题，导致删除对象从 tmp 内的文件（或文件夹），变成了 E 盘根目录下的所有文件（或文件夹），并且删除是直接删不放回收站。 事已至此，Cursor 给了我一堆诸如从备份盘、网盘恢复等没卵用的建议，并向我表达了同情，让我节哀的意思。Cursor 在思考过程中，我还看到它在检查是否有 git 记录可供恢复数据，有是不可能有的，别说根目录了，就连原本有 git 的当前项目目录，也被它删除干净了。 以上是事故过程简述。 Cursor 以及它所依赖的大模型，似乎都不太擅长 Windows 命令行操作，不知这锅该 Windows 背，还是该大模型背。 总之，大家慎用 Windows 系统下 Cursor 的 Debug 模式，严格控制删除命令。最好在远程或虚拟机下使用。 用 DiskGenius 的提示信息结语： 「数据无价，谨慎操作」。 ④明确告知 Cursor ，可以在当前先后根目录下的 tmp 文件夹内，创建调试用的 Electron 小项目。如果需要其他信息或需要我协助执行操作，可以询问我。 经过一番排查，Cursor 给出的方案是在用户目录下的 npmrc 中，添加 loglevel=info ，并指定 Electron 的国内镜像源。我手动添加、指定了。问题排查到此没必要继续了，控制台输出问题已解决，国内镜像源只能接受。于是我按照提示点击了 [ Mark fixed ] 按钮，表示已修复。 在上述排查过程中，Cursor 在当前项目目录（项目在 E 盘，但非 E 盘根目录，在 E 盘根目录下第 4 层）的根目录（强调：是当前项目根目录）的 tmp 文件夹内直接或间接（调用工具、指令）自动生成了名为 node-diag 的子文件夹，该子文件夹的原貌已不可知。在事故发生后，在残留的此文件夹上（没错，该删的没删干净，不该删的全删了）点进去后，内层都是单个文件夹，最内层是一个名为 default_app.asar 的文件，从 tmp 到 default_app.asar 的路径为 .\node-diag\node_modules\electron\dist\resources\default_app.asar 。 我点击了 [ Mark fixed ] 按钮后，Cursor 按照惯例，开始了 Debug 完成后的自动清理，本次调试不涉及埋点， 因此 Cursor 开始自动清理 Debug 过程中 tmp 目录内产生的调试文件和日志文件。一分钟后 Cursor 前端提示执行成功，一切就如往常一样顺利，此时的我还沉浸在项目收尾的激动中，丝毫没意识到今晚（现在是凌晨，所以准确说是昨晚）将是个不眠之夜。 我忘记了我是因何打开了资源管理器并进入了 E 盘，也许是上天眷顾吧。我突然发现原本爆红的 E 盘血槽空白，下面显示 950 GB 可用（此处为了保护隐私，取了约数），我第一反应是系统显示有误，下意识在资源管理器右键刷新了一下，还是一样。 一瞬间我意识到，坏菜了，Cursor 这是要删库跑路了 。 我马上让 Cursor 核查刚刚 Debug. 时执行了什么命令，导致 E 盘被清空。Cursor 回答，在 Debug 完清理 tmp 下的调试文件和日志时，它在执行了危险的删除命令，但它没处理好 Windows Poweshell 下的引号有问题，导致删除对象从 tmp 内的文件（或文件夹），变成了 E 盘根目录下的所有文件（或文件夹），并且删除是直接删不放回收站。 事已至此，Cursor 给了我一堆诸如从备份盘、网盘恢复等没卵用的建议，并向我表达了同情，让我节哀的意思。Cursor 在思考过程中，我还看到它在检查是否有 git 记录可供恢复数据，有是不可能有的，别说根目录了，就连原本有 git 的当前项目目录，也被它删除干净了。 以上是事故过程简述。 Cursor 以及它所依赖的大模型，似乎都不太擅长 Windows 命令行操作，不知这锅该 Windows 背，还是该大模型背。 总之，大家慎用 Windows 系统下 Cursor 的 Debug 模式，严格控制删除命令。最好在远程或虚拟机下使用。 用 DiskGenius 的提示信息结语： 「数据无价，谨慎操作」。 天河何处 2026 年 5 月 22 日 凌晨 在住处
大家慎用 Windows 系统下 Cursor 的 Debug 模式。 我已被 Cursor 误删 E 盘上 921GB 的重要数据。我有备份，但最新备份是 2024 年的。 手机码字，电脑在恢复数据，不敢再开任何应用。事故现场截图我等数据恢复完再贴上。事发过程简述如下。 近日业余时间，本来在用 Cursor 愉快地 「 vibe coding 」一个有趣的个人开源项目（此处我必须模糊表述，想留点悬念，等数据恢复处理完，收收尾会发布。本来憋了个大的准备发布时发个帖子，还想象了项目发布后和其他 V 友一样获得点关注，没想到最后关头 Cursor 给我拉了坨大的。但我不恨 Cursor ，已经很惊艳了。）。 继续说。项目即将完成，我整在添加和调试一些 Demo 。 调试过程中，考虑将所有依赖 Node 的 Demo ，统一升级到较新的 Node 版本。我和 Cursor 一起评估规划了方案，Cursor 建议我直接统一依赖到 Node24+ 。 方案制定好了，我想到我本机的 Node24 有点问题，一是 npm install 无控制台日志输出（ npm install --verbose 才能看到日志），二是 npm install 下载 Electron 依赖时，会卡在 postinstall { code: 0, signal: null }（国内镜像源能解决此问题，但我比较排斥）。于是我让 Cursur 帮我排查。 此时 Cursor 是开着上文提到的那个项目的，我将 Cursor 切到了 Debug 模式，给 Cursor 如下的提示词（回忆版且适当概括）： ① 我的操作系统是 Windows 10 ，使用解压版的 nvm 管理多个版本的 Node ，我下载了多个版本的 Node 解压版，解压并以 vxxxx （版本号）的形式命名后放在了 nvm 根目录。nvm list 可正常识别，nvm use 可正常完成 Node 版本切换； ② Node18 工作和控制台日志输出正常，20 、22 、24 存在问题（上文已描述过）。 ③ 贴了 nvm 、node （当前使用的是 24 ） 和 npm 的版本信息，nvm 根目录截图以及 nvm list 的输出。贴了当前系统 path 下所有环境变量。 ④明确告知 Cursor ，可以在当前先后根目录下的 tmp 文件夹内，创建调试用的 Electron 小项目。如果需要其他信息或需要我协助执行操作，可以询问我。 经过一番排查，Cursor 给出的方案是在用户目录下的 npmrc 中，添加 loglevel=info ，并指定 Electron 的国内镜像源。我手动添加、指定了。问题排查到此没必要继续了，控制台输出问题已解决，国内镜像源只能接受。于是我按照提示点击了 [ Mark fixed ] 按钮，表示已修复。 在上述排查过程中，Cursor 在当前项目目录（项目在 E 盘，但非 E 盘根目录，在 E 盘根目录下第 4 层）的根目录（强调：是当前项目根目录）的 tmp 文件夹内直接或间接（调用工具、指令）自动生成了名为 node-diag 的子文件夹，该子文件夹的原貌已不可知。在事故发生后，在残留的此文件夹上（没错，该删的没删干净，不该删的全删了）点进去后，内层都是单个文件夹，最内层是一个名为 default_app.asar 的文件，从 tmp 到 default_app.asar 的路径为 .\node-diag\node_modules\electron\dist\resources\default_app.asar 。 我点击了 [ Mark fixed ] 按钮后，Cursor 按照惯例，开始了 Debug 完成后的自动清理，本次调试不涉及埋点， 因此 Cursor 开始自动清理 Debug 过程中 tmp 目录内产生的调试文件和日志文件。一分钟后 Cursor 前端提示执行成功，一切就如往常一样顺利，此时的我还沉浸在项目收尾的激动中，丝毫没意识到今晚（现在是凌晨，所以准确说是昨晚）将是个不眠之夜。 我忘记了我是因何打开了资源管理器并进入了 E 盘，也许是上天眷顾吧。我突然发现原本爆红的 E 盘血槽空白，下面显示 950 GB 可用（此处为了保护隐私，取了约数），我第一反应是系统显示有误，下意识在资源管理器右键刷新了一下，还是一样。 一瞬间我意识到，坏菜了，Cursor 这是要删库跑路了 。 我马上让 Cursor 核查刚刚 Debug. 时执行了什么命令，导致 E 盘被清空。Cursor 回答，在 Debug 完清理 tmp 下的调试文件和日志时，它在执行了危险的删除命令，但它没处理好 Windows Poweshell 下的引号有问题，导致删除对象从 tmp 内的文件（或文件夹），变成了 E 盘根目录下的所有文件（或文件夹），并且删除是直接删不放回收站。 事已至此，Cursor 给了我一堆诸如从备份盘、网盘恢复等没卵用的建议，并向我表达了同情，让我节哀的意思。Cursor 在思考过程中，我还看到它在检查是否有 git 记录可供恢复数据，有是不可能有的，别说根目录了，就连原本有 git 的当前项目目录，也被它删除干净了。 以上是事故过程简述。 Cursor 以及它所依赖的大模型，似乎都不太擅长 Windows 命令行操作，不知这锅该 Windows 背，还是该大模型背。 总之，大家慎用 Windows 系统下 Cursor 的 Debug 模式，严格控制删除命令。最好在远程或虚拟机下使用。 用 DiskGenius 的提示信息结语： 「数据无价，谨慎操作」。 ④明确告知 Cursor ，可以在当前先后根目录下的 tmp 文件夹内，创建调试用的 Electron 小项目。如果需要其他信息或需要我协助执行操作，可以询问我。 经过一番排查，Cursor 给出的方案是在用户目录下的 npmrc 中，添加 loglevel=info ，并指定 Electron 的国内镜像源。我手动添加、指定了。问题排查到此没必要继续了，控制台输出问题已解决，国内镜像源只能接受。于是我按照提示点击了 [ Mark fixed ] 按钮，表示已修复。 在上述排查过程中，Cursor 在当前项目目录（项目在 E 盘，但非 E 盘根目录，在 E 盘根目录下第 4 层）的根目录（强调：是当前项目根目录）的 tmp 文件夹内直接或间接（调用工具、指令）自动生成了名为 node-diag 的子文件夹，该子文件夹的原貌已不可知。在事故发生后，在残留的此文件夹上（没错，该删的没删干净，不该删的全删了）点进去后，内层都是单个文件夹，最内层是一个名为 default_app.asar 的文件，从 tmp 到 default_app.asar 的路径为 .\node-diag\node_modules\electron\dist\resources\default_app.asar 。 我点击了 [ Mark fixed ] 按钮后，Cursor 按照惯例，开始了 Debug 完成后的自动清理，本次调试不涉及埋点， 因此 Cursor 开始自动清理 Debug 过程中 tmp 目录内产生的调试文件和日志文件。一分钟后 Cursor 前端提示执行成功，一切就如往常一样顺利，此时的我还沉浸在项目收尾的激动中，丝毫没意识到今晚（现在是凌晨，所以准确说是昨晚）将是个不眠之夜。 我忘记了我是因何打开了资源管理器并进入了 E 盘，也许是上天眷顾吧。我突然发现原本爆红的 E 盘血槽空白，下面显示 950 GB 可用（此处为了保护隐私，取了约数），我第一反应是系统显示有误，下意识在资源管理器右键刷新了一下，还是一样。 一瞬间我意识到，坏菜了，Cursor 这是要删库跑路了 。 我马上让 Cursor 核查刚刚 Debug. 时执行了什么命令，导致 E 盘被清空。Cursor 回答，在 Debug 完清理 tmp 下的调试文件和日志时，它在执行了危险的删除命令，但它没处理好 Windows Poweshell 下的引号有问题，导致删除对象从 tmp 内的文件（或文件夹），变成了 E 盘根目录下的所有文件（或文件夹），并且删除是直接删不放回收站。 事已至此，Cursor 给了我一堆诸如从备份盘、网盘恢复等没卵用的建议，并向我表达了同情，让我节哀的意思。Cursor 在思考过程中，我还看到它在检查是否有 git 记录可供恢复数据，有是不可能有的，别说根目录了，就连原本有 git 的当前项目目录，也被它删除干净了。 以上是事故过程简述。 Cursor 以及它所依赖的大模型，似乎都不太擅长 Windows 命令行操作，不知这锅该 Windows 背，还是该大模型背。 总之，大家慎用 Windows 系统下 Cursor 的 Debug 模式，严格控制删除命令。最好在远程或虚拟机下使用。 用 DiskGenius 的提示信息结语： 「数据无价，谨慎操作」。 天河何处 2026 年 5 月 22 日 凌晨 在住处