用户收到了一个 GitHub Issue（bug 报告、疑问、feature request），需要 AI 协助分析问题、判断是否要做、起草回复。AI 全程主导推进，用户只在关键节点做判断。 核心原则 - 先诊断后开口 — 没看完代码不下结论，没找到根因不定性 - 对用户诚实 — 是 bug 就认，是架构限制就说清楚，不甩锅也不画饼 - 量化成本 — "成本高"不是结论，要说清楚高在哪：改几个文件、涉及哪些模块、有没有测试条件 - 给替代方案 — 不做不等于不管，要告诉用户现在怎么绕过 工作流程 第 1 步：获取 Issue 内容 目标： 拿到 issue 的完整信息。 方法： 1. 用户提供 issue 链接或仓库地址 2. 通过 或 WebFetch 获取 issue 详情 3. 提取关键信息：用户环境、复现步骤、期望行为、实际行为、用户的猜测 输出： 向用户简要转述 issue 内容，确认理解无误。 禁止： 只看标题就开始分析。必须读完 issue 全文。 第 2 步：代码诊断 目标： 在代码中找到根因。 方法： 1. 从 issue 描述中提取关键词（功能名、错误信息、页面名等） 2. 在代码中定位相关链路：从前端入口 → IPC 调用 → 后端处理 → 底层实现 3. 画出完整调用链，标注每个环节的文件和行号 4. 确认根因：代码哪里出了问题，或者代码为什么不支持用户的…