Как проверить diff после работы ИИ-агента
Отчет агента показывает его интерпретацию работы, но источником истины остается diff. Проверка должна идти от границ задачи к рискам: сначала лишние файлы и секреты, затем контракты и логика, после этого тесты и возможность отката.
Что учесть до начала работы
Просмотр diff не подтверждает корректность поведения без тестов и проверки требований.
Не публикуйте секреты и внутренний код во внешнем чате для дополнительного ревью.
Что подготовить
Что делать
Сверьте границы изменения
Начните со списка измененных, новых и удаленных файлов. Для каждого файла свяжите правку с требованием задачи. Отдельно отметьте форматирование, переименование и рефакторинг, которых не просили.
Результат: В diff нет необъяснимых файлов и скрытого расширения задачи.Проверьте секреты и конфигурацию
Ищите токены, пароли, личные адреса, отладочные флаги и изменения production-настроек. Убедитесь, что пример окружения не содержит реального значения.
Результат: Изменение не публикует секреты и не ослабляет рабочую конфигурацию.Просмотрите контракты
Сопоставьте типы, публичные API, схему данных, миграции и форматы событий с существующими потребителями. Проверьте обратную совместимость и порядок развертывания.
Результат: Потребители и данные не ломаются незаметно для локального теста.Пройдите логику по веткам
Проверьте обычный путь, пустой ввод, ошибку внешней системы, повторный вызов и границы коллекций. Ищите проглоченные исключения, бесконечные повторы и неверные значения по умолчанию.
Результат: Для важных веток понятно ожидаемое поведение и обработка ошибки.Сопоставьте тесты с рисками
Убедитесь, что тесты проверяют новое поведение, а не только строки реализации. Запустите принятые команды lint, typecheck, тестов и сборки в доверенном окружении и сохраните результат.
Результат: Проверки покрывают заявленные критерии и действительно выполнены.Подготовьте объединение и откат
Разделите независимые изменения, уберите временные файлы и зафиксируйте ограничения. Для миграции, флага или инфраструктуры запишите безопасный порядок включения и способ возврата.
Результат: Изменение можно объяснить, объединить и при необходимости отменить.Промпт для структурированного ревью diff
Проведи ревью вставленного diff относительно задачи. Не утверждай, что запускал команды или видел файлы вне diff. Не переписывай код сразу. Задача и критерии приемки: [текст]. Не должно меняться: [границы]. Команды проверки проекта: [команды]. Diff: --- [вставьте diff без секретов] --- Верни: 1) краткое соответствие задаче, 2) лишние или необъяснимые изменения, 3) риски секретов и конфигурации, 4) изменения API, типов, схемы и совместимости, 5) ошибки логики по веткам, 6) недостающие тесты, 7) команды, которые человеку нужно запустить, 8) вопросы перед объединением. Для каждого замечания укажи файл и фрагмент из diff. Если данных недостаточно, скажи, какой файл или контракт нужно открыть, и не додумывай его содержимое.
Проверка перед объединением
Что чаще всего портит результат
Читать только отчет агента
Сначала откройте полный список файлов и diff, затем сопоставьте его с отчетом.
Считать зеленый тест достаточным
Проверьте, что тест действительно охватывает новое поведение и риск регрессии.
Пропускать удаленные строки
Отдельно просмотрите удаления: агент мог убрать проверку, логирование или обработку ошибки.
Короткие ответы
Чем этот процесс отличается от проверки кода перед первым запуском?
Здесь проверяется конкретный diff в знакомом проекте. Перед первым запуском неизвестного репозитория дополнительно нужны аудит зависимостей, изоляция и временные учетные данные.
Можно ли просить другой ИИ проверить diff?
Можно использовать его для второго списка замечаний, но не передавайте закрытый код внешнему сервису без разрешения и подтверждайте выводы самостоятельно.
Проверка diff по намерению, риску и доказательствам
Ревью начинается с формулировки ожидаемого поведения и списка затронутых поверхностей. Затем diff читают от конфигурации и данных к потребителям, отделяя содержательные изменения от механических. Незнакомый файл, изменение зависимости или сгенерированный артефакт требует объяснения, даже если тесты зеленые.
Ограничения: Проверка diff по намерению, риску и доказательствам
Прохождение тестов не доказывает отсутствие логической ошибки, а большой diff снижает качество ручной проверки. Неизвестную предметную область передают профильному владельцу. Сгенерированный код оценивают через источник и воспроизводимость.
Маршрут: Проверка diff по намерению, риску и доказательствам
Смоделировать реальную приемку
Сначала определите, кто будет принимать протокол ревью, список замечаний с приоритетом, результаты повторных команд, принятые допущения, подтверждение пользовательского сценария и решение о готовности и в какой программе или канале он его увидит. Подготовьте исходную задачу, чистый diff, список файлов, результаты тестов, инструкции репозитория, схему данных, журнал команд, сведения о новых зависимостях и ожидаемый пользовательский сценарий в том же формате и качестве, что используются в работе, включая неудобные пограничные случаи.
Пройти маршрут целиком
Выполните сопоставление файлов с планом, чтение содержательных блоков, проверку входов и выходов, поиск случайных изменений, запуск целевых тестов, негативный сценарий, анализ сгенерированных файлов и итоговую ручную приемку от начала до конечного файла. Не останавливайтесь на удачном превью: запишите экспорт, открытие, редактирование, согласование и повторное использование. Ручные обходные действия считаются частью стоимости процесса.
Проверить глазами получателя
Оцените правильность алгоритма, обработку пустых и ошибочных данных, типы, доступы, секреты, миграции, совместимость, зависимости, локализацию, производительность, SEO при необходимости, тестовое покрытие и чистоту истории в конечной среде, а не только в редакторе. Попросите получателя назвать непонятные места и воспроизвести одно ключевое действие. Ошибка передачи важнее визуально аккуратного черновика.
Оформить воспроизводимую поставку
Передайте протокол ревью, список замечаний с приоритетом, результаты повторных команд, принятые допущения, подтверждение пользовательского сценария и решение о готовности, инструкции по открытию и список контрольных точек. Добавьте исходники, права, версии и контакт ответственного за исправления.
Критерии: Проверка diff по намерению, риску и доказательствам
Риск ошибки: Проверка diff по намерению, риску и доказательствам
Ревьюер смотрит только красные и зеленые строки и пропускает удаленное ограничение, изменение конфигурации или новый публичный интерфейс. Другой риск - доверять описанию агента без запуска команд. Восстановите намерение по задаче и проверьте доказательства.
Передача результата: Проверка diff по намерению, риску и доказательствам
Автор получает конкретные замечания с файлами, ожидаемым поведением и способом повторной проверки. После исправления ревьюер повторяет рискованные сценарии и сохраняет финальные результаты рядом с решением.
Коротко
Надежное ревью начинается не с поиска красивого кода, а с границ задачи и изменений высокого риска. Полный diff, подходящие тесты и понятный откат важнее уверенного отчета агента.