За последнее время большие языковые модели (LLM) стали привычным инструментом для анализа и работы с текстом. Но, что важно, качество ответа зависит не только от самой модели, но и от того, как именно задан запрос.

Обычно промт строят по проверенной схеме: задать роль («представь, что ты эксперт»), дать инструкцию, что и как сделать («сделай краткое резюме»), указать ограничения и уточнить формат (объём, стиль, язык), добавить входные данные и, если есть, пример ответа.

Однако, такой подход не всегда дает нужный ответ в творческих задачах. Заданная «роль» сужает поиск решений; инструкция «как сделать», может навязывать неоптимальный метод или ограничивать варианты поиска более подходящих. А неполное описание задачи (даже то, что кажется очевидным) нередко вынуждает модель придумывать и выдавать галлюцинации.

Цель этой статьи-размышления - предложить альтернативную структуру архитектурного промта, которая не заменяет, а расширяет и дополняет существующие практики. Я попробую показать, как можно сместить акцент с «роли» на логику рассуждений, и добавить метрики - критерии корректности ответа. Такой подход делает прозрачным не только итоговый ответ, но и сам процесс его построения.

Дисклеймер: Я не разработчик. Всё, о чём здесь написано, мой практический опыт работы с языковыми моделями. Это личный метод, который показал результат.

1. Мотивация для расширения

1.1. Ограничения классических практик

• Роль как ограничитель. Когда промт задаёт роль («ты — эксперт»), модель усиливает вероятностные ассоциации с этой ролью. Как правило, это работает в прикладных задачах, но в исследовательских и творческих случаях я часто упиралась в ограничение среднестатистического ответа по области, задаваемой ролью и потерю кросс‑дисциплинарных связей.

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

• Неточность входных данных. Если задать неполный контекст, модель будет «додумывать» пропуски. Это часто ведёт к фактическим ошибкам.

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

1.2. Логика предлагаемого расширения

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

Вместо инструкции «как делать» я пишу в промте только «что сделать»: модель получает цель и связи входов‑выходов, но сама выбирает оптимальный маршрут решения. Так я получаю несколько вариантов вместе с их анализом.

Добавление метрик внутри промта (что считать успехом, какие пункты запроса проверить) позволяет встроить самопроверку прямо в процесс генерации. Модель сверяется с запросом и проверяет соответствие ответу.

Таким образом, предложенный подход нацелен дополнение классического алгоритма промтинга:

• сохранить управляемость и предсказуемость;

• снизить количество выдуманных деталей;

• встроить критерии проверки;

• понять, как именно ИИ пришёл к результату.

2. Предлагаемая структура промта

2.1. Общая идея и элементы структуры

Смысл предлагаемой структуры промта в том, чтобы модель работала не только по «эталону ответа», но и по рамке мышления, которую пользователь задаёт в явном виде.

1. Контекст (входные данные)

• исходный материал: текст, код, описание области вопроса, собственные рассуждения.

• важно задавать контекст полно. Но пользователь может раскрывать детали по ходу - этого достаточно, чтобы модель могла начать работать.

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

Такой запрос не содержит полного контекста (текст статьи ещё не предоставлен), но уже задаёт область, цель и структуру диалога. Модель получает рамку: обзор → уточнение → редактирование.

Примечание: совпадает с классическими практиками (контекст всегда важен), но отличается тем, что не требует «вспомнить всё» — промт может начинаться с области или черновых мыслей.

2. Логика (правила обработки)

• описание, в какой логике думать, какие допущения допустимы, какие альтернативы стоит рассмотреть.

• заменяет «роль» на архитектурную рамку мышления.

Пример: «Строй рассуждение с маркировкой факта, гипотезы и идеи; допускай метафоры, но проверяй их на связность».

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

3. Инструкция (что сделать)

• постановка задачи в терминах цели, а не метода.

• вместо «как делать» (например, «реши через метод Х») - «что должно быть на выходе» (например, «найди варианты решения уравнения и объясни шаги»).

Например, есть логическое утверждение А. Если напрямую указывать, как сделать, возможны ошибки:
«Докажи утверждение А» → модель выдаёт доказательство.
«Опровергни утверждение А» → та же модель на то же утверждение строит опровержение.
Проблема в том, что модель не анализирует корректность утверждения, а подстраивается под инструкцию «как делать» («докажи» или «опровергни»), подгоняя логику под условие.

Пример: «Сформулируй возможные подходы к проверке утверждения «А». Рассмотри и покажи варианты доказательства, опровержения или альтернативной трактовки. Сравни и предложи наиболее обоснованный вариант.»

Примечание: модель перестаёт подгонять ответ под формулировку («докажи» / «опровергни») и вместо этого анализирует поле вариантов и связи между ними.

4. Метрика (критерии успеха)

• заранее заданные критерии проверки ответа на корректность, непротиворечивость и полезность.

Пример: «Ответ должен содержать маркировку: факт, гипотеза, идея. Обязательно проверь логику построения ответа - нет ли логических противоречий или логической подмены».

5. Примеры логики построения ответа

• привести несколько примеров, указать на поиск функционального сходства в них;

• показывать ИИ не только стиль ответа, но и пример логики (в том числе метафорический), чтобы задать траекторию reasoning.

Нюанс: потоковый пример в творческих и исследовательских областях.

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

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

2.2. Динамический характер архитектурного промта

• Контекст не обязан быть полным с первого шага. Пользователь может давать сырые или сомнительные соображения в привычном формате; задача модели - проверить факты и логику, выделить гипотезы, задать уточнения.

• Совместная итеративность. Архитектурный промт предполагает цикл:

  1. Пользователь задаёт исходный запрос.

  2. Модель формирует предварительный ответ с указанием пробелов и гипотез.

  3. Пользователь уточняет, ставит акценты, добавляет мысли.

  4. Модель дорабатывает ответ, опираясь на уточнённый контекст.
     

• Оптимальная глубина. По практическим наблюдениям, 2–4 повторения такого взаимодействия дают наилучший результат: ответ становится точным, связным и содержит меньше «галлюцинаций».
  

• Избежание избыточности. Метод нацелен на быстрое достижение устойчивой логики, а не на бесконечные переписки.

2.3. Чем полезно:

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

• Гибкость: модель ищет альтернативы.

• Прозрачность: встроенная метрика показывает, как строился ответ.

• Расширяемость: можно комбинировать с классическими форматами.

Классическая структура промта чаще предполагает статичную модель взаимодействия: пользователь задал вопрос — модель дала ответ. Я предпочитаю рассматривать запросы, как процесс согласования логики между пользователем и моделью. Итеративность становится встроенной частью метода, а не внешней практикой «править промт вручную».

3. Отличие и взаимодополняемость подходов

Общие выводы

• Классический промтинг остаётся оптимальным для прикладных задач, где важны скорость и предсказуемость.

• Архитектурный промтинг расширяет возможности в исследовательских и творческих сценариях: он усиливает прозрачность reasoning, снижает риск «галлюцинаций» и делает процесс диалоговым.

• Вместе оба подхода формируют гибкость методов: от формата → к архитектуре мышления, которую можно масштабировать под разные задачи

• Пользователь может формулировать запросы привычным для себя языком

Примеры использования

Пример 1. Совместное написание текущей статьи

Ситуация

Задача ставится не «сразу написать статью» и не вместо пользователя, а поэтапно: сначала вспомнить структуру классического промта, затем обсудить план, после этого последовательно прорабатывать введение, обзор, таблицы и кейсы. Каждый раздел рассматривается как отдельная задача.

Ход работы

1. На старте задается общая рамка рассуждений и черновые мысли.

2. Каждый блок обсуждается и дорабатывается отдельно.

3. Пользователь вносит уточнения.

4. Модель адаптирует логику на каждом шаге, сохраняя общую структуру и непрерывность смысла.

5. Итоговая логика текста собирается пошагово, без перегрузки.

Плюсы для пользователя:

• Не нужно готовить громоздкий промт «сразу обо всём».

• Каждый блок можно уточнять по ходу работы.

• Формулировки и акценты корректируются естественно, в процессе диалога-обсуждения.

Плюсы для модели:

• Итеративность снижает риск ошибок: уточнения сразу встроены в ход reasoning.

• Общая структура известна заранее, детали раскрываются постепенно.

• Важные элементы не теряются, как в длинных статичных промтах.

• Корректировки встроить проще - они идут модульно.

Результат

После 2–3 итераций каждый блок написан пользователем согласованно. В итоге получена статья без перегрузки контекста, с помощью ИИ, а не вместо пользователя.

Пример 2. Разработка плагина Obsidian (Markdown → RTF) архитектурным промтом

Ситуация

Нужна простая утилита для Obsidian: конвертировать заметку .md в формат, понимаемый текстовыми редакторами типа Word/LibraOffice, чтобы удобно открывать её в том числе на планшетах. Пользователь - не разработчик, поэтому решение должно быть максимально простым в установке и использовании.

Почему «одним промтом» не сработает

Запрос вида «напиши плагин» заставляет модель просто сгенерировать код «по вероятности». Проверки среды, сборки и критериев приёмки нет - и результат почти всегда ломается. Архитектурный промт, задаёт рамку: сначала план и критерии, потом шаги реализации, с обязательной самопроверкой и уточнениями по ходу.

Ход работы

1. Контекст

На вход подаётся задача и ограничения: «Obsidian (Win/macOS), выбрать вариант конвертера, минимальная установка, выбор места сохранения файла». Этого достаточно, чтобы очертить цель и условия.

2. Логика

Сначала модель уточняет параметры окружения: структура плагина, сборка, API Obsidian. Затем предлагает план из 5–7 шагов и критерии приёмки для каждого.

3. Инструкция

• Шаг A: создать каркас плагина с пустой командой. Критерий: плагин загружается.

• Шаг B: минимальный экспорт — генерируется .rtf с простым текстом. Критерий: файл создаётся.

• Шаг C: поддержка Markdown-разметки (заголовки, жирный/курсив, списки), настройка каталога вывода, лог ошибок.

4. Метрики

• M1: плагин включается без ошибок.

• M2: файл .rtf создаётся.

• M3: базовая разметка сохраняется.

• M4: цель достигается за несколько шагов уточнений.

5. Пример

• Загружен на анализ известный плагин конвертации в HTML.

Итеративность.

• Итерация 1: анализ окружения и нюансов + скелет.

• Итерация 2: рабочая команда + минимальный RTF.

• Итерация 3-4: добавление настроек + лог.

На каждом шаге пользователь тестировал плагин, а модель корректировала код по обратной связи.

Результат

Через 4 итерации получился стабильный плагин, проверенный в работе. Количество ошибок и «галлюцинаций» оказалось минимальным: каждое решение проверялось по критериям и уточнялось в процессе, а не в виде одного готового ответа.

Плагин доступен на GitHub. Не идеален, но функцию выполняет.

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