Начните с состояния базы
Предположим, заказ получает новый статус. Снимите схему таблицы, индексы, внешние ключи и пример старых записей без персональных данных. Узнайте версию СУБД и размер таблицы: операция, быстрая на тысяче строк, может надолго заблокировать миллионы. Зафиксируйте, кто пишет в таблицу и какие отчёты читают старое поле. Модели передавайте обезличенную схему, а не дамп продакшена. Попросите отдельно назвать неизвестные сведения, от которых зависит безопасность изменения.
Пусть ИИ предложит варианты, а не одну команду
Запросите минимум два маршрута: добавление nullable-поля с последующим заполнением и переходом к ограничению либо отдельное поле с постепенным переключением приложения. Для каждого маршрута нужны шаги, предпосылки, риск блокировки и способ остановиться. Если новая версия кода и старая некоторое время работают вместе, проверьте совместимость записи и чтения. Нельзя принимать ответ «просто добавьте NOT NULL», пока не ясно, как поступить со старыми заказами. Похожая дисциплина нужна при проверке диапазонов отчёта: красивый итог не заменяет исходные данные.
Репетиция на отдельной копии
В тестовой среде используйте сопоставимый объём и распределение данных, а не пустую таблицу. Сначала проверьте резервную копию и возможность восстановления. Выполните миграцию, измерьте время и посмотрите план запросов после создания индекса. Затем проверьте число строк, долю пустых статусов, несколько краевых случаев и основные пользовательские операции. Если нужен откат, различайте отмену кода и отмену изменения данных: удаление нового столбца может уничтожить уже записанную информацию.
Протокол запуска и ответы
Запишите исполнителя, время окна, контрольные запросы до и после, порог остановки и контакт ответственного за базу. При несоответствии количества записей дальнейшие команды не запускают. Можно ли попросить ИИ выполнить миграцию самому? Нет: доступ к рабочей базе и подтверждение каждого шага остаются у команды. Достаточно ли успешной сборки приложения? Нет: она не проверяет реальные блокировки и старые данные. Для проверки объяснений модели полезен разбор ревью кода и зависимостей.
Короткая проверка
- Понятны цель и человек, который примет результат.
- Исходники очищены, их версия и дата сохранены.
- Факты, числа и ограничения сверены вручную.
- Неудачный пример записан вместе с причиной.
- Есть измеримый следующий шаг и путь назад.