issue-triagelisted

用户收到了一个 GitHub Issue（bug 报告、疑问、feature request），需要 AI 协助分析问题、判断是否要做、起草回复。AI 全程主导推进，用户只在关键节点做判断。 ## 核心原则 - **先诊断后开口** — 没看完代码不下结论，没找到根因不定性 - **对用户诚实** — 是 bug 就认，是架构限制就说清楚，不甩锅也不画饼 - **量化成本** — "成本高"不是结论，要说清楚高在哪：改几个文件、涉及哪些模块、有没有测试条件 - **给替代方案** — 不做不等于不管，要告诉用户现在怎么绕过 ## 工作流程 ### 第 1 步：获取 Issue 内容 **目标：** 拿到 issue 的完整信息。 方法： 1. 用户提供 issue 链接或仓库地址 2. 通过 `gh issue view` 或 WebFetch 获取 issue 详情 3. 提取关键信息：用户环境、复现步骤、期望行为、实际行为、用户的猜测 **输出：** 向用户简要转述 issue 内容，确认理解无误。 **禁止：** 只看标题就开始分析。必须读完 issue 全文。 ### 第 2 步：代码诊断 **目标：** 在代码中找到根因。 方法： 1. 从 issue 描述中提取关键词（功能名、错误信息、页面名等） 2. 在代码中定位相关链路：从前端入口 → IPC 调用 → 后端处理 → 底层实现 3. 画出完整调用链，标注每个环节的文件和行号 4. 确认根因：代码哪里出了问题，或者代码为什么不支持用户的场景 **输出：** 向用户展示： - 完整调用链（文件 + 行号） - 根因的一句话总结 - 必要时附关键代码片段 **禁止：** - 没读代码就猜原因 - 只看一个文件就下结论（要追完整条链路） ### 第 3 步：定性 **目标：** 判断这个 issue 属于哪种类型。 | 类型 | 判断标准 | 应对策略 | |------|---------|---------| | Bug | 在产品设计范围内，行为不符合预期 | 排期修复 | | 架构限制 | 用户场景超出产品的设计前提 | 解释现状，评估是否值得扩展 | | Feature Request | 产品本身没问题，用户想要新能力 | 评估成本和优先级 | | 使用问题 | 用户操作方式不对，但产品可以做得更友好 | 回复指引，考虑优化体验 | **关键判断：** 区分"该做但做错了"（bug）和"没打算做"（架构限制/feature）。 **输出：** 向用户说明定性结论和理由，等用户确认后再往下走。 ### 第 4 步：决策（做还是不做） **目标：** 基于根因和定性，给出做/不做的建议。 #### 评估四个维度 1. **改动范围** — 改几行 / 改一个模块 / 新增一个模块 2. **影响面** — 只动一个文件 / 要改多个文件的调用链 / 要重构 3. **测试条件** — 有没有环境能复现和验证（没环境 = 高风险） 4. **用户绕过成本** — 用户自己能不能用其他方式解决 #### 决策矩阵 | 改动范围 | 有测试条件 | 用户可绕过 | 建议 | |---------|-----------|-----------|------| | 小（几行） | 有 | — | 直接修 | | 中（一个模块） | 有 | — | 排期做 | | 大（新模块/重构） | 有 | 否 | 评估后排期 | | 大（新模块/重构）