TL;DR
PromptMN — система условных обозначений для промптов, где каждая часть задачи помечается коротким ключевым словом с %: %role, %goal, %req, %mustnot, %out. Вместо того чтобы описывать всё это прозой, вы расставляете семантические маркеры — и модель однозначно понимает что от неё ждут.
Классическая проблема сложных промптов: ограничения, роли и ожидаемый результат буквально тонут в тексте. Пишешь абзац, в котором одновременно объясняешь контекст, формулируешь задачу и случайно упоминаешь "но только без X" — в середине. Модель читает это как поток, теряет "но только без X" и делает X.PromptMN делает каждое требование явным — у него есть имя и зарезервированное место.
Метод работает в три слоя: контекст (%role, %goal, %domain) объясняет кто ты и зачем, требования (%req, %mustnot, %should) фиксируют что нельзя нарушать, выход (%plan, %showplan, %out) задаёт как модель должна действовать и что показать в ответе.
Схема метода
Блок PromptMN — один промпт, порядок ключевых слов ПРОИЗВОЛЬНЫЙ
(модель сама переупорядочивает перед выполнением)
КОНТЕКСТ И НАМЕРЕНИЕ:
%role → кто исполняет задачу (роль/персона модели)
%domain → область знаний / контекст задачи
%goal → что нужно получить в итоге
%problem → какая проблема решается
ТРЕБОВАНИЯ (MoSCoW-приоритеты):
%req → обязательно (Must Have)
%should → желательно (Should Have)
%could → если останется время (Could Have)
%mustnot → жёсткий запрет (Won't Have / Never)
ПЛАН И УПРАВЛЕНИЕ:
%plan → общая стратегия
%1 %2 %3 → конкретные шаги в порядке выполнения
%showplan → показать план ДО начала работы (защита от ошибок)
%trace → пояснить логику после выполнения
ДАННЫЕ:
%in → входные данные для задачи
%out → формат и содержание ответа
Всё это — один промпт в обычном чате. Никакого кода.
Пример применения
Задача: Ты — продакт в fintech-стартапе. Нужно дать Claude задание: разобрать онбординг конкурента (Тинькофф) и предложить улучшения для вашего приложения. Задача сложная, полно ограничений, нужен чёткий вывод.
Промпт:
∞
%role product manager в b2c fintech;
%domain мобильные приложения, UX онбординга, российский рынок;
%goal проанализировать онбординг Тинькофф и найти 3 точки роста
для нашего приложения;
%in {
наш онбординг: 6 экранов, верификация через Госуслуги,
падение на шаге 3 — 40%;
целевая аудитория: 25–35 лет, Москва и региональные города;
}
%req выводы должны быть применимы без редизайна — только UX-текст
и порядок шагов;
%should указать на что обращают внимание пользователи в первые
30 секунд;
%mustnot не предлагать функции, требующие изменения API или
бэкенда;
%plan
%1 описать ключевые паттерны онбординга Тинькофф;
%2 сравнить с нашим — где мы теряем внимание;
%3 предложить 3 конкретных изменения с обоснованием;
%showplan;
%out структурированный разбор: паттерны → сравнение → 3 рекомендации
с приоритетами;
∞
Результат:
Модель сначала покажет собранный план (%showplan) — ты увидишь интерпретацию задачи ДО того как она начнёт анализировать. Если план не тот — правишь сразу. Потом — структурированный разбор строго по трём шагам, с рекомендациями только в рамках ограничения %mustnot.
Почему это работает
Слабость LLM: Модель читает промпт как поток текста и сама решает что важно. Ограничение в середине абзаца имеет меньший вес, чем то же ограничение в начале или конце. Нет маркера — нет гарантии, что это требование будет учтено.
Сильная сторона LLM: Модели хорошо следуют явно размеченным структурам — это заложено в обучении на документации, инструкциях, кодовых базах. Когда у элемента есть имя и тип (%mustnot vs просто "не надо"), модель трактует его иначе — как обязательный параметр, а не как пожелание.
Как метод использует это: %-ключевые слова превращают части промпта в семантические якоря. Модель не угадывает что важно — она видит явные метки. %showplan — отдельный мощный приём: вы видите как модель поняла задачу ещё до выполнения. Это как попросить исполнителя "сначала перескажи задание своими словами" — ловишь ошибки до, а не после.
Рычаги управления:
- Убери %showplan → модель сразу переходит к результату, без промежуточного плана
- Добавь %trace → после ответа получишь объяснение логики каждого шага
- Вложи в %req { } несколько пунктов → список обязательных требований в блоке
- Используй %newconcept → можно ввести свой ключевой слово прямо в сессии
Шаблон промпта
∞
%role {кто выполняет задачу — роль или профессия};
%domain {область знаний и контекст};
%goal {итоговая цель — что должно быть достигнуто};
%in {
{входные данные, контекст, прикреплённый текст}
}
%req {обязательные требования — без них результат неприемлем};
%should {желательные требования};
%could {опциональные улучшения};
%mustnot {жёсткие запреты};
%plan {общая стратегия решения};
%1 {первый шаг};
%2 {второй шаг};
%3 {третий шаг};
%showplan;
%out {формат ответа — что именно и как структурировано};
∞
Что подставлять:
- {роль} → senior copywriter, финансовый аналитик, scrum-master
- {область} → B2B SaaS, маркетинг в телеграме, найм в IT
- {обязательные требования} → "только факты из приложенного текста", "на русском языке"
- {жёсткие запреты} → "не упоминать конкурентов по имени", "без советов по коду"
🚀 Быстрый старт — вставь в чат:
Вот шаблон PromptMN — системы структурированных промптов с %-ключевыми словами.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить все поля.
[вставить шаблон выше]
LLM спросит про роль, ограничения и ожидаемый формат ответа — потому что именно это нужно для работы метода: без чётких %req и %out промпт останется неполным.
Ограничения
⚠️ Нет пользы на простых задачах: "Переведи эту фразу" или "Объясни слово" — разметка только добавит шум. Метод окупается на многошаговых задачах с несколькими ограничениями.
⚠️ Проверено на примерах, не на массиве данных: Авторы показали что модели понимают PromptMN корректно — но без сравнения с базовым промптингом на больших выборках. Неизвестно насколько прирост качества стабилен.
⚠️ Требует дисциплины при написании: Чем сложнее промпт — тем больше соблазн формально добавить
%req, но написать туда всё подряд. Систему легко перегрузить и она перестанет работать как структура.
⚠️ Обратный промптинг — на зрелых моделях: Попросить Claude или GPT-5.5 переформулировать твой запрос в PromptMN работает хорошо. На менее мощных или локальных моделях — непредсказуемо.
Как исследовали
Авторы не гнались за статистикой — они проверяли: работает ли нотация вообще? Для этого взяли несколько типов задач по возрастающей сложности, от простого %repeat ("напечатай строку три раза") до проверки числа на простоту через %method, %var и %if-ветвление. Каждый промпт содержал полную спецификацию PromptMN в контексте — без дообучения. Всё это прогнали через Claude Fable 5, Claude Opus 4.8, Gemini 3.1 Pro и GPT-5.5. Все четыре модели правильно выполнили задачи, включая вложенные циклы и условный выход из метода. Интересный момент: авторы специально теcтировали %showplan — и модели действительно показывали собранный план ДО работы, а не генерировали его постфактум. Это важно: значит директива работает как ограничение на порядок действий, а не просто как просьба описать что сделано. Честный минус: это feasibility study, не сравнительный эксперимент. Нет контрольной группы с обычным промптом, нет метрик качества вывода. Авторы сами признают это и называют крупную валидацию будущей работой.
Оригинал из исследования
%role game developer;
%intro a platform-independent Snake game; on every tick the snake
advances by one cell in its current direction.
%goal decide what happens next based on the next cell the snake
is about to enter.
%var %next-cell;
%if <%next-cell is an obstacle OR is part of the snake's body> {
end the game and show "Game Over";
}
%else %if <%next-cell contains food> {
grow the snake by one segment;
spawn new food in a random empty cell;
increment the score by 10;
}
%else {
move the snake forward by one cell;
}
%showplan;
%out the resulting game state;
Контекст: Демонстрация ветвления (%if, %else) на логике одного тика игры в Snake. Модель (Claude Opus 4.7) перед выполнением показала полный план с приоритетами веток — это и есть %showplan в действии.
Адаптации и экстраполяции
💡 Адаптация: Обратный промптинг — рентген твоего запроса
Вместо того чтобы писать PromptMN вручную — попроси модель переписать твой сырой запрос в PromptMN-формат. Это позволяет увидеть как модель тебя поняла — какие цели вывела, какие ограничения предположила, что считает входными данными.
Перепиши мой запрос в формате PromptMN с ключевыми словами
%role, %goal, %req, %mustnot, %in, %out.
Покажи свои предположения о том, что я, возможно, не указал явно.
Мой запрос:
[вставь сюда任何 сырой запрос]
Ты увидишь что модель "достроила" сама — и сможешь скорректировать до выполнения задачи. Особенно ценно для сложных задач с неочевидными ограничениями.
🔧 Техника: Лёгкий режим — только нужные ключевые слова
Не обязательно использовать все %-директивы. PromptMN работает даже если добавить %mustnot и %out к обычному промпту:
Напиши пост для Telegram-канала про наш новый продукт.
%mustnot упоминать цену и конкурентов по имени;
%out пост до 800 знаков, с эмодзи, без кнопки "купить";
Это уже решает главную проблему — явный запрет и явный формат. Весь остальной промпт — обычная проза.
Ресурсы
- Работа: PromptMN: Pseudo Prompting Language — Enkhzol Dovdon, ICT Group
- Репозиторий с полной спецификацией и примерами: github.com/denkhzol/PromptMN
- Связанные методы из статьи: ReAct (рассуждение + действие), Chain-of-Thought, Super-NaturalInstructions, псевдокод-промптинг (Mishra et al., Kumar et al.), MEMENTO