Салют! На днях писала пост про то,
как ИИ повлиял на нашу работу. Сегодня привожу пример с моей рабочей жизни)
Пример: Интеграция с внешним API поставщикаБыл проект по автоматизации закупок. Нужно было интегрироваться с API крупного поставщика, у которого документация была… как бы помягче… «исторической». Swagger-спеки не было, был PDF на 200 страниц, где описание полей шло вперемешку с юридическими оговорками и примерами на устаревшем XML.
Задача: спроектировать систему обмена данными (заказы, статусы, отгрузки), описать маппинги полей и написать ТЗ для разработки адаптера.
👩💻
Как я использовала ИИ1. Структурирование «мусора»Я скормила ИИ (через API, с соблюдением всех NDA и анонимизацией данных) выдержки из PDF — только описания методов и схемы объектов.
Промпт был такой:
У меня есть описание REST API (фрагменты). Документация неструктурированная. Выдели все эндпоинты, методы, обязательные и опциональные параметры. Приведи в виде таблицы: эндпоинт, метод, описание, входные параметры (с типами), выходные параметры. Если есть зависимости между вызовами — отметь. Не додумывай, только то, что явно написано
ИИ вытащил структуру за 15 мин, которую я вручную собирала бы 2–3 дня. Да, были неточности — нейросеть иногда путала description поля с примером значения. Но база была готова.
2. Генерация маппинговДальше нужно было сопоставить поля поставщика с нашей внутренней моделью данных.
Я подготовила таблицу с нашей схемой (поля, типы, ограничения) и дала задание:
Вот поля поставщика (колонка A), вот наши поля (колонка B). Предложи маппинг. Где нет прямого соответствия — отметь как “требует преобразования” и предложи вариант логики. Где данных не хватает — отметь как “требует уточнения у бизнеса”
ИИ выдал черновик маппинга с 40+ полями. Из них около 30 я приняла без изменений, в 7 добавила свои правки, а 3 действительно пошли на уточнение к заказчику (и оказалось, что эти поля реально не используются — я бы сама копалась полдня).
3. Написание ТЗ для разработчиковСамый приятный момент. У меня была готова структура: эндпоинты, маппинги, бизнес-сценарии. Нужно было превратить это в ТЗ, которое не вызовет у разработчиков 100500 уточняющих вопросов.
Я использовала ИИ так:
У меня есть описание интеграции. Напиши раздел ТЗ “Логика обработки ошибок” для следующих сценариев: таймаут, 4xx, 5xx, невалидный JSON. Для каждого укажи: что логируем, нужен ли ретрай (с какой задержкой), переходим ли в ручной режим. Стиль — технически точный, без воды
ИИ сгенерировал матрицу обработки ошибок, которую я только немного адаптировала под наши корпоративные стандарты (у нас своя политика ретраев с экспоненциальной задержкой).
Аналогично я накидала:
- описание аутентификации
- примеры запросов/ответов (которые ИИ сгенерировал на основе структуры полей)
- чек-лист для приемки интеграции (разработчик сказал потом: «О, тут даже кейс с пустым массивом учтен — спасибо, я б забыл»)
4. Валидация (ключевой момент!)И вот тут — самое важное. Я не просто скопировала результат.
Когда ИИ сгенерировал маппинг, я заметила странность: поле delivery_address.line2 он замаппил на наше address_extra, а поле delivery_address.full — на наше address_full. Но в документации поставщика было написано, что line2 используется только если full не заполнен. Это бизнес-логика, которую нейросеть упустила (или она была на другой странице PDF, которую я не скормила).
Я докрутила: добавила условие «если full не пуст — берем его, иначе формируем из line1 + line2».
‼️ Без моей экспертизы это уехало бы в разработку, а потом — баг на тестировании и лишняя итерация.
Что по итогу Итого: вместо 4–5 рабочих дней я уложилась в 1,5 дня. При этом качество выросло — потому что время освободилось на сложную логику и валидацию, а не на перепечатывание полей из PDF в Excel.
‼️В комментариях оставила небольшой вывод👇
Источник:
@ba_and_sa💙
BA|SA | 💬
BA|SA
AN 
