Void APIБаза знанийКод-ревью с помощью ИИ: как выбрать модель и встроить проверку в работу
Код-ревью с помощью ИИ: как выбрать модель и встроить проверку в работу
Нейросеть может быстро прочитать diff, найти забытую проверку на null, гонку состояний или расхождение с описанием задачи. Но полезным ревью становится только тогда, когда модель получает контекст, отвечает в проверяемом формате и не заменяет собой тесты и ответственность автора. Разберём рабочий процесс: от одного запроса в чате до шага в CI.
Что ИИ-ревью находит хорошо, а что пропускает
Языковые модели хорошо замечают локальные ошибки: неправильные условия, необработанные исключения, утечки ресурсов, опечатки в именах, несогласованность между изменённой функцией и её вызовами внутри diff. Они также полезны для вопросов читаемости: слишком длинные функции, неясные имена, дублирование.
Хуже модели справляются с тем, чего нет во входных данных: архитектурными договорённостями команды, поведением соседних сервисов, нагрузкой в продакшене и бизнес-правилами, которые нигде не записаны. Модель может уверенно сообщить о несуществующей проблеме или пропустить реальную. Поэтому каждое замечание — гипотеза для проверки, а не вердикт.
Практическая цель ИИ-ревью — сократить время человека на очевидное и привлечь внимание к рискованным местам. Решение о слиянии, проверка безопасности критичных изменений и ответственность за код остаются у команды.
Какой контекст передать модели
Минимальный набор: unified diff с несколькими строками контекста, описание задачи или pull request, язык и версия платформы. Если изменение затрагивает публичный интерфейс, добавьте полные исходники изменённых функций и их ключевых вызовов — по одному diff модель не видит, как код используется.
Добавьте короткие правила проекта: стиль ошибок, запрет на определённые зависимости, требования к логированию и тестам. Пять конкретных правил полезнее, чем ссылка на весь style guide. Не отправляйте в модель секреты, ключи, персональные данные из фикстур и закрытый код, если политика компании этого не разрешает.
Большие pull request лучше делить по файлам или логическим блокам. Огромный diff в одном запросе увеличивает стоимость и повышает шанс, что модель пропустит детали в середине. Генерированные файлы, lock-файлы и миграции-снимки обычно исключают из ревью.
Промпт для ревью pull request
Попросите модель искать конкретные классы проблем и возвращать структурированный список с указанием файла, строки, серьёзности и обоснования. Явно разрешите ответ «замечаний нет»: без этого модель склонна придумывать стилистические придирки, чтобы список не был пустым.
Ты проводишь код-ревью pull request.
Проект: backend на Python 3.12, FastAPI, PostgreSQL.
Правила команды:
- ошибки API возвращаются через HTTPException с кодом и коротким detail;
- запросы к БД только через репозитории в app/db;
- каждое изменение поведения сопровождается тестом.
Ищи в порядке важности:
1. Ошибки корректности и граничные случаи.
2. Проблемы безопасности: инъекции, утечки данных, проверка прав.
3. Конкурентность, транзакции, утечки ресурсов.
4. Нарушения правил команды и отсутствие тестов.
Стиль упоминай, только если он мешает пониманию.
Формат ответа — JSON-массив объектов:
{"file": "...", "line": 0, "severity": "high|medium|low",
"problem": "...", "suggestion": "..."}
Ссылайся только на строки из diff. Если уверенности нет, укажи это в problem.
Если существенных замечаний нет, верни [].GPT или Claude для код-ревью
Универсального победителя нет: результат зависит от языка, размера изменения и того, насколько хорошо задан контекст. Разумный подход — взять 10–20 уже закрытых pull request с известными найденными ошибками и прогнать их через две-три модели с одним промптом. Считайте полезные замечания, ложные срабатывания и пропуски.
Через Void API можно сравнить модели семейств GPT и Claude одним ключом, меняя только поле model. Для быстрого первичного прохода подойдёт более дешёвая модель, а для сложных или критичных изменений — более сильная. Рейтинги на сайте отражают использование и пользовательские оценки, а не бенчмарк код-ревью.
| Сценарий | Что важно | Как выбирать |
|---|---|---|
| Быстрый проход по каждому PR | Цена и скорость | Недорогая модель, короткий контекст, только high/medium замечания. |
| Сложный рефакторинг | Понимание связей между файлами | Сильная модель с полными исходниками изменённых модулей. |
| Изменения безопасности | Минимум пропусков | Сильная модель плюс обязательное ревью человеком. |
Скрипт: отправить diff на ревью через API
Пример ниже берёт diff текущей ветки относительно main и отправляет его в OpenAI-совместимый API. Ключ читается из переменной окружения. Ответ модели проверяется как JSON: если разбор не удался, скрипт завершается ошибкой, а не публикует произвольный текст.
import json
import subprocess
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["VOID_API_KEY"],
base_url="https://void-api.tech/v1",
)
diff = subprocess.run(
["git", "diff", "--unified=5", "origin/main...HEAD",
"--", ".", ":(exclude)*.lock"],
capture_output=True, text=True, check=True,
).stdout
if not diff.strip():
raise SystemExit("Изменений нет")
prompt = open("review-prompt.txt", encoding="utf-8").read()
response = client.chat.completions.create(
model="claude-sonnet-5.5",
messages=[
{"role": "system", "content": prompt},
{"role": "user", "content": diff},
],
)
text = response.choices[0].message.content
findings = json.loads(text)
for item in findings:
print(f"[{item['severity']}] {item['file']}:{item['line']} {item['problem']}")Как встроить ИИ-ревью в CI
Запускайте ревью как необязательную проверку: шаг публикует замечания комментарием, но не блокирует слияние. Блокирующий шаг на основе вероятностного ответа быстро приучит команду игнорировать или обходить проверку.
Храните API-ключ в секретах CI и не запускайте шаг с секретами для pull request из форков: чужой код может прочитать переменные окружения. Ограничьте размер diff и количество запросов на PR, чтобы один огромный коммит не превратился в неожиданный счёт.
Записывайте модель, версию промпта и стоимость запроса. Через месяц станет видно, какие замечания команда принимает, а какие закрывает как шум, — и промпт можно сократить до действительно полезных категорий.
Ревью в IDE и агентах: OpenCode, Cline, Codex CLI
Не обязательно писать скрипт: агенты для программирования умеют читать репозиторий и запускать git diff сами. Попросите агента проверить незакоммиченные изменения по тем же правилам и сначала перечислить замечания, не исправляя код. Так вы сохраните контроль над тем, какие правки принимать.
Преимущество агента — доступ к соседним файлам и тестам: он может проверить гипотезу, запустив тест, а не только предположить ошибку. Недостаток — больший расход токенов на чтение проекта.
Попробуйте GPT и Claude через Void API
Подключайте GPT и Claude к своим приложениям, ботам и ИИ-агентам через Void API — единый OpenAI-совместимый API. Доступ из России без VPN, пополнение по СБП и оплата по фактическому использованию. Выбирайте модель под задачу, сравнивайте цены и начинайте с одного API-ключа.
Вопросы и ответы
Может ли нейросеть заменить код-ревью человеком?
Нет. Она ускоряет поиск очевидных ошибок и подсвечивает рискованные места, но не знает всех договорённостей команды и может ошибаться. Решение о слиянии остаётся за человеком.
Сколько стоит ИИ-ревью одного pull request?
Зависит от размера diff, контекста и модели. Посчитайте входные и выходные токены и умножьте на цены из каталога. Небольшой PR обычно стоит доли цента — несколько центов, но большие изменения с полными файлами дороже.
Безопасно ли отправлять код в API?
Это вопрос политики вашей компании. Не отправляйте секреты и персональные данные, исключайте закрытые части кода, если их обработка внешними сервисами запрещена.