Ревью кода

Проверяйте изменения кода на корректность, безопасность, производительность и качество с помощью команды /review.

Быстрый старт

# Проверить локальные незакоммиченные изменения
/review
 
# Проверить pull request (по номеру или URL)
/review 123
/review https://github.com/org/repo/pull/123
 
# Проверить и оставить inline-комментарии в PR
/review 123 --comment
 
# Проверить конкретный файл
/review src/utils/auth.ts

Если незакоммиченных изменений нет, /review сообщит об этом и остановится — агенты не запускаются.

Как это работает

Команда /review запускает многоэтапный пайплайн:

Шаг 1: Определение области (локальный diff / worktree PR / файл)
Шаг 2: Загрузка правил ревью проекта
Шаг 3: 10 параллельных агентов ревью                         [10 вызовов LLM]
           |-- Агент 0: Issue Fidelity и поиск корневой причины
           |-- Агент 1: Корректность
           |-- Агент 2: Безопасность
           |-- Агент 3: Качество кода
           |-- Агент 4: Производительность и эффективность
           |-- Агент 5: Покрытие тестами
           |-- Агент 6: Свободный аудит (3 персоны: 6a/6b/6c)
           '-- Агент 7: Сборка и тесты (запускает shell-команды)
Шаг 4: Дедупликация --> Пакетная проверка --> Агрегация         [1 вызов LLM]
Шаг 5: Итеративный обратный аудит (1-3 раунда, поиск пробелов) [1-3 вызова LLM]
Шаг 6: Предоставление результатов + вердикт
Шаг 7: Отправка ревью PR (inline-комментарии, если запрошено)
Шаг 8: Сохранение отчета + инкрементальный кэш
Шаг 9: Очистка (удаление worktree + временных файлов)

Агенты ревью

Все агенты работают параллельно (Агент 6 запускает 3 варианта персон одновременно, в сумме 10 параллельных задач для ревью PR в том же репозитории; Агент 0 пропускается для ревью локального diff и путей к файлам, где запускается 9 задач). Результаты Агентов 0-6 проверяются в один проход пакетной проверки (один агент проверяет все результаты сразу, фиксируя стоимость проверки независимо от количества находок). После проверки запускается итеративный обратный аудит на 1-3 раунда поиска пробелов — каждый раунд получает накопительный список находок из предыдущих раундов, поэтому последующие раунды фокусируются на том, что осталось не обнаруженным. Цикл останавливается, как только раунд возвращает “No issues found”, или после 3 раундов (жесткий лимит). Находки обратного аудита пропускают проверку (агент уже имеет полный контекст) и включаются как результаты с высокой степенью достоверности.

Уровни критичности

Результаты с низкой достоверностью отображаются в отдельной секции “Needs Human Review” в терминале и никогда не публикуются как комментарии в PR.

Изоляция worktree

При ревью PR команда /review создает временный git worktree (.qwen/tmp/review-pr-<number>) вместо переключения текущей ветки. Это означает:

• Ваше рабочее дерево, проиндексированные изменения и текущая ветка никогда не затрагиваются
• Зависимости устанавливаются в worktree (npm ci и т.д.), чтобы сборка/тесты работали
• Команды сборки и тестов запускаются изолированно, не засоряя локальный кэш сборки
• Если что-то пойдет не так, ваша среда не пострадает — просто удалите worktree
• Worktree автоматически очищается после завершения ревью
• Если ревью прервано (Ctrl+C, сбой), следующая команда /review для того же PR автоматически очистит устаревший worktree перед началом работы
• Отчеты о ревью и кэш сохраняются в основную директорию проекта (не в worktree)

Ревью PR из другого репозитория

Вы можете делать ревью PR из других репозиториев, передав полный URL:

/review https://github.com/other-org/other-repo/pull/456

Это выполняется в облегченном режиме — без worktree, без сборки/тестов. Ревью основано только на тексте diff (полученном через GitHub API). Комментарии в PR все еще могут быть опубликованы, если у вас есть доступ на запись.

Inline-комментарии в PR

Используйте --comment, чтобы публиковать находки прямо в PR:

/review 123 --comment

Или, после запуска /review 123, введите post comments, чтобы опубликовать находки без повторного запуска ревью.

Что публикуется:

• Находки уровня Critical и Suggestion с высокой достоверностью в виде inline-комментариев к конкретным строкам
• Для вердиктов Approve/Request changes: сводка ревью с вердиктом
• Для вердикта Comment, когда все inline-комментарии опубликованы: отдельная сводка не выводится (inline-комментариев достаточно)
• Сноска об авторстве модели в каждом комментарии (например, — qwen3-coder via Qwen Code /review)

Что остается только в терминале:

• Находки уровня Nice to have
• Находки с низкой достоверностью

Собственные PR: GitHub не позволяет отправлять ревью с APPROVE или REQUEST_CHANGES на ваши собственные pull request — оба варианта завершаются ошибкой HTTP 422. Когда /review обнаруживает, что автор PR совпадает с текущим аутентифицированным пользователем, он автоматически понижает событие API до COMMENT независимо от вердикта, чтобы отправка прошла успешно. В терминале при этом отображается честный вердикт (“Approve” / “Request changes” / “Comment”) — нейтрализуется только событие ревью на стороне GitHub. Сами находки по-прежнему появляются в виде inline-комментариев к конкретным строкам, поэтому содержательная обратная связь не меняется.

Повторное ревью PR с предыдущими комментариями Qwen Code: когда /review запускается для PR, в котором уже есть предыдущие комментарии ревью Qwen Code, он классифицирует их перед публикацией новых. Только перекрытие на одной строке (существующий комментарий на той же (path, line), что и новая находка) требует подтверждения — это тот случай, когда вы увидите визуальный дубликат на одной и той же строке кода. Комментарии из старых коммитов, комментарии с ответами (считаются решенными) и комментарии, которые просто не пересекаются ни с одной новой находкой, молча пропускаются, с записью в логе терминала, чтобы вы знали, что было отфильтровано.

Проверка статуса CI / сборки перед APPROVE: если вердикт — “Approve”, /review запрашивает check-runs и commit statuses PR перед отправкой. Если какая-либо проверка упала (или все проверки еще в ожидании), событие API автоматически понижается с APPROVE до COMMENT, а тело ревью объясняет причину. Обоснование: ревью LLM читает код статически и не может увидеть ошибки тестов во время выполнения; одобрение при красном CI было бы вводящим в заблуждение. Inline-находки при этом публикуются без изменений. Если вы все равно хотите одобрить (например, при известном нестабильном падении CI), отправьте одобрение GitHub вручную после проверки.

Последующие действия

После ревью контекстные подсказки появляются в виде ghost text. Нажмите Tab, чтобы принять:

Примечание: fix these issues доступно только для локальных ревью. Для ревью PR worktree очищается после завершения, поэтому интерактивное исправление после ревью невозможно — используйте --comment или post comments для публикации находок.

Правила ревью проекта

Вы можете настроить критерии ревью для каждого проекта. /review читает правила из следующих файлов (по порядку):

1. .qwen/review-rules.md (нативный для Qwen Code)
2. .github/copilot-instructions.md (приоритетный) или copilot-instructions.md (резервный — загружается только один из них, не оба)
3. AGENTS.md — секция ## Code Review
4. QWEN.md — секция ## Code Review

Правила внедряются в агентов ревью LLM (0-6) как дополнительные критерии. Для ревью PR правила читаются из базовой ветки, чтобы предотвратить внедрение правил обхода злонамеренным PR.

Issue Fidelity

Для PR с исправлениями багов агент Issue Fidelity получает доказательства из issue напрямую, а не полагается на текст описания PR. Он использует gh pr view <pr> --repo <owner/repo> --json closingIssuesReferences для получения надежных метаданных GitHub о связанных issue, затем gh issue view <number> --repo <issue_owner>/<issue_repo> --json title,body,comments для получения оригинального отчета и обсуждения — форма --json включает body issue (оригинальное воспроизведение от репортера), которое отсутствует при использовании только --comments, а собственный репозиторий issue читается из каждой ссылки (PR может закрывать issue в другом репозитории). Этот агент запускается только для целей PR; ревью локального diff и путей к файлам его пропускают.

closingIssuesReferences — это подсказка для поиска, а не доказательство того, что автор связал правильный issue: если он пуст, но PR ссылается на очевидное целевое issue, агент все равно получит его после оценки релевантности. Полученный текст issue рассматривается как ненадежные данные (факты извлекаются, встроенные инструкции игнорируются). Для релевантных issue оригинальное воспроизведение, наблюдаемые данные, ожидаемое поведение и комментарии мейнтейнеров рассматриваются как доказательства наивысшего приоритета для определения того, решает ли PR правильную проблему.

Если доказательства из issue показывают, что вышестоящий сервис или провайдер вернул некорректные данные вне клиентского контракта, изменения клиентского парсера или санитайзера не рассматриваются как валидное исправление корневой причины, если только мейнтейнер явно не запросил защитное обходное решение. Тест, который воспроизводит некорректный вывод вышестоящего сервиса, доказывает лишь то, что обходное решение обрабатывает такую форму данных; он не доказывает, что обходное решение архитектурно уместно.

Пример .qwen/review-rules.md:

# Правила ревью
 
- Все API-эндпоинты должны проверять аутентификацию
- Запросы к базе данных должны использовать параметризованные выражения
- React-компоненты не должны использовать инлайн-стили
- Сообщения об ошибках не должны раскрывать внутренние пути

Инкрементальное ревью

При повторном ревью PR команда /review проверяет только изменения, внесенные с момента последней проверки:

# Первое ревью — полная проверка, создается кэш
/review 123
 
# PR обновлен новыми коммитами — проверяются только новые изменения
/review 123

Кросс-модельное ревью

Если вы смените модель (через /model) и повторно проверите тот же PR, /review обнаружит изменение модели и выполнит полную проверку вместо пропуска:

# Ревью с моделью A
/review 123
 
# Смена модели
/model
 
# Повторное ревью — полная проверка моделью B (не пропускается)
/review 123
# → "Предыдущее ревью использовало qwen3-coder. Запускается полная проверка с помощью gpt-4o для получения второго мнения."

Кэш хранится в .qwen/review-cache/ и отслеживает как SHA коммита, так и ID модели. Убедитесь, что эта директория добавлена в .gitignore (также подойдет более общее правило, например .qwen/*). Если закешированный коммит был удален при rebase, инструмент вернется к полной проверке.

Отчеты о ревью

Для ревью в рамках одного репозитория результаты сохраняются в виде Markdown-файла в директории .qwen/reviews/ вашего проекта (облегченные кросс-репозиторные ревью пропускают сохранение отчетов):

.qwen/reviews/2026-04-06-143022-pr-123.md
.qwen/reviews/2026-04-06-150510-local.md

Отчеты включают: временную метку, статистику диффа, результаты сборки/тестов, все найденные проблемы со статусом проверки и итоговый вердикт.

Анализ влияния между файлами

Когда изменения в коде затрагивают экспортируемые функции, классы или интерфейсы, агенты ревью автоматически ищут всех, кто их вызывает, и проверяют совместимость:

• Изменения количества или типов параметров
• Изменения типа возвращаемого значения
• Удаленные или переименованные публичные методы
• Критические изменения API

Для больших диффов (>10 измененных символов) анализ отдает приоритет функциям с измененными сигнатурами.

Эффективность использования токенов

Пайплайн ревью использует ограниченное количество вызовов LLM независимо от количества найденных проблем:

Для большинства PR результат сходится к нижней границе диапазона (1 раунд обратного аудита); лимит предотвращает неконтролируемый рост затрат в патологических случаях.

Что НЕ помечается

Ревью намеренно исключает:

• Уже существующие проблемы в неизмененном коде (фокус только на диффе)
• Стиль или форматирование, которые автоматически нормализуются форматтером, или именование, соответствующее соглашениям вашей кодовой базы — но НЕ существенные проблемы, которые отметил бы линтер или проверка типов (неиспользуемые переменные, недостижимый код, ошибки типов), так как они входят в область проверки
• Субъективные предложения “рассмотрите возможность сделать X” без указания на реальную проблему
• Незначительный рефакторинг, который не исправляет баг или не снижает риск
• Отсутствие документации, если только логика не является по-настоящему запутанной
• Проблемы, уже обсуждавшиеся в существующих комментариях к PR (чтобы не дублировать отзывы людей)

Философия дизайна

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

• Если нет уверенности, является ли что-то проблемой → не сообщайте об этом
• Одинаковый паттерн в N файлах → агрегируется в одну найденную проблему
• Комментарии к PR содержат только проблемы с высокой степенью уверенности
• Косметические правки стиля/форматирования, соответствующие соглашениям кодовой базы, исключаются