| name | generic-issue-log-analysis |
| description | 分析 IndustrialPlanner 仓库的公开 GitHub issue。优先读取 issue 正文和评论，结合截图、复现步骤、浏览器环境信息与仓库代码判断根因，并给出修复建议。 |
IndustrialPlanner Issue Analysis
项目概况
IndustrialPlanner 是一个运行在浏览器中的工厂规划工具（纯前端 Web App，React + TypeScript + Vite）。
关键目录结构：
src/app/ — 应用层 UI（面板、工具栏、状态管理）src/editor/ — 编辑器核心（放置、验证、文档存储、视口）src/domain/ — 领域模型（设备、配方、蓝图等）src/registry/ — 静态数据定义（配方、设备变体、物品等注册表）src/shared/i18n/ — 多语言翻译文件（以中文为主）src/renderer/ — 渲染层（设备精灵、画布绘制）src/simulation/ — 仿真引擎.temp/json-export.json — 游戏解包数据（端口坐标、设备变体、渲染模板等，用于校验数据准确性）blueprints/ — 示例蓝图文件help/ — 帮助文档
Scope
- 默认把
#1234 视为当前仓库 issue。
- 如果用户给了完整 issue URL，则以该 URL 为准。
- 只分析可以直接访问的公开 issue、评论、截图和附件。
- 本项目是纯前端应用，没有后端日志或崩溃转储。主要证据来源是：截图、浏览器控制台输出（如果用户提供）、复现步骤、issue 正文描述。
- 如果证据不足（缺少截图、复现步骤或控制台错误），要先明确说明，再基于现有材料给出初步判断。
Workflow
-
规范化输入。
#1234 视为当前仓库 issue。- 完整 issue URL 以 URL 为准。
-
获取 issue 内容。
- 读取正文和评论。
- 提取：版本、浏览器、设备类型（桌面/平板/手机）、预期行为、实际行为、复现步骤、截图附件。
- 如果维护者或其他评论已经给出结论，不要直接照抄；仍要用代码和文档自行验证。
-
提取附件和现场证据。
- 优先关注截图（最直接的证据来源）。
- 留意用户是否提供了浏览器控制台错误信息、导出的蓝图 JSON、配置信息。
- 截图重点观察：UI 是否正常渲染、是否有异常遮罩或弹窗、数据是否正确显示。
-
建立复现路径。
- 从 issue 文本确定用户操作路径和"出问题的时刻"。
- 对照项目代码中的组件、状态流转、事件处理链路。
-
回溯到代码和文档。
- 先看
src/registry/ 确认数据定义是否正确（如配方数据、设备端口坐标）。
- 再看
src/domain/ 和 src/editor/ 确认业务逻辑。
- 最后看
src/app/ 确认 UI 渲染逻辑。
- 如果涉及解包数据准确性，对照
.temp/json-export.json 校验。
- 如果涉及设备/物品名称，先在
src/shared/i18n/ 查找中文名和对应 id。
5.5. 判断是否为仿真与游戏行为不一致问题。
- 确认用户表达的根因是否是"仿真的实现与游戏内行为不一致"。
- 典型信号：用户说"游戏里是这样的，但工具里是那样的"、配方产物/耗时/端口与游戏不符、设备行为逻辑与游戏不同。
- 若属于此类问题，必须要求补充游戏内截图作为对照证据。没有游戏内截图则标记为证据不足，不给出最终结论。
- 对照游戏截图与仿真数据/逻辑，逐项列出差异点。
-
区分 issue 当时环境与当前分支。
- 从 issue 文本还原用户当时的版本/环境。
- 对照当前代码判断问题是仍然存在还是已修复。
- 如果 issue 较旧，必要时按对应 tag 复核旧逻辑。
-
输出结论。
- 明确区分"已证实的根因""高概率怀疑点""证据不足的待确认项"。
- 给出可执行的下一步。
证据类型与优先级
截图（最高优先级）
- 项目是可视化工厂规划工具，截图是最直接的证据。
- 最适合看：
- UI 渲染是否正确（设备图标、连接线、端口位置）
- 数据面板显示的数值是否正确
- 是否有异常弹窗、遮罩、加载态
- 布局/缩放/分辨率是否导致显示问题
issue 正文描述
- 适合看：
- 用户操作路径和预期行为
- 复现步骤
- 使用的设备/配方名称
浏览器控制台输出
- 适合看：
- JavaScript 错误堆栈
- React 渲染警告
- 数据解析异常
导出的蓝图 JSON / 配置文件
解包数据对照
- 当 issue 涉及设备数据、端口坐标、配方数值的准确性时，对照
.temp/json-export.json 校验。
How To Filter Evidence
-
从 issue 文本提取锚点：
- 版本、浏览器、设备类型（桌面/平板/手机）
- 操作路径（如"从工具箱拖入设备→连接端口→保存蓝图"）
- 用户声称"出问题"的具体界面/阶段
-
从截图中找高价值信号：
- UI 元素是否错位、缺失、重叠
- 数据数值是否异常
- 是否有异常状态提示
-
先锁定关键组件再下钻。
- 从 issue 描述定位涉及的 UI 组件或业务模块。
- 在该模块代码中搜索相关逻辑。
-
区分表象和根因。
- 用户看到的 UI 异常可能只是表象。
- 根因可能在数据定义（
src/registry/）、业务逻辑（src/domain/）或状态管理（src/app/state/）。
-
回答时只保留关键片段，不要倾倒整段代码。
Common Patterns
-
问题在截图和描述不一致：以截图为准，指出描述与截图不符之处。
-
问题涉及数据值不对：优先检查 src/registry/ 中的定义数据，必要时对照 .temp/json-export.json。
-
问题只在特定设备/分辨率出现：检查 src/shared/browser/ 的响应式判断逻辑。
-
问题涉及中文名称：在 src/shared/i18n/ 中查找对应 id。
-
仿真与游戏行为不一致：先确认用户是否声称仿真实现与游戏内行为有差异。若是，则必须要求补充游戏内截图作为对照。无游戏截图则不给出最终结论，标记为证据不足。对照游戏截图与仿真数据逐项列出差异。
-
证据更接近"场景不支持"：给出代码中的限制逻辑依据，不要只给主观判断。
Correlating With Code
对本项目的代码回溯优先级：
src/registry/ — 静态数据定义（配方、设备、物品）src/domain/ — 领域模型和业务规则src/editor/ — 编辑器核心逻辑src/simulation/ — 仿真引擎src/app/ — UI 层src/shared/i18n/ — 翻译文案help/ — 帮助文档.temp/json-export.json — 解包数据校验
中文文案查找
本项目使用 src/shared/i18n/ 管理多语言文案。输出结论时：
- 设备名称、物品名称、按钮文案等，先在
src/shared/i18n/ 中查找中文名和对应 id。
- 如果找不到中文文案，给出 key/id 并说明"未在 i18n 文件中找到对应中文"。
- 用户自定义名称优先保留，必要时括号补原始 key。
Linking Code Evidence
- 统一给出远端 GitHub
blob 行号链接：https://github.com/<owner>/<repo>/blob/<commit>/<path>#L14-L20
<commit> 默认使用当前 HEAD。- 引用文档或配置也尽量给远端链接。
Output Format
## Issue 概要
- issue：`#1234`
- 版本 / 浏览器 / 设备：
- 涉及功能 / 设备 / 配方：
- 用户现象：
## 附件概览
- 实际可读文件 / 截图：
- 缺失或未上传的证据：
## 关键证据
<details><summary>点击此处展开</summary>
- issue 正文 / 评论：
- 截图分析：
- 控制台输出：
- 代码依据：
</details>
## 根因判断
- 直接结论：
- 证据链：
- 当前主线是否可能已修复：
## 修复方案
1. 代码 / 数据层修复
2. 需要补充的测试或验证
3. 如属于不支持场景，如何限制入口或改进提示
## 给用户的建议
- 临时绕过方案：
- 是否建议升级/刷新：
## 置信度
- 高 / 中 / 低
- 还缺什么证据
Reminders
- 不要仅凭 issue 文本下结论，必须回溯代码。
- 不要把当前分支代码直接当成 issue 当时的真实环境。
- 截图和分析冲突时，优先解释冲突，再决定更可信的证据链。
- 涉及数据准确性时，对照
src/registry/ 和 .temp/json-export.json。
- 设备/物品名称使用 i18n 中文文案，不要直接输出内部 id。
- 代码引用用远端 GitHub blob 链接，不要给本地路径。
