Когда использовать
Когда нужно наполнить БД/тесты/демо реалистичными данными, а руками долго: сид для разработки, фикстуры под тесты, данные для демо. Роль — инженер данных. Ключ — даёте схему/типы, и модель генерит ТОЛЬКО под неё, включая края и «грязные» записи. Результат: валидные синтетические данные в нужном формате + набор намеренно проблемных кейсов.
Промт (бери и вставляй)
Ты — инженер данных. Сгенерируй РЕАЛИСТИЧНЫЕ синтетические тестовые данные строго по схеме ниже. Никаких реальных персональных данных — только выдуманные.
СХЕМА / ПОЛЯ И ТИПЫ: «<ВСТАВЬ: таблицы и колонки, или TS-интерфейс, или описание полей с ограничениями>».
ФОРМАТ ВЫВОДА: <JSON-массив / SQL INSERT / CSV>. СКОЛЬКО ЗАПИСЕЙ: <N>. ЛОКАЛЬ/ЯЗЫК ДАННЫХ: <напр. русские имена и адреса>.
ОСОБЫЕ ПРАВИЛА: «<связи между полями, диапазоны, уникальность, бизнес-логика — напр. дата окончания > даты начала>».
Требования:
1. Соблюдай типы, ограничения и связи из схемы (внешние ключи, уникальные поля, форматы email/телефон/дат).
2. Данные должны быть ПРАВДОПОДОБНЫМИ и разнообразными (разные имена, города, значения), а не «test1/test2».
3. Включи КРАЕВЫЕ случаи: пустые/максимальной длины строки, граничные числа (0, минимум, максимум), даты на границах, спецсимволы и юникод, NULL там, где поле необязательно.
4. Добавь несколько НАМЕРЕННО «грязных»/невалидных записей ОТДЕЛЬНЫМ блоком (для негативных тестов) — и подпиши, чем каждая плоха.
5. Если в схеме есть связи (например заказы ссылаются на пользователей) — сохрани целостность ссылок.
Выдай: 1) валидные данные в указанном формате; 2) отдельно блок «невалидные/краевые для негативных тестов» с пометкой проблемы у каждой; 3) одну строку — как этим воспользоваться (импорт/сид).
Пример заполнения
Схема: users(id, email UNIQUE, name, age INT, city, created_at) и orders(id, user_id FK, amount NUMERIC, status, created_at). Формат: SQL INSERT. Записей: 10 пользователей и 20 заказов. Локаль: русские имена/города. Правило: amount > 0, status из ('new','paid','cancelled').
Ожидаемый ответ ИИ: INSERT-ы с правдоподобными данными (разные ФИО, города — Москва, Казань, Новосибирск; валидные email; возраст в разумном диапазоне), заказы ссылаются на существующие user_id, status только из списка, amount положительный, даты заказов ≥ дат регистрации; отдельный блок «невалидные для негатив-тестов» — запись с age=−1, пустым name, дублирующимся email, amount=0, статусом не из списка, каждая подписана «чем плоха»; в конце — «импортируй: psql -f seed.sql».
Вариации
- Под фреймворк. «Дай не данные, а код-фабрику (Faker/factory_boy/Prisma seed), которая их генерит» — для повторяемости.
- Большой объём. «Сгенерируй скрипт, который создаёт 100 000 записей» (саму массовую генерацию лучше кодом, а не построчно в ответе).
- Связанный граф. «Сделай согласованный набор по нескольким таблицам с реалистичным распределением (80% заказов у 20% юзеров)».
Про-советы
- Схема — обязательна и точна: без типов и ограничений ИИ выдумает поля, и импорт упадёт. Скопируйте
CREATE TABLE, интерфейс или чёткое описание с ограничениями. - Главная ценность — краевые и «грязные» записи: именно на них падает прод. Всегда просите отдельный блок невалидных данных для негативных тестов, а не только «красивые» строки.
- НИКОГДА не генерьте «тестовые» данные на основе реальных людей и не подмешивайте реальные ПД — это синтетика по определению (иначе это уже 152-ФЗ). Для огромных объёмов берите код-фабрику с фиксированным seed, чтобы данные были воспроизводимы между прогонами.