Промпты для технического задания. 26 готовых примеров для генерации

Создание качественного технического задания – задача, от которой зависит успех всего проекта. Однако многие сталкиваются с тупиком, пытаясь сформулировать требования ясно и полно. В этой статье собраны практичные промпты для технического задания, которые помогут превратить размытые идеи в четкие инструкции для разработчиков, используя возможности нейросетей.

Этот материал предназначен для менеджеров проектов, аналитиков, владельцев бизнеса и всех, кто устал от бесконечных правок и недопонимания в команде. Вместо абстрактной теории здесь предложены конкретные, готовые к использованию шаблоны.

Что Вы найдете внутри:

• Готовые формулировки для самых разных разделов ТЗ.
• Примеры для описания функциональных и нефункциональных требований.
• Шаблоны для определения ролей пользователей и структуры данных.
• Подходы к генерации пользовательских историй и сценариев использования.

Типичные ошибки при работе с промптами для ТЗ

Многие ошибки при составлении ТЗ с помощью нейросетей происходят из-за неверного подхода к формулировке запросов. Понимание этих подводных камней – первый шаг к созданию действительно полезного документа.

1. Запрашивать все ТЗ одним гигантским промптом. Это приводит к тому, что нейросеть выдает поверхностный и шаблонный текст, упуская важные детали. Модель не может глубоко проработать десять разделов одновременно.
2. Использовать расплывчатые формулировки без конкретики. Запрос «Напиши ТЗ для интернет-магазина» гарантированно даст бесполезный результат. Нейросеть не знает специфики вашего бизнеса, целевой аудитории и бюджета.
3. Забывать указать роль и аудиторию документа. ТЗ для внутреннего разработчика и ТЗ для внешней студии на тендере – это два разных документа по стилю и уровню детализации. Без этого уточнения результат будет «средним по больнице».
4. Не предоставлять контекст и ограничения. Если не упомянуть технологический стек, бюджетные рамки или сроки, нейросеть предложит идеалистические решения, которые невозможно реализовать. Конечно, разработчики обожают узнавать о таких мелочах уже после старта проекта.
5. Игнорировать нефункциональные требования. Большинство фокусируется на функциях («что делает система»), забывая о производительности, безопасности, масштабируемости. В итоге получается медленный и уязвимый продукт.
6. Принимать первый полученный результат за финальный. Нейросеть – это помощник, а не оракул. Первый вариант – это черновик, который нужно итеративно дорабатывать, уточняя детали и добавляя новые вводные.

Сравнение слабого и сильного промпта для задачи «Описать функционал личного кабинета»

Параметр	Слабый промпт (чего следует избегать)	Сильный промпт (рекомендуемый подход)
Формулировка	Напиши раздел ТЗ про личный кабинет.	Ты – опытный системный аналитик. Создай раздел «Личный кабинет пользователя» для технического задания на разработку образовательной платформы. Целевая аудитория – студенты онлайн-курсов. Опиши регистрацию, авторизацию, профиль, раздел «Мои курсы» и настройки уведомлений.
Причина неэффективности	Нет роли, нет контекста, нет структуры. Результат будет слишком общим и бесполезным.	Четко задана роль, контекст (образовательная платформа), целевая аудитория (студенты) и структура раздела. Это позволяет нейросети сгенерировать релевантный и детализированный текст.
Полученный результат (вероятный)	«В личном кабинете пользователь может управлять своим профилем и просматривать информацию».	Детальное описание каждого подраздела: поля для регистрации (email, пароль), способы авторизации (через соцсети), редактируемые поля профиля (имя, фото), отображение карточек курсов с прогрессом, опции для включения/выключения email- и push-уведомлений.
Комментарий	Такой запрос – пустая трата времени. Он не дает нейросети никакой зацепки для генерации полезной информации.	Такой промпт экономит часы работы, выдавая на 80% готовый черновик раздела, который остается только немного доработать.

Готовые промпты для технического задания: 26 шаблонов

Ниже представлены промпты, разработанные для решения конкретных задач при написании ТЗ. Они построены так, чтобы минимизировать «шум» и получить от нейросети максимум пользы. Важно понимать: это не волшебные заклинания, а инструменты, которые требуют вдумчивого заполнения переменных.

1. Генерация общей структуры ТЗ

Проблема:
Непонятно, с чего начать и какие разделы вообще должны быть в техническом задании. Хочется получить полный каркас документа.

Решение:
Промпт генерирует классическую структуру ТЗ, адаптированную под конкретный проект, которую можно использовать как план для дальнейшей работы.

Текст промпта:

*****

Ты – опытный руководитель проектов с 10-летним стажем. Твоя задача – составить структуру технического задания (ТЗ) для проекта [опишите суть проекта, например, «создание мобильного приложения для доставки еды»].

Контекст: Проект находится на начальной стадии, требуется создать полный и логичный документ для команды разработки. Технологический стек предварительно определен как [укажите технологии, если известны, например, «Python/Django для бэкенда, React Native для мобильного приложения»].

Составь оглавление ТЗ, включающее все стандартные разделы:

1. Введение и терминология.
2. Назначение и цели проекта.
3. Функциональные требования (с подразделами для основных модулей).
4. Нефункциональные требования (производительность, безопасность, надежность).
5. Требования к пользовательскому интерфейсу и опыту (UI/UX).
6. Роли пользователей и их права.
7. Требования к данным и структуре базы данных.
8. Требования к интеграциям с внешними системами.
9. Требования к развертыванию и поддержке.

Формат ответа: нумерованный список верхнего уровня с вложенными маркированными списками для подпунктов. Избегай общих фраз, сделай структуру максимально конкретной для указанного проекта.

*****

Почему это работает:
Промпт задает роль эксперта, предоставляет ключевой контекст (суть проекта, стек) и требует четкий формат ответа. Это заставляет нейросеть не просто перечислить стандартные разделы, но и адаптировать их под специфику задачи (например, для магазина еды она предложит разделы «Каталог», «Корзина», «Оформление заказа»).

2. Описание ролей пользователей

Проблема:
Сложно четко определить всех участников системы и разграничить их полномочия, что приводит к путанице в правах доступа.

Решение:
Этот промпт помогает создать подробный список ролей пользователей с описанием их ключевых возможностей в системе.

Текст промпта:

*****

Ты – системный аналитик. Твоя задача – создать раздел «Роли пользователей и права доступа» для ТЗ на разработку [название системы, например, «корпоративной CRM-системы»].

Проанализируй следующие типы пользователей и опиши их полномочия: [перечислите предполагаемые роли, например, «Администратор», «Менеджер по продажам», «Руководитель отдела», «Маркетолог»].

Для каждой роли подробно опиши:

1. Краткое описание роли (за что отвечает этот пользователь).
2. Основные доступные действия (что может делать в системе).
3. Ограничения (чего делать не может или какие данные не видит).

Контекст: Система предназначена для автоматизации отдела продаж. Менеджеры должны видеть только своих клиентов, руководители – всех клиентов своего отдела, а администратор – всю систему.

Формат ответа: таблица с колонками «Роль», «Описание», «Основные возможности», «Ограничения».

*****

Почему это работает:
Требование табличного формата и четкая структура описания для каждой роли заставляют ИИ систематизировать информацию. Предоставленный контекст (про отдел продаж) дает конкретные зацепки для разграничения прав, делая результат практичным, а не теоретическим.

3. Формулирование функциональных требований (пользовательские истории)

Проблема:
Техническое описание функций часто получается сухим и непонятным для бизнеса. Пользовательские истории помогают сфокусироваться на ценности для конечного пользователя.

Решение:
Промпт генерирует список пользовательских историй для конкретного модуля системы, что облегчает понимание требований всей командой.

Текст промпта:

*****

Ты – владелец продукта (Product Owner), работающий по гибкой методологии. Твоя задача – написать пользовательские истории для функционального модуля «[название модуля, например, «Управление задачами»]» в проекте [название проекта, например, «таск-менеджер для небольшой команды»].

Опиши не менее 5-7 ключевых пользовательских историй в формате «Как [роль], я хочу [действие], чтобы [ценность]».

Контекст: Основные роли в системе – «Менеджер» и «Исполнитель». Менеджер создает задачи и назначает их, исполнитель выполняет и отчитывается.

Пример: «Как Менеджер, я хочу создавать новую задачу с названием, описанием и сроком выполнения, чтобы четко ставить цели команде».

Тон: Ясный, лаконичный, ориентированный на пользователя. Избегай технического жаргона.

*****

Почему это работает:
Строгий формат «Как…, я хочу…, чтобы…» заставляет нейросеть фокусироваться не на технической реализации, а на бизнес-ценности каждой функции. Указание ролей («Менеджер», «Исполнитель») помогает создать сценарии, отражающие реальные потребности пользователей.

4. Детализация нефункциональных требований

Проблема:
Часто забывают прописать требования к производительности, безопасности и надежности, что приводит к проблемам на этапе эксплуатации.

Решение:
Этот промпт помогает сформулировать основные нефункциональные требования, о которых нельзя забывать.

Текст промпта:

*****

Ты – опытный архитектор программного обеспечения. Твоя задача – составить раздел «Нефункциональные требования» для ТЗ на [тип системы, например, «высоконагруженный новостной портал»].

Опиши требования по следующим категориям, приведя конкретные измеримые показатели:

1. Производительность: время ответа страниц (не более [укажите время, например, «1.5 секунды»] при [укажите нагрузку, например, «1000 одновременных пользователей»]).
2. Надежность: целевой уровень доступности системы (например, «99.8%»).
3. Безопасность: требования к защите от [перечислите угрозы, например, «SQL-инъекций, XSS-атак»], политика паролей, шифрование данных.
4. Масштабируемость: способность системы выдерживать рост нагрузки до [укажите предел, например, «5000 одновременных пользователей»] без деградации производительности.
5. Совместимость: список поддерживаемых браузеров и их версий (например, «Chrome последней версии, Firefox ESR»).

Стиль: Технический, точный, без двусмысленностей.

*****

Почему это работает:
Промпт требует указать конкретные, измеримые метрики (время отклика в секундах, доступность в процентах). Это заставляет ИИ генерировать не абстрактные пожелания («система должна быть быстрой»), а конкретные технические критерии, которые можно проверить на этапе тестирования.

5. Описание сценария использования (Use Case)

Проблема:
Недостаточно просто перечислить функции. Нужно описать, как пользователь будет взаимодействовать с системой шаг за шагом для достижения цели.

Решение:
Промпт создает подробное описание сценария использования для одной ключевой операции в системе.

Текст промпта:

*****

Ты – бизнес-аналитик. Твоя задача – детально описать сценарий использования (Use Case) для процесса «[название процесса, например, «Оформление заказа в интернет-магазине»]».

Опиши сценарий по следующей структуре:

1. Название сценария: [например, «Успешное оформление заказа авторизованным пользователем»].
2. Действующее лицо (Actor): [например, «Покупатель»].
3. Предусловия: [например, «Покупатель авторизован в системе, в корзине есть хотя бы один товар»].
4. Основной поток событий (шаги):
   • Шаг 1: Пользователь переходит в корзину.
   • Шаг 2: … (продолжи логическую цепочку).
5. Постусловия (результат): [например, «Заказ создан в системе со статусом ‘Новый’, товары зарезервированы на складе, пользователю отправлено email-подтверждение»].
6. Альтернативные потоки:
   • Если товара нет в наличии.
   • Если не удалось обработать платеж.

Формат: структурированный текст с нумерованными шагами.

*****

Почему это работает:
Жесткая структура (предусловия, основной поток, постусловия, альтернативные потоки) заставляет нейросеть продумать не только «счастливый путь», но и возможные ошибки и исключения. Это критически важно для создания отказоустойчивой системы.

6. Генерация требований к API

Проблема:
Нужно описать, как разные части системы (например, мобильное приложение и сервер) будут обмениваться данными, но нет понимания, как правильно структурировать эти требования.

Решение:
Промпт помогает создать базовое описание методов API для определенного модуля.

Текст промпта:

*****

Ты – бэкенд-разработчик, проектирующий RESTful API. Твоя задача – описать методы API для управления сущностью «[название сущности, например, «Статья в блоге»]».

Опиши следующие методы:

1. Создание статьи: HTTP-метод, URL, ожидаемые данные в теле запроса (заголовок, контент, автор), пример успешного ответа.
2. Получение списка статей: HTTP-метод, URL, параметры для пагинации и фильтрации (по автору, по дате), пример ответа.
3. Получение одной статьи: HTTP-метод, URL, пример ответа.
4. Обновление статьи: HTTP-метод, URL, данные в теле запроса.
5. Удаление статьи: HTTP-метод, URL, ожидаемый код ответа.

Контекст: API будет использоваться для взаимодействия с клиентским приложением, написанным на Vue.js. Авторизация происходит через Bearer-токен.

Формат ответа: для каждого метода укажи: «HTTP-метод URL», «Описание», «Тело запроса (для POST/PUT)», «Пример ответа (JSON)».

*****

Почему это работает:
Промпт использует стандартную для REST-архитектуры терминологию (HTTP-методы, URL, JSON). Это направляет ИИ на генерацию технически грамотного и структурированного описания, понятного любому разработчику. Упоминание контекста (клиентское приложение на Vue.js) добавляет реалистичности.

7. Описание структуры базы данных

Проблема:
Необходимо спроектировать таблицы в базе данных для хранения информации, но сложно продумать все поля и связи между ними.

Решение:
Этот промпт создает описание таблиц базы данных для конкретной сущности, включая типы данных и связи.

Текст промпта:

*****

Ты – архитектор баз данных. Твоя задача – спроектировать структуру таблиц для хранения информации о [сущности, например, «Пользователи» и «Заказы»] в реляционной базе данных (например, PostgreSQL).

Опиши следующие таблицы:

1. Таблица users: перечисли поля (id, email, password_hash, first_name, created_at), их типы данных и комментарии (например, «id — первичный ключ, автоинкремент»).
2. Таблица orders: перечисли поля (id, user_id, status, total_price, created_at) и их типы. Укажи, что поле user_id является внешним ключом, ссылающимся на users.id.

Ограничения: Пароли не должны храниться в открытом виде. Статус заказа может принимать значения из списка: [перечислите статусы, например, «новый», «в обработке», «доставлен», «отменен»].

Формат ответа: Для каждой таблицы – название и список полей с указанием «Название поля | Тип данных | Описание/Ограничения».

*****

Почему это работает:
Промпт требует описать конкретные атрибуты таблицы (поля, типы данных, ключи, связи). Указание ограничений (например, про хеширование паролей или перечисление статусов) заставляет ИИ сгенерировать более продуманную и безопасную схему данных.

8. Требования к дизайну и UI/UX

Проблема:
Как передать дизайнеру и фронтенд-разработчику общие пожелания к внешнему виду и удобству интерфейса, чтобы результат не стал сюрпризом?

Решение:
Промпт помогает сформулировать общие, но важные требования к UI/UX, которые зададут правильное направление для работы дизайнера.

Текст промпта:

*****

Ты – UX-дизайнер. Твоя задача – написать раздел «Общие требования к пользовательскому интерфейсу (UI/UX)» для проекта [опишите проект, например, «сервис бронирования отелей»].

Опиши требования, касающиеся следующих аспектов:

1. Общая стилистика: [опишите желаемый стиль, например, «минималистичный, светлый, с использованием фирменных цветов #3498db и #ecf0f1»].
2. Адаптивность: интерфейс должен корректно отображаться на десктопах (от 1280px), планшетах (от 768px) и мобильных устройствах (от 360px).
3. Принципы навигации: [опишите логику, например, «основные разделы доступны через верхнее меню, личный кабинет – через иконку в шапке сайта»].
4. Интерактивные элементы: опиши поведение кнопок, ссылок, полей ввода (состояния: обычное, при наведении, при нажатии, неактивное).
5. Доступность (Accessibility): интерфейс должен соответствовать базовым требованиям WCAG 2.1 (контрастность текста, навигация с клавиатуры).

Избегай конкретных указаний по расположению элементов, сфокусируйся на общих принципах и правилах.

*****

Почему это работает:
Промпт четко разделяет стратегические требования (стилистика, адаптивность) от тактических (расположение конкретной кнопки). Это помогает создать «дизайн-гайдлайны» в рамках ТЗ, не ограничивая творческую свободу дизайнера, но задавая нужные рамки.

9. Написание введения и глоссария

Проблема:
В начале ТЗ нужно ввести читателя в курс дела и определить все специфические термины, чтобы избежать недопонимания.

Решение:
Промпт генерирует раздел с общим описанием проекта и словарем терминов.

Текст промпта:

*****

Ты – технический писатель. Твоя задача – написать разделы «Введение» и «Термины и определения» для ТЗ на разработку [название проекта, например, «платформы для проведения вебинаров»].

1. Во введении: кратко опиши назначение разрабатываемой системы, ее основные цели (например, «автоматизация процесса регистрации участников, проведение онлайн-трансляций») и для кого она предназначена.
2. В разделе «Термины и определения»: составь глоссарий для следующих понятий: [перечислите термины, например, «Вебинар», «Спикер», «Участник», «Запись вебинара», «Лендинг вебинара»]. Для каждого термина дай краткое и однозначное определение в контексте данного проекта.

Формат ответа: два раздела с подзаголовками. Глоссарий оформить в виде списка.

*****

Почему это работает:
Промпт заставляет ИИ выступить в роли «переводчика» с языка бизнеса на язык разработки. Четкое определение терминов в самом начале документа – это фундамент, который предотвращает 90% споров на более поздних этапах.

10. Требования к интеграции с внешним сервисом

Проблема:
Нужно описать, как система будет взаимодействовать со сторонним сервисом (например, платежной системой или службой доставки), но непонятно, что именно указывать.

Решение:
Этот промпт помогает структурировать требования к интеграции.

Текст промпта:

*****

Ты – системный интегратор. Твоя задача – описать требования к интеграции [название вашей системы, например, «интернет-магазина»] с внешним сервисом [название сервиса, например, «платежная система ЮKassa»].

Опиши следующие аспекты интеграции:

1. Цель интеграции: [например, «прием онлайн-платежей от клиентов за заказы»].
2. Способ интеграции: [например, «через REST API сервиса ЮKassa»]. Ссылка на документацию API: [вставьте ссылку].
3. Ключевые сценарии взаимодействия:
   • Создание платежа (какие данные передаем: сумма, номер заказа).
   • Обработка уведомлений от платежной системы об успешной оплате (какой URL с нашей стороны будет их принимать).
   • Обработка сценария возврата платежа.
4. Требования к обработке ошибок: что должна делать система, если API платежного шлюза недоступно или возвращает ошибку.

Формат: структурированный текст с нумерованными пунктами.

*****

Почему это работает:
Промпт фокусируется на практических аспектах: цель, способ, ключевые сценарии и обработка ошибок. Указание ссылки на документацию API помогает нейросети (если у нее есть доступ к сети) или разработчику быстрее сориентироваться. Это превращает абстрактную задачу «интегрировать оплату» в конкретный план действий.

11. Генерация чек-листа для тестирования

Проблема:
После описания функции хочется сразу понять, как ее проверять. Это поможет и разработчику в самопроверке, и тестировщику.

Решение:
Промпт, основанный на пользовательской истории или функции, создает чек-лист для ее тестирования.

Текст промпта:

*****

Ты – инженер по качеству (QA Engineer). На основе следующего функционального требования: «[вставьте описание функции или пользовательскую историю, например, ‘Как пользователь, я хочу иметь возможность сбросить свой пароль, если я его забыл’]», создай чек-лист для тестирования.

Чек-лист должен включать:

1. Позитивные сценарии: проверка основного («счастливого») пути.
2. Негативные сценарии: проверка поведения системы при неверных данных или действиях пользователя.
3. Проверки UI: проверка корректности отображения элементов интерфейса.

Пример для позитивного сценария: «Пользователь вводит корректный email, переходит по ссылке из письма и успешно устанавливает новый пароль».
Пример для негативного сценария: «Пользователь вводит несуществующий в базе email и видит сообщение об ошибке».

Формат: три маркированных списка с подзаголовками: «Позитивные тесты», «Негативные тесты», «UI-тесты».

*****

Почему это работает:
Разделение на позитивные, негативные и UI-тесты заставляет ИИ продумать всестороннее покрытие функции. Это позволяет выявить потенциальные проблемы на ранней стадии и сразу заложить в ТЗ критерии приемки, что очень дисциплинирует разработку.

12. Описание административной панели

Проблема:
Часто про «админку» забывают, а потом делают ее в спешке. Нужно заранее продумать, какие инструменты для управления сайтом или приложением понадобятся.

Решение:
Промпт помогает спроектировать основные разделы и функции административной панели.

Текст промпта:

*****

Ты – менеджер продукта. Твоя задача – описать в ТЗ требования к административной панели для проекта [название проекта, например, «блог-платформа»].

Основная цель админ-панели – управление контентом и пользователями. Опиши необходимые разделы и их ключевые функции:

1. Раздел «Пользователи»:
   • Просмотр списка всех пользователей.
   • Поиск и фильтрация пользователей (по email, дате регистрации).
   • Возможность заблокировать/разблокировать пользователя.
2. Раздел «Статьи»:
   • Просмотр списка всех статей со статусами (опубликована, черновик).
   • Создание/редактирование/удаление статей.
   • Управление категориями и тегами.
3. Главная страница (Дашборд):
   • Отображение ключевой статистики (количество новых пользователей, статей за последнюю неделю).

Контекст: админ-панелью будут пользоваться модераторы контента и администраторы системы. Доступ должен быть защищен логином и паролем.

*****

Почему это работает:
Промпт структурирует требования к «админке» по разделам (Пользователи, Статьи), что соответствует типичной архитектуре таких систем. Описание конкретных действий (поиск, фильтрация, блокировка) превращает общую задачу в список конкретных подзадач для разработчика.

13. Требования к системе уведомлений

Проблема:
Как описать, какие уведомления, когда и по каким каналам должна отправлять система?

Решение:
Промпт генерирует таблицу с описанием системных уведомлений. Ирония судьбы в том, что правильно настроенные уведомления никто не замечает, а вот неправильные – бесят абсолютно всех.

Текст промпта:

*****

Ты – UX-аналитик. Твоя задача – спроектировать систему уведомлений для [название сервиса, например, «платформы онлайн-обучения»].

Составь таблицу, описывающую следующие уведомления:

1. Событие-триггер: [например, «Регистрация нового пользователя»].
2. Канал отправки: [например, «Email»].
3. Получатель: [например, «Пользователь»].
4. Содержание сообщения (кратко): [например, «Приветственное письмо со ссылкой для подтверждения почты»].

Опиши не менее 5 различных уведомлений, включая:

• Успешная оплата курса.
• Напоминание о предстоящем уроке за 24 часа.
• Уведомление о новом ответе от преподавателя.
• Еженедельный отчет о прогрессе.

Формат: таблица с колонками «Событие», «Канал (Email/Push/SMS)», «Получатель», «Содержание».

*****

Почему это работает:
Табличный формат заставляет четко сопоставить событие, канал, получателя и содержание. Это систематизирует «хаос» уведомлений и позволяет сразу увидеть всю картину: где-то не хватает напоминания, а где-то уведомления дублируются.

14. Требования к поиску и фильтрации

Проблема:
Просто сказать «нужен поиск» недостаточно. Нужно определить, по каким полям искать, как фильтровать и сортировать результаты.

Решение:
Промпт помогает детализировать требования к функции поиска на сайте или в приложении.

Текст промпта:

*****

Ты – специалист по поисковым системам. Твоя задача – описать требования к функции поиска и фильтрации для раздела «[название раздела, например, «Каталог товаров»]» в [тип проекта, например, «интернет-магазине электроники»].

Детализируй следующие аспекты:

1. Поисковая строка:
   • Поиск должен работать по [по каким полям искать, например, «названию товара, артикулу, описанию»].
   • Должны ли поддерживаться исправление опечаток и поиск по синонимам?
2. Фильтры:
   • Перечисли все доступные фильтры: [например, «Цена (от/до)», «Производитель (чекбоксы)», «Диагональ экрана (диапазон)»] и тип каждого фильтра.
3. Сортировка:
   • Перечисли доступные опции сортировки: [например, «по популярности», «сначала дешевле», «сначала дороже», «по новизне»].
4. Отображение результатов:
   • Как выглядят результаты? (например, «плитка товаров с фото, названием, ценой»).
   • Что происходит, если ничего не найдено? (например, «показывается сообщение ‘Ничего не найдено, попробуйте изменить запрос'»).

*****

Почему это работает:
Промпт разбивает абстрактную задачу «поиск» на четыре конкретных компонента: строка поиска, фильтры, сортировка и отображение. Это заставляет продумать все детали и передать разработчикам исчерпывающее описание, а не повод для домыслов.

15. Описание процесса миграции данных

Проблема:
При запуске новой системы часто нужно перенести данные из старой. Этот процесс полон подводных камней и требует тщательного планирования.

Решение:
Промпт помогает составить план миграции данных.

Текст промпта:

*****

Ты – специалист по миграции данных. Твоя задача – составить раздел ТЗ, описывающий процесс переноса данных из [название старой системы, например, «самописной CRM в Excel»] в новую [название новой системы, например, «Битрикс24»].

Опиши следующие шаги:

1. Источник данных: формат и структура данных в старой системе.
2. Переносимые сущности: какие именно данные нужно перенести ([например, «контакты клиентов», «история сделок», «каталог товаров»]).
3. Правила преобразования (мэппинг): как поля из старой системы будут соотноситься с полями в новой. Например, «Поле ‘ФИО’ из Excel должно быть разделено на три поля ‘Имя’, ‘Фамилия’, ‘Отчество’ в Битрикс24».
4. План миграции: последовательность действий (например, «1. Экспорт данных из Excel в CSV. 2. Написание скрипта для очистки и преобразования данных. 3. Тестовый импорт на staging-сервере. 4. Финальный импорт на production-сервере»).
5. Критерии успеха: как мы поймем, что миграция прошла успешно (например, «количество записей в новой и старой системах совпадает»).

*****

Почему это работает:
Промпт заставляет думать не только о том, «что» переносить, но и «как». Пункт про «Правила преобразования» (мэппинг) – самый важный. Он заставляет заранее продумать все несоответствия в структурах данных, которые являются главной причиной неудачных миграций.

16. Требования к локализации и мультиязычности

Проблема:
Проект должен поддерживать несколько языков, но непонятно, как это правильно заложить в архитектуру с самого начала.

Решение:
Промпт помогает описать требования к поддержке нескольких языков в приложении.

Текст промпта:

*****

Ты – архитектор ПО, проектирующий международный продукт. Задача – описать требования к локализации для проекта [название проекта, например, «SaaS-платформа для управления проектами»].

Система должна поддерживать следующие языки: [перечислите языки, например, «Русский (по умолчанию)», «Английский»].

Опиши требования:

1. Хранение переводов: весь текстовый контент интерфейса (названия кнопок, меню, подсказки) должен храниться в отдельных языковых файлах (например, JSON или .po), а не в коде.
2. Механизм переключения языка: пользователь должен иметь возможность выбрать язык в настройках профиля. Система должна запоминать его выбор.
3. Определение языка по умолчанию: при первом визите язык должен определяться автоматически на основе настроек браузера пользователя.
4. Контент, создаваемый пользователями: как система будет обрабатывать контент, который вводят сами пользователи на разных языках? [например, «контент не переводится, отображается на языке оригинала»].
5. Форматы дат, времени и чисел: они должны автоматически адаптироваться под выбранную локаль (например, «12/31/2023» для en-US и «31.12.2023» для ru-RU).

*****

Почему это работает:
Промпт затрагивает ключевые технические аспекты локализации: хранение переводов, переключение языка, форматы данных. Это позволяет заложить правильную архитектуру с самого начала, а не «прикручивать» второй язык сбоку, когда это становится в 10 раз сложнее и дороже.

17. Требования к журналированию (логированию)

Проблема:
Когда в системе что-то идет не так, разработчикам нужны «черные ящики» – логи. Но что именно нужно записывать?

Решение:
Промпт помогает определить, какие события в системе должны логироваться для последующего анализа и отладки.

Текст промпта:

*****

Ты – DevOps-инженер. Твоя задача – составить требования к системе журналирования (логирования) для [название проекта, например, «бэкенд-сервиса интернет-банкинга»].

Опиши, какие события и на каком уровне детализации должны записываться в логи:

1. Уровень INFO: ключевые бизнес-события. [Примеры: «пользователь X вошел в систему», «создан новый перевод на сумму Y», «пользователь Z сменил пароль»].
2. Уровень WARNING: некритичные, но потенциально проблемные ситуации. [Примеры: «неудачная попытка входа для пользователя X», «API стороннего сервиса ответило с задержкой»].
3. Уровень ERROR: критические ошибки, требующие внимания. [Примеры: «не удалось подключиться к базе данных», «необработанное исключение в модуле Z», «ошибка при обработке платежа»].

Для каждой записи в логе укажи обязательную информацию: временная метка, уровень лога, ID пользователя (если применимо), текст сообщения, контекст (например, ID запроса).

*****

Почему это работает:
Промпт использует стандартные уровни логирования (INFO, WARNING, ERROR), что является общепринятой практикой. Требование описать конкретные примеры событий для каждого уровня заставляет задуматься о том, какая информация действительно будет полезна для диагностики проблем в будущем.

18. Описание отчетов

Проблема:
Бизнесу нужны отчеты, но запрос «хочу отчет по продажам» слишком абстрактен. Нужно детализировать его структуру и параметры.

Решение:
Промпт помогает составить детальное описание для конкретного отчета в системе.

Текст промпта:

*****

Ты – бизнес-аналитик. Твоя задача – описать требования к отчету «[название отчета, например, «Ежемесячный отчет по продажам»]» для [название системы, например, «CRM-системы»].

Опиши отчет по следующей структуре:

1. Назначение отчета: для кого он и какие решения помогает принимать.
2. Параметры формирования: какие фильтры должны быть доступны пользователю перед генерацией отчета ([например, «выбор периода (месяц, год)», «выбор менеджера», «выбор региона»]).
3. Структура отчета (колонки): какие данные должны отображаться в отчете ([например, «Название товара», «Количество проданных единиц», «Сумма продаж», «Средний чек»]).
4. Визуализация: должен ли отчет содержать графики или диаграммы? ([например, «круговая диаграмма по доле каждого товара в общей выручке»]).
5. Форматы экспорта: в каких форматах можно скачать отчет ([например, «XLSX», «PDF»]).

*****

Почему это работает:
Промпт декомпозирует абстрактное понятие «отчет» на конкретные составляющие: параметры, колонки, визуализация, экспорт. Это позволяет избежать ситуации, когда разработанный отчет оказывается бесполезным, потому что в нем не хватает нужного фильтра или столбца данных.

19. Требования к резервному копированию и восстановлению

Проблема:
Все надеются, что данные никогда не потеряются, но никто не застрахован от сбоев. Нужно заранее продумать стратегию бэкапов. Конечно, думать об этом заранее – для слабаков, настоящие профессионалы решают проблему, когда сервер уже «упал».

Решение:
Промпт помогает сформулировать требования к процедурам резервного копирования и восстановления данных.

Текст промпта:

*****

Ты – системный администратор. Твоя задача – описать требования к резервному копированию и восстановлению для проекта [название проекта, например, «база данных корпоративного портала»].

Опиши следующие параметры:

1. Объекты резервного копирования: какие именно данные и файлы нужно копировать ([например, «полная копия базы данных PostgreSQL», «файлы, загруженные пользователями в папку /uploads»]).
2. Частота резервного копирования (RPO — Recovery Point Objective): как часто должны создаваться бэкапы ([например, «ежедневно в 03:00 ночи»]).
3. Срок хранения копий: как долго должны храниться бэкапы ([например, «ежедневные – 7 дней, еженедельные – 1 месяц, ежемесячные – 1 год»]).
4. Время восстановления (RTO — Recovery Time Objective): за какое максимальное время система должна быть восстановлена из резервной копии в случае сбоя ([например, «не более 4 часов»]).
5. Процедура проверки бэкапов: как и как часто будет проверяться целостность и работоспособность резервных копий ([например, «еженедельно автоматически разворачивать последнюю копию на тестовом сервере»]).

*****

Почему это работает:
Промпт использует стандартные в индустрии метрики RPO и RTO, что сразу задает профессиональный тон. Он заставляет определить не только «что» и «когда» копировать, но и «как долго хранить» и, что самое важное, «как проверять». Последний пункт часто упускают, что приводит к нерабочим бэкапам.

20. Описание страницы или экрана приложения

Проблема:
Нужно описать содержимое конкретной страницы сайта или экрана мобильного приложения, чтобы дизайнер и разработчик поняли, из каких блоков она состоит.

Решение:
Промпт помогает создать поблочное описание для конкретной страницы.

Текст промпта:

*****

Ты – UX-проектировщик. Твоя задача – описать структуру страницы «[название страницы, например, «Главная страница новостного сайта»]».

Опиши страницу как последовательность логических блоков сверху вниз. Для каждого блока укажи его назначение и ключевое содержимое.

Примерная структура:

1. Шапка сайта (Header): логотип, главное меню навигации, кнопка входа/регистрации.
2. Блок «Главная новость»: крупное фото, заголовок и краткое описание самой важной новости дня.
3. Блок «Лента новостей»: список из 10 последних новостей, каждая в виде карточки (фото, заголовок, дата). Внизу блока – кнопка «Загрузить еще».
4. Блок «Популярные темы»: облако тегов или список самых обсуждаемых тем.
5. Подвал сайта (Footer): ссылки на соцсети, контакты, юридическая информация.

Сфокусируйся на структуре и содержании, а не на визуальном дизайне.

*****

Почему это работает:
Подход «сверху вниз» и описание через «логические блоки» помогает создать «каркас» страницы, понятный всем участникам процесса. Это гораздо эффективнее, чем пытаться описать страницу словами в свободной форме. Такой формат легко превращается в прототип.

21. Требования к обработке ошибок и состояний

Проблема:
Интерфейс должен адекватно реагировать на разные ситуации: загрузка данных, отсутствие данных, ошибка сервера.

Решение:
Промпт помогает описать, как должен выглядеть и вести себя интерфейсный компонент в различных состояниях.

Текст промпта:

*****

Ты – фронтенд-разработчик. Твоя задача – описать все возможные состояния для компонента «[название компонента, например, «Список комментариев под статьей»]».

Опиши, что должен видеть пользователь в следующих ситуациях:

1. Состояние загрузки (Loading): пока данные загружаются с сервера. [Пример: «отображается анимация-скелет (skeleton) или спиннер»].
2. Пустое состояние (Empty): если данные загрузились, но их нет. [Пример: «отображается сообщение ‘Комментариев пока нет. Станьте первым!’ и иконка»].
3. Состояние с данными (Ideal): если данные успешно загружены. [Пример: «отображается список комментариев»].
4. Состояние ошибки (Error): если при загрузке данных произошла ошибка. [Пример: «отображается сообщение ‘Не удалось загрузить комментарии’ и кнопка ‘Попробовать снова'»].

Формат: нумерованный список с описанием визуального представления для каждого состояния.

*****

Почему это работает:
Продумывание всех состояний (загрузка, пустота, данные, ошибка) – признак качественного проектирования интерфейса. Этот промпт заставляет заранее предусмотреть все сценарии, что предотвращает появление «белых экранов» или неинформативных сообщений об ошибках в готовом продукте.

22. Требования к email-шаблонам

Проблема:
Нужно описать, как должны выглядеть письма, которые система отправляет пользователям.

Решение:
Промпт помогает создать ТЗ для верстальщика на создание адаптивных email-шаблонов.

Текст промпта:

*****

Ты – email-маркетолог. Твоя задача – составить требования к созданию HTML-шаблона для [тип письма, например, «транзакционного письма о подтверждении заказа»].

Опиши структуру и содержание шаблона:

1. Тема письма: [например, «Заказ №[номер_заказа] успешно оформлен»].
2. Шапка (Header): логотип компании.
3. Тело письма:
   • Приветствие («Здравствуйте, [имя_клиента]!»).
   • Основная информация («Ваш заказ №[номер_заказа] на сумму [сумма] принят в обработку.»).
   • Таблица с составом заказа (название товара, количество, цена).
   • Информация о доставке (адрес, способ доставки).
4. Подвал (Footer): контакты службы поддержки, ссылки на отписку (если применимо).

Особые требования: шаблон должен быть адаптивным и корректно отображаться в основных почтовых клиентах (Яндекс.Почта, Mail.ru, Gmail, Outlook). Все переменные (в квадратных скобках) должны быть легко заменяемыми.

*****

Почему это работает:
Промпт разбивает письмо на стандартные блоки (шапка, тело, подвал) и требует указать переменные. Это позволяет создать универсальный шаблон, который разработчики смогут легко интегрировать и наполнять реальными данными. Упоминание адаптивности и почтовых клиентов – критически важное требование для email-верстки.

23. Требования к производительности клиентской части

Проблема:
Сайт может тормозить не из-за сервера, а из-за медленной работы в браузере. Как сформулировать требования к скорости загрузки и отклика интерфейса?

Решение:
Промпт помогает установить конкретные метрики производительности для фронтенда.

Текст промпта:

*****

Ты – эксперт по веб-производительности. Твоя задача – сформулировать требования к производительности клиентской части для [тип проекта, например, «лендинга продукта»].

Используя метрики Core Web Vitals, определи целевые показатели:

1. Largest Contentful Paint (LCP): отрисовка крупнейшего элемента на первом экране должна занимать не более [например, «2.5 секунд»].
2. First Input Delay (FID): задержка перед первым взаимодействием пользователя (например, клик по кнопке) не должна превышать [например, «100 миллисекунд»].
3. Cumulative Layout Shift (CLS): совокупный сдвиг макета не должен превышать [например, «0.1»].
4. Общий вес страницы: не должен превышать [например, «1.5 МБ»].
5. Количество запросов: общее число HTTP-запросов на главной странице не должно быть больше [например, «50»].

Проверка должна производиться с помощью инструментов, таких как Google PageSpeed Insights, в режиме «mobile» с эмуляцией медленного 3G-соединения.

*****

Почему это работает:
Промпт использует общепринятые в индустрии метрики (Core Web Vitals), что делает требования объективными и измеримыми. Указание инструментов и условий тестирования (медленное соединение) гарантирует, что сайт будет быстрым не только у разработчика с гигабитным интернетом, но и у реальных пользователей.

24. Генерация гипотез для A/B-тестирования

Проблема:
Есть желание улучшить какой-то показатель (например, конверсию), но нет идей, что именно можно изменить и протестировать.

Решение:
Промпт помогает сформулировать гипотезы для проведения A/B-тестов.

Текст промпта:

*****

Ты – аналитик-маркетолог. Твоя задача – сгенерировать 3 гипотезы для A/B-тестирования, направленные на увеличение [ключевая метрика, например, «конверсии в регистрацию»] на странице [опишите страницу, например, «главная страница сайта»].

Сформулируй гипотезы в формате: «Если мы [изменение], то [ожидаемый результат], потому что [обоснование]».

Пример: «Если мы заменим кнопку ‘Начать’ на ‘Зарегистрироваться бесплатно’, то конверсия в регистрацию вырастет, потому что новый текст более явно указывает на следующее действие и снимает барьер возможной оплаты».

Контекст: Текущая конверсия в регистрацию составляет 2%. Цель – поднять ее до 3%. Целевая аудитория – [опишите аудиторию].

*****

Почему это работает:
Строгий формат «Если…, то…, потому что…» заставляет не просто предлагать изменения, а осмысливать их. Он требует сформулировать ожидаемый результат и психологическое обоснование, что превращает случайные «догадки» в проверяемые научные гипотезы.

25. Описание политики безопасности

Проблема:
Как в ТЗ описать общие требования к безопасности, чтобы разработчики заложили правильные практики с самого начала?

Решение:
Промпт помогает сформулировать основные пункты политики безопасности приложения.

Текст промпта:

*****

Ты – специалист по информационной безопасности. Твоя задача – написать раздел «Политика безопасности» для ТЗ на разработку [тип приложения, например, «веб-приложения для финансового учета»].

Опиши требования в следующих областях:

1. Аутентификация:
   • Требования к сложности пароля (минимальная длина, наличие цифр, спецсимволов).
   • Обязательное использование двухфакторной аутентификации (2FA) для всех пользователей.
   • Блокировка учетной записи после [например, «5»] неудачных попыток входа.
2. Авторизация и управление доступом:
   • Принцип минимальных привилегий: пользователи по умолчанию должны иметь доступ только к тем функциям, которые необходимы для их работы.
3. Защита данных:
   • Все чувствительные данные ([например, «пароли, персональные данные клиентов»]) должны храниться в зашифрованном/хешированном виде.
   • Весь трафик между клиентом и сервером должен передаваться только по протоколу HTTPS.
4. Защита от распространенных уязвимостей:
   • Приложение должно быть защищено от атак типа [например, «OWASP Top 10, включая SQL-инъекции, XSS, CSRF»].

*****

Почему это работает:
Промпт структурирует требования по ключевым областям безопасности (аутентификация, авторизация, защита данных). Упоминание стандартов вроде OWASP Top 10 дает разработчикам четкий ориентир и чек-лист для проверки защищенности приложения.

26. Формулирование критериев приемки

Проблема:
Задача вроде бы сделана, но заказчик недоволен. Это происходит, когда заранее не определено, что считать «готовой работой».

Решение:
Промпт помогает для каждой функции или пользовательской истории сформулировать четкие критерии приемки.

Текст промпта:

*****

Ты – менеджер проекта. Для следующей пользовательской истории: «[вставьте историю, например, ‘Как покупатель, я хочу добавлять товары в корзину, чтобы оформить заказ позже’]», напиши критерии приемки (Acceptance Criteria).

Критерии должны быть написаны в формате «Дано…, Когда…, Тогда…».

Примеры:

• Дано: я нахожусь на странице товара, Когда: я нажимаю кнопку «Добавить в корзину», Тогда: товар появляется в моей корзине, а иконка корзины в шапке сайта обновляет счетчик товаров.
• Дано: я добавил товар в корзину, Когда: я перехожу на другую страницу сайта, Тогда: товар остается в корзине.
• Дано: товар уже есть в корзине, Когда: я снова нажимаю «Добавить в корзину» на его странице, Тогда: количество этого товара в корзине увеличивается на 1.

Напиши не менее 3-5 критериев, покрывающих основной и альтернативные сценарии.

*****

Почему это работает:
Формат «Дано-Когда-Тогда» (Gherkin-синтаксис) заставляет мыслить сценариями и описывать поведение системы максимально однозначно. Он не оставляет места для интерпретаций. Если все критерии приемки выполнены, задача считается завершенной. Это лучший способ синхронизировать ожидания бизнеса и команды разработки.

Ключевые команды для уточнения ТЗ в промптах

Иногда нейросети требуется дополнительная «настройка». Эти команды помогут получить более точный и полезный результат при генерации разделов технического задания.

Команда/Модификатор	Что делает	Когда применять
«Действуй как [роль]»	Задает нейросети определенную профессиональную перспективу (аналитик, разработчик, дизайнер).	Всегда. Это самый важный модификатор для получения релевантного ответа.
«Опиши с точки зрения пользователя»	Смещает фокус с технической реализации на пользовательский опыт и ценность.	При написании пользовательских историй, описании сценариев использования.
«Используй измеримые показатели»	Заставляет ИИ приводить конкретные цифры, а не абстрактные описания.	При описании нефункциональных требований (производительность, надежность).
«Предложи 3 альтернативных варианта»	Помогает рассмотреть разные подходы к реализации функции.	Когда вы не уверены в единственно верном решении и хотите изучить альтернативы.
«Исключи технический жаргон»	Требует изложить мысль простым языком, понятным для нетехнических специалистов.	При написании разделов для заказчика или инвесторов.
«Структурируй ответ в виде таблицы с колонками: […], […], […]»	Задает жесткий формат вывода, что делает информацию более наглядной и систематизированной.	При описании ролей, уведомлений, отчетов, сравнении чего-либо.
«Продумай пограничные случаи и ошибки»	Направляет ИИ на анализ не только «счастливого пути», но и исключительных ситуаций.	При описании сценариев использования, форм ввода данных, интеграций.

Неочевидные советы для работы с промптами

Освоив базу, можно переходить к более тонким настройкам. Вот несколько советов, которые помогут поднять качество генерируемых ТЗ на новый уровень.

1. Используйте «негативные» промпты. Вместо того чтобы говорить, что делать, иногда полезнее сказать, чего НЕ делать. Например: «Опиши процесс регистрации, но избегай упоминания входа через соцсети, так как мы от них отказались». Это помогает отсечь ненужные варианты.
2. Создайте «персону» для вашего проекта и ссылайтесь на нее. В начале диалога с ИИ опишите вашего целевого пользователя: «Наш пользователь – бухгалтер 45 лет, не очень уверенно владеет компьютером, ценит простоту». А затем в промптах добавляйте: «Опиши интерфейс с учетом нашей персоны».
3. Просите нейросеть покритиковать ваше же требование. Сформулируйте требование, а затем попросите: «Выступи в роли скептичного разработчика и найди слабые места, двусмысленности и потенциальные проблемы в этом требовании: ‘[ваше требование]'». Это невероятно полезное упражнение.
4. Сохраняйте удачные «цепочки» промптов. Часто лучший результат дает не один промпт, а последовательность из 2-3. Например: 1) «Накидай идеи для личного кабинета», 2) «Отлично, возьмем идею №3 и детализируй ее в виде пользовательских историй», 3) «Теперь для этих историй напиши критерии приемки». Сохраните всю цепочку.
5. Используйте примеры «от противного». Покажите нейросети не только хороший пример, но и плохой. «Вот хороший пример требования: ‘…’. А вот плохой: ‘…’. Создай требование для моей задачи в стиле хорошего примера, избегая ошибок плохого».
6. Задавайте ограничения по объему. Иногда нейросеть слишком увлекается. Команда «опиши кратко, не более 100 слов» или «детализируй, объем не менее 500 слов» помогает контролировать уровень детализации ответа.
7. Переиспользуйте сгенерированные части ТЗ как контекст для новых. Сгенерировали роли пользователей? В следующем промпте по функционалу вставьте их в контекст: «Контекст: у нас есть роли ‘Администратор’ и ‘Менеджер’ с такими-то правами. Теперь опиши функцию ‘Создание отчета’, учитывая их полномочия». Это обеспечивает целостность документа.

Использование этих приемов превращает работу с нейросетью из простого получения ответов в полноценный диалог, где вы вместе создаете качественный и продуманный продукт. Грамотно составленные промпты для технического задания – это не замена аналитика, а мощный инструмент в его руках, экономящий время на рутине и позволяющий сосредоточиться на действительно сложных задачах.