Как кодить с GPT-5: гайд от OpenAI с готовыми промптами

GPT-5 отлично следует инструкциям — иногда даже слишком буквально. Поэтому вместо «нажать газ во всю» срабатывает аккуратная подача задачи: чёткие требования, правильный уровень «размышлений», понятная структура промпта и немного места для планирования. Ниже — короткий, практичный разбор и набор шаблонов, которые можно копировать в свою IDE.

Больше о том, как использовать нейросети с пользой — на бесплатном вебинаре по этой теме!

1. Будьте точны и избегайте противоречий

GPT-5 послушный, но не телепат. Чем меньше разночтений — тем стабильнее результат.

Плохо: «Сделай красиво и быстро, но сначала собери всю информацию, и отвечай кратко». (кратко ≠ собери всё)

Хорошо:

• «Сделай компонент ProductCard c props: title:string, price:number.
• Стек: React + Tailwind.
• Ограничения: без сторонних UI-библиотек.
• Вывод: один файл TSX, 40–60 строк, с примерами использования.»

Совет: если у вас есть .cursor/rules, AGENTS.md или общие «правила кодовой базы», уберите дубликаты и противоречия. Оставьте один источник истины и ссылку на него в каждом промпте.

ОНЛАЙН-ПРАКТИКУМ

ЗАПУСК нейросети DEEPSEEK R1 ЛОКАЛЬНО НА СВОЕМ КОМПЬЮТЕРЕ

ЧТО БУДЕТ НА ОБУЧЕНИИ?

• ПОКАЖЕМ, КАК РАЗВЕРНУТЬ МОДЕЛЬ нейросети DEEPSEEK R1 ПРЯМО НА СВОЁМ КОМПЬЮТЕРЕ
• Где и как применять? Потестируем модель после установки на разных задачах
• Как дообучить модель под себя?

Участвовать бесплатно

2. Подбирайте «усилие рассуждения» под задачу

GPT-5 всегда немного «думает», но уровень стоит задавать сами:

• Просто (правка функции, форматирование) → низкий/средний.
• Сложно (архитектура, миграции, дизайн API) → высокий.

Если видите «перепридумывание велосипеда» на мелочи — явно понижайте планку: «используй низкий уровень рассуждений; не предлагай альтернативный стек».

3. Структурируйте инструкции псевдо-XML блоками

GPT-5 устойчиво реагирует на «каркас» промпта. Это помогает отделить правила от задачи.

<code_editing_rules>

<guiding_principles>

— Компоненты модульные и переиспользуемые

— Минимум побочных эффектов, максимум явности

</guiding_principles>

<defaults>

— Язык: TypeScript

— Frontend: React + TailwindCSS

— Тесты: Vitest

</defaults>

<done_definition>

— Компилируется без ошибок

— Покрытие тестами ключевой логики

— Один цельный патч без «магии»

</done_definition>

</code_editing_rules>

4. Осторожнее с «командным тоном»

Фразы вроде «БУДЬ ПРЕДЕЛЬНО ТЩАТЕЛЕН» у GPT-5 включают режим чрезмерной дотошности: лишние tool-коллы, сбор всех метаданных, «портянки» проверок. Заменяйте на спокойные параметры:

• «Собери минимальный контекст: package.json, список импортов, README.»
• «Если данных мало — задай один уточняющий вопрос, затем действуй.»

5. Дайте место для планирования и самопроверки

Когда строите что-то «с нуля», добавьте короткую внутреннюю паузу на план.

<self_reflection>

— Сформируй внутренний рубрикатор качества (5–7 критериев: DX, тестопригодность, производительность, безопасность, простота API).

— Прогоняй промежуточные решения по рубрике; не показывай рубрику пользователю.

— Если критерии не выполняются — пересобери решение и только потом выведи результат.

</self_reflection>

6. Управляйте «рвением» агента и бюджетом инструментов

По умолчанию GPT-5 стремится собрать максимум контекста. Задайте бюджет, параллелизм и точки синхронизации.

<tool_policy>

— Бюджет tool-вызовов: 6 на задачу

— Параллелизация: не более 2 одновременных запросов

— Приоритизируй: чтение текущего файла → package.json → тесты

— Если остаётся <2 вызова, остановись и выведи план дальнейших шагов

</tool_policy>

<persistence>

— Не запрашивай подтверждения мелких допущений; выбери наиболее разумное и зафиксируй его в конце.

</persistence>

Готовые промпты (копируйте в свою IDE)

Быстрый фикс бага

<task>

Нужен точечный фикс: функция formatPrice возвращает «NaN ₽» при null.

</task>

<context>

— Файл: utils/format.ts

— Требование: не ломать текущие тесты, добавить 1 новый тест-кейс на null.

</context>

<constraints>

— Язык: TypeScript

— Нельзя менять внешнее API функции

</constraints>

<reasoning level=»low»/>

<output>

— Патч кода

— Короткое объяснение (до 4 предложений)

</output>

Рефакторинг без изменения поведения

<task>Рефакторинг модуля cartService с выделением чистых функций.</task>

<goals>

— Убрать скрытые побочные эффекты

— Вынести форматирование/валидацию отдельно

</goals>

<done_definition>

— Сигнатуры публичных методов прежние

— Юнит-тесты зелёные

</done_definition>

<reasoning level=»medium»/>

Генерация тестов по коду

<task>Сгенерируй минимальный набор unit-тестов для src/lib/dateRange.ts.</task>

<rules>

— Покрыть граничные случаи (часовые пояса, переход месяца)

— AAA-стиль, Vitest

</rules>

<artifacts>Вывести файл тестов и команды запуска.</artifacts>

<reasoning level=»medium»/>

Нулевой прототип (one-shot веб-страница)

<task>Однофайловый прототип лендинга «AI Bookmarks».</task>

<stack>React + TailwindCSS, без внешних UI-китов.</stack>

<self_reflection>

— Внутренняя рубрика: скорость загрузки, читабельность, адаптивность, доступность

</self_reflection>

<reasoning level=»high»/>

<output>Один TSX-файл + инлайн-комментарии.</output>

Миграция схемы БД (план → SQL)

<task>Добавить поле is_archived в таблицу projects и индексы для фильтрации.</task>

<constraints>

— PostgreSQL 15

— zero-downtime миграция

</constraints>

<steps>

— План миграции

— SQL-скрипты up/down

— Роллбэк-стратегия в 3 шага

</steps>

<reasoning level=»high»/>

Мини-чек-лист перед запуском

Перед тем как запускать промпт, убедитесь, что у вас есть единый источник правил и не возникает противоречий. Важно, чтобы формулировка содержала чёткие требования к вводу и выводу: какой именно файл нужен, в каком формате, с какими лимитами.

Заранее определите уровень рассуждений — низкий, средний или высокий, в зависимости от задачи. Для объёмных запросов добавьте короткую самопроверку, которая поможет скорректировать результат. И не забудьте поставить ограничение на количество вызовов инструментов.

Частые ошибки и быстрые правки

Одна из самых распространённых проблем — слишком много целей в одном промпте. Лучше разделить их на этапы.

Ещё одна ошибка — отсутствие критериев завершённости: решается это добавлением чёткого блока <done_definition>. Жёсткий или директивный тон также мешает, поэтому стоит заменить его на параметризованные правила, чтобы промпт был более гибким.

Если техническое задание выглядит туманно, пропишите входы, выходы и ограничения подробнее. А там, где нет необходимости в глубоком рассуждении, наоборот, опустите уровень «мышления» и сделайте инструкцию проще.