После выполнения этой инструкции вы сможете писать промпты для кода так, чтобы модель чаще возвращала пригодный к запуску, ревью и автоматической проверке результат: с понятной задачей, ограничениями, форматом вывода и способом валидации.
Практический вердикт: для кода обычно лучше работает не короткое «напиши функцию», а компактное ТЗ из блоков: задача, контекст, ограничения, формат ответа, примеры и проверка. Официальные рекомендации OpenAI, GitHub Copilot, Gemini и Anthropic сходятся именно на этом, хотя детали зависят от модели и среды.
- Время: 25–35 минут
- Сложность: средний
- Стоимость: документация бесплатна; использование API, IDE-ассистента или платного плана зависит от выбранного вендора, тариф и доступность проверяйте на официальной странице pricing
- Что потребуется: доступ к одному из кодовых ассистентов или API, тестовый файл или репозиторий, возможность запускать тесты или проверки формата, понимание целевого языка программирования
- Актуальная база: официальные руководства OpenAI, GitHub Copilot, Gemini API и Anthropic Claude, а также репозитории OpenAI и 2 исследования; актуальность источников проверена на 2026-08-17
Редакционное ограничение: здесь нет обещаний про «универсальный лучший промпт» и нет численных бенчмарков, потому что источники прямо указывают на зависимость от семейства моделей, контекста IDE и быстро меняющихся релизов. Перед публикацией внутренних стандартов промптинга перепроверьте changelog и документацию конкретного инструмента.
| Что добавить в промпт | Зачем это нужно | На чём основано |
|---|---|---|
| Одна чёткая задача | Снижает размытость и облегчает проверку | Gemini рекомендует прямые, хорошо структурированные запросы; Copilot — дробить сложные задачи |
| Отдельные блоки инструкций и контекста | Модель реже смешивает требования с входными данными | OpenAI советует разделять инструкции и контекст; Gemini и Claude поддерживают XML-подобную структуру |
| Формат ответа | Проще автоматизировать постобработку и сравнение | OpenAI рекомендует явно задавать формат; Structured Outputs поддерживает JSON schema |
| Примеры | Фиксируют желаемый паттерн решения | OpenAI, Copilot и Anthropic рекомендуют добавлять примеры |
| Границы контекста и инструменты | Меньше скрытых предположений и лишних действий | Copilot учитывает текущий файл и историю чата; GPT-5 cheatsheet советует явный tool budget |
| Тесты и evals | Позволяют сравнивать версии промпта, а не спорить о вкусе | OpenAI рекомендует pin model versions и evals; Copilot — валидировать код перед использованием |
1. Сформулируйте одну наблюдаемую задачу
Начните с одного результата, который можно проверить. Для кода это обычно функция, SQL-запрос, патч, тест, миграция или рефакторинг с ограниченным объёмом. GitHub Copilot рекомендует разбивать сложные задачи на меньшие части, а Gemini — писать прямые и хорошо структурированные запросы с ясными ограничениями.
Плохой вариант:
Оптимизируй backend.Рабочий вариант:
Напишите функцию на Python, которая читает CSV из stdin,
агрегирует строки по полю status и печатает итог в JSON.
Не меняйте интерфейс CLI.
Верните только код и unit-тесты.Ожидаемый результат: после этого шага у вас есть запрос, который можно проверить по одному критерию: код либо делает именно это, либо нет.
2. Отделите инструкции от контекста
OpenAI рекомендует разделять инструкции и контекст, а Gemini и Anthropic прямо допускают XML-подобные теги или Markdown-заголовки как удобный способ структурирования. Для кода это особенно полезно: требования не смешиваются с фрагментами репозитория, логами и примерами входных данных.
Используйте такой каркас:
<task>
Напишите функцию на Python для нормализации email.
</task>
<context>
Функция используется в API регистрации.
Текущий формат входа: строка или null.
</context>
<constraints>
Не используйте внешние зависимости.
Сохраните совместимость с Python 3.
Не меняйте публичное имя функции.
</constraints>
<output_format>
1. Короткое объяснение до 5 пунктов.
2. Один блок кода.
3. Набор unit-тестов.
</output_format>Если вам нужен только черновик структуры, OpenAI также советует использовать Generate Anything для наброска промпта под задачу. Но черновик не заменяет ручную проверку ограничений и критериев готовности.
Ожидаемый результат: промпт читается как спецификация, а не как поток мыслей.
3. Зафиксируйте язык, стиль и формат вывода
Не заставляйте модель угадывать, на чём писать и как отвечать. OpenAI рекомендует быть конкретным насчёт формата ответа. Для кодогенерации официальный гайд также отмечает простой приём управления стилем: ведущие слова вроде import направляют ответ к Python-стилю, а SELECT — к SQL-стилю.
Примеры:
import
Напишите минимальный Python-скрипт, который читает JSON из файла и валидирует поле id.SELECT
Составьте SQL-запрос, который возвращает 10 последних заказов по customer_id.Если код нужен для CI, укажите точный формат вывода:
Верните ответ в таком порядке:
1. Краткий план.
2. Один блок кода.
3. Один блок тестов.
4. Никаких пояснений после кода.Это переносимая практика: она работает лучше, чем просьба «сделай красиво», потому что даёт машине проверяемый контракт.
4. Добавьте пример и крайний случай
Когда задача неоднозначна, примеры экономят больше всего итераций. OpenAI, Copilot и Anthropic рекомендуют использовать примеры там, где они помогают зафиксировать шаблон ответа. Для кода полезны не только позитивные примеры, но и крайние случаи.
Пример входа:
["[email protected] ", "[email protected]", null]
Ожидаемый выход:
["[email protected]", "[email protected]", null]
Крайний случай:
Пустая строка должна возвращаться как пустая строка, а не как null.Если хотите исключить нежелательный стиль решения, добавьте контрпример или запрет:
Не используйте глобальное состояние.
Не добавляйте ORM.
Не переписывайте существующий интерфейс класса.Ожидаемый результат: модель получает не только цель, но и эталон поведения на спорных входах.
5. Ограничьте контекст и инструменты
GitHub Copilot учитывает текущий файл и историю чата как контекст, а его рекомендации советуют открывать релевантные файлы, выделять нужный код и начинать новый тред, когда старая история больше мешает, чем помогает. Для агентных сценариев GPT-5 cheatsheet рекомендует явный tool budget, а Anthropic — в том числе правило очистки временных файлов. Gemini рекомендует подключать grounding через Google Search для редких или свежих фактов и инструмент code execution для вычислений.
Практически это означает: прямо скажите модели, какой контекст использовать и что ей можно делать.
<context_scope>
Используйте только текущий файл и код ниже.
Не предполагайте существование других модулей.
Если в истории обсуждались старые требования, игнорируйте их.
</context_scope>
<tools>
Если ваш инструмент поддерживает поиск по сети, используйте его только для редких или свежих фактов.
Если ваш инструмент поддерживает выполнение кода, используйте его для вычислений и проверки арифметики.
Бюджет инструментов: не более 2 вызовов.
</tools>
<agent_rules>
После проверки удалите временные файлы, созданные для теста.
</agent_rules>Ожидаемый результат: в ответе меньше скрытых предположений, а поведение модели проще повторить в новой сессии.
6. Попросите машинно-проверяемый вывод
Для рабочих процессов, где код идёт в пайплайн, естественного языка мало. Репозиторий OpenAI по Structured Outputs прямо указывает, что Structured Outputs заставляет ответы и tool calls соблюдать заданную JSON schema. Это удобно, если вы дальше разбираете результат программно, сравниваете версии промпта или автоматически создаёте файлы.
Минимальный пример схемы ответа:
{
"type": "object",
"properties": {
"summary": {"type": "string"},
"files": {
"type": "array",
"items": {
"type": "object",
"properties": {
"path": {"type": "string"},
"content": {"type": "string"}
},
"required": ["path", "content"],
"additionalProperties": false
}
}
},
"required": ["summary", "files"],
"additionalProperties": false
}Если вы работаете через CLI и автоматизацию, полезен и JSON-вывод на уровне инструмента. В документации Claude Code описан флаг --output-format json, что подходит для скриптовой проверки. Даже если вы не используете Claude, логика та же: чем меньше свободного текста, тем легче автоматическая валидация.
Ожидаемый результат: ответ можно проверить не глазами, а схемой, парсером или тестом.
7. Проверяйте промпт тестами и фиксируйте базовую версию модели
OpenAI в API-документации рекомендует для устойчивого поведения закреплять версии моделей и использовать evals. Репозиторий OpenAI Cookbook показывает практический evaluation flywheel: вы меняете промпт, измеряете результат, сравниваете конфигурации и не путаете улучшение промпта с изменением модели. GitHub Copilot отдельно рекомендует валидировать сгенерированный код перед использованием. Исследования из arXiv и ACM также подтверждают, что формулировка промпта влияет на кодогенерацию и важна для безопасного кода.
Минимальный рабочий цикл такой:
- Зафиксируйте одну версию модели.
- Подготовьте 3–5 тест-кейсов: нормальный вход, крайний случай, ошибочный вход.
- Прогоните старый и новый промпт на одном и том же наборе.
- Сравните не «красоту», а прохождение тестов, формат ответа и объём ручных правок.
Если промпт хорош только в одной длинной истории чата, а в новой сессии ломается, это плохой стандарт для команды.
Как проверить, что всё работает
- Проверка 1. Запустите промпт в новой чистой сессии. Ответ должен сохранять ту же структуру без опоры на скрытую историю.
- Проверка 2. Убедитесь, что вывод точно соответствует запрошенному формату: только код, код плюс тесты или JSON по заданной схеме.
- Проверка 3. Запустите unit-тесты или хотя бы три ручных кейса: штатный, крайний и ошибочный.
- Проверка 4. Если используете IDE-ассистента, повторите задачу с открытыми релевантными файлами или выделенным фрагментом и сравните, насколько меняется качество ответа.
- Проверка 5. Если задача требует свежих фактов или вычислений, проверьте, что вы включили соответствующий инструмент только там, где он действительно нужен.
Короткий критерий успеха: хороший промпт для кода воспроизводим, проверяем и не зависит от догадок модели о вашем проекте.
Частые ошибки и исправления
- Ошибка: «Сделай рефакторинг сервиса» без границ задачи. Исправление: разбейте запрос на один наблюдаемый результат: например, «вынеси валидацию из контроллера в отдельную функцию и сохрани сигнатуры методов».
- Ошибка: модель смешивает объяснение, код и рассуждения. Исправление: явно задайте формат ответа и порядок блоков; при автоматизации переходите на JSON schema или другой машинно-проверяемый контракт.
- Ошибка: в IDE ответ зависит от случайного состояния истории чата. Исправление: откройте нужные файлы, выделите релевантный код и начните новый тред, если старый контекст больше не нужен.
- Ошибка: модель пишет «умный», но неисполняемый код. Исправление: требуйте тесты, фиксируйте ограничения по версиям и прогоняйте результат через проверку, а не принимайте по внешнему виду.
- Ошибка: промпт для продакшена не учитывает безопасность. Исправление: сделайте требования к безопасному коду явными и отдельно проводите ревью; исследования по secure code generation показывают, что безопасность нужно задавать и проверять как отдельный критерий.
Безопасность и ограничения
- Промптинг не заменяет проверку безопасности. Даже хороший запрос не гарантирует безопасный код; требования безопасности и постпроверка должны быть отдельным шагом.
- Советы не универсальны для всех моделей. Источники охватывают GPT-5, GitHub Copilot, Gemini 3 и Claude 4; переносите рекомендации между вендорами только после проверки.
- Документация меняется быстро. В changelog Gemini видно, что даже параметры и рекомендации к взаимодействию с моделями меняются со временем; то же относится и к другим платформам.
- Стоимость и лимиты не фиксированы в этой инструкции. В исходном пакете нет единой актуальной таблицы цен, rate limits и региональной доступности, поэтому эти параметры нужно проверять у каждого вендора отдельно.
- Агентные сценарии требуют гигиены артефактов. Если ассистент создаёт временные файлы для проверки, включайте в инструкции явную очистку таких файлов после работы.
Практический вывод: если вы хотите улучшить кодовые промпты одним действием уже сегодня, добавьте явный формат ответа и способ проверки. Это самая полезная и наиболее переносимая рекомендация из всего набора источников.
Что делать дальше
- Если вы хотите сначала выстроить базовую логику промпта, прочитайте Как написать эффективный промпт для ChatGPT.
- Если вы работаете в IDE, продолжите с инструкцией Как установить и настроить Cursor для кода.
- Для повседневной работы с репозиторием пригодится Как использовать Cursor для автодополнения кода.
- Чтобы использовать те же принципы для описаний и README, откройте Как использовать AI для генерации документации кода.
Источники
- Best practices for prompt engineering with the OpenAI API
- GitHub – openai/openai-structured-outputs-samples: Sample apps to help developers get started with Structured Outputs
- API Reference – OpenAI API
- Prompt engineering for GitHub Copilot Chat
- Best practices for using GitHub Copilot
- Prompting strategies | Gemini API | Google AI for Developers
- Release notes | Gemini API | Google AI for Developers
- GPT-5 for coding cheatsheet
- Claude 4提示工程最佳实践 – Anthropic
- CLI reference – Claude Code Docs
- GitHub – openai/openai-cookbook: Examples and guides for using the OpenAI API
- Guidelines to Prompt Large Language Models for Code Generation: An Empirical Characterization
- Prompting Techniques for Secure Code Generation: A Systematic Investigation
Вопросы и ответы
Нужно ли всегда писать промпт для кода в XML-подобной структуре?
Нет. Но OpenAI советует отделять инструкции от контекста, а Gemini и Anthropic считают XML-подобные теги удобным способом такой структуры. Если задача простая, хватит и Markdown-заголовков.
Когда добавлять примеры в промпт?
Когда без примера возможны разные интерпретации. Особенно полезны примеры входа-выхода и крайние случаи, потому что они снижают число итераций и фиксируют желаемый паттерн кода.
Как понять, что промпт стал лучше?
Не по ощущению, а по проверке: закрепите версию модели, прогоните одинаковые тест-кейсы, сравните прохождение тестов, точность формата ответа и объём ручных исправлений. Именно такой подход поддерживают рекомендации про evals и validation.
Можно ли переносить один и тот же промпт между Copilot, GPT, Gemini и Claude?
Частично. Базовые принципы совпадают, но источники подчёркивают модельную и продуктовую специфику: у Copilot важен контекст текущего файла и истории, у Gemini и Claude полезны структурные теги, у OpenAI для стабильности важны pin model versions и evals.
Что важнее для автоматизации: красивый ответ или строгий формат?
Строгий формат. Для пайплайнов и скриптов лучше требовать машинно-проверяемый вывод, например JSON по схеме, потому что его можно валидировать автоматически и сравнивать между версиями промпта.