Не так давно в нашем блоге была статья о том, какискусственный интеллект помогает разбирать логи 1C. В этой — поговорим о задачах архитекторов ПО. LLM и диффузионные модели уже способны генерировать варианты архитектур, оценивать компромиссы и предлагать решения быстрее, чем это возможно вручную. Пора разобраться, насколько глубоко ИИ может встроиться в рабочие процессы архитектора ПО — и стоит ли ему там оставаться.
Привет, Хабр! Меня зовут Александр Брейман, я доцент департамента программной инженерии факультета компьютерных наук НИУ ВШЭ и по совместительству старший преподаватель Учебного центра IBS. В этой статье расскажу про большие языковые модели в приложении к работе архитектора ПО. Вместе мы посмотрим, насколько хорошо GPT понимает ИТ-архитектуру и сможет ли уже сегодня заменить архитектора.
Какую модель выбрать?
Большие языковые модели делятся на коммерческие (OpenAI, Anthropic, Google и другие) и открытые (DeepSeek, Qwen, LLaMA, Mistral и другие) модели.
Плюсы коммерческих моделей очевидны:
- высокая производительность из «коробки» (особенно на сложных задачах);
- простота доступа (API, веб-интерфейсы);
- большое окно контекста;
- нахождение на пике технологий (мультимодальность и прочее);
- меньшие затраты на инфраструктуру, если использовать облачные API.
С открытыми моделями тоже все понятно — они бесплатны и, что немаловажно, доступны в России без VPN. В числе минусов открытых моделей обычно называют кражу данных, но, я думаю, мы все понимаем, что ChatGPT точно так же обучается на всех загруженных промптах, как и DeepSeek.
Я тестировал большинство современных моделей и сейчас, как правило, пользуюсь открытыми LLM. Больше всего радуют Qwen от Alibaba (не зря на нее перешел YandexGPT) и DeepSeek. Для проработки корпоративной архитектуры и для кодирования еще очень хорошо подходит свежая версия гугловского Gemini 2.5, а вот новая LLaMA 4, на мой взгляд, особого внимания не заслуживает. Под программирование сильно заточен Claude Sonnet, а с текстовыми документами лучше работает Claude Opus.
Критерии выбора LLM для рабочих проектов
- Конфиденциальность:если нужен контроль за чувствительными данными — а в корпоративных проектах это обычно главный вопрос, то выбор один — открытая модель на локальном сервере.
- Бюджет:за API придется заплатить, но его проще начать, тогда как опенсорс потребует самостоятельной интеграции и инвестиций в инфраструктуру, но может быть дешевле в масштабе.
- Эффективность:для сложнейших задач лучше выбирать коммерческие модели, но на практике с большинством вопросов справляются и открытые решения с минимальной донастройкой.
- Кастомизация:если требуется дообучение на своих данных, то выбираем открытые модели. При этом важно иметь в команде соответствующую экспертизу для поддержки.
В целом выбор зависит от задачи, требований к безопасности и ресурсов. Часто оптимальна гибридная стратегия.
LLM как инструмент архитектора
Работу современного архитектора ПО можно разбить на шесть групп задач:
- Анализ требований и выявление противоречий в спецификациях.
- Проектирование и оценка архитектурных решений.
- Создание и обновление технической документации.
- Разработка API-спецификаций и контрактов.
- Оценка технического долга и рефакторинг.
- Генерация диаграмм и схем архитектуры.
Чтобы понять, как LLM справляются с работой архитектора, я сформулировал конкретные промпты и оценил ответы нейросети по каждой из этих задач. Дабы не раздувать статью до слишком больших размеров, приложил не все ответы, а лишь некоторые.
Задача 1. Анализ требований
Архитектор ПО работает с огромным количеством документации — ТЗ, пользовательские истории, спецификации — требования могут быть разбросаны по разным документам или разделам. Ручной анализ десятков, а то и сотен страниц текста — это трудоемкий процесс, требующий значительного времени. Противоречия — например, между функциональными и нефункциональными требованиями — не всегда очевидны с первого взгляда, естественный язык допускает разные трактовки и может приводить к неоднозначной интерпретации, а у человека при этом может элементарно «замылиться» взгляд.
Как с этой задачей поможет нейросеть? Мы можем использовать LLM для первичного анализа текстовых требований и быстрой идентификации потенциальных проблем и скрытых конфликтов в документации.
Что можно спросить у LLM:
- Найти неясные или двусмысленные формулировки:«Какие фразы могут быть истолкованы по-разному?»
- Выявить прямые противоречия:«Есть ли требования, которые конфликтуют друг с другом?»
- Обнаружить недостающую информацию:«Чего не хватает для полного понимания этого требования?»
- Сгруппировать связанные требования:«Собери все требования, относящиеся к модулю аутентификации».
- Задать уточняющие вопросы:«Какие вопросы стоит задать заказчику по этому пункту?»
Анализ требований — запрос 1
Проанализируй следующие требования из спецификации на систему управления заказами. Найди возможные противоречия или неясности:Система должна позволять Менеджеру изменять статус заказа на «Отменен» в любое время до момента его передачи в службу доставки.После того как Пользователь оплатил заказ, статус заказа автоматически меняется на «Оплачен» и не может быть изменен Менеджером вручную для предотвращения мошенничества.Менеджер должен иметь возможность отменить любой заказ по запросу клиента, даже если он уже оплачен, но еще не отправлен.
Анализ требований — ответ нейросети 1
Обнаружены потенциальные противоречия и неясности:Прямое противоречие (Требования 2 и 3)Требование 2 запрещает Менеджеру изменять статус после оплаты, а Требование 3 разрешает Менеджеру отменять оплаченный (но не отправленный) заказ. Необходимо уточнить, какой процесс имеет приоритет или как обрабатывается отмена оплаченного заказа (возврат средств, изменение статуса и т. д.).Неясность (Требование 1 и 3)Требование 1 ограничивает отмену моментом передачи в доставку. Требование 3 также упоминает «еще не отправлен». Являются ли «передача в службу доставки» и «отправлен» синонимами в данном контексте? Нужно единое определение.Потенциальный конфликт (Требование 1 и 2)Если оплата происходит до передачи в доставку, то Требование 2 (автоматическая блокировка изменения статуса после оплаты) может конфликтовать с Требованием 1 (возможность отмены до передачи в доставку). Нужно определить последовательность и условия изменения статусов.
Понятно, что при наличии всего трех требований эти противоречия мы могли бы легко найти и своими глазами, но вот когда их сотня, то помощь ИИ уже кажется по-настоящему ценной. С этой задачей нейросеть справилась на ура.
Анализ требований — запрос 2
Проанализируй следующее нефункциональное требование (NFR) для новой системы отчетности. Укажи на неясности, недостающую информацию и предложи вопросы, которые помогут сделать это требование измеримым и тестируемым:NFR-05. Система должна обеспечивать быстрый доступ к генерируемым отчетам.
Анализ требований — ответ нейросети 2
Анализ требования «NFR-05. Система должна обеспечивать быстрый доступ к генерируемым отчетам» выявил следующие неясности и недостающую информацию:Неопределенность термина «быстрый»«Быстрый» является субъективным понятием. Для одного пользователя это 1 секунда, для другого — 10 секунд.Вопрос: Какое максимальное время от запроса отчета до его отображения пользователю считается приемлемым (в секундах или миллисекундах)?Отсутствие контекста нагрузкиПроизводительность системы может сильно зависеть от количества одновременных пользователей или сложности отчета.Вопросы: При какой нагрузке (например, количество одновременных пользователей, объем данных в отчете) должно выполняться требование по времени отклика? Это требование для среднего времени отклика или для 95-го перцентиля?Неясность определения «доступ к отчетам»Что именно включает в себя «доступ»? Только генерацию? Или генерацию + загрузку? Или открытие уже сгенерированного отчета?Вопросы: Какая конкретно операция должна быть «быстрой»? Генерация нового отчета? Открытие существующего? Экспорт отчета?Отсутствие критериев измеримостиТекущая формулировка не позволяет объективно проверить выполнение требования.Вопрос: Как будет измеряться и проверяться выполнение этого требования? Какие инструменты будут использоваться?
Нейросеть мгновенно нашла пробелы в требованиях и сформулировала готовые наводящие вопросы, избавив нас от рутины.
Анализ требований — запрос 3
Проанализируй следующую User Story на предмет полноты. Какие потенциальные вопросы возникают? Какие ключевые Acceptance Criteria (AC) могут быть пропущены?Как зарегистрированный пользователь я хочу иметь возможность загружать аватар в свой профиль, чтобы другие пользователи могли меня узнать.
Анализ требований — ответ нейросети 3
Анализ данной User Story выявил потенциальные вопросы и недостающие Acceptance Criteria (AC):Возникающие вопросы:Форматы файлов: Какие форматы изображений для аватара поддерживаются (JPEG, PNG, GIF)?Размер файла: Есть ли ограничение на максимальный размер загружаемого файла (в МБ)?Размеры изображения: Есть ли ограничения на минимальные/максимальные размеры изображения (в пикселях)? Что происходит, если изображение слишком большое/маленькое?Обрезка/Редактирование: Предоставляется ли пользователю инструмент для кадрирования (обрезки) аватара после загрузки?Замена аватара: Что происходит при загрузке нового аватара? Старый удаляется? Хранится история?Удаление аватара: Может ли пользователь удалить аватар, оставив изображение по умолчанию? Что является изображением по умолчанию?Ошибки: Как система информирует пользователя об ошибках (неверный формат, превышен размер и т.д.)?Место отображения: Где именно будет отображаться этот аватар (в профиле, в комментариях, в списке пользователей)?Потенциально пропущенные Acceptance Criteria (AC):AC1: Пользователь может выбрать файл изображения со своего устройства через стандартный диалог выбора файла.AC2: Система проверяет формат файла (принимает только .jpg, .png).AC3: Система проверяет размер файла (не более 5 МБ).AC4: [Если есть кадрирование] Пользователь видит превью и может обрезать изображение перед сохранением.AC5: После успешной загрузки пользователь видит свой новый аватар на странице профиля.AC6: При попытке загрузить неподдерживаемый формат файла пользователь видит сообщение об ошибке [текст ошибки].AC7: При попытке загрузить файл большего размера пользователь видит сообщение об ошибке [текст ошибки].AC8: Пользователь может удалить текущий аватар, после чего отображается аватар по умолчанию.Итог:User Story понятна на высоком уровне, но требует детализации через уточняющие вопросы и добавление конкретных AC для полного понимания и тестирования функциональности.
Отличный развернутый ответ. Нейросеть снова на высоте.
Задача 2. Проектирование и оценка решений
Проектирование и оценка решений — запрос 1
Мы проектируем систему обработки событий для IoT-платформы, ожидается высокий поток данных (сотни тысяч сообщений в секунду) от устройств. Данные нужно надежно доставить нескольким независимым сервисам-обработчикам (аналитика, мониторинг, хранение). Порядок событий важен в рамках одного устройства.Сравни Kafka и RabbitMQ для этого сценария. Укажи ключевые плюсы и минусы каждого в контексте задачи (пропускная способность, гарантии порядка, модель потребления, масштабируемость).
Не буду копировать длинный ответ нейросети, скажу лишь, что и с этой задачей она справилась — расписала преимущества и недостатки обоих решений и сделала вывод, что под нашу задачу лучше подойдет Kafka ввиду более простой масштабируемости.
Проектирование и оценка решений — запрос 2
Я проектирую взаимодействие между микросервисом «Заказы» и микросервисом «Уведомления». Когда статус заказа меняется на «Отправлен», сервис «Уведомления» должен отправить email клиенту. Этот процесс может иногда занимать время или временно быть недоступным, и он не должен блокировать основной поток обработки заказа. Какой паттерн взаимодействия (синхронный REST API вызов или асинхронный через очередь сообщений) лучше подходит? Обоснуй кратко.
Проектирование и оценка решений — запрос 3
Мы выбираем базу данных для хранения каталога товаров в e-commerce системе. Структура товара может меняться (разные атрибуты для разных категорий: у ноутбука — процессор, у футболки — размер/цвет). Ожидается высокая нагрузка на чтение (просмотр каталога) и необходимость гибкого поиска/фильтрации по разным атрибутам. Сравни реляционную БД (например, PostgreSQL) и документо-ориентированную NoSQL БД (например, MongoDB или Elasticsearch) для этой задачи. Укажи плюсы и минусы в контексте гибкости схемы, производительности чтения и возможностей поиска.
Со вторым и третьим запросом нейросеть также справилась без проблем. Перейдем к более сложной задаче — генерации решений.
Задача 3. Документация
Генерация ADR — запрос
Сгенерируй Architecture Decision Record (ADR) в формате Markdown, используя стандартный шаблон (Статус, Контекст, Решение, Последствия).Тема: Выбор асинхронного взаимодействия через брокер сообщений для уведомления пользователей.Статус: ПринятоКонтекст: Сервису «Заказы» необходимо уведомлять сервис «Уведомления» об изменении статуса заказа (например, «Отправлен»), чтобы тот мог отправить email клиенту. Прямой синхронный вызов (REST) может блокировать обработку заказа и чувствителен к временной недоступности сервиса «Уведомления». Требуется отказоустойчивое и слабо связанное решение.Рассмотренные альтернативы: 1. Синхронный REST вызов от «Заказов» к «Уведомлениям». 2. Прямая запись в БД сервиса «Уведомления» (нарушение инкапсуляции). 3. Асинхронное взаимодействие через брокер сообщений (Kafka/RabbitMQ).Решение: Использовать асинхронное взаимодействие. Сервис «Заказы» публикует событие OrderShippedEvent в топик брокера сообщений. Сервис «Уведомления» подписывается на этот топик и обрабатывает события. Выбран брокер Apache Kafka из-за требований к потенциальной высокой нагрузке и возможности перечитывания событий.Мы пунктирно описали задачу, контекст, какое решение было выбрано, почему оно было выбрано, какие альтернативы рассматривали и почему от них отказались. Нейросеть легко генерирует разумное ADR и может даже подсказать другие альтернативы.
README — запрос
Создай структуру основногоREADME.mdфайла для нового микросервиса "Payment Service”.Ключевая информация:Назначение: Обработка входящих платежей через интеграцию с платежным шлюзом.Технологии: Java 17, Spring Boot 3, Maven, PostgreSQL, Docker.Основные API эндпоинты (примеры): POST /payments (создать платеж), GET /payments/{id} (получить статус).Как запустить локально: Использовать docker-compose up.Сгенерируй базовую структуру с основными разделами.
Нейросеть генерирует базовую документацию README для репозитория с описанием, о чем вообще этот микросервис, на чем он сделан, какие у него эндпоинты и как его запускать. Это еще одна рутинная задача, которую можно спокойно переложить на ИИ.
Задача 4. Генерация OpenAPI
Генерация OpenAPI — запрос
Сгенерируй фрагмент спецификации OpenAPI 3.0 в формате YAML для описания эндпоинта получения информации о пользователе по его ID.Путь: /users/{userId}Метод: GETПараметр пути: userId (тип: строка, формат: uuid, обязательный)Успешный ответ (200 OK): Объект User со полями id (uuid), username (string), email (string, format: email), createdAt (string, format: date-time).Ответ при ошибке (404 Not Found): Стандартный ответ «Пользователь не найден».Краткое описание (summary): «Получить информацию о пользователе по ID».Тег: Users
Я задал краткое поверхностное описание — и нейросеть сгенерировала нормальную «простыню» OpenAPI. Если на проекте API-first подход, когда API формируется до кода, а не наоборот, то автогенерация через ИИ сильно упрощает жизнь. Да, возможно, придется что-то по минимуму подправить или дописать, но в целом никаких особых «галлюцинаций» у нейросети здесь не возникает.
Генерация примера запроса/ответа — запрос
Опиши пример JSON-тела запроса и пример JSON-ответа (201 Created) для API эндпоинта POST /api/v1/orders.Описание запроса: Создание нового заказа. Должен содержать ID пользователя (строка, uuid), список заказанных товаров (массив объектов, каждый с productId (строка) и quantity (число > 0)) и адрес доставки (объект с полями street, city, zipCode).Описание ответа (201): Должен содержать ID созданного заказа (строка, uuid) и его текущий статус (строка, значение по умолчанию "PENDING").
Поскольку большинство LLM учили на Python и JavaScript, нейросети отлично знают эти два языка и выдают хорошие ответы в формате JSON. Кстати, опыт показывает, что если прописать сам промпт в виде JSON, то модель воспримет его еще лучше и выдаст еще более качественный структурированный результат в том же формате.
Задача 5. Рефакторинг
Рефакторинг — запрос
Опиши основные стратегии рефакторинга для следующей ситуации:У нас есть большой класс OrderProcessor в монолитном приложении. Он отвечает за:Валидацию данных нового заказа.Проверку наличия товаров на складе (прямой запрос к таблице склада).Резервирование товаров на складе (прямой update таблицы склада).Расчет итоговой стоимости с учетом скидок (сложная логика скидок внутри).Создание записи о заказе в БД заказов.Инициацию процесса оплаты через вызов PaymentService.Отправку уведомления пользователю (вызов NotificationService).Класс стал очень большим (~2000 строк), его сложно тестировать и изменять.Какие подходы к рефакторингу можно применить, чтобы улучшить его структуру и снизить связанность?
Разумный запрос, на который нейросеть выдает весьма разумный ответ. Опять же, копировать не буду, чтобы не делать бесконечный лонгрид.
Задача 6: Диаграммы
Диаграммы PlantUML — запрос
Сгенерируй код для диаграммы компонентов PlantUML, описывающий взаимодействие в системе онлайн-заказов:Компоненты:Веб-интерфейс пользователя (UI)API GatewayСервис Заказов (Order Service)Сервис Продуктов (Product Service)База данных Заказов (Orders DB)База данных Продуктов (Products DB)Взаимодействия:UI использует API Gateway.API Gateway направляет запросы к Сервису Заказов и Сервису Продуктов.Сервис Заказов взаимодействует с Базой данных Заказов.Сервис Заказов также может запрашивать информацию у Сервиса Продуктов (например, для проверки цены).Сервис Продуктов взаимодействует с Базой данных Продуктов.Используй стандартные обозначения компонентов и интерфейсов, если возможно.Сделай Сервис Заказов центральным элементом.
Большие языковые модели отлично знают PlantUML, так что при грамотных вводных, с указанием компонентов и взаимодействий, без проблем генерируют код для диаграммы.
Диаграммы Mermaid — запрос
Сгенерируй код для диаграммы последовательности Mermaid, иллюстрирующий процесс создания нового заказа.Участники: Клиент (User), API Gateway, Сервис Заказов (OrderService), Сервис Склада (InventoryService).Последовательность действий:Клиент отправляет запрос POST /orders на API Gateway с данными заказа.API Gateway перенаправляет запрос на Сервис Заказов.Сервис Заказов валидирует запрос.Сервис Заказов отправляет запрос на Сервис Склада для резервирования товаров (reserveItems).Сервис Склада отвечает Сервису Заказов (успех/неудача резервирования).Если резервирование успешно, Сервис Заказов создает заказ в своей БД (пометь это как внутреннее действие).Сервис Заказов отвечает API Gateway (статус 201 Created с ID заказа).API Gateway отвечает Клиенту (статус 201 Created).
То же самое — LLM понимают устройство диаграмм Mermaid и выдают результат в хорошем текстовом формате. Полдела сделано — нам останется только визуализировать диаграмму.
Промпт как ТЗ: проектируем архитектуру вместе с нейросетью
Теперь попробуем набросать высокоуровневую микросервисную архитектуру для простого e-commerce сайта в диалоге с LLM. Для решения этой задачи я решил использовать веб-интерфейс модели с открытым исходным кодом DeepSeek.
Идентификация сервисов
Я проектирую микросервисную архитектуру для e-commerce платформы. Предложи основные функциональные домены/микросервисы, которые понадобятся.
Поскольку такого рода задачи все большие языковые модели видели много раз, результат будет максимально типовым. В принципе, это нормально — дальше мы всё равно будем его отшлифовывать. Но если развернуть ТЗ чуть более подробно и сразу задать нейросети роль, то и ответ получится гораздо более точным.
Ты — эксперт по проектированию микросервисных архитектур. Твоя задача — помочь идентифицировать набор микросервисов для системы на основе предоставленных требований.Контекст:Мы разрабатываем систему для онлайн-платформы по продаже билетов на мероприятия (концерты, спектакли, фестивали). Платформа должна поддерживать следующие ключевые функции:1. Регистрация и аутентификация пользователей.2. Поиск мероприятий по различным критериям (дата, место, жанр).3. Просмотр деталей мероприятия (описание, участники, расписание).4. Бронирование и покупка билетов.5. Управление заказами пользователя (просмотр истории, отмена заказов).6. Интеграция с платежными системами.7. Аналитика продаж для организаторов мероприятий.Требования к архитектуре:Каждый микросервис должен быть независимым и решать одну конкретную бизнес-задачу.Микросервисы должны взаимодействовать через хорошо определенные API.Архитектура должна быть масштабируемой и отказоустойчивой.Задача:На основе описанных требований предложи список микросервисов, которые необходимы для реализации этой системы. Для каждого сервиса укажи:1. Название сервиса.2. Его основную ответственность (бизнес-функцию).3. Основные операции (например, CRUD или специфические действия).4. Какие другие сервисы он может использовать или с которыми взаимодействовать.Результат представь в виде структурированного списка.
Чтобы еще больше упростить себе задачу, можно сначала сформировать такого рода промпт с помощью этой же или любой другой модели, а потом его же ей и «скормить». Важно, чтобы промпт был структурирован и разбит на пункты — LLM такое очень любят.
Детализация одного сервиса
Давай сфокусируемся на сервисе «Заказы». Какие у него ключевые обязанности (ответственности)? Какие основные API-эндпоинты ему могут понадобиться (CRUD операций достаточно для примера)?
Можно ограничиться таким простеньким запросом — текущие версии LLM все равно выдадут что-то вполне приличное. Если же мы хотим получить не самый типовой вариант, то детализируем запрос:
Ты — эксперт по проектированию микросервисных архитектур. Твоя задача — помочь детализировать микросервис OrderService для системы онлайн-продажи билетов на мероприятия.Контекст:OrderService отвечает за управление заказами пользователей. Заказы включают информацию о выбранных билетах, статусе оплаты и истории покупок. Сервис должен быть независимым, но взаимодействовать с другими микросервисами для выполнения своих функций.Известные интеграции:1. TicketService: Управляет билетами (бронирование, покупка, отмена).2. PaymentService: Обрабатывает платежи через внешние платежные системы.3. EventCatalogService: Предоставляет информацию о мероприятиях.Требования к OrderService:Сервис должен поддерживать CRUD-операции для заказов.Должен предоставлять API для просмотра истории заказов пользователя.Должен обрабатывать изменения статуса заказа (например, «создан», «оплачен», «отменен»).Должен быть отказоустойчивым и масштабируемым.Задача:На основе предоставленного контекста предложи детальное описание OrderService, включая:1. Основные сущности (Entity), которые будут использоваться в сервисе.2. CRUD-операции и дополнительные действия (например, изменение статуса заказа).3. API-методы (в формате OpenAPI или простом текстовом описании).4. Взаимодействие с другими сервисами (какие запросы отправляются и какие данные получены).5. Возможные расширения функциональности (например, уведомления о статусе заказа).Результат представь в виде структурированного описания.
По сути, мы взаимодействуем с нейросетью как с младшим помощником. Если выдать джуну ТЗ на пару предложений, что-нибудь вменяемое он, вероятно, и выдаст. Но если сразу дать все вводные и подробно объяснить, что ты хочешь от него получить, результат будет более рабочим.
Взаимодействие сервисов
Простой запрос:
Как сервис «Заказы» должен взаимодействовать с сервисом «Пользователи» (для получения данных о клиенте) и сервисом «Каталог» (для проверки цен/наличия)? Предложи варианты (синхронно/асинхронно, REST/события) и кратко обоснуй.
Развернутый запрос:
Ты — эксперт по проектированию микросервисных архитектур. Твоя задача — помочь описать взаимодействие между тремя микросервисами: OrderService, UserService и EventCatalogService в рамках системы онлайн-продажи билетов на мероприятия.Контекст:1. OrderService: Управляет заказами пользователей, включая создание, просмотр и изменение статуса заказов.2. UserService: Отвечает за регистрацию, аутентификацию и управление данными пользователей (например, профиль пользователя).3. EventCatalogService: Хранит информацию о мероприятиях (описание, расписание, доступность билетов).Сценарии использования:1. Пользователь регистрируется или авторизуется в системе.2. Пользователь ищет мероприятия через EventCatalogService.3. Пользователь создает заказ на покупку билетов.4. Система проверяет доступность билетов и подтверждает бронирование.5. Пользователь оплачивает заказ, и система обновляет статус заказа.6. Пользователь может просматривать историю своих заказов.Задача:На основе предоставленного контекста предложи детальное описание взаимодействия между сервисами, включая:1. Последовательность вызовов API между сервисами для каждого сценария использования.2. Основные запросы и ответы (в виде примеров JSON или текстового описания).3. Какие данные передаются между сервисами и как они используются.4. Возможные точки отказа и способы обеспечения отказоустойчивости.Результат представь в виде последовательного описания для каждого сценария использования.
Визуализация
Простой запрос:
Сгенерируй Mermaid диаграмму (component diagram), показывающую сервисы «Пользователи», «Каталог», «Заказы» и их основные синхронные взаимодействия (REST API), которые мы обсудили.
Развернутый запрос:
Ты — эксперт по проектированию микросервисных архитектур и созданию технической документации. Твоя задача — помочь создать Mermaid-диаграмму для визуализации взаимодействия между микросервисами в системе онлайн-продажи билетов на мероприятия.Контекст:1. AuthService/UserService: Отвечает за регистрацию, аутентификацию и управление данными пользователей.2. EventCatalogService: Хранит информацию о мероприятиях (описание, расписание, доступность билетов).3. OrderService: Управляет заказами пользователей, включая создание, просмотр и изменение статуса заказов.4. TicketService: Управляет билетами (бронирование, покупка, отмена).5. PaymentService: Обрабатывает платежи через внешние платежные системы.Сценарий взаимодействия:1. Пользователь авторизуется в системе через AuthService.2. Пользователь ищет мероприятие через EventCatalogService.3. Пользователь создает заказ на покупку билетов через OrderService.4. OrderService взаимодействует с TicketService для бронирования билетов.5. OrderService инициирует платеж через PaymentService.6. После успешной оплаты OrderService обновляет статус заказа и сохраняет его.Задача:На основе предоставленного контекста сгенерируй Mermaid-диаграмму (типа sequenceDiagram), которая визуализирует взаимодействие между сервисами для описанного сценария. Убедись, что:1. Диаграмма показывает последовательность вызовов между сервисами.2. Каждый шаг взаимодействия четко обозначен (например, "Пользователь -> AuthService: Авторизация").3. Используются корректные названия сервисов и операций.Результат представь в виде готового Mermaid-кода.
Что важно учесть при общении с моделью
LLM хорошо работает в диалоге, поэтому исходный промпт можно и нужно уточнять. Четкость и контекст в запросе = лучший результат. Фокус помогает быстрее перейти от идеи к конкретным структурированным артефактам — API и диаграммам.
Но здесь есть такой момент: все самые важные ключевые слова должны быть прописаны в самом начале запроса. Матрицы внимания нейросети реагируют на исходный промпт и дальше отталкиваются именно от него. Если вдруг вы в начале сказали что-то лишнее или вообще сформулировали задачу неправильно, то сойти с этих рельсов, переключить внимание LLM уже не получится — придется сбрасывать весь диалог и начинать общение с нуля.
Еще один лайфхак: ключевые слова из исходного промпта можно повторять по ходу дела — таким образом вы подтверждаете их важность для нейросети.
Конечно, чтобы нейросеть выдавала качественно иные результаты и мыслила как сеньор, нужно проделать большую предварительную работу — построить семантические структуры, графы знаний, загрузить всю документацию в отдельную векторную базу и отсылать модель к ней как к источнику данных о контексте проекта. Если сделать все «по красоте», то нейросеть сможет сосредоточиться на особенностях конкретного проекта вместо того, чтобы креативить в типовом вакууме.
Тем не менее даже если мы ограничимся такими простыми запросами, какие я дал в статье, от ИИ уже будет большая польза. На данном этапе развития нейросетей ИИ — уже не хайп и генератор хаоса, а полноценный рабочий инструмент и помощник для архитектора ПО. Он ускоряет рутину в работе с документацией, API и диаграммами и помогает в творческих задачах брейншторминга, оценки требований и решений.
При этом полностью доверить нейросети создание архитектуры пока нельзя. Критическое мышление и валидация человеком — обязательны. Ответы нейросети не идеальны и требуют проверки, критики и доработки архитектором. ИИ на сегодняшний день все еще умный ассистент, а не замена человека.
