Ревью кода с Opus 5.5: как проверить каждую найденную ошибку

Проверяйте замечания Opus 5.5 по входным данным, требованиям и тестам. Скачайте учебный Python-модуль с двумя дефектами, промпт и таблицу для фиксации результатов.

Чёрный рисунок настольной лампы на светлой карточке, серо-голубой фон, точки и надпись Opus 5.5 Code Review.

Замечание Opus 5.5 при ревью должно указывать на воспроизводимое поведение, а не просто на необычный вид кода. Здесь небольшой Python-модуль, промпт и тесты помогают отделить доказанный дефект от предположения.

Руководство по Opus 5.5 проверено 24 сентября 2026 года. Мы запускали синтетический код локально. Не утверждаем, что Opus нашёл его ошибки, и не измеряем точность модели или ложные срабатывания.

Зафиксируйте код и требования

В архиве нужны review_fixture.py, review-prompt.txt, review_tests.py и пустой findings.csv. Модуль намеренно дефектный и не предназначен для production.

Контракт: функция пагинации возвращает до size элементов начиная с offset; скидка вне диапазона 0–100 должна отклоняться; копирование тегов возвращает независимую поверхностную копию списка. Без этих условий рецензент может принять проектное решение за ошибку или пропустить важное поведение.

Запишите commit либо хеш архива, ID модели, провайдера, версию клиента, effort и права инструментов. В Claude Code проверьте модель по инструкции доступа. Одной подписи в интерфейсе недостаточно для доказательства маршрута каждого вызова.

Сначала доказательство, затем правка

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

При оценке независимого обнаружения спрячьте тесты и эталон до получения замечаний. Если дать их заранее, проверяется умение читать готовый ответ — это другая задача. Для обычного исправления показывать тесты уместно, но такой запуск нужно обозначать как исправление по тестам, а не независимый поиск дефектов.

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

Воспроизведите два подготовленных дефекта

После сохранения замечаний запустите:

python3 review_tests.py

Ненулевой код завершения ожидается. Мы получили два проваленных теста и один успешный. Это намеренный результат упражнения, а не ошибка сборки сайта.

ПоведениеВходОжидаетсяПолучается
На элемент меньшеpage([1,2,3], 0, 2)[1,2][1]
Неверная скидка принятаpayable(1000, 120)ValueError-200
Независимая поверхностная копияДобавление элемента в результат copy_tags(['a'])Исходный список неизмененОстаётся ['a']

Срез заканчивается на один элемент раньше нужного, а скидка вычисляется без проверки диапазона. Копирование выполняет именно заданное требование. Это не доказательство универсальной корректности функции, но отсутствие глубокой копии не является дефектом при требовании поверхностной.

Оценивайте находки, а не уверенный тон

Повторите каждый триггер на замороженной версии и присвойте статус: подтверждено, не обосновано или не решено. Сведите дубли одной причины перед подсчётом. Отдельно запишите подготовленные дефекты, которых не было в отчёте.

Одна правильная находка и одна пропущенная ошибка — неполное ревью, даже если все написанные фразы верны. Подробное объяснение не исправляет неверный триггер или придуманное требование.

Precision и recall требуют согласованных меток и знаменателей. Маленький модуль обучает методу, но не даёт рейтинг модели. В реальном проекте есть интеграции, миграции данных, конкурентное выполнение и неясные требования. Берите соответствующие работе примеры и сохраняйте трудные и неудачные прогоны.

Исправляйте отдельно и проверяйте регрессии

После оценки создайте ветку, исправьте конец среза и добавьте отклонение недопустимых скидок, затем повторите тесты. Добавьте пустой список, нулевой размер страницы и скидки 0 и 100. Поведение для отрицательного offset, дробной скидки и неверной суммы сначала определите в требованиях.

Патч ассистента всё равно нужно прочитать и проверить. Успех трёх случаев не означает полной корректности. Сохраните исходный дефектный модуль и вывод, чтобы опубликованный результат оставался воспроизводимым.

Изменения Opus 5.5 затрагивают интеграцию и обработку отказов: старую конфигурацию нельзя считать эквивалентной. Сохраняйте фактическую причину остановки и незавершённые ревью, не выдавая их за завершённые.

В платной оценке учитывайте usage, все попытки, подтверждённые находки, пропуски, необоснованные замечания и время человека. Сравнение стоимости Sol и Opus объясняет, почему цена токена не доказывает качество ревью. Начните с упражнения, затем собирайте свидетельства в собственном разрешённом репозитории.

Часто задаваемые вопросы

Здесь измерена точность поиска ошибок Opus 5.5?
Нет. Дефекты и ожидаемое поведение подготовлены для обучения. Локальный тест не является результатом ревью модели.
Можно подтвердить замечание без воспроизведения?
До независимой проверки входных данных, ожидаемого и фактического поведения считайте его гипотезой.
Зачем оставлен успешный тест?
Он фиксирует нормальное поведение и помогает обсуждать неподтверждённые замечания. Один случай не определяет общую частоту ложных срабатываний.