Перейти к основному содержанию
VOID

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 замечания.
Сложный рефакторингПонимание связей между файламиСильная модель с полными исходниками изменённых модулей.
Изменения безопасностиМинимум пропусковСильная модель плюс обязательное ревью человеком.

Модели и цены Void APIРейтинг моделей по задачам

Скрипт: отправить diff на ревью через API

Пример ниже берёт diff текущей ветки относительно main и отправляет его в OpenAI-совместимый API. Ключ читается из переменной окружения. Ответ модели проверяется как JSON: если разбор не удался, скрипт завершается ошибкой, а не публикует произвольный текст.

review.py, Python 3 и пакет openai
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']}")

Справочник API: chat completions и модели

Как встроить ИИ-ревью в CI

Запускайте ревью как необязательную проверку: шаг публикует замечания комментарием, но не блокирует слияние. Блокирующий шаг на основе вероятностного ответа быстро приучит команду игнорировать или обходить проверку.

Храните API-ключ в секретах CI и не запускайте шаг с секретами для pull request из форков: чужой код может прочитать переменные окружения. Ограничьте размер diff и количество запросов на PR, чтобы один огромный коммит не превратился в неожиданный счёт.

Записывайте модель, версию промпта и стоимость запроса. Через месяц станет видно, какие замечания команда принимает, а какие закрывает как шум, — и промпт можно сократить до действительно полезных категорий.

Ревью в IDE и агентах: OpenCode, Cline, Codex CLI

Не обязательно писать скрипт: агенты для программирования умеют читать репозиторий и запускать git diff сами. Попросите агента проверить незакоммиченные изменения по тем же правилам и сначала перечислить замечания, не исправляя код. Так вы сохраните контроль над тем, какие правки принимать.

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

Подключить агентов к Void API

Попробуйте GPT и Claude через Void API

Подключайте GPT и Claude к своим приложениям, ботам и ИИ-агентам через Void API — единый OpenAI-совместимый API. Доступ из России без VPN, пополнение по СБП и оплата по фактическому использованию. Выбирайте модель под задачу, сравнивайте цены и начинайте с одного API-ключа.

Перейти на void-api.techПосмотреть модели и цены

Вопросы и ответы

Может ли нейросеть заменить код-ревью человеком?

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

Сколько стоит ИИ-ревью одного pull request?

Зависит от размера diff, контекста и модели. Посчитайте входные и выходные токены и умножьте на цены из каталога. Небольшой PR обычно стоит доли цента — несколько центов, но большие изменения с полными файлами дороже.

Безопасно ли отправлять код в API?

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