Промпты для рабочих задач: десять запросов для структуры и схем

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

Четыре части запроса

Роль задаёт точку зрения: редактор, аналитик, ведущий встречи. Входные данные ограничивают источник фактов. Формат результата помогает использовать ответ дальше. Ограничения запрещают добавлять неизвестное и выполнять лишние действия. Роль сама по себе не делает ответ профессиональным: исходники и критерии проверки важнее.

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

Как пользоваться десятью заготовками

Ниже описаны задачи и критерии проверки; в конце статьи — десять блоков с кнопкой копирования. Подставьте свой материал вместо квадратных скобок. Не вставляйте секреты, токены и персональные данные. Если инструмент подключён к сервису, отдельно укажите конкретный объект и запрет на изменения без подтверждения.

1. Диаграмма последовательности из описания API

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

2. ER-диаграмма из предметной области

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

3. Состояния объекта

Отделяйте состояние от действия. «Ожидает оплаты» — состояние, «отправить уведомление» — действие. Проверяйте, какое событие переводит объект дальше и есть ли запрещённые переходы.

4. План в формате Ганта

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

5. Решения после встречи

Главная защита от ошибок — ссылка на фразу-основание. «Было бы неплохо сделать» не равно решению «делаем». Пустая ячейка ответственного честнее случайно выбранного участника.

6. Противоречия в требованиях

Просите сравнить утверждения попарно и объяснить конфликт. Пусть модель отличает противоречие от недостающей информации. Отсутствие правила возврата денег — пробел; два несовместимых правила возврата — противоречие.

7. Структура документа

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

8. Группировка заметок

Сохраняйте исходные формулировки и идентификаторы. Группа «коммуникация» мало помогает, если в ней смешаны ожидание ревью, поиск документов и конфликт приоритетов. Название группы должно объяснять общую проблему.

9. Критерии приёмки

Для каждого требования нужен наблюдаемый результат. «Удобно» и «быстро» нельзя проверить без уточнений. Просите предложить вопросы, а не самостоятельно назначать нормативы.

10. План проверки гипотезы

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

Как проверить ответ до использования

Сначала проверьте полноту: все ли части исходного материала отражены. Затем точность: у каждого факта есть источник, у каждой связи — основание. Наконец, проверьте полезность формата: можно ли по таблице принять решение, а по схеме объяснить процесс коллеге. Если нет, уточните запрос одним конкретным изменением вместо просьбы «сделай лучше».

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

Что было проверено

5 октября 2026 года все десять заготовок вручную выполнены в Codex с MCP на учебных данных. Для первых четырёх созданы sequence, ER, state и Гант; проверены исходники и отрисовка в открытой доске. Для остальных шести сохранены входы и результаты: решения встречи, противоречия, структура документа, группы заметок, критерии приёмки и план проверки гипотезы. Это ручная проверка конкретных примеров, не сравнение моделей и не гарантия результата в любом клиенте.

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

Один проверенный текстовый результат

В учебной записи встречи Анна предложила показать прототип в пятницу, Дима подтвердил, что подготовит его к четвергу, а Маша сказала, что экспорт «было бы неплохо добавить позже». Результат пятого запроса сохранил показ в пятницу и ответственность Димы за подготовку. Экспорт попал в предложения, а не в принятые решения. Проверка здесь простая: у каждого решения есть явная фраза-основание; у пожелания нет выдуманного исполнителя и срока.

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

Чего не исправит формулировка

Промпт не даёт доступа к закрытому файлу, не делает старые данные актуальными и не подтверждает придуманный факт. Если нужно работать в сервисе, необходим разрешённый инструмент — например, MCP-подключение. Если материала нет, правильный результат — вопрос или обозначенный пробел.

Для диаграмм используйте поддерживаемые типы и проверяйте нотацию по документации Mermaid. Возможности движка в конкретном продукте могут быть уже, чем полный список Mermaid. Не просите обещать поддержку BPMN или всего UML только потому, что модель умеет написать похожий текст.

Создайте доску с исходниками и результатами. Разместите рядом запрос, ответ и замечания: так команда видит, что подтверждено, а что ещё нужно уточнить.

Ты системный аналитик. По описанию ниже выдели участников и сообщения. Сначала перечисли недостающие сведения. Затем подготовь Mermaid sequenceDiagram: основной и ошибочный исход. Не придумывай сервисы, запросы и ответы. После исходника укажи, какие фразы его подтверждают.
Описание: [вставьте описание API]

По описанию предметной области перечисли сущности, атрибуты и кратности связей. Для каждой связи приведи фразу-основание. Если обязательность не задана, задай вопрос. Не добавляй поля по привычке. После согласования дай Mermaid erDiagram.
Описание: [вставьте текст]

Выдели состояния объекта и события перехода из текста. Не путай действия и состояния. Покажи недостижимые и неописанные переходы как вопросы, не дополняй их самостоятельно. Подготовь Mermaid stateDiagram-v2 только по подтверждённым правилам.
Правила: [вставьте текст]

Собери список задач, длительностей и зависимостей из исходных данных. Если нет даты старта, календаря или длительности, остановись и задай вопросы. После уточнений подготовь Mermaid gantt. Не назначай людей и сроки самостоятельно.
Данные: [вставьте план]

Разбери запись на явно принятые решения, открытые вопросы и предложения. Таблица решений: решение, короткая цитата, ответственный, срок. Если имя или срок не названы, напиши «не определено». Не превращай пожелания в обязательства.
Запись: [обезличенный текст]

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

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

Сгруппируй заметки по конкретной общей проблеме, сохрани исходный текст и ID каждой заметки. Неоднозначные вынеси отдельно. Предложи не больше пяти групп и объясни критерий каждой. Исходные объекты не меняй.
Заметки: [ID и текст]

Для каждого требования предложи наблюдаемый критерий приёмки в формате «условие — действие — результат». Не назначай численные пороги, если их нет. Отдельно перечисли вопросы о словах «быстро», «удобно», «надёжно».
Требования: [вставьте текст]

По описанию подготовь план проверки гипотезы: предположение, аудитория, наблюдение, метод и критерий решения. Не выдумывай результаты исследований и размер выборки. Отметь, что нужно согласовать до запуска.
Гипотеза и ограничения: [вставьте текст]