Промпт на проверку технического задания на разработку PWA приложения - не работает
С помощью ИИ я пишу части ТЗ, и это ТЗ уже больше 600 страниц. Т.к. вычитывать всё самому сложно, то я делегирую эту задачу ИИ и надеюсь что он справится :). Хотя потом сам таки вычитываю.
Вот промпт для Gemini 2.5 Pro, в который я сгружаю своё ТЗ. Из особенностей - в ТЗ описана админка для PWA приложения без привязки к конкретному фреймворку. Функционал - монолит, описанный как множество модулей внутри целого.
Самая мякотка в том, что по результатам первой версии промпта Gemini работать отказался, пишет: "Я не могу помочь вам, я просто языковая модель.".
Вторая РАБОТАЮЩАЯ версия промпта
Проанализируй загруженный файл с техническим заданием на разработку PWA-приложения.
Проверь описание модулей на наличие:
дублирующегося или пересекающегося функционала;
неясных или противоречивых формулировок;
признаков избыточной сложности для MVP-версии;
нарушений проектных принципов (например, слишком широкая ответственность одного модуля, слабая декомпозиция).
Также оцени:
насколько каждый модуль действительно нужен в MVP;
есть ли неочевидные зависимости между модулями;
насколько описание модулей согласовано с другими разделами ТЗ.
Дай лог аудита по каждому модулю: название, есть ли проблемы, краткие рекомендации. В конце — общее резюме по качеству ТЗ.
Первая НЕРАБОТАЮЩАЯ версия: Промпт для Gemini 2.5 Pro (роль: системный аналитик):
Ты — системный аналитик уровня Senior.
Я загрузил файл с техническим заданием на разработку PWA-приложения. Проанализируй его критически, профессионально и системно.
Твоя задача — оценка обоснованности, полноты и качества описания модулей и функционала с учётом того, что это MVP-проект. Следуй следующим критериям:
🔍 Проверь для каждого модуля:
Обоснован ли модуль для текущих бизнес-целей и стадии проекта (MVP)?
Есть ли дублирующийся или избыточный функционал?
Есть ли пересечения между модулями (функции, ответственность, интерфейсы)?
Не нарушаются ли базовые принципы проектирования (SRP, модульность, масштабируемость)?
Есть ли признаки плохих проектных решений (например: чрезмерная связанность, дублирование логики, избыточные зависимости, сложный жизненный цикл)?
Является ли описание модуля достаточно чётким, непротиворечивым и понятным для разработки?
Соответствует ли модуль общей архитектуре, целям и ограничениям проекта (например, если это PWA — нет ли противоречий с офлайн-доступом, хранением данных и т.п.)?
📋 Проверь документацию в целом:
Консистентность между разделами (описания модулей, бизнес-требования, API, UI, сценарии, ограничения).
Есть ли противоречия между частями ТЗ?
Указаны ли внешние зависимости, технические ограничения, используемые технологии?
Нет ли функционала, не обеспеченного соответствующими интерфейсами, ролями или API?
📤 Выводи результат в виде:
Лог аудита — по каждому модулю: краткое название, оценка (ОК / Есть проблемы), выявленные проблемы, рекомендации.
Итоговое резюме — список ключевых недостатков, если есть; общая оценка зрелости и проработанности ТЗ; рекомендации по улучшению.
Помни, цель — не просто найти ошибки, а сделать ТЗ лучше, практичнее, дешевле в реализации и понятнее для команды.