КодСреднийКод~11 мин

Промпты для кода: баг, патч, ревью и тесты

Для кода работает та же схема, что и для текстов: цель, контекст, формат — только вместо «письма» вы просите патч, список рисков или тесты. Ниже — шаблоны под баг, ревью, рефакторинг и unit-тесты плюс подсказки, какую модель взять в GPThub. Практики взяты из гайдов OpenAI и Anthropic, примеры — на русском и под обычный чат, не под SDK.

Опубликовано 6 августа 2026 г.

Понадобится

·Фрагмент кода или ошибка (стек, сообщение, ожидаемое поведение)
·Понимание языка/стека: Python, TypeScript, Go и т.п.
·Базовый гайд «Как писать промпты» — желательно, но не обязательно

Открыть чат Все гайды

Шаги

01Соберите минимум контекста
Модели не видят ваш репозиторий целиком, пока вы его не вставите. Для бага: сообщение об ошибке, стек, кусок кода вокруг, что ожидали и что получили. Для фичи: сигнатура, ограничения, пример входа/выхода. Лучше 30–80 строк точного контекста, чем «весь файл на 800 строк» без цели.
Совет: Длинный файл режьте: «вот функция X и её тесты», а не весь модуль.
02Задайте роль и жёсткий формат ответа
Напишите, кто отвечает («senior Python», «ревьюер безопасности») и как вернуть результат. Удачные форматы: «только unified diff», «сначала 3 гипотезы, потом патч», «таблица: риск / место / правка». Иначе получите поток объяснений без кода, который можно вставить.
03Баг: воспроизведение → гипотезы → патч
Просите не «почини», а цепочку: 1) что ломается, 2) 2–3 вероятные причины, 3) минимальный патч, 4) как проверить. Запретите менять несвязанный код. Если стек есть — вставьте его целиком; если нет — опишите шаги воспроизведения.
04Ревью: критерии, а не «ну как тебе»
Задайте оси проверки: корректность, читаемость, края (null, пустые списки), безопасность, производительность. Попросите нумерованный список замечаний с серьёзностью (блокер / желательно / косметика) и без переписывания всего файла, если не просили.
05Тесты и рефакторинг — отдельно от «сделай красиво»
Для тестов укажите фреймворк (pytest, vitest, testing) и что покрыть. Для рефакторинга — цель (убрать дубль, упростить ветки) и инвариант («поведение не менять»). Не смешивайте «почини баг + перепиши архитектуру» в одном запросе — разнесите на два.
06Выберите модель под тяжесть
Короткий баг и черновик — DeepSeek V4 Flash или GLM 4.7 Flash («Плюс»). Средний код и скрины UI — Luna / Grok 4.3. Сложный рефакторинг, длинный контекст, аккуратное следование инструкциям — Claude Sonnet 5, Terra, Grok 4.5, Kimi K3 («Про»). Скрин ошибки — Nano или модель с картинками вашего тарифа.
Совет: Не помог Flash — сначала уточните промпт, потом смените модель. Подробнее: гайд «Как выбрать модель».

Готовые запросы

Нажмите «Скопировать» и вставьте в чат. Текст в квадратных скобках замените на свой.

Баг → патч

DeepSeek V4 Flash

Роль: опытный разработчик [язык/стек].
Задача: найти причину бага и предложить минимальный патч.
Ожидаемое поведение: […]
Фактическое: […]
Стек / лог:
---
[вставьте]
---
Код (только релевантный фрагмент):
```
[вставьте]
```
Формат ответа:
1) 2–3 гипотезы (коротко)
2) наиболее вероятная причина
3) патч: unified diff или полный заменённый блок
4) как проверить вручную
Не рефакторь соседний код. Не выдумывай файлы, которых нет во вставке.

Ревью diff

Claude Sonnet 5

Сделай ревью кода. Критерии: корректность, края, читаемость, безопасность (инъекции, секреты), лишняя сложность.
Для каждого замечания: серьёзность (блокер / желательно / косметика), файл/место, суть, пример правки в 1–3 строки.
Не переписывай весь файл. Если критичных нет — так и скажи.
Diff или код:
```
[вставьте]
```

Unit-тесты

GLM 4.7 Flash

Напиши unit-тесты на [фреймворк] для функции ниже.
Покрой: нормальный путь, пустой ввод, ошибка/исключение, один граничный случай.
Стиль: один assert на проверку смысла, понятные имена test_…
Не тестируй приватные детали реализации, только поведение.
Код:
```
[вставьте]
```

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

Grok 4.5

Отрефактори фрагмент: [цель: убрать дубли / упростить ветки / вынести функцию].
Инвариант: поведение и публичный API не менять.
Верни:
1) краткий план (3–5 пунктов)
2) новый код целиком
3) что проверить вручную
Код:
```
[вставьте]
```

Скрин ошибки (UI / консоль)

GPT-5 Nano

На скрине — ошибка или UI. Опиши, что видишь. Предложи 3 шага диагностики и один вероятный фикс в коде [стек], если данных хватает. Если не хватает — список уточняющих вопросов.
Контекст: [страница / сервис / что нажали].

Готово, если…

Во вставке есть ошибка/ожидание или чёткая цель изменения
Указан формат ответа (diff, список, тесты)
Запрещены лишние рефакторинги, если не просили
Язык и фреймворк названы явно
Модель соответствует сложности и тарифу
Патч проверен у себя (тест или ручной прогон), а не только «выглядит умно»

Частые ошибки

«Почини» без стека и без ожидаемого поведения
Вставить 2 тыс. строк и ждать точечный патч
Просить одновременно архитектуру микросервисов и запятую в if
Принимать код без запуска — модели ошибаются в API и импортах
Кидать скрин в текстовую модель без поддержки картинок

Частые вопросы

Какую модель взять для повседневного кода на бесплатном тарифе?

DeepSeek V4 Flash — текст и патчи. Скрин консоли или UI — GPT-5 Nano. Если сложности не хватает, смотрите «Плюс»/«Про» и гайд по выбору модели.

Почему модель выдумывает несуществующие функции?

Мало контекста или слишком общая задача. Вставьте реальные сигнатуры, запретите выдумывать API («только из вставки») и попросите помечать неуверенность.

Лучше diff или полный файл?

Для точечного бага — diff или замена одного блока. Для нового файла с нуля — полный код. Всегда указывайте формат в промпте.

Можно ли просить объяснить чужой код?

Да: «объясни по шагам, что делает функция, входы/выходы, побочные эффекты, риски». Для обучения добавьте «без переписывания, только разбор».

Как не сжечь пакет токенов на коде?

Режьте вставки, не копируйте node_modules и lock-файлы, дробите задачи. Длинные репозитории — кусками по файлу/функции.