Каждый разработчик сталкивался с этим: пишешь в ChatGPT или Claude «напиши функцию валидации email» — получаешь что-то общее, с regex из 2010 года и без учёта твоего стека. Проблема не в модели. Проблема в том, что мы общаемся с LLM как с коллегой по Slack, а не как с исполнителем, которому нужен точный бриф.
Промпт-инжиниринг — это не «магия слов». Это инженерия контекста: роль, ограничения, формат вывода, примеры и цепочка рассуждений. Ниже — 12 формул, которые я использую ежедневно. Каждая проверена на реальных задачах: от рефакторинга до генерации тестов и разбора инцидентов.
1. Формула роли и контекста (Role + Context)
Проблема: модель не знает, что ты senior Python-разработчик в финтехе, а не студент. Решение — явно задать роль, стек и ограничения.
Ты — senior backend-разработчик на Python 3.12 (FastAPI, PostgreSQL, SQLAlchemy 2.0).
Контекст: микросервис платежей, нагрузка 500 RPS, критична идемпотентность.
Задача: предложи схему таблицы для идемпотентных платежей.
Ограничения: без ORM-магии, только явные constraints, миграции через Alembic.
Формат: SQL DDL + 3 строки обоснования.
Результат: вместо абстрактной таблицы — конкретный DDL с UNIQUE-индексом на idempotency_key и объяснением, почему это важно при ретраях.
2. Few-shot: три примера вместо десяти инструкций
Модели лучше улавливают паттерн из примеров, чем из описаний. Формула: 2–3 пары «вход → выход» в нужном формате.
Преобразуй сообщение об ошибке в короткий код инцидента.
Пример 1: "Connection refused to db-primary:5432" → DB_CONN_REFUSED
Пример 2: "JWT expired at 2026-10-01" → AUTH_TOKEN_EXPIRED
Пример 3: "Timeout waiting for payment gateway" → PAY_GW_TIMEOUT
Теперь: "Redis cluster node 3 unreachable" →
Модель выдаёт REDIS_NODE_UNREACHABLE в том же стиле. Без примеров она начала бы объяснять ошибку текстом.
3. Chain-of-Thought: заставь думать пошагово
Для задач с логикой (дебаг, оценка рисков, планирование) добавь требование рассуждать поэтапно. Это снижает количество галлюцинаций.
Проанализируй этот stack trace шаг за шагом:
1) Определи тип исключения и модуль.
2) Найди вероятную причину (данные, гонка, конфиг).
3) Предложи 2 гипотезы и способ проверки каждой.
4) Дай минимальный фикс.
Stack trace: <...>
Важно: проси рассуждение до ответа, а не после. Иначе модель подгоняет логику под уже озвученный вывод.
4. Формула ограничений и анти-примеров (Negative Prompt)
Скажи не только что делать, но и чего не делать. Это резко повышает точность.
Сгенерируй unit-тесты на pytest для функции calculate_fee.
НЕ используй: моки на уровне БД, sleep, случайные данные без seed.
НЕ пиши тесты, которые проверяют реализацию, а не поведение.
Обязательно: parametrize, edge cases (0, отрицательные, float-погрешность).
5. Формат вывода как контракт
Если ответ должен идти в пайплайн — задай схему. JSON, таблица, diff — что угодно, но явно.
Верни только JSON без markdown-обёртки:
{"severity": "low
|medium|high", "cwe": "CWE-XXX", "fix": "строка", "confidence": 0.0-1.0}
Не добавляй пояснений вне JSON.
6. Декомпозиция задачи (Divide and Conquer)
Большие задачи модель решает хуже. Разбей на шаги и попроси выполнить только текущий.
Шаг 1 из 3: только спроектируй интерфейс модуля (сигнатуры функций, типы).
Не пиши реализацию. Дождись моего «дальше».
7. Self-consistency: попроси альтернативы
Для архитектурных решений проси 3 варианта с плюсами и минусами — так ты видишь пространство решений, а не один ответ.
Предложи 3 подхода к кэшированию сессий: Redis, in-memory LRU, sticky sessions.
Для каждого: latency, сложность, отказоустойчивость. Сведи в таблицу.
8. Ревью собственным ответом (Self-critique)
Двухшаговый промпт: сначала решение, потом критика этого решения той же моделью.
Шаг 1: напиши SQL-запрос для отчёта.
Шаг 2: проверь его на: индексы, N+1, корректность NULL, SQL-инъекции. Найди минимум 2 проблемы.
Шаг 3: выдай исправленную версию.
9. RAG-контекст с цитированием
Когда даёшь документы — требуй ссылаться на фрагменты. Это отсекает выдумки.
Ответь, используя ТОЛЬКО текст ниже. После каждого утверждения укажи [абзац N].
Если ответа нет в тексте — напиши "НЕТ В ИСТОЧНИКЕ".
Текст: <...>
10. Персона-критик (Red Team)
Полезно для security-ревью: попроси модель атаковать собственный код.
Ты — пентестер. Найди 5 способов сломать этот endpoint: IDOR, инъекции, rate limit, SSRF, утечка данных в логах. Для каждой — конкретный запрос и ожидаемый результат.
11. Температура и повторяемость
Промпт не работает без настройки параметров. Для кода и классификации — temperature 0–0.2. Для брейншторма — 0.7+. В API OpenAI параметр temperature, в Anthropic — temperature в Messages API. Это не «мелочь»: при 0.9 один и тот же промпт даёт разные структуры JSON.
12. Итеративный бриф (Prompt Refinement Loop)
Финальная формула: попроси модель улучшить твой промпт перед выполнением.
Вот черновик промпта: <...>. Сначала задай мне 3 уточняющих вопроса, затем перепиши промпт в структуре: роль, контекст, задача, ограничения, формат. Только после моего подтверждения — выполняй.
| Формула | Когда применять | Эффект |
|---|---|---|
| Роль + контекст | Код, архитектура | Точность стека |
| Few-shot | Классификация, форматирование | Стабильный формат |
| Chain-of-Thought | Дебаг, анализ | Меньше галлюцинаций |
| Negative prompt | Тесты, генерация | Отсекает анти-паттерны |
| JSON-контракт | Пайплайны | Парсится без правок |
| Self-critique | SQL, ревью | Ловит ошибки |
Главный вывод: промпт — это не текст, а спецификация. Чем точнее контракт (роль, ограничения, формат, примеры), тем меньше итераций. Начни с формул 1, 2 и 5 — они дают самый быстрый прирост качества. А формулу 12 используй, когда промпт уже работает, но хочется стабильности.
Официальные рекомендации по промптингу стоит сверять с документацией: OpenAI Cookbook (cookbook.openai.com), Anthropic Prompt Engineering Guide (docs.anthropic.com), Google Gemini Prompting Strategies (ai.google.dev). Там же — актуальные ограничения моделей, которые меняются чаще, чем кажется.
Комментарии