Клод Соннет 4.6 оценивает отчёты об ошибках от четырёх локальных моделей Qwen3.5.

Тестирование локальных моделей для составления отчётов об ошибках

Разработчик, переходящий с Sonnet/Haiku на локальные модели на 32-гигабайтном MacBook Air M5, протестировал четыре варианта Qwen3.5 на способность составлять отчёты об ошибках. Используя LM Studio в качестве сервера и opencode CLI для вызова моделей, он попросил каждую модель изучить и составить отчёт об ошибке для проблемы в iOS-игре, где границы снаряжения не сбрасывают цвет должным образом после снятия предметов.

Протестированные модели

• Tesslate/OmniCoder-9B-GGUF Q8_0
• lmstudio-community/Qwen3.5-27B-GGUF Q4_K_M
• Jackrong/Qwen3.5-27B-Claude-4.6-Opus-Reasoning-Distilled-GGUF Q4_K_M
• lmstudio-community/Qwen3.5-35B-A3B-GGUF Q4_K_M

Подтверждение ошибки

Основная ошибка подтверждена в исходных файлах. В EquipmentSlotNode.swift условие if let c = borderColor в методе setEquipment молча пропускает присваивание, когда передаётся nil. В EquipmentNode.swift метод updateEquipment(from:) передаёт borderColor: nil для пустых слотов, поэтому цвет границы никогда не сбрасывается. Документация к setEquipment гласит "передайте nil, чтобы сохранить текущий цвет" — документируя некорректное поведение как намеренный дизайн.

Оценки отчётов от Claude Sonnet 4.6

bug_report_9b_omnicoder — A−

Лучший из четырёх. Предлагает самое чистое и идиоматичное исправление на Swift: borderShape.strokeColor = borderColor ?? theme.textDisabledColor.skColor — одна строка, заменяющая блок if let без лишних ветвлений. Единственный отчёт, упоминающий дополнительные контекстные файлы (GameScene.swift, BackpackManager.swift), которые являются частью потока, вызывающего ошибку.

Недостаток: Как и все четыре отчёта, тестовый код не скомпилируется. borderShape объявлен как private let в EquipmentSlotNode — @testable import раскрывает только internal, но не private. Не упоминает, что комментарий в документации нуждается в обновлении.

bug_report_27b_lmstudiocommunity — B+

Точный диагноз. Предлагает чистое исправление с двумя ветвями: if id != nil { borderShape.strokeColor = borderColor ?? theme.textDisabledColor.skColor } else { borderShape.strokeColor = theme.textDisabledColor.skColor } — более многословно, чем нужно, но верно. Правильно определяет EquipmentNode.updateEquipment как вызывающий метод и включает предложение по интеграционному тестированию.

Недостаток: Предлагает тест в LogicTests/EquipmentNodeTests.swift — файл, который уже существует и покрывает EquipmentNode, а не EquipmentSlotNode. Та же проблема с доступом к private в тестовом коде.

bug_report_27b_jackrong — B−

Правильный диагноз, но самое слабое предложенное исправление. Добавляет сброс внутри блока else: borderShape.strokeColor = theme.textDisabledColor.skColor // Reset border on clear — технически верно для конкретного случая снятия снаряжения, но оставляет весь метод в запутанном состоянии. Сброс границы в блоке else может быть немедленно перезаписан блоком if let ниже, если кто-то передаст id: nil, borderColor: someColor. Исправление латает конкретный сбой, не устраняя избыточность.

Разработчик использовал параметры по умолчанию, кроме размера контекстного окна, чтобы уместить как можно больше в оперативной памяти, отметив, что некоторая настройка может дать улучшение. Он пробовал некоторые модели unsloth, но с ограниченным успехом.