Подборка паттернов промптинга, которые помогают получать понятную архитектуру, стабильные интерфейсы и меньше переписывать код после правок требований.
ИИ редко «ошибается из вредности» — чаще он честно заполняет пробелы в запросе. Если контекст неполный, цели размыты, а ограничения не названы, модель начинает угадывать: придумывает недостающие детали, выбирает привычные паттерны и «улучшает» систему на свой вкус. В результате вы получаете решение, которое выглядит убедительно, но плохо стыкуется с реальностью проекта — и начинается переписывание.
Неполный контекст. Нет текущей архитектуры, не указаны границы ответственности сервисов, неясно, что уже существует и что менять нельзя.
Размытая цель. Фраза вроде «сделай чистую архитектуру» без уточнения приоритетов (скорость разработки, тестируемость, стоимость поддержки, сроки) приводит к тому, что ИИ оптимизирует «в среднем по больнице».
Скрытые ограничения. Например: нельзя добавлять новые базы данных, запрещены фоновые задачи, есть легаси‑протокол, команда не использует определённый язык/фреймворк. Если это не проговорить, модель предложит лишние компоненты.
Вы видите, что модель:
Успех — это не «идеальная архитектура в вакууме», а согласованная структура: понятные границы модулей и интерфейсов, минимальное число итераций и ясные контракты. То есть: что принимает/возвращает каждый слой, какие данные хранятся, где проходят транзакции, что считается источником истины.
Запрос «напиши код» уместен, когда решение уже выбрано. Архитектурный промпт нужен раньше: чтобы зафиксировать цели, ограничения и критерии приёмки, сравнить варианты и договориться о структуре — и только потом переходить к реализации и кодингу.
Главная причина лишних переделок — модель начинает проектировать «в вакууме»: угадывает домен, пользователей и ограничения, а затем вы уточняете детали, и архитектуру приходится разворачивать обратно. Чтобы с первого шага получать пригодные решения, подготовьте короткий пакет контекста.
Дайте 8–12 строк, которые задают рамки:
Такой «паспорт» помогает модели не предлагать архитектуру уровня корпорации там, где важнее скорость поставки.
В двух списках обозначьте:
Anti-scope особенно полезен: он предотвращает советы «с запасом», которые потом не применяются.
Если есть — перечислите и кратко опишите:
Даже неполный набор снижает количество предположений и спорных мест.
Дайте самое стабильное: цели, границы, ограничения, 1–2 примера данных. Детали (полные логи, все таблицы, весь код) — по запросу. Хорошая практика: «коротко сейчас, расширю по вопросам».
Ты архитектор. Перед тем как предлагать решение, задай до 12 уточняющих вопросов.
Сгруппируй их по темам: цели, пользователи/сценарии, границы системы (входит/не входит),
данные и интеграции, ограничения (время/бюджет/стек), нефункциональные требования.
Если информации уже достаточно — напиши "вопросов нет" и перечисли принятые допущения.
Вот карточка проекта: <вставьте 8–12 строк>
Вот границы (scope/anti-scope): <вставьте>
Имеющиеся артефакты: <перечень/ссылки>
После ответов на эти вопросы следующий запрос можно формулировать гораздо точнее — и правок станет заметно меньше.
Когда вы просите LLM «придумать архитектуру», она часто отвечает как универсальный советчик: добавляет лишние технологии, расширяет функциональность и расплывается в эссе. Паттерн «Роли и границы» делает запрос управляемым: вы заранее задаёте, кто отвечает, что можно предлагать, что нельзя и в каком виде вы хотите получить результат.
Задайте 2–4 роли и явно попросите их спорить между собой коротко и по делу. Примеры ролей:
Роли здесь не «для театра», а для самопроверки решения с разных сторон, чтобы модель не «уезжала» в одну плоскость.
Формулируйте ограничения как «запреты» и «разрешения»:
Попросите один из форматов, которые сложно «размыть»:
Роли:
- Архитектор
- Инженер по качеству
- Продукт
- Безопасность
Задача: <что нужно спроектировать/решить>
Контекст: <кратко про систему, ограничения, текущие боли>
Ограничения:
- Не выдумывай технологии: <список>
- Не добавляй функции без требований
- Если данных недостаточно — задай до 5 вопросов
Формат ответа:
1) Варианты (2–3)
2) Рекомендация
3) Риски и проверки
Критерии качества:
- Минимум новых сущностей
- Ясные границы модулей
- Обратимая миграция/изменения
Этот паттерн особенно полезен, когда вам нужен не «самый умный ответ», а предсказуемое решение, которое можно обсудить, согласовать и реализовать без лишних переделок.
Если в запросе есть только «сделай сервис Х», модель почти неизбежно додумывает детали: выбирает стек, упрощает безопасность, игнорирует сроки. Результат выглядит правдоподобно, но в вашем проекте быстро ломается — и начинается переписывание. Этот паттерн дисциплинирует диалог: сначала фиксируем, что нужно, затем в каких рамках, и только потом — как поймём, что готово.
Разделяйте требования по уровню обязательности. Так модель перестаёт «оптимизировать» важное ради второстепенного.
Это не «детали», а границы проектирования. Укажите хотя бы ключевые:
Просите формулировать проверки так, чтобы их можно было подтвердить тестами, метриками или ревью архитектуры.
Примеры критериев:
Добавьте явную инструкцию: найти противоречия и задать уточняющие вопросы до предложения финального решения. Это дешевле, чем правки после.
Ниже — удобный формат «Требование → Почему важно → Как проверим».
Контекст: <1–3 предложения о продукте и пользователях>
Требования:
Must:
- <Требование> → Почему важно: <…> → Как проверим: <метрика/тест/ревью>
- ...
Should:
- ...
Could:
- ...
Ограничения:
- Инфраструктура: ...
- Лицензии/комплаенс: ...
- Производительность: ...
- Сроки: ...
Задача модели:
1) Найди противоречия/дыры в требованиях и ограничениях.
2) Сформулируй 5–10 уточняющих вопросов (по приоритету).
3) Предложи решение, явно привязав каждый пункт к Must/Should и критериям приёмки.
Такой «контракт на входе» делает ответы проверяемыми и снижает шанс, что архитектура поедет в сторону уже на втором уточнении.
Когда вы просите ИИ «сделай сервис/модуль», он часто сразу уходит в детали кода и выбирает структуру наугад. Паттерн «Схема до реализации» заставляет сначала согласовать каркас: какие части системы существуют, как они общаются и какие данные живут внутри. Это снижает риск переписываний, потому что вы правите не реализацию, а схему.
Сначала попросите перечислить компоненты и их роли: UI/API, прикладные сервисы, адаптеры к внешним системам, хранилища, очереди, планировщики. Важно: без классов и методов — только границы и ответственность.
Дальше — потоки. Минимум три:
Так вы рано обнаружите, где нужны транзакции, события, дедупликация и наблюдаемость.
Отдельным запросом: сущности, связи, состояния, что является источником истины, как данные создаются/обновляются/архивируются. Это помогает избежать «внезапных» миграций и конфликтов доменных понятий.
Попросите 1–2 представления на выбор: таблица компонентов, последовательность шагов, Mermaid‑диаграмма.
flowchart LR
UI[Клиент] --> API[API]
API --> SVC[Сервис]
SVC --> DB[(БД)]
SVC --> MQ[(Очередь)]
MQ --> WORKER[Воркер]
В конце задайте: «Какие части можно заменить без каскадных правок, и за счёт каких интерфейсов/контрактов?» Если ответ расплывчатый — схема ещё не зафиксирована, и рано переходить к реализации.
Этот паттерн нужен, чтобы ИИ не «размазал» ответственность по проекту и не заставил вас потом переносить логику из контроллеров в сервисы, из сервисов — в домен, а затем обратно. Вы заранее фиксируете правила слоёв и просите модель проверять любые решения через призму зависимостей.
В промпте задайте четыре слоя и их роль:
Просите модель выдать не только текст, но и матрицу «кто кого может вызывать/импортировать». Например:
| Слой → может зависеть от | Домен | Приложение | Инфраструктура | Интерфейсы |
|---|---|---|---|---|
| Домен | ✓ | ✗ | ✗ | ✗ |
| Приложение | ✓ | ✓ | ✗* | ✗ |
| Инфраструктура | ✓** | ✓ | ✓ | ✗ |
| Интерфейсы | ✓ | ✓ | ✓ | ✓ |
* вместо прямой зависимости — через порты/интерфейсы.
** инфраструктура может реализовывать доменные/прикладные порты, но домен не должен её импортировать.
Сформулируйте их как жёсткие ограничения:
Чтобы изменения не ломали структуру, попросите примеры:
UserRepository, PaymentGateway, Clock, EventPublisher.В конце промпта добавьте требование: «Объясни, какие переделки мы избегаем благодаря правилам слоёв». Хороший ответ привяжет выгоду к практике: смена БД не трогает домен, замена транспорта (HTTP → очередь) не ломает юзкейсы, а тесты пишутся без поднятия инфраструктуры — значит, меньше “перетаскиваний” кода и неожиданных циклических зависимостей.
Главная причина переделок — когда реализация появляется раньше договорённостей. Модель генерирует «красивый» код, а потом выясняется, что другим модулям нужен другой формат данных, другие ошибки, другие события. Паттерн «интерфейсы сначала» переворачивает порядок: сначала фиксируем контракты, затем разрешаем писать реализацию.
Попросите ИИ описать публичные интерфейсы модулей и границы ответственности: какие методы доступны, какие DTO (структуры входа/выхода) используются, какие события публикуются/подписываются, какие классы ошибок возможны.
Важно явно задать требование стабильности: «не меняй контракты без миграционного плана». Тогда любые правки будут оформляться как версия, адаптер или совместимый режим, а не как ломающее изменение.
Чтобы контракт был проверяемым, запросите 3–5 примеров «запрос → ответ» (или «вход → выход») для основных пользовательских сценариев и одного‑двух негативных кейсов (ошибка валидации, отсутствие доступа). Примеры часто выявляют спорные места раньше реализации: где нужна идемпотентность, какие поля обязательны, как формулировать сообщения об ошибках.
Сразу определите, как вводите изменения:
Сгенерируй публичные интерфейсы модулей, DTO, события и список инвариантов.
Без кода реализации.
Укажи возможные ошибки и правила версионирования.
Не меняй контракты без миграционного плана.
Дай 5 примеров вход/выход для ключевых сценариев.
Этот подход делает изменения управляемыми: вы обсуждаете договорённости один раз, а переписывания сводятся к точечным адаптерам и понятным миграциям.
Одна из причин бесконечных правок — когда ИИ выдаёт «единственно правильное» решение, а позже выясняется, что оно не вписывается в сроки, командные навыки, бюджет, ограничения инфраструктуры или требования безопасности. Паттерн «Варианты и компромиссы» заставляет модель сразу думать как архитектор: предлагать несколько путей и явно показывать цену каждого.
Просите 2–3 варианта решения и фиксируйте оси сравнения. Рабочая формула: «Дай 3 варианта (быстро внедрить / сбалансировано / максимально надёжно) и сравни по сложности, рискам, скорости внедрения, влиянию на поддержку».
Важно сразу задать «рамку выбора»: ваши ограничения (например, нельзя добавлять новые сервисы, ограничен бюджет на инфраструктуру, команда знает только определённый стек) и критерии приёмки (SLO, время отклика, требования аудита, обратная совместимость).
Попросите явный раздел: «Технические риски и как их снизить». Это помогает отсеять варианты, которые красиво выглядят на схеме, но ломаются на миграциях, наблюдаемости, нагрузке или данных.
Пример формулировки: «Для каждого варианта перечисли 3–5 рисков, вероятность/влияние и конкретные меры снижения (тесты, фичефлаги, поэтапный rollout, мониторинг)».
Добавьте требование: «В конце перечисли предположения, которые ты считаешь истинными, и вопросы, которые нужно подтвердить». Так вы быстро увидите, где модель “додумала” за вас: объёмы трафика, консистентность данных, доступность очередей, права на изменение схемы БД.
Попросите финальный вывод в формате: «Если приоритет X и ограничения Y, выбираем вариант №… потому что…». Тогда рекомендация будет не абстрактной, а привязанной к вашим условиям — и правок станет заметно меньше.
Когда вы просите ИИ «сделать по‑другому», он часто предлагает переписать половину системы — просто потому, что ему проще мыслить целостной картиной. Этот паттерн переключает фокус на управляемые изменения: минимум правок, предсказуемое внедрение и (если нужно) безопасную миграцию данных и контрактов.
Используйте структуру: «что меняем → почему → минимальный дифф → шаги внедрения».
Пример формулировки:
Сразу задайте рамки, иначе ИИ «оптимизирует» лишнее.
Хорошая формулировка: «Можно менять только модули A и B, и только добавлением новых файлов/классов; модуль C и публичные DTO не трогать; сигнатуры внешних API оставить прежними». Если допустимы исключения — попросите их явно перечислить и обосновать.
Если изменение касается БД, событий или API‑контрактов, попросите:
Цель — не «идеальная схема», а безопасный переход.
Попросите результат в виде списка задач для трекера: маленькие, проверяемые, в правильном порядке (подготовка → внедрение → переключение → чистка).
Отдельным пунктом запросите обновления: какие разделы документации поправить, какие примеры/сниппеты устареют, какие тестовые сценарии добавить. Это снижает вероятность ситуации «всё работает, но никто не знает как».
Даже хороший запрос часто даёт «правдоподобный» ответ с незаметными изъянами: зависимость идёт не в тот слой, контракт не согласован, ошибки замалчиваются. Паттерн «Самопроверка» решает это простым приёмом: вы просите модель сначала выступить в роли ревьюера, а уже затем — внести правки по найденным проблемам.
Попросите отдельный блок проверки по чек‑листу и запретите «мягкие формулировки». Удобный формат — «проблема → влияние → исправление».
Проведи самопроверку решения.
1) Проверь на противоречия требованиям и критериям приёмки.
2) Пройди чек-лист: слои, зависимости, контракты, обработка ошибок.
3) Укажи пограничные случаи: таймауты, ретраи, частичные сбои.
Формат вывода строго: Проблема → Влияние → Исправление.
После списка проблем дай исправленную версию решения.
Попросите модель явно подтвердить пункты:
Добавьте явное требование к тестам: какие нужны (юнит, интеграционные, контрактные — по необходимости) и что именно они доказывают. Отдельно запросите анализ углов: таймауты внешних сервисов, ретраи с backoff, идемпотентность, частичные сбои и восстановление.
Этот паттерн особенно полезен, когда вы хотите уменьшить правки: сначала находите расхождения, затем просите минимальные изменения, закрывающие конкретные пункты чек‑листа.
Главная причина лишних переписываний — вы начинаете улучшать «как написано», не договорившись «что именно строим». Двухпроходное ревью разделяет эти задачи: сначала проверяем архитектуру и границы, а уже потом — качество реализации. Такой порядок снижает риск, что вы отполируете код, который завтра придётся выкинуть из‑за неверных слоёв или контрактов.
На этом этапе вы обсуждаете не строки кода, а структуру решения. Попросите ИИ оценить:
Ключевое правило промпта: «если архитектура не согласована — не переходи к реализации». Это дисциплинирует: модель не «убегает» в программирование, пока вы не приняли решения по границам и контрактам.
Дополнительно полезно просить подсветить места будущих правок при росте требований. Например: «какие компоненты сломаются, если появятся роли пользователей», «что изменится при росте нагрузки в 10 раз», «где понадобится кэш/очередь/пагинация».
Только после того, как структура принята, переходите к деталям исполнения. В этом проходе фокус на:
Используйте, когда хотите заранее найти «минные поля»:
«Сделай ревью в 2 прохода. Проход 1 — архитектура: границы, слои, контракты, потоки данных. Проход 2 — реализация: читабельность, дублирование, обработка ошибок, тестируемость. Если архитектура не согласована — не переходи к реализации. Найди 10 причин, почему это придётся переписать, и предложи, как предотвратить каждую.»
Эта техника особенно хорошо работает как регулярный ритуал: вы получаете предсказуемый формат обратной связи и меньше “сюрпризов” на этапе изменений.
Ниже — набор «скелетов» промптов, которые удобно копировать и заполнять переменными. Держите их в одном месте (например, на внутренней странице /docs/prompts), чтобы команда использовала одинаковый формат входных данных и результата.
Ты — {роль}. Домен: {домен}. Цель: {цель}. Текущее состояние: {как сейчас}. Ограничения: {время/бюджет/стек/регуляторика}. Риски: {известные}. Задай до 7 уточняющих вопросов, затем предложи 2 варианта решения и что нужно проверить.
Опиши архитектуру для {фича} в {система}. Формат вывода:
- Компоненты (список)
- Потоки данных (кто → куда → что)
- Хранилища и ключевые сущности
- Границы доверия/безопасности
- Набор решений (ADR) с причинами
Спроектируй контракты для {интеграция}. Дай:
- эндпоинты/топики, поля, типы
- ошибки и коды
- идемпотентность/версирование
- примеры запрос/ответ Укажи, какие изменения будут обратно совместимыми.
Преобразуй {сырой текст/задача} в:
- Требования (must/should/could)
- Ограничения
- Критерии приёмки (проверяемые)
- Негативные кейсы Если данных не хватает — перечисли пробелы.
Предложи план внедрения {изменение}. Дай:
- минимальный набор правок по модулям
- миграции/скрипты
- флаги/поэтапный релиз
- откат
- тесты, которые надо добавить
Проведи ревью {PR/фрагмент кода/дизайн}. Сначала структура: границы модулей, зависимости, контракты. Потом детали: читаемость, ошибки, тесты. Формат: «Найдено → Почему важно → Как исправить → Приоритет».
Минимальный набор: {домен}, {цель}, {аудитория/пользователь}, {ограничения}, {не делать}, {формат вывода}, {уровень детализации} (черновик/план/спека).
Зафиксируйте в /docs/prompts обязательные поля для запроса и единый формат ответа (например, «Вопросы → Варианты → Рекомендация → Риски → Следующие шаги»).
Эффект удобно измерять простыми метриками: число итераций до принятого решения, объём переделок (строки/файлы/время), частота изменений публичных интерфейсов и количество багов на интеграциях после релиза.
Если вы используете TakProsto.AI как платформу для vibe‑coding, эти паттерны дают максимальный эффект именно за счёт «договорённостей до реализации». Практический подход такой:
Отдельно, для проектов с требованиями к хранению данных, важно, что TakProsto.AI работает на серверах в России и использует локализованные/opensource LLM‑модели — без отправки данных за пределы страны. А если вы хотите снизить стоимость экспериментов, можно стартовать с бесплатного тарифа и перейти на pro/business/enterprise по мере роста; также у платформы есть программы получения кредитов за контент и реферальные приглашения.
ИИ заполняет пробелы в запросе правдоподобными допущениями: домысливает доменную модель, выбирает «типовой» стек и добавляет компоненты «на всякий случай». Когда вы уточняете реальный контекст (границы, запреты, существующие контракты), эти допущения рушатся — и решение приходится переделывать.
Практика: сначала фиксируйте цели, ограничения и критерии приёмки, а уже потом просите варианты архитектуры.
Минимум, который даёт большой эффект:
Этого достаточно, чтобы модель меньше «угадывала» и реже предлагала лишнее.
Признаки, что промпт недостаточно точный:
Если видите такое — остановитесь и добавьте границы и запреты в запрос.
Успех — это согласованные границы и контракты, а не «идеальная архитектура в вакууме». Хорошие критерии:
Если это зафиксировано, дальнейший кодинг обычно идёт с меньшим числом итераций.
Просить «напиши код» стоит, когда вы уже приняли решения о:
До этого лучше просить варианты, компромиссы и вопросы на уточнение, иначе вы получите красивую реализацию неподходящего решения.
Scope/anti-scope снижает риск «разрастания» решения.
Практика: добавляйте anti-scope отдельным списком в каждый архитектурный промпт — это уменьшает вероятность, что модель добавит лишние интеграции или подсистемы.
Сформулируйте роли и попросите их коротко спорить по делу:
Дополнительно задайте границы: «не выдумывай технологии», «не добавляй функций без требований», «если данных мало — сначала вопросы».
Попросите модель оформить входные данные так:
Это превращает обсуждение из «впечатлений» в проверяемый контракт: что делаем, в каких рамках и как поймём, что готово.
Попросите сначала зафиксировать каркас, а не детали:
Выход просите в структурированном виде (таблица/список/диаграмма Mermaid). Пока каркас не принят — не переходите к программированию.
Запросите у модели:
Практический тест: попросите объяснить, какие переделки предотвратит такая структура (смена БД, смена транспорта, упрощение тестов).