Ревью кода

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

Агенты ревью

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

Детерминированный анализ

Перед запуском LLM-агентов /review автоматически запускает линтеры и проверки типов вашего проекта:

Для проектов, не соответствующих стандартным паттернам (например, OpenJDK), /review читает файлы CI-конфигурации, чтобы определить, какие команды линтинга/проверки использует проект. Настройка пользователем не требуется.

Детерминированные находки помечаются тегами [linter] или [typecheck] и пропускают LLM-верификацию — это ground truth.

• Ошибки → Критическая важность
• Предупреждения → Полезно иметь (только в терминале, не публикуются как комментарии в PR)

Если инструмент не установлен или превышен таймаут, он пропускается с информационным уведомлением.

Уровни важности

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

Автофикс

После вывода результатов /review предлагает автоматически применить исправления для находок уровня Critical и Suggestion, имеющих четкие решения:

Found 3 issues with auto-fixable suggestions. Apply auto-fixes? (y/n)

• Исправления применяются через инструмент edit (целевые замены, а не полная перезапись файлов)
• После исправлений запускаются пофайловые проверки линтером, чтобы убедиться, что новые проблемы не появились
• Для ревью PR исправления автоматически коммитятся и пушатся из worktree — ваш рабочий каталог остается чистым
• Находки уровня Nice to have и с низкой степенью уверенности никогда не исправляются автоматически
• Отправка ревью PR всегда использует вердикт до исправлений (например, “Request changes”), так как удаленный 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 и статусы коммитов PR перед отправкой. Если какая-либо проверка завершилась ошибкой (или все проверки еще в ожидании), событие API автоматически понижается с APPROVE до COMMENT, а в теле ревью объясняется причина. Обоснование: LLM-ревью читает код статически и не видит ошибки runtime-тестов; одобрение при красном CI было бы misleading. Inline-находки все равно публикуются без изменений. Если вы хотите одобрить в любом случае (например, известная нестабильность CI), отправьте одобрение GitHub вручную после проверки.

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

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

Примечание: fix these issues доступно только для локальных ревью. Для ревью PR используйте Автофикс (Шаг 8) — worktree очищается после ревью, поэтому интерактивное исправление после ревью невозможно.

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

Вы можете настроить критерии ревью для каждого проекта. /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-агентов ревью (1-6) как дополнительные критерии. Для ревью PR правила читаются из базовой ветки, чтобы злонамеренный PR не мог внедрить правила обхода.

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

# Review Rules
 
- All API endpoints must validate authentication
- Database queries must use parameterized statements
- React components must not use inline styles
- Error messages must not expose internal paths

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

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

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

Ревью разными моделями

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

# Ревью моделью A
/review 123
 
# Переключение модели
/model
 
# Повторное ревью — полное ревью моделью B (не пропускается)
/review 123
# → "Previous review used qwen3-coder. Running full review with gpt-4o for a second opinion."

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

Отчеты ревью

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

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

Отчеты включают: временную метку, статистику diff, результаты детерминированного анализа, все находки со статусом верификации и вердикт.

Анализ влияния на другие файлы

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

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

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

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

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

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

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

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

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

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

Молчание лучше шума. Каждый комментарий должен стоить времени читателя.

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