live-debuggerlisted

# live-debugger 模拟人工 debugger 的排查循环：**快速找埋点位置 → 埋点（公告明细）→ 打开/刷新页面 → 复现（默认人工，AI 自动按需）→ 读数据 → 收敛**。每轮迭代必须基于上一轮数据缩小范围，直至找到根因、用户无法复现。 ## 核心哲学（必须遵守） 1. **埋点数据是主要信息来源，代码分析只是辅助**。代码分析唯一目的是回答"埋点什么、埋在哪"，禁止为建立完整理解而读代码——读不懂没关系，数据会说话。 2. **打开/刷新页面 + 复现是每轮迭代的基本验证动作，必须执行**。复现默认由用户手动执行（**人工复现：最快、最稳、无卡点**——用户点一下的事，AI 自动可能要几个快照，且丰富 DOM 下易点错）；AI 自动复现仅为用户明确要求时的可选加速，不默认启用；自动复现受阻时必须显式降级人工，不允许静默跳过。 3. **时间是最高约束**：读代码要克制、等编译要克制。宁可多埋几个点，不多读一个文件、不多等一秒编译。 ## 前置：明确 bug 信息（三要素） 开始前确认用户已提供三要素，缺哪项问哪项——不带着模糊目标空跑： | 要素 | 说明 | | --- | --- | | **复现步骤** | 在什么环境（URL、登录状态、前置数据）做什么操作。描述要求见下 | | **现状（问题）** | 实际发生的现象 | | **预期** | 应该是什么样。闭环依据：复现后数据与预期相符 = 问题解决 | **复现步骤描述要求**： - **默认人工复现** → 用户描述步骤即可，AI 会把步骤整理成操作清单回执给用户，用户按清单（或按自己习惯）操作 - **步骤未提供** → 先基于代码疑点推断最简复现路径：人工模式下把推断出的操作步骤告知用户请求执行；自动模式下由 AI 直接尝试 - 步骤是否简单，决定用户要求 AI 自动复现时能否启用（见"复现策略"） **页面 URL 是可选项，永远不为此询问**：用户提供了就用提供的；未提供**直接用默认 `http://localhost/editor?cll=debug`**，打开时告知用户"当前使用默认地址，如需其他页面请说明"，不阻塞流程。 ## 前置：确认浏览器控制 MCP 可用 用 ToolSearch 查找浏览器控制工具（navigate / snapshot / click / fill / read console 等，工具名形如 `mcp__playwright__*`、`mcp__chrome-devtools__*`）。**以实际找到的工具名为准，不要臆造工具名。** MCP 的两个用途： - **页面控制与取数**（默认人工复现模式也需要）：MCP 负责打开/刷新页面、读取 console 日志——这是本技能使用 MCP 的主要方式，让"人工复现"模式仍然免去"手动开页面、回贴日志"的麻烦 - **AI 自动复现**（可选加速）：仅当用户明确要求时使用；playwright 为首选（无障碍快照 + ref 确定性交互），chrome-devtools / puppeteer 兜底 - **找到浏览器 MCP**（任一）→ 按上述用途使用 - **没有任何浏览器 MCP** → **必须明确告知用户**"未找到浏览器控制工具（可在 /mcp 添加 playwright 等 MCP 并重启会话生效）"，询问用户：先配置再继续，还是降级为完全手动模式（用户手动打开/刷新页面、打开 DevTools Console 回贴 `[