Автоматизация code review в облаке: Claude и GPT в CI

Архитектура облачного ревью

Каждое событие pull request идёт одним и тем же путём.

Событие pull request
    -> очередь с SHA коммита
    -> изолированный воркер ревью
    -> diff и политика репозитория
    -> API Claude или GPT
    -> проверка и удаление дублей
    -> хранилище комментариев ревью
    -> API ревью в Git-провайдере

Воркеру хватает чтения репозитория: ему нужны diff, выбранные файлы, команды тестов и текст политики. Результат публикует отдельный публикатор с короткоживущим токеном и минимальным правом на ревью. Ключ API хранится в секретах CI, а не в файле workflow и не в промпте. У каждого слоя пайплайна одна задача:

Маршрутизация моделей

Живой каталог codexkey мы проверили 4 октября 2026 года, эти четыре ID в нём нашлись. Маршрут меняется вместе с вашей оценкой качества, поэтому перед запуском загляните в актуальные данные о моделях.

На обычном diff начните с claude-sonnet-5 или gpt-6-sol. Критерии эскалации пишите кодом, потому что надежда не правило: миграции базы, изменения авторизации, платежи, внешние webhooks, удаление данных. Только diff, подпавший под одно из условий, получает второй проход на claude-opus-5-5 или gpt-6-astra.

После регистрации создайте отдельный ключ для CI и поставьте ему лимит под бюджет проекта. Расходы на ревью тогда видны отдельной строкой, отдельно от продуктового трафика.

Дубли событий и неконтролируемый расход

Системы pull request могут прислать несколько событий на один коммит. Соберите ключ идемпотентности из репозитория, номера pull request, SHA коммита и версии политики ревью и запишите его до вызова модели. Если такой ключ уже есть, верните прежний результат.

Каждой задаче задайте дедлайн. Зависший запрос к модели должен уйти в очередь повторов или в состояние «ждёт человека», а не держать воркер и блокировку pull request бесконечно.

Лимит на ключе CI служит второй линией защиты. Если webhook зациклится или выкатят битый конфиг, расход упрётся в лимит, и остаток баланса уцелеет.

Границы контекста и политика данных

Начинайте с изменённых файлов, а интерфейс или тест модуля добавляйте, только когда ревьюеру без них не обойтись. Секреты, записи клиентов и учётные данные вычищайте до сборки промпта. Исходный diff оставьте в системе контроля версий, а в журнале ревью храните его хеш, если полное хранение запрещено.

Репозиторий может содержать инструкции, написанные атакующим, поэтому помечайте diff как недоверенные данные. Правила ревью живут в защищённом системном промпте или в конфиге. Комментарий в коде способен выдать себя за политику, и модель ему может поверить.

Проверка и публикация

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

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

Наблюдаемость, которая помогает

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

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

План запуска

Сначала включите пайплайн для внутреннего репозитория. Возьмите свежие закрытые pull request, где настоящие ошибки известны, и посчитайте точность: сколько находок бота указывают на реальный дефект. Если бот сыплет общими советами, сузьте промпт, дайте ему правила проекта и запретите комментировать без воспроизводимого последствия.

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

После обновления модели прогоните набор фикстур, прежде чем переводить трафик на новый маршрут. Прежний ID модели держите под рукой, пока новый не даст стабильный сигнал ревью.

FAQ

Что нельзя передавать в AI-ревью?

Секреты, ключи, дампы production и персональные данные, если их обработка не согласована. Фильтруйте файлы и очищайте данные до вызова модели.

Как понять, что автоматизация приносит пользу?

Сравните время до первого полезного замечания, долю подтверждённых находок и стоимость на один закрытый риск. Лайки под комментариями проверку результата не заменяют.

Можно ли запускать облачное ревью, не храня исходный код?

Можно: храните хеш и результат ревью, а провайдеру отправляйте только тот diff, который нужен модели. Срок хранения зависит от вашей политики данных и условий провайдера, поэтому решите его до запуска.

Какая модель должна блокировать merge?

Та, что прошла ваши фикстуры проверки, и только по находкам с воспроизводимым последствием. Название модели политикой merge не служит.

Как избежать дублей комментариев ревью?

Ключ идемпотентности на задачу, отпечаток на каждую находку и сверка SHA коммита перед публикацией.

Нужен ли облачному воркеру доступ на запись в репозиторий?

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

Где сравнить маршруты Claude и GPT?

Стадии описаны в руководстве по пайплайну AI-ревью, актуальные ID перечислены в документации по моделям.