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

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

Для кода работает та же схема, что и для текстов: цель, контекст, формат — только вместо «письма» вы просите патч, список рисков или тесты. **Быстрый win за 5 минут:** научитесь формулировать баг-репорт (ошибка + ожидание + 30-80 строк контекста) → получите патч в unified diff за 10-15 секунд → проверите и примените. Ниже — шаблоны под баг, ревью, рефакторинг и unit-тесты плюс подсказки, какую модель взять в GPThub. Практики взяты из гайдов OpenAI и Anthropic, примеры — на русском и под обычный чат, не под SDK.

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

Понадобится

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

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

Шаги

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

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

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

Баг → патч (ответ за 10-15 сек, unified diff на 5-20 строк)

DeepSeek V4 Flash

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

Ревью кода (ответ за 15-20 сек, список из 5-10 пунктов)

Claude Sonnet 5

Проревьюй фрагмент по критериям:
- Корректность (края: null, пустые списки, overflow)
- Читаемость (имена, структура)
- Безопасность (инъекции, утечки)
- Производительность (грубая оценка)
Формат: нумерованный список замечаний с серьёзностью (🔴 блокер / 🟡 желательно / ⚪ косметика).
Не переписывай весь код. Только список проблем и точечные правки.
Код:
```
[вставьте]
```

Unit-тесты (ответ за 10-15 сек, 4-6 тестов)

GLM 4.7 Flash

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

Рефакторинг без смены поведения (ответ за 20-30 сек, зависит от размера)

Grok 4.5

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

Скрин ошибки (UI / консоль) — ответ за 5-10 сек

GPT-5 Nano

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

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

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

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

«Почини» без стека и без ожидаемого поведения → модель угадывает причину, патч может сломать другое место
Вставить 2 тыс. строк и ждать точечный патч → жжёте пакет токенов, получаете общий ответ. Режьте на 30-80 строк релевантного кода
Просить одновременно архитектуру микросервисов и запятую в if → разнесите на 2 запроса, иначе получите полуфабрикат
Принимать код без запуска → модели ошибаются в API и импортах. Всегда проверяйте патч у себя
Кидать скрин в текстовую модель (Flash, GLM) без поддержки картинок → потеряете запрос впустую

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

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

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

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

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

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

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

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

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

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

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