Архитектурный промт для Gemini: как собирать запросы, которые понимает модель

Промт — это не вопрос, а чертеж

Gemini выдаёт то, что заложено в структуре запроса. Учитесь собирать промты как архитектор — по слоям, с точными спецификациями и допусками.

Структура запроса Контекст и роль Примеры кода

Почему обычные промты ломаются

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

Разница не в деталях, а в архитектуре промта. Модель не «понимает» смысл — она сопоставляет паттерны. Чёткая структура даёт чёткий паттерн.

Размытость

Модель выбирает среднее по обучающей выборке

Контекст

Роль, ограничения, формат выхода — не указаны

Конфликт

Противоречивые инструкции в одном запросе

Формат

Ответ приходит как текст, а нужен JSON или код

Анатомия архитектурного промта: 6 слоёв

1

Роль и экспертиза

СЛОЙ

Определите, кем является модель. Не «ты — помощник», а «ты — старший архитектор бюро с 15-летним опытом проектирования общественных зданий по стандартам LEED».

Role: Senior Architect, LEED AP Specialization: Public buildings, passive design Experience: 15+ years, 40+ completed projects Tone: Precise, regulatory-aware, constructible

Добавьте область ответственности: что входит в компетенцию, а что — нет. Это отсекает галлюцинации за пределами роли.

Границы роли (пример)

  • Концепция, планировка, фасад, системы
  • Не считаю конструкции — для этого структурник
  • Не подбираю оборудование — для этого ТГ-инженер
2

Контекст проекта

СЛОЙ

Входные данные, которые меняют всё: география, климат, нормативная база, этап проектирования, бюджет, сроки. Gemini не знает этого, если не сказать.

Site: Moscow, 55.75°N, urban infill, 12m width Climate: Dfb (humid continental), HDD 4500 Codes: SP 54.13330, SP 50.13330, local MGSN Stage: Concept design (stage P) Budget: 120k RUB/m² construction cost Timeline: 8 weeks to package

Правило: один проект — один контекст-блок. Копируйте его в каждый новый чат сессии. Не заставляйте модель угадывать широту и нормативы.

Шаблон контекста

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]
}
3

Задача и декомпозиция

СЛОЙ

Большую задачу разбивают на атомарные шаги. Модель лучше выполняет последовательность малых инструкций, чем один монолитный запрос.

Task: Develop concept package for residential building Steps: 1. Site analysis diagram (solar, wind, views, noise) 2. Massing options (3 variants, FAR compliance) 3. Unit mix & typical floor plates (efficiency >82%) 4. Facade strategy (material, window ratio, shading) 5. Sustainability narrative (passive + active) 6. Phasing & cost logic Deliverable per step: structured markdown + mermaid diagram

Используйте Chain-of-Thought явно: «рассуждай пошагово, показывай промежуточные выводы». Для архитектуры это критично — решение принимается на этапе массового моделирования, а не в фасаде.

✓ Хорошо

«Сгенерируй 3 варианты массовки. Для каждого: FAR, покрытие, ориентация, insolation. Выбери оптимальный по критериям…»

✗ Плохо

«Сделай лучшую планировку дома»

4

Ограничения и правила

СЛОЙ

Жёсткие рамки (hard constraints) и мягкие предпочтения (soft preferences). Модель должна знать, где нарушить нельзя, а где можно балансировать.

Hard: Max height 18m, FAR ≤ 2.5, setback 3m/5m Hard: Min 50% units dual-aspect, corridor ≤ 18m Hard: WWR 30-40%, U-value ≤ 1.2 W/m²K Soft: Prefer brick facade, courtyard typology Soft: Target BREEAM Excellent Soft: Modular grid 6m × 6m preferred

Формулируйте ограничения измеримо. «Достаточно света» — бесполезно. «Коэффициент естественной освещенности ≥ 1.5% в жилых» — рабочее правило.

Паттерн записи ограничений

Constraint {
  parameter: "WWR"
  type: "range"
  value: [0.30, 0.40]
  source: "SP 52.13330 §7.2"
  priority: "hard