Второй ИИ-помощник полезен, если получает самостоятельную задачу проверки. Когда ему передают рассказ автора о том, почему всё правильно, он рискует лишь подтвердить ту же картину. Настоящая дополнительная проверка начинается с поведения пользователя, исходной версии и конкретного изменения.
Ниже предлагаю процесс, в котором Claude Code выполняет ограниченную правку, а Codex рассматривает её как проверяющий. Роли можно поменять. Ценность подхода определяется независимостью вопросов и качеством подтверждений, а не сочетанием названий продуктов. Для небольшого изменения достаточно короткого прохода без сложной организации команды.
В этой статье
- 1. Сформулируйте критерий до изменения кода
- 2. Дайте автору ограниченную область работы
- 3. Подготовьте независимый пакет для проверяющего
- 4. Используйте интеграцию Codex с GitHub, если она подходит
- 5. Требуйте воспроизводимый дефект
- 6. Проверьте исправления и пользовательский результат
- 7. Оформите результат для следующего человека
- Реальные проекты
- Источники
1. Сформулируйте критерий до изменения кода
Запишите, что делает пользователь, что происходит сейчас и что должно происходить после исправления. Для сайта это может быть карточка, которая на узком экране выходит за границы, или форма, теряющая введённое значение после ошибки.
Сохраните исходный снимок или данные для воспроизведения. Укажите соседние возможности, которые должны продолжить работать. Избегайте запроса «проверь весь проект» для локальной правки: он размывает внимание и создаёт поток замечаний, не связанных с задачей. Конкретный критерий позволяет проверить результат даже человеку, который не участвовал в обсуждении реализации.
2. Дайте автору ограниченную область работы
Claude Code поддерживает работу с файлами проекта и выполнение команд. Для этой роли ему нужны инструкция запуска, критерий результата и понятная исходная версия.
Перед началом сохраните существующие изменения и не смешивайте новую задачу с чужой незавершённой работой. Попросите сначала воспроизвести дефект, затем выбрать минимальную область исправления. В конце автор должен показать, что изменил и чем проверил. Не просите искусственно минимальное число строк: иногда правильное решение требует небольшого структурного изменения. Ограничивать нужно область задачи и побочные последствия.
Первоисточники: Claude Code overview ↗
3. Подготовьте независимый пакет для проверяющего
Передайте Codex исходное требование, базовую версию, текущий diff и команды проверок. Не делайте авторское объяснение единственным источником понимания. Проверяющему полезно самому прочитать соседний код и пройти пользовательский сценарий.
Зафиксируйте commit или другой однозначный идентификатор версии. Если автор продолжает менять файлы во время проверки, выводы могут относиться к уже исчезнувшему состоянию. Удобнее завершить небольшой набор правок, проверить его и лишь затем принимать дополнительные изменения. Такой порядок снижает число споров о том, какую именно ошибку кто видел.
4. Используйте интеграцию Codex с GitHub, если она подходит
Официальная интеграция позволяет запрашивать проверку pull request комментарием @codex review после настройки доступа к репозиторию. Она учитывает применимые инструкции AGENTS.md. Документация отдельно отмечает, что такая проверка не заменяет тесты и обязательные правила приёмки.
Если вы работаете локально, тот же принцип можно реализовать отдельной задачей проверки с доступом к нужной копии проекта. Важно, чтобы проверяющий видел конкретные файлы и версию, а не только вставленный в чат фрагмент. Перед применением инструкции GitHub проверьте, что интеграция доступна вашей организации и настроена для выбранного репозитория.
Первоисточники: Codex GitHub integration ↗
5. Требуйте воспроизводимый дефект
Хорошее замечание связывает условие, участок изменения и пользовательское последствие. Например: при пустом ответе API карточка обращается к отсутствующему полю, поэтому список не открывается. Проверяющий должен показать вход, на котором это происходит, либо объяснить точную цепочку в коде.
Замечания о вкусе оформления и реальные дефекты лучше различать. Это не означает, что читаемость кода не важна; просто исправление ошибки не должно зависеть от бесконечного согласования личных предпочтений. Если доказательств недостаточно, отметьте вопрос для проверки, а не называйте предположение подтверждённой поломкой.
Проверь изменение относительно указанной базовой версии. Ищи нарушения требования и воспроизводимые регрессии. Для каждого замечания дай условие, место в коде, последствия и способ проверки. Отдельно перечисли непроверенные области. Не меняй файлы во время этого прохода.
6. Проверьте исправления и пользовательский результат
После замечаний автор исправляет подтверждённые проблемы. Затем повторяются затронутые проверки и исходный пользовательский сценарий. Если после проверки появился новый код, он должен попасть в следующий проход в необходимом объёме.
Для интерфейса откройте реальную страницу на узком и широком экранах. Для интеграции проверьте ответ сервиса и сохранённую запись. Для преобразования данных сравните значения и идентификаторы. Скриншот, успешный тест и серверная запись отвечают на разные вопросы; выбирайте доказательство по типу изменения.
Сравнение по задаче · на телефоне таблицу можно листать
| Изменение | Основная проверка | Дополнительный крайний случай |
|---|---|---|
| Вёрстка карточки | Реальный экран и взаимодействие | Длинное название и отсутствующее фото |
| Форма | Ввод, отправка и ответ | Ошибка сервера и повтор |
| Каталог | Правильная карточка и ссылка | Пустой список и неизвестный товар |
| Обработка данных | Значения и идентификаторы | Пропущенное обязательное поле |
7. Оформите результат для следующего человека
Итоговый отчёт должен отвечать на четыре вопроса: что изменилось, какая версия проверена, какие сценарии прошли и что осталось неизвестным. Успешная проверка локальной версии ещё не доказывает, что именно она опубликована. После выпуска нужен короткий проход по работающему адресу.
В кейсе сайта Сергея Галана значимы представление эксперта, ссылки и обращение посетителя. Здесь проверка должна доходить до реального перехода. В демонстрационных mini apps ШУМ и SHEDEUX важно соответствие карточки исходному товару и переходу в магазин. Эти примеры помогают выбрать сценарии приёмки; они не утверждают, что проекты проверялись именно парой Claude Code и Codex.
Перейдите от инструмента к проекту.
Сергей Галан: сайт эксперта ↗Проверка реального пути от страницы к обращению
ШУМ и SHEDEUX: демонстрационные каталоги ↗Проверка товара и перехода к исходному магазинуОтделите исполнение от проверки, привяжите замечания к конкретной версии и завершите работу пользовательским сценарием. Второй помощник приносит пользу, когда помогает найти подтверждённую проблему или обозначить предел проверки. Согласие двух моделей само по себе не является приёмкой.
Настроим понятную проверку изменений
Выберем одну функцию вашего сайта или приложения и соберём процесс: задача, изменение, независимая проверка и подтверждение на работающей версии.
Источники и дата проверки
Проверено 15 октября 2026 года. Доступность функций зависит от продукта, аккаунта и региона; приведённые примеры запросов — рабочие заготовки для вашей проверки.
- Claude Code overview ↗Работа с проектом, файлами и командами
- Codex GitHub integration ↗Запрос @codex review, применимые AGENTS.md и границы проверки
