Как написать ТЗ для AI-конструктора приложений
Запрос вроде сделай CRM оставляет конструктору слишком много решений. Полезное ТЗ описывает один минимальный рабочий сценарий, границы первой версии и то, как проверить каждый результат.
Что учесть до начала работы
Не передавайте в конструктор реальные пароли, ключи API, персональные данные и закрытые документы.
Сгенерированный проект требует проверки функций, прав доступа и расходов до рабочего запуска.
Что подготовить
Что делать
Сформулируйте один результат MVP
Запишите, какую задачу пользователь должен завершить в первой версии. Отдельно перечислите функции, которые сознательно не входят в MVP.
Результат: Одна проверяемая цель и короткий список границ.Опишите роли и вход
Для гостя, обычного пользователя, менеджера и администратора укажите способ входа, доступные данные и разрешенные действия. Не объединяйте роли фразой разные права.
Результат: Матрица ролей без скрытых допущений.Разложите путь по экранам
Для каждого экрана укажите цель, обязательные поля, действия, переходы, пустое состояние и сообщение об ошибке.
Результат: Последовательность экранов от входа до результата.Опишите данные отдельно от интерфейса
Перечислите сущности, поля, связи, обязательность, уникальность и владельца записи. Для статусов задайте допустимые переходы.
Результат: Черновая модель данных, которую можно проверить до сборки.Зафиксируйте интеграции и секреты
Укажите внешние сервисы, какие данные уходят наружу, где хранятся ключи и что должно происходить при ошибке или превышении лимита.
Результат: Список интеграций с безопасными границами.Добавьте критерии приемки
Для каждого главного сценария запишите входные данные, ожидаемый результат, запрещенный результат и способ ручной проверки.
Результат: Чек-лист, по которому можно принять или отклонить версию.Промпт с ТЗ для первого MVP
Создай только первую проверяемую версию веб-приложения. Проблема пользователя: [одна проблема]. Главный результат: [что пользователь должен завершить]. Не входит в MVP: [функции вне первой версии]. Роли и права: - Гость: [что видит и делает]. - Пользователь: [что видит и делает]. - Администратор: [что видит и делает]. Экраны: 1. [название]: цель, поля, действия, пустое состояние, ошибка. 2. [название]: цель, поля, действия, пустое состояние, ошибка. Данные: - [сущность]: поля, обязательность, уникальность, владелец записи. - Связи: [какая запись с чем связана]. Правила: [валидация, статусы, допустимые переходы]. Интеграции: [сервис, передаваемые данные, поведение при ошибке]. Критерии приемки: [3-7 проверяемых условий]. Сначала покажи план экранов, данных и прав. Не создавай код и не подключай реальные сервисы, пока я не подтвержу план. Не придумывай недостающие требования: вынеси их отдельным списком вопросов.
Проверка ТЗ перед генерацией
Что чаще всего портит результат
Просить весь продукт одним сообщением
Сначала соберите один сквозной сценарий и только затем добавляйте соседние функции.
Описывать только экраны
Добавьте сущности, связи, владельца записи и серверные правила доступа.
Не задавать отрицательные границы
Явно перечислите функции и данные, которых не должно быть в первой версии.
Короткие ответы
Нужно ли указывать конкретный стек?
Только если перенос кода, интеграция или политика компании требуют определенной технологии. Для no-code платформы важнее сначала задать данные и сценарии.
Можно ли вставить весь документ с требованиями?
Лучше разделить его на стабильные правила проекта и одно небольшое задание на текущую итерацию.
Техническое задание для проверяемого прототипа приложения
AI-конструктору нужен ограниченный первый контур продукта: пользователи, ключевой сценарий, данные, правила и критерий готовности. Отделите обязательную версию от будущих идей, перечислите состояния загрузки, пустого результата и ошибки. Для каждого экрана укажите действие пользователя и изменение данных, а не только визуальное пожелание.
До начала заведите контрольную таблицу: идентификатор материала, версия входа, владелец, обязательный результат, доказательство, статус и дата. Для каждой ручной правки записывайте причину, а промежуточные файлы называйте так, чтобы нельзя было перепутать черновик и принятую версию. Правило остановки тоже задается заранее: критичная ошибка в факте, правах, данных, формате или воспроизводимости возвращает работу на соответствующий этап. После приемки попросите коллегу повторить одну ключевую проверку только по переданному комплекту. Если ему нужна история личного чата или устное пояснение автора, передача еще не завершена. Такой журнал нужен не ради формальности: он показывает реальную стоимость исправлений, не дает потерять ограничение при следующем обновлении и помогает расследовать расхождение без повторения всей работы.
Контрольный сценарий от входа до приемки
Зафиксировать исходные данные
Соберите цель продукта, роли пользователей, один основной маршрут, список экранов, поля и сущности, бизнес-правила, примеры данных, ограничения доступа, интеграции, нефункциональные требования и критерии приемки. Отделите подтвержденные сведения от предположений, назначьте владельца проверки и сохраните неизменную копию входа. Если часть данных закрыта, обезличьте ее до передачи во внешний сервис и запишите, что именно было удалено.
Выполнить рабочий проход
Проведите разбиение сценария на шаги, описание состояний интерфейса, проектирование данных и прав, выделение минимального объема, формулировку тестовых примеров, передачу задания конструктору и поэтапную проверку. Не меняйте критерии по ходу работы и сохраняйте промежуточные версии, чтобы ошибку можно было связать с конкретным действием. Любой пропуск отмечайте явно, а не заполняйте правдоподобной догадкой.
Проверить по оригиналам
Отдельный проверяющий должен оценить полноту маршрута от входа до результата, сохранение данных, валидацию полей, права ролей, обработку ошибок, мобильный вид, доступность, граничные значения, стоимость внешних вызовов и возможность экспорта. Он работает с исходниками и заранее подготовленным контрольным списком, а не только читает гладкий итог. Спорные места возвращаются автору с точной ссылкой на фрагмент или параметр.
Собрать пакет результата
Подготовьте версионное ТЗ, карту экранов, словарь данных, матрицу ролей, тестовые сценарии, набор демонстрационных записей, список исключений и журнал решений. Пакет должен открываться у коллеги без истории личного чата, содержать дату, версию, ограничения и понятное правило возврата на доработку.
Критерии, которые нужно записать до начала
Граница применимости
Генератор ускоряет прототип, но не принимает за команду решения о безопасности, праве и архитектуре. Нечеткое ТЗ приводит к правдоподобным догадкам. Платежи и персональные данные требуют отдельного проектирования.
Ошибка, из-за которой результат выглядит надежнее, чем есть
Команда описывает красивый главный экран, но не задает, что происходит после ошибки сети или повторной отправки формы. Затем прототип выглядит готовым только на демоданных. Проверяйте полный маршрут с невалидным вводом.
Что передать следующему участнику
Исполнитель получает ТЗ, тестовые аккаунты, демоданные, критерии по шагам и список запрещенных допущений. Заказчик хранит журнал изменений и принимает каждую функцию по сценарию, а не по скриншоту.
Коротко
Хорошее ТЗ для AI-конструктора не пытается заменить весь проектный документ. Оно ограничивает одну итерацию и связывает каждый экран с данными, правами и критерием приемки.