Как проверить 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, список файлов, результаты тестов, инструкции репозитория, схему данных, журнал команд, сведения о новых зависимостях и ожидаемый пользовательский сценарий в том же формате и качестве, что используются в работе, включая неудобные пограничные случаи.
Пройти маршрут целиком
Выполните сопоставление файлов с планом, чтение содержательных блоков, проверку входов и выходов, поиск случайных изменений, запуск целевых тестов, негативный сценарий, анализ сгенерированных файлов и итоговую ручную приемку от начала до конечного файла. Не останавливайтесь на удачном превью: запишите экспорт, открытие, редактирование, согласование и повторное использование. Ручные обходные действия считаются частью стоимости процесса.
Проверить глазами получателя
Оцените правильность алгоритма, обработку пустых и ошибочных данных, типы, доступы, секреты, миграции, совместимость, зависимости, локализацию, производительность, SEO при необходимости, тестовое покрытие и чистоту истории в конечной среде, а не только в редакторе. Попросите получателя назвать непонятные места и воспроизвести одно ключевое действие. Ошибка передачи важнее визуально аккуратного черновика.
Оформить воспроизводимую поставку
Передайте протокол ревью, список замечаний с приоритетом, результаты повторных команд, принятые допущения, подтверждение пользовательского сценария и решение о готовности, инструкции по открытию и список контрольных точек. Добавьте исходники, права, версии и контакт ответственного за исправления.
Критерии, которые нужно записать до начала
Ошибка, из-за которой результат выглядит надежнее, чем есть
Ревьюер смотрит только красные и зеленые строки и пропускает удаленное ограничение, изменение конфигурации или новый публичный интерфейс. Другой риск - доверять описанию агента без запуска команд. Восстановите намерение по задаче и проверьте доказательства.
Что передать следующему участнику
Автор получает конкретные замечания с файлами, ожидаемым поведением и способом повторной проверки. После исправления ревьюер повторяет рискованные сценарии и сохраняет финальные результаты рядом с решением.
Коротко
Надежное ревью начинается не с поиска красивого кода, а с границ задачи и изменений высокого риска. Полный diff, подходящие тесты и понятный откат важнее уверенного отчета агента.