Как принять правку AI-агента по изменённому сценарию
Как принять изменение AI-агента: связать запрос, список файлов, доказательство исправления и соседние сценарии, которые могла затронуть правка.
Запрос «поправить кнопку» может закончиться изменением формы, стилей, обработчика и маршрута заявки. Приёмка начинается с ответа, какие действия посетителя затронуты. Количество исправленных файлов само по себе не показывает ни качество, ни опасность изменения.
В работе с AI-лендингом я бы связывал каждую правку с одним исходным сценарием. Например: Enter в поле отправлял форму дважды. Признак готовности — одна логическая заявка при предусмотренных способах отправки, а не просто исчезновение ошибки компиляции.
Постановка, которую можно проверить
Укажите URL, исходные условия, шаги, фактический и ожидаемый результат. Если речь о визуале, добавьте ширину экрана и конкретное несоответствие. Если о данных, назовите конечную систему и разрешённый способ теста. Формулировка «сделай профессиональнее» не задаёт границу приёмки.
В документации Claude Code проверяемая обратная связь — тест, сборка, сравнение изображения — предлагается как рабочий инструмент агента. Выбирайте проверку под проблему. Для кнопки отправки обычно нужно больше одного вида доказательства.
| Доказательство | Что подтверждает | Что остаётся отдельно |
|---|---|---|
| Просмотр изменений | Какая логика и файлы изменены | Фактическая работа версии |
| Типизация и сборка | Совместимость в пределах проверок инструмента | Удобство и внешняя доставка |
| Браузерный сценарий | Поведение интерфейса на проверенном адресе | Другие устройства и непроверенные состояния |
| Запись у получателя | Конечная доставка конкретного теста | Стабильность для всех будущих обращений |
Смотрите на последствия изменения
Попросите агента перечислить изменённые файлы и объяснить их связь с задачей. Если для исправления отступа сменился получатель заявок, это требует отдельного объяснения. Чужие незавершённые изменения должны сохраниться; агенту нельзя молча возвращать проект к удобной для него исходной версии.
GitHub описывает review как обсуждение и оценку предлагаемых изменений. Даже без Git-процесса полезен тот же предметный подход: сравнить до и после, задать вопрос о конкретной строке и понять пользовательское последствие. Общая оценка «код хороший» плохо помогает принять исправление.
Определите ближайшие соседние сценарии
Если менялась отправка, проверьте клик, Enter, ожидание ответа, неверный ввод и повтор после ошибки. Если менялись общие стили таблиц, посмотрите широкую таблицу на телефоне. Если изменён базовый layout, одной страницей уже нельзя подтвердить отсутствие регрессии в остальных типах материалов.
Не превращайте каждую правку в повтор всего тестирования сайта. Выберите проверки по зависимостям и последствиям. Изменение подписи не требует заново отправлять десятки заявок. А изменение общего обработчика нельзя принять по одному скриншоту. Для повторной отправки есть отдельный диагностический сценарий.
Отчёт, который переживёт следующую правку
Зафиксируйте версию, проверенный URL, исходную проблему, изменение и фактический результат. Добавьте существенные ограничения: например, подтверждён браузерный успех, а доставка в CRM ещё не проверена. Такая граница помогает принять решение; фраза «всё готово» её прячет.
Если после проверки меняется код, прежний результат относится к прежней версии. Повторите затронутую часть. Для общего выпуска используйте проверку перед запуском, а перед переключением подготовьте возврат прошлой версии. Приёмка завершена, когда исправленное действие воспроизводится на том адресе, которым будет пользоваться посетитель.