Ревью кода

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

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

# Review local uncommitted changes
/review
 
# Review a pull request (by number or URL)
/review 123
/review https://github.com/org/repo/pull/123
 
# Review and post inline comments on the PR
/review 123 --comment
 
# Review a specific file
/review src/utils/auth.ts

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

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

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

Step 1:  Determine scope (local diff / PR worktree / file)
Step 2:  Load project review rules
Step 3:  Run deterministic analysis (linter, typecheck)    [zero LLM cost]
Step 4:  5 parallel review agents                          [5 LLM calls]
           |-- Agent 1: Correctness & Security
           |-- Agent 2: Code Quality
           |-- Agent 3: Performance & Efficiency
           |-- Agent 4: Undirected Audit
           '-- Agent 5: Build & Test (runs shell commands)
Step 5:  Deduplicate --> Batch verify --> Aggregate         [1 LLM call]
Step 6:  Reverse audit (find coverage gaps)                 [1 LLM call]
Step 7:  Present findings + verdict
Step 8:  Autofix (user-confirmed, optional)
Step 9:  Post PR inline comments (if requested)
Step 10: Save report + incremental cache
Step 11: Clean up (remove worktree + temp files)

Агенты ревью

Все агенты запускаются параллельно. Результаты агентов 1–4 проверяются в рамках единого прохода верификации (один агент проверяет все находки сразу, фиксируя количество вызовов LLM). После верификации агент обратного аудита перечитывает весь дифф с учётом всех подтверждённых находок, чтобы выявить проблемы, которые пропустили остальные агенты. Результаты обратного аудита пропускают этап верификации (агент уже обладает полным контекстом) и сразу включаются в отчёт как результаты с высокой степенью уверенности.

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

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

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

Находки детерминированного анализа помечаются тегами [linter] или [typecheck] и пропускают LLM-верификацию — они считаются истиной.

• Errors → Критическая важность
• Warnings → Полезно, но не обязательно (только в терминале, не публикуется в комментариях к 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, линтера, сборки/тестов и автоисправлений. Ревью основывается только на тексте диффа (полученного через GitHub API). Комментарии к PR всё ещё можно публиковать, если у вас есть права на запись.

Инлайн-комментарии к PR

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

/review 123 --comment

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

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

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

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

• Находки уровня Nice to have (включая предупреждения линтера)
• Находки с низкой степенью уверенности

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

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

Примечание: fix these issues доступно только для локальных ревью. Для ревью PR используйте Autofix (Шаг 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–4) в качестве дополнительных критериев. Для ревью 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 анализирует только изменения с момента последнего ревью:

# First review — full review, cache created
/review 123
 
# PR updated with new commits — only new changes reviewed
/review 123

Ревью с другой моделью

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

# Review with model A
/review 123
 
# Switch model
/model
 
# Review again — full review with model B (not skipped)
/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

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

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

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

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

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

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

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

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

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

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

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

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

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