用途
Debug 是一个系统化调试技能，适用于功能出错、用户报告错误、部署失败或测试不通过等场景。它的核心信条是：不要猜测，先收集信息。反面做法是“出问题 → 随便试一个修复 → 不行 → 再试一个 → 试了 5 次还是坏的”；正确做法是“出问题 → 复现 → 收集诊断信息 → 诊断根因 → 修复（通常一次成功）”。即先诊断，后修复。
主要能力
该技能按所用工具区分调试方式。在 Claude Code 中，它可以自行收集诊断信息，无需先向创始人索要截图或日志，自动执行以下步骤：检查 git 历史（git log --oneline -10 与 git diff HEAD~3）、在代码库中搜索错误文本、读取失败文件及其上下文、运行开发服务器或测试套件以复现、读取服务器日志与构建输出、核对 .env.example 与实际配置。只有在无法自行获取时（如浏览器中看到的内容、点击了什么、视觉 bug 截图）才向创始人询问。在 Lovable / Replit 中，创始人需手动收集信息并粘贴，技能提供结构化的“Tell AI:”提示模板以确保上下文完整。
对于生产环境 bug，技能要求先检查监控与错误追踪：错误追踪工具（Sentry、LogRocket）中的确切错误、堆栈跟踪与用户上下文；按报告时间戳过滤服务器日志；托管面板中该时段是否有部署或故障；数据库是否有失败的迁移或连接问题。
使用方式
调试流程为：一致地复现 bug → 收集诊断信息（Claude Code 中自动，其他环境手动）→ 检查近期变更 → 在提出修复前诊断根因 → 修复根因 → 测试修复有效 → 验证未破坏其他功能 → 思考如何预防。
复现 bug 时需确认：触发 bug 的确切步骤、是每次都发生还是间歇性、特定浏览器或设备、特定数据或用户。若无法复现，可向用户索要确切步骤或录屏、换浏览器/设备/账号、换数据、清缓存重试、检查是否与时机相关。
错误信息捕获方面，浏览器控制台可通过右键页面 → 检查 → Console 标签查看红色错误并截图完整堆栈；网络面板可通过 DevTools → Network 标签复现 bug，查找失败请求（红色、4xx、5xx），点击失败请求查看 Response 标签。视觉 bug 需截图期望效果与实际效果，并注明设备与浏览器。
技能还列出常见 bug 类型的排查方向：“点击无反应”检查控制台错误、网络请求失败、元素是否被遮挡；“页面无法加载”检查网络错误、JavaScript 错误、无限重定向、缺失环境变量；“显示错误数据”检查 API 返回、缓存、状态更新、用户上下文；“表单不提交”检查验证错误、控制台错误、网络请求是否发出；“开发正常生产损坏”检查环境变量、数据库差异、构建步骤、CORS 配置；“Chrome 正常 Safari 损坏”检查 CSS/JS 兼容性、Safari 默认值、日期解析差异。
升级纪律与根因分析
1 次修复失败后应重新评估是否误诊、是否需收集更多信息；2 次失败后应停止尝试修复，因为诊断很可能错误；3 次失败后不要尝试第 4 次，而应更换策略：用更简单的方式重建功能、请人类开发者介入、先发布临时方案日后再正式修复。
技能强调用“不断追问为什么”找到真正根因。例如服务器崩溃 → 内存不足 → 认证服务内存泄漏 → 数据库连接未释放 → 错误处理器未关闭连接 → finally 块中没有清理，最后这一层才是修复点。判断是否找到真正根因的标准：它是你能实际改变的东西（代码、配置、流程）；修复它能防止问题复发；再问“为什么”不会导向可行动的内容。常见错误是停在“AI 把它弄坏了”，这是归责而非原因，应改问：什么流程本可以捕获这个问题？缺失测试？缺失验证？没有代码审查？
当 bug 有多个原因时，需寻找第二条分支。例如部署失败 → 数据库迁移超时，分支 A：迁移为何慢？→ 长查询导致表锁 → 缺失索引；分支 B：超时为何这么短？→ 使用默认超时 → 没有部署专用配置。两条分支都需修复，否则 bug 会在略有不同的条件下复发。在实施修复前应反向验证诊断：“如果我修复 X，是否能阻止 Y，进而阻止 Z，进而阻止原始问题？”若链条断裂，说明找错了根因。
间歇性 bug、边界测试与生产处理
间歇性 bug（“有时正常有时坏”）很可能是竞态条件、缓存问题或外部 API 不稳定。应记录 10 次中成功与失败次数、失败与成功的条件模式，并添加日志捕获失败时的状态。
修复主用例后还应测试边界情况：空状态（无数据、空列表、缺失字段）、数据量（1 条、100 条、10000 条）、时机（慢连接、快速双击、过期会话、多标签页）、边界值（超长文本、特殊字符、零值、负数）。
生产环境 bug 先判断优先级：用户能否绕过？能则下次部署修复，不能则需紧急修复。紧急修复应使用能解除用户阻塞的最简方案，日后再改进。多个 bug 同时出现时，先列出所有症状，判断是独立 bug 还是同一根因，并按优先级修复：阻塞（无法使用应用）→ 严重（主要功能损坏）→ 重要 → 次要，不要在严重 bug 未修复时去修次要 bug。
调试日志与预防
难以诊断时可添加策略性日志：函数入口记录输入值、API 调用前后记录请求/响应、状态变更记录前后值、错误处理器记录完整上下文、决策点记录走了哪个分支。格式为 [TIMESTAMP] [LEVEL] [CONTEXT] Message，例如 [2025-01-13 10:30:45] [ERROR] [UserAuth] Login failed for user@example.com - Reason: Invalid password - Attempts: 3。bug 修复后应移除或减少日志。
每次修复后应从三个层面思考：即时修复（bug 已消失）、预防措施（什么能阻止它再次发生，如验证、测试、类型检查）、检测机制（若预防失败，如何尽早发现，如监控告警、错误追踪）。还应思考这是否是一种模式，同类 bug 是否存在于代码库其他地方。
适用场景与限制
该技能适用于个人开发者或小团队在 AI 辅助开发流程中排查功能、部署、测试类问题，尤其适合与 Claude Code、Lovable、Replit 等工具配合使用。当遵循完整流程后仍卡住、遇到无法解决的关键生产 bug、同一 bug 反复出现、复杂第三方集成中的 bug、或涉及安全与数据损坏风险时，应考虑聘请开发者。对大多数 bug，配合 AI 工具使用本流程已足够。
常见错误包括：无信息就尝试修复、描述含糊（“它不工作”）、未先复现、向 AI 索要随机修复、忽略控制台与网络错误、修复后不测试、在严重 bug 存在时修次要 bug、接受第一个看似合理的原因、把“AI 弄坏了”当作诊断。
关于该技能的具体安装命令、收费方式、支持平台与版本要求，资料中暂未提供。