Narylr350 JetBrains Code Fix
前置条件
- 先加载
jetbrains-ide-mcp，遵循其 IDE-first 编辑和验证规则。 - 输入可以是审查报告、IDE problems、构建失败、测试失败或用户提供的可复现 bug；不强制要求已有正式审查报告。
- 先读取相关 Git diff，避免覆盖用户已有改动。
Fix Process
1. 确认问题和范围
逐条确认问题可定位、可复现或有明确 Inspection/构建证据。来源未确认的问题先调查，不为了清零列表盲目修改。
按根因和修改边界分组：
- 同一 API 迁移或弃用问题
- 未使用 import、变量或不可达代码
- 符号命名或 shadowing
- 类型、空值和泛型问题
- 构建、配置或依赖问题
- 需要运行时证据的行为 bug
优先修 ERROR 和阻塞构建/测试的问题；WARNING 按本轮范围和用户要求处理。
2. 选择最安全的编辑方式
- 符号重命名：使用
rename_refactoring。 - 小范围确定性修改：使用
replace_text_in_file。 - 多文件或结构化修改：先用 IDE 搜索确认引用和影响范围，再使用精确 patch。
- 运行时根因不明确：先用测试、运行配置或
xdebug_*收集证据，再修改。 - 不为了消除 warning 改变未经确认的业务行为或公共 API。
3. 分批修复和即时验证
每完成一类或一个独立根因：
- 对修改文件调用
get_file_problems(errorsOnly=false)。 - 确认目标 error/warning 消失。
- 检查是否新增其他 error/warning。
- 调用
build_project验证受影响文件或模块。 - 行为变化时运行相关测试或运行配置。
不要使用 errorsOnly=true 证明 warning 已修复，因为它不会返回 warning。
4. 最终验证
完成全部修复后：
- 对所有修改代码文件调用
get_file_problems(errorsOnly=false)。 - 调用
build_project。 - 运行与修改相关的测试或复现步骤。
- 查看 Git diff，确认没有无关重构、自动格式化扩散或调试残留。
只有目标问题消失且没有本轮新增的阻塞问题时，才能报告修复完成。仍存在的问题按“已修复、明确跳过、需要业务决策、来源未确认”分类。
不硬修的情况
- 需要产品或业务决策
- 会改变公共 API 或架构边界但用户尚未确认
- 第三方库自身问题
- 无法复现且缺少足够证据
- 超出用户指定范围的既有问题
这些问题保留原始证据和下一步，不用猜测性修改换取表面清零。