TL;DR
MAIA — техника, где AI не пытается угадать, что вы хотите, а по очереди предлагает варианты выбора («либо/или» с опцией «другое») и помечает каждую свою догадку как гипотезу, которую нужно подтвердить, прежде чем она попадёт в финальный документ.
Когда вы просите AI «напиши бриф дизайнеру» или «сформулируй, что мне нужно от подрядчика», модель либо выдаёт общие фразы, либо начинает придумывать детали, которые вы не называли — конкретный стиль, палитру, формат. Вы получаете красиво звучащий текст, но это не то, что вы хотели: модель заполнила пробелы своими дефолтами, а вы этого даже не заметили. Проблема глубже: у вас самих есть только чувство, образ в голове — а слов, чтобы его описать точно, нет.
MAIA решает это через четыре шага внутри одного диалога: фиксирует, что вы сказали → предлагает варианты того, что вы могли иметь в виду → сверяет своё же предположение перед тем как его произнести (одобрено / нужна правка) → задаёт вам вопрос в формате выбора. Каждая деталь получает метку: сказано явно, придумано (нужно подтвердить), или отдано на откуп исполнителю. Финальный документ собирается только из подтверждённых и явных пунктов.
Схема метода
ШАГ 1: Log & Distill → зафиксировать сырой ввод пользователя + краткую суть
ШАГ 2: Diagnose → предложить визуальные/технические термины, которые могут стоять за словами юзера (внутренний CoT-анализ)
ШАГ 3: Validate → проверить предложение шага 2: ОДОБРЕНО / НУЖНА_ПРАВКА (если правка — вернуться к шагу 2)
ШАГ 4: Respond → задать 1-2 вопроса юзеру в формате выбора (≥4 варианта + «другое»), обновить состояние
Цикл повторяется, пока все параметры не помечены ЯВНО или НА_УСМОТРЕНИЕ →
финальный документ собирается только из подтверждённых пунктов
Всё происходит в одном непрерывном диалоге, роли — это разные "режимы" одной модели, разделённые инструкциями.
Пример применения
Задача: Вы хотите заказать обложку для своего подкаста про стартапы у дизайнера на Кворке. У вас есть только смутное чувство: «что-то в стиле киберпанка, но не совсем, и чтобы было солидно, а не как у школьника». Вы боитесь, что если написать это дизайнеру напрямую — получите не то.
Промпт:
Ты работаешь со мной по методу "проверка важнее выдумки" — помогаешь
превратить моё смутное ощущение в конкретный бриф для дизайнера.
Роли, которые ты выполняешь по очереди в одном диалоге:
1. ДИАГНОСТ: анализируешь, что я написал, и предлагаешь конкретные
визуальные термины (стиль, цвета, композиция), которые МОГУТ стоять
за моими словами. Для каждого термина — короткое объяснение простыми
словами, без жаргона.
2. ВАЛИДАТОР: проверяешь предложения Диагноста. Если там есть деталь,
которую я НЕ говорил напрямую — она автоматически получает тег
ГИПОТЕЗА и должна быть у меня подтверждена, прежде чем попасть в
финальный бриф. Ничего не должно проскочить в финал без подтверждения.
3. СОСТАВИТЕЛЬ БРИФА: собираешь финальный текст только из пунктов
с тегами ЯВНО (я подтвердил) или НА_УСМОТРЕНИЕ (я разрешил решить
дизайнеру). Пункты с тегом ГИПОТЕЗА в финал не попадают.
Отслеживай 6 параметров: стиль, цветовая палитра, композиция,
настроение/тон, формат/размер, что можно отдать на откуп дизайнеру.
Каждый помечай: НЕ_ЗАТРОНУТО / ГИПОТЕЗА / ЯВНО / НА_УСМОТРЕНИЕ.
По каждому непроверенному пункту задавай мне вопрос в формате выбора:
минимум 4 варианта + "Другое (напишу сам)". Не больше 2 вопросов за раз.
Начинаем. Вот моя идея: "что-то в стиле киберпанка, но не совсем,
и чтобы было солидно, а не как у школьника".
Результат: Модель не выдаст сразу готовый бриф. Она разберёт вашу фразу на составляющие («киберпанк» → неоновые цвета? тёмная палитра? футуристичный шрифт? — уточнит), предложит 4-5 вариантов на каждый неясный параметр с опцией «другое», и только после того как вы пройдёте через 2-4 раунда вопросов-ответов — соберёт финальный текстовый бриф, где каждая деталь либо прямо от вас, либо явно отдана на откуп дизайнеру. Никаких «от себя добавленных» деталей в финале не будет.
Почему это работает
Когда вы даёте модели открытую задачу «напиши бриф», она не может оставить пробелы пустыми — ей нужно выдать связный текст. Поэтому она заполняет неизвестное своими дефолтными представлениями — тем, что чаще встречается в её обучающих данных. Это и называют «семантическим дрифтом»: итоговый текст звучит убедительно, но на деле описывает не вашу идею, а усреднённую идею модели.
При этом модель отлично умеет генерировать релевантные варианты выбора и придерживаться структуры, если её явно попросить об этом — вести внутренний «счётчик» состояния, помечать пункты тегами, не переходить к следующему шагу, пока предыдущий не закрыт.
Метод использует это так: одна «роль» модели предлагает, а другая — проверяет предложение на вопрос «это сказал юзер или я это придумала?». Это встроенный фактчекер внутри одного диалога, который не даёт домыслам модели попасть в финальный текст без вашего явного «да».
Рычаги управления: - Число вопросов за раз (2) → уменьшите до 1 для медленного, вдумчивого прохождения; увеличьте для быстрого прогона - Список параметров (стиль, цвет, композиция...) → замените под свою задачу: для ТЗ разработчику — функции, сроки, бюджет, приоритеты - Условие финализации (все теги ЯВНО/НА_УСМОТРЕНИЕ) → можно смягчить, разрешив закрыть бриф с парой ГИПОТЕЗ, если не критично - Названия ролей → замените на «Арт-директор», «Редактор», «Продюсер» — конкретные имена усиливают выполнение роли
Шаблон промпта
Ты работаешь со мной по методу "проверка важнее выдумки" — помогаешь
превратить моё смутное ощущение в конкретный документ для {задача}.
Роли, которые ты выполняешь по очереди в одном диалоге:
1. ДИАГНОСТ: анализируешь, что я написал, и предлагаешь конкретные
термины ({тип_параметров}), которые МОГУТ стоять за моими словами.
Для каждого — короткое объяснение простыми словами.
2. ВАЛИДАТОР: проверяешь предложения Диагноста. Если там есть деталь,
которую я НЕ говорил напрямую — она получает тег ГИПОТЕЗА и должна
быть подтверждена мной, прежде чем попасть в финальный документ.
3. СОСТАВИТЕЛЬ: собираешь финальный документ только из пунктов
с тегами ЯВНО (я подтвердил) или НА_УСМОТРЕНИЕ (я разрешил решить
исполнителю). Пункты с тегом ГИПОТЕЗА в финал не попадают.
Отслеживай параметры: {список_параметров}.
Каждый помечай: НЕ_ЗАТРОНУТО / ГИПОТЕЗА / ЯВНО / НА_УСМОТРЕНИЕ.
По каждому непроверенному пункту задавай вопрос в формате выбора:
минимум 4 варианта + "Другое". Не больше 2 вопросов за раз.
Начинаем. Вот моя идея: {ваша_смутная_идея}
Подставьте: {задача} — что вы формулируете (бриф, ТЗ, запрос), {тип_параметров} — категория деталей (визуальные, технические, функциональные), {список_параметров} — 5-8 конкретных пунктов важных для вашей задачи, {ваша_смутная_идея} — то, что у вас есть на старте.
🚀 Быстрый старт — вставь в чат:
Вот шаблон MAIA (метод выявления требований через проверку гипотез).
Адаптируй под мою задачу: {твоя задача — например, «нужен бриф для
свадебного фотографа, но я не знаю как объяснить чего хочу»}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие параметры важны для вашей конкретной задачи и в какой роли лучше выступить каждому «агенту» — потому что от типа задачи зависит, что стоит отслеживать (визуальные детали для дизайна ≠ функции для разработки).
Ограничения
⚠️ Медленнее, чем прямой запрос: метод растягивает получение результата на несколько раундов вопросов-ответов. Если нужен быстрый результат «здесь и сейчас» — это не для вас.
⚠️ Только текст, без картинок: исследователи специально не подключали генерацию изображений — показ готовой картинки слишком рано «перезаписывает» ваше смутное представление своим вариантом. Если добавить визуал раньше времени, метод теряет смысл.
⚠️ Проверено на маленькой группе: эксперимент на 16 участниках показал большой и значимый эффект на «ощущение что тебе помогли разобраться», но некоторые другие метрики (чувство «владения» результатом) улучшения не показали — вероятно, потому что в транзакционных заказах людям важен результат, а не процесс.
⚠️ Не для тех, у кого уже есть чёткое видение: метод создан для ситуации «чувствую, но не могу сформулировать». Если у вас уже готовый бриф в голове — этот процесс будет лишним трением.
Ресурсы
MAIA (Multi-Agent Intent Articulation) — Yu-Chao Wang, Yanhong Lu, Yingjie Victor Chen, Tim McGraw, Purdue University. Принято на IEEE AIxHEART 2026. Система реализована на OpenCode Desktop с моделью MiniMax M2.5; ключевой принцип статьи — правило «Verification over Invention» («проверка важнее выдумки»).