SWE-BenchStandard Solving Workflow

本技能指导你按照 SWE-Bench 的严苛标准解决 GitHub Issue。不仅是修复代码，更是要证明修复的正确性和无副作用。

🏆 核心原则 (Core Principles)

• Reproduction First: 修改代码前，必须先编写复现脚本，证明 Bug 存在。

• Test Driven: 只有当复现脚本从 Fail 变为 Pass，且不破坏原有测试时，任务才算完成。

• Minimal Changes: 只修改必要的文件，避免重构无关代码。

🚀 标准工作流 (Standard Workflow)

请严格按照以下 5 个阶段执行：

Phase 1: Issue Analysis (审题)

• 阅读 Issue: 理解用户报告的 Bug 现象、环境和复现步骤。

• 调用工具: 使用 code_search 初步探索 Issue 提到的报错信息或关键词。

• 输出: 明确 "Bug 预期行为" vs "实际行为"。

Phase 2: Reproduction (复现 - 最关键一步)

❌ 严禁跳过此步直接改代码！

• 创建脚本: 使用 scripts/reproduce_template.py 模板，在项目根目录创建 reproduce_issue.py 。

• 编写断言: 脚本必须包含 assert 语句：

• 在 Bug 存在时，脚本应抛出 AssertionError 或 crash (Exit Code != 0)。

• 在 Bug 修复后，脚本应正常退出 (Exit Code = 0)。

• 验证复现: python reproduce_issue.py

预期输出: AssertionError 或 Traceback

Phase 3: Localization (定位)

• AST 定位: 使用 code_search(search_type="function") 查找相关函数定义。

• 调用分析: 使用 code_impact(direction="both") 查看调用链，确定修改的影响范围。

• 确认根因: 阅读源码，找到逻辑漏洞的确切位置。

Phase 4: TDD Fixing (修复)

• 开发修复: 修改代码，修复 Bug。

• 增量测试: 如果需要，在项目测试套件（如 tests/ 目录）中添加新的测试用例文件。

• ** lint 检查**: 确保代码风格符合项目规范。

Phase 5: Verification (验证)

• 验证复现脚本 (Fail-to-Pass): python reproduce_issue.py

预期输出: 无报错，正常退出

• 验证原有测试 (Pass-to-Pass): 运行与修改模块相关的原有测试，确保无 Regression。 pytest tests/path/to/relevant_tests.py

🛠️ 常用工具集

• reproduce_issue.py : 必须创建的复现脚本。

• code_search : 查找定义。

• code_impact : 评估影响。

• run_command : 执行测试命令。

⚠️ 常见陷阱 (Pitfalls)

• 陷阱1: 没写复现脚本就改代码。 -> 后果: 无法证明你通过了 SWE-Bench 评测。

• 陷阱2: 修改了太多无关文件。 -> 后果: 引入新 Bug，评分降低。

• 陷阱3: 这里的测试通过了，但破坏了其他模块。 -> 后果: 必须运行相关回归测试。