Промт — это не вопрос, а чертеж
Gemini выдаёт то, что заложено в структуре запроса. Учитесь собирать промты как архитектор — по слоям, с точными спецификациями и допусками.
Почему обычные промты ломаются
Запрос «сделай красивый дом» даёт картинку. Запрос «спроектируй двухэтажный дом 150 м² на узком участке с южной ориентацией, пассивным охлаждением и модульной структурой» даёт черновик технического задания.
Разница не в деталях, а в архитектуре промта. Модель не «понимает» смысл — она сопоставляет паттерны. Чёткая структура даёт чёткий паттерн.
Размытость
Модель выбирает среднее по обучающей выборке
Контекст
Роль, ограничения, формат выхода — не указаны
Конфликт
Противоречивые инструкции в одном запросе
Формат
Ответ приходит как текст, а нужен JSON или код
Анатомия архитектурного промта: 6 слоёв
Роль и экспертиза
Определите, кем является модель. Не «ты — помощник», а «ты — старший архитектор бюро с 15-летним опытом проектирования общественных зданий по стандартам LEED».
Добавьте область ответственности: что входит в компетенцию, а что — нет. Это отсекает галлюцинации за пределами роли.
Границы роли (пример)
- Концепция, планировка, фасад, системы
- Не считаю конструкции — для этого структурник
- Не подбираю оборудование — для этого ТГ-инженер
Контекст проекта
Входные данные, которые меняют всё: география, климат, нормативная база, этап проектирования, бюджет, сроки. Gemini не знает этого, если не сказать.
Правило: один проект — один контекст-блок. Копируйте его в каждый новый чат сессии. Не заставляйте модель угадывать широту и нормативы.
Шаблон контекста
ProjectContext {
location: {city, lat, lon, urban/rural}
climate: {zone, HDD/CDD, wind, snow}
regulations: [code_list]
stage: concept|schematic|DD|CD
constraints: {budget, timeline, footprint, height}
stakeholders: [client, consultants, authorities]
}
Задача и декомпозиция
Большую задачу разбивают на атомарные шаги. Модель лучше выполняет последовательность малых инструкций, чем один монолитный запрос.
Используйте Chain-of-Thought явно: «рассуждай пошагово, показывай промежуточные выводы». Для архитектуры это критично — решение принимается на этапе массового моделирования, а не в фасаде.
✓ Хорошо
«Сгенерируй 3 варианты массовки. Для каждого: FAR, покрытие, ориентация, insolation. Выбери оптимальный по критериям…»
✗ Плохо
«Сделай лучшую планировку дома»
Ограничения и правила
Жёсткие рамки (hard constraints) и мягкие предпочтения (soft preferences). Модель должна знать, где нарушить нельзя, а где можно балансировать.
Формулируйте ограничения измеримо. «Достаточно света» — бесполезно. «Коэффициент естественной освещенности ≥ 1.5% в жилых» — рабочее правило.
Паттерн записи ограничений
Constraint {
parameter: "WWR"
type: "range"
value: [0.30, 0.40]
source: "SP 52.13330 §7.2"
priority: "hard