Системный аналитик тонет в документации, архитектор — в противоречивых требованиях, а заказчик уже в третий раз меняет «последнюю» деталь. Знакомо? Если да, то эта подборка — ваш спасательный круг. Я собрал 12 готовых промтов, которые помогут вам быстрее собирать требования, строить UML-диаграммы и фиксировать архитектурные решения. Это не магия, а проверенные шаблоны, которые экономят часы работы и снижают количество итераций. Каждый промт можно скопировать и адаптировать под свой проект — просто замените текст в квадратных скобках.
Почему это работает? Потому что большие языковые модели (LLM) сильны в структурировании информации, если дать им чёткую роль, контекст и формат вывода. Промты ниже построены именно по этому принципу: роль + контекст + задача + формат. Это не просто «напиши ТЗ», а полноценные инструкции, которые превращают нейросеть в ассистента, понимающего специфику вашей работы.
1. Промт для сбора требований: «Интервью с заинтересованными сторонами»
Когда использовать: На старте проекта, когда нужно вытащить из голов заказчика все ожидания и ограничения.
Ты — опытный системный аналитик. Проведи структурированное интервью с заинтересованными сторонами для проекта [название проекта]. Твоя цель — выявить функциональные и нефункциональные требования, а также бизнес-цели. Задай по очереди вопросы, начиная с общих и заканчивая детальными. После каждого ответа уточняй детали и фиксируй требования в виде списка. В конце сформируй итоговый документ со следующими разделами:
1. Бизнес-контекст и цели
2. Функциональные требования (с приоритетами MoSCoW)
3. Нефункциональные требования (производительность, безопасность, удобство)
4. Ограничения и допущения
5. Открытые вопросы
Начни с первого вопроса.
Пример использования: Вместо того чтобы часами созваниваться с заказчиком, вы запускаете этот промт в ChatGPT, Claude или другой LLM и получаете структурированный опросник. Затем отправляете его заказчику, собираете ответы и возвращаете их модели для финального документа.
2. Промт для анализа требований: «Проверка на полноту и непротиворечивость»
Когда использовать: Когда у вас есть черновик требований и нужно найти в нём дыры.
Ты — системный аналитик с 10-летним опытом. Проанализируй следующий список требований и выяви:
- Противоречия между требованиями
- Пропущенные сценарии (например, обработка ошибок, крайние случаи)
- Неоднозначные формулировки
- Отсутствующие нефункциональные требования
Для каждой проблемы предложи конкретное исправление или уточняющий вопрос.
Требования: [вставьте текст]
Пример: Вы вставляете список требований из ТЗ, а модель находит, что «пользователь может удалить аккаунт» противоречит «история заказов хранится 5 лет», и предлагает уточнить, что происходит с данными при удалении.
3. Промт для моделирования: «Генерация UML-диаграммы вариантов использования»
Когда использовать: Когда нужно быстро набросать Use Case диаграмму для нового функционала.
Ты — эксперт по UML. Создай текстовое описание диаграммы вариантов использования для системы [описание системы]. Включи:
- Акторов (роли пользователей и внешних систем)
- Варианты использования (основные сценарии)
- Связи (include, extend, generalization)
Формат вывода: список акторов, затем варианты использования с описанием, затем связи. Используй синтаксис PlantUML для генерации кода.
Система: [описание]
Пример: Вы описываете «интернет-магазин с корзиной и оплатой», а модель выдаёт PlantUML-код, который вы вставляете в редактор и получаете готовую диаграмму. Это экономит время на рисовании вручную.
4. Промт для моделирования: «Построение ER-диаграммы»
Когда использовать: Для проектирования базы данных.
Ты — архитектор баз данных. Спроектируй ER-диаграмму для системы [описание]. Определи сущности, атрибуты, первичные и внешние ключи, а также связи между сущностями (1:1, 1:N, N:M).
Формат вывода: список сущностей с атрибутами (тип данных, PK/FK), затем описание связей. Используй синтаксис Mermaid или PlantUML для генерации кода.
Система: [описание]
Пример: Для «системы управления заказами» модель предложит сущности Customer, Order, Product, OrderItem, а связи покажет в виде кода, который визуализируется в удобную схему.
5. Промт для документации: «Генерация ADR (Architecture Decision Record)»
Когда использовать: Когда вы приняли важное архитектурное решение и нужно его задокументировать.
Ты — архитектор ПО. Составь Architecture Decision Record (ADR) по шаблону Michael Nygard (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions.html). Используй следующие разделы:
- Заголовок: краткое описание решения
- Статус: Принято / Предложено / Заменено
- Контекст: почему возникла необходимость в решении
- Решение: что именно решено
- Последствия: положительные и отрицательные эффекты
Решение: [опишите решение]
Контекст: [опишите контекст]
Пример: Вы пишете «Переход с монолита на микросервисы», а модель формирует ADR с обоснованием и последствиями, который можно сразу добавить в репозиторий.
6. Промт для документации: «Создание технического задания»
Когда использовать: Когда нужно быстро собрать ТЗ из разрозненных заметок.
Ты — технический писатель и системный аналитик. Составь техническое задание на разработку [что разрабатываем] на основе следующих заметок. Структурируй текст по разделам: цели, функциональные требования, нефункциональные требования, требования к интерфейсу, требования к безопасности, этапы разработки. Используй формальный, но понятный язык.
Заметки: [вставьте текст]
Пример: Вы вставляете черновые заметки с созвона, а модель превращает их в структурированный документ, который остаётся только отредактировать.
7. Промт для анализа архитектуры: «Проверка на соответствие принципам SOLID»
Когда использовать: Когда нужно проверить, не нарушает ли предлагаемая архитектура базовые принципы.
Ты — эксперт по объектно-ориентированному проектированию. Проанализируй следующий код/архитектуру на соответствие принципам SOLID (SRP, OCP, LSP, ISP, DIP). Для каждого принципа укажи, соблюдается ли он, и если нет — предложи конкретные изменения.
Код/описание: [вставьте]
Пример: Вы вставляете описание классов, а модель находит, что класс OrderProcessor делает слишком много, и предлагает разбить его на несколько.
8. Промт для оценки рисков: «Анализ архитектурных рисков»
Когда использовать: Когда нужно заранее выявить потенциальные проблемы в архитектуре.
Ты — архитектор с опытом в оценке рисков. Проанализируй предложенную архитектуру [описание] и выяви:
- Технические риски (узкие места, отказы)
- Рыночные риски (устаревание технологий)
- Организационные риски (сложность поддержки)
Для каждого риска оцени вероятность (низкая/средняя/высокая) и влияние (низкое/среднее/высокое), предложи меры по снижению.
Архитектура: [описание]
Пример: Модель укажет, что использование определённой БД может создать проблемы с масштабированием, и предложит альтернативы.
9. Промт для генерации пользовательских историй (User Stories)
Когда использовать: Для перевода требований в формат, понятный разработчикам.
Ты — product owner. Преобразуй следующие требования в пользовательские истории по формату: «Как [роль], я хочу [действие], чтобы [ценность]». Для каждой истории добавь критерии приёмки (Given/When/Then).
Требования: [вставьте]
Пример: Требование «Система должна отправлять уведомления» превращается в историю «Как пользователь, я хочу получать уведомления о статусе заказа, чтобы знать, когда он будет доставлен» с критериями приёмки.
10. Промт для моделирования процессов: «Создание BPMN-диаграммы»
Когда использовать: Когда нужно описать бизнес-процесс.
Ты — бизнес-аналитик и эксперт по BPMN. Создай BPMN-диаграмму для процесса [описание процесса]. Включи: события, задачи, шлюзы, потоки управления. Используй синтаксис BPMN (например, для Camunda или других движков).
Опиши процесс текстом, а затем предложи код на языке моделирования, например, BPMN XML (если применимо).
Процесс: [описание]
Пример: Вы описываете процесс «обработка заказа», а модель выдаёт текстовое описание и XML-файл, который можно импортировать в инструмент моделирования.
11. Промт для проверки согласованности: «Сравнение требований и архитектуры»
Когда использовать: Когда нужно убедиться, что архитектура покрывает все требования.
Ты — системный аналитик. Сравни следующий список требований с архитектурным описанием. Для каждого требования укажи, реализовано ли оно в архитектуре, частично или отсутствует. Если отсутствует — предложи, как его добавить.
Требования: [список]
Архитектура: [описание]
Пример: Модель находит, что требование «поддержка двухфакторной аутентификации» не отражено в архитектуре, и предлагает добавить модуль аутентификации.
12. Промт для генерации тест-кейсов на основе требований
Когда использовать: Когда нужно быстро подготовить тестовые сценарии.
Ты — QA-инженер. Создай тест-кейсы для следующих функциональных требований. Для каждого тест-кейса укажи: ID, название, предварительные условия, шаги, ожидаемый результат. Покрой позитивные и негативные сценарии.
Требования: [вставьте]
Пример: Для требования «пользователь может зарегистрироваться с email и паролем» модель создаст тест-кейсы: успешная регистрация, невалидный email, короткий пароль и т.д.
Как использовать эти промты максимально эффективно
- Уточняйте контекст. Чем больше деталей вы укажете в квадратных скобках, тем точнее будет результат.
- Итерируйте. Первый ответ модели — это черновик. Уточняйте, задавайте дополнительные вопросы, просите переписать разделы.
- Проверяйте факты. Модель может ошибаться в деталях. Всегда проверяйте ключевые решения и код.
- Адаптируйте под свой инструмент. Если вы используете специализированные AI-инструменты для моделирования (например, для UML), промты можно настроить под их синтаксис.
Заключение
Эти 12 промтов — не догма, а отправная точка. Со временем вы адаптируете их под свой стиль работы и специфику проектов. Главное — они уже сейчас могут сэкономить вам часы рутины и снизить количество ошибок в документации. Попробуйте применить хотя бы один из них на следующем проекте — и вы почувствуете разницу. А если у вас есть свои проверенные промты, делитесь ими в комментариях — вместе мы сделаем работу системных аналитиков и архитекторов ещё эффективнее.
Комментарии