Практика промптинга для разработчиков: шаблоны промптов под код-ревью, отладку и генерацию патчей
Соберём набор повторяемых промптов для задач из ежедневной разработки: ревью диффов, локализация причины бага, генерация патча с ограничениями и форматированными ответами. Покажем, как снижать хаос и добиваться проверяемых результатов.
Содержание
Промптинг для разработчика — это не про «написать красивый запрос». Это инженерная дисциплина: формулировать задачу так, чтобы модель выдавала предсказуемый результат, а не поток догадок. В ежедневной работе (ревью диффов, анализ багов, подготовка патчей) хаос возникает не из‑за отсутствия знаний, а из‑за отсутствия структуры: контекст то теряется, то смешивается, то модель угадывает формат ответа, а затем вы тратите время на «перевод» её результата в рабочий артефакт.
Ниже — набор повторяемых промптов, которые можно копировать и адаптировать под свои задачи. Они ориентированы на проверяемость: вход и выход фиксированы, есть ограничения, есть требования к формату, есть вопросы, которые модель обязана задать при нехватке данных.
Как промптинг вписать в инженерный цикл
Перед шаблонами полезно определить «контур управления», без которого промптинг превращается в гадание. Типовой цикл для задач разработки:
- Сформировать вход: дифф/файл, ошибка и контекст, требования к патчу.
- Определить цель и критерии: что считается «хорошим ответом», а что — ошибкой.
- Указать ограничения: что менять нельзя, какие форматы поддерживаются (например, unified diff), что модель должна соблюдать.
- Заставить модель работать по шагам: сначала анализ, потом гипотезы, потом конкретные действия.
- Закрыть цикл обратной связью: если модель не может сделать вывод без данных — пусть запросит недостающее.
Практически: вы строите «протокол разговора», где модель — вычислительный сопроцессор, а вы — оператор, задающий правила игры.
Шаблоны промптов под код-ревью диффов
1) Ревью диффа с фиксированным форматом отчёта
Когда использовать: у вас есть PR/дифф в GitHub/GitLab, и нужно быстро получить качественное ревью: корректность, стиль, безопасность, производительность, тесты.
Ты — опытный ревьюер кода (senior backend/frontend). Твоя задача: проанализировать предоставленный unified diff и дать ревью в строгом формате.
ВХОД:
{DIFF}
ТРЕБОВАНИЯ К ВЫХОДУ (строго соблюдай формат):
1. Summary: 3–6 пунктов, кратко что изменилось и какие риски/выигрыши видны сразу.
2. Correctness (ошибки/краевые случаи): список. Для каждого пункта:
- File: <путь>
- Lines: <диапазон или фрагмент>
- Issue: <что не так>
- Why: <почему это проблема>
- Suggestion: <конкретное исправление>
3. Security: только если есть релевантные темы. Иначе напиши "Security: нет явных рисков".
4. Performance: где есть потенциальные узкие места/лишние вычисления/запросы.
5. Maintainability/Style: архитектурные/стилистические замечания.
6. Tests: что нужно добавить/обновить. Формат:
- Test case: <название>
- Purpose: <что проверяет>
- Sketch: <краткий пример или псевдокод>
7. Blockers: список критичных замечаний, без которых мёрдж рискован.
8. Ready-to-merge checklist: короткий чек-лист требований.
ОГРАНИЧЕНИЯ:
- Не выдумывай контекст. Если не хватает информации (например, про схемы БД/контракты API/поведение функций) — укажи вопросы в конце раздела "Questions".
- Не предлагай массовые рефакторинги без необходимости.
- Пиши на русском.
- Если дифф слишком короткий/неполный — скажи, что именно нужно для полноценного ревью.
В КОНЦЕ добавь раздел "Questions" с максимум 5 уточняющими вопросами.
Почему это работает: вы заставляете модель выходить в «контролируемом протоколе», а не отвечать свободным текстом. Ваше ревью превращается в структурированный документ, пригодный для комментариев в PR.
2) Ревью диффа с приоритетами (triage) и ссылками на критерии
Иногда важно быстро отсортировать замечания по приоритету: что исправлять обязательно сейчас, что можно отложить, а что несущественно.
Проанализируй {DIFF} и сделай triage-ревью.
Выход (строгий формат):
A) Must-fix (P0): 0–8 пунктов.
B) Should-fix (P1): 0–10 пунктов.
C) Nice-to-have (P2): 0–10 пунктов.
D) No-issue (P3): 0–5 пунктов, если изменения выглядят корректно (по запросу: кратко почему).
Для каждого пункта в A/B/C:
- File:
- Location (фрагмент/строки):
- Категория (correctness/security/performance/maintainability/tests):
- Почему это важно:
- Как исправить (конкретно, без абстракций).
Правила:
- Не добавляй замечаний без объяснения.
- Если данных не хватает, помещай в конец: "Missing info" с конкретикой, что нужно.
Подводный камень: если вы не задаёте критерии приоритизации, модель может размыть границы P0/P1. Поэтому в промпте лучше заранее закрепить категории (correctness/security/performance и т.д.).
3) Ревью с фокусом на баг-репродукцию
Полезно, если вы получаете дифф и хотите понять: «почему этот фикс должен сработать» и «не сломает ли он соседние сценарии».
Ты помогаешь инженеру подтвердить фикс в диффе {DIFF}.
Сначала сделай гипотезы:
1) Which reported bug scenarios this change targets
2) What invariant should hold after the patch
Затем:
3) Evidence from diff: для каждого сценария укажи строки/фрагменты, которые подтверждают или не подтверждают гипотезы.
4) New risk introduced: что может сломаться/измениться побочно.
В конце:
- List of targeted tests (минимум 3) для каждого сценария.
- Questions (если нет исходных данных для воспроизведения багов).
Шаблоны промптов для локализации причины бага
Локализация бага — это поиск причины, а не придумывание «версии». Поэтому промпт должен управлять структурой: сначала собрать наблюдения, потом построить гипотезы, затем связать гипотезы с проверяемыми действиями.
4) Анализ stack trace + гипотезы + план проверки
У меня есть ошибка. Помоги локализовать причину.
ДАННЫЕ:
- Language/stack: {LANG/FRAMEWORK}
- Runtime: {например Node 20 / JDK 21 / Python 3.12}
- Error message: {ERROR}
- Stack trace:
{STACKTRACE}
- Что делалось перед ошибкой: {STEPS}
- Была ли попытка воспроизвести локально: {YES/NO + детали}
- Репозиторий/код: {нужные фрагменты, если есть}
ЗАДАЧИ:
1) Extract facts: перечисли только факты из сообщения/trace (без интерпретаций).
2) Hypotheses: предложи 3–6 гипотез с вероятностями (rough) и обоснованием.
3) Verification plan: для каждой гипотезы:
- What to check in code/logs
- Suggested snippet (если уместно)
- How to reproduce reliably
4) Likely root cause: выбери 1–2 наиболее вероятные причины, но обязательно привяжи к evidence.
ОГРАНИЧЕНИЯ:
- Не предлагай изменения кода, пока не сформирован план проверки.
- Если в данных критически не хватает контекста — сначала задай до 7 уточняющих вопросов.
Важно: модель часто «спешит» с предложением патча. Этот промпт тормозит её: сначала план верификации.
5) Локализация на основе минимального воспроизведения (MCVE)
Если у вас есть минимальный пример, модель можно использовать как «методолога»: проследить поток данных и найти несостыковки.
Ты — отладчик-практик. Разбери проблему по минимальному воспроизведению.
MCVE:
{MINIMAL_REPRO}
Контекст:
- Ожидаемое поведение:
{EXPECTED}
- Фактическое поведение:
{ACTUAL}
- Ограничения (нельзя менять API/контракты/формат):
{LIMITATIONS}
ВЫХОД:
1) Reconstructed control flow: пошагово как данные проходят по коду (или по логике).
2) Where the invariant breaks: какая инварианта нарушается, и на каком шаге это происходит.
3) Candidate causes: 3–5 причин, отсортируй по вероятности.
4) Instrumentation suggestions: какие логи/проверки/профилирование добавить (конкретно).
5) Debug experiments: минимальные эксперименты, которые различают гипотезы (например, поменять параметр, подложить edge case, проверить типы/валидацию).
Подводный камень: если MCVE нет, этот промпт вернёт много предположений. Поэтому лучше сначала попросить уточнения/факты.
Шаблоны промптов для генерации патчей и diff’ов
Самый частый сценарий — «Сделай патч». Но если не задать контракт, модель выдаст текстовый «совет» вместо работающего patch или нарушит стиль/формат. Здесь ключевые элементы: формат ответа (unified diff), ограничения изменений, проверяемость (какие тесты/как запускать).
6) Генерация unified diff с ограничениями и комментарием к изменениям
Сгенерируй патч (unified diff) для исправления бага.
ВХОД:
- Repo language/framework: {LANG/FRAMEWORK}
- Описание бага:
{BUG_DESCRIPTION}
- Репро шаги:
{STEPS_TO_REPRO}
- Ожидаемое:
{EXPECTED}
- Фактическое:
{ACTUAL}
- Текущий код (релевантные файлы/функции):
{CODE_SNIPPETS}
- Требования:
- Must not change public API: {YES/NO}
- Must keep backward compatibility: {YES/NO}
- Max files changed: {N}
- Coding style: {например, eslint/prettier rules / existing patterns}
- Тесты:
- Existing tests: {описание}
- Что должно быть добавлено: {если есть}
ЗАДАЧА:
1) Сначала кратко: Plan (3–8 пунктов).
2) Затем выдай патч в виде unified diff ТОЛЬКО в этом блоке:
```diff
...patch...
- После патча дай раздел "Post-conditions":
- какие инварианты/свойства исправлены
- какие регрессии не должны появиться
- Раздел "Tests to run":
- конкретные команды (если знаешь типовой tooling) или запроси, если неизвестно.
ОГРАНИЧЕНИЯ:
- Нельзя менять файлы сверх {N} (укажи, если нужен больший объём).
- Нельзя переписывать архитектуру.
- Если данных недостаточно, сначала спроси 5–10 вопросов; патч не генерируй до подтверждения.
- Не добавляй dependency, кроме случаев когда это явно разрешено в требованиях.
**Почему это надёжнее:** патч появляется в строго заданном виде, и модель вынуждена сначала объяснить план, что снижает вероятность «галлюцинаций» по структуре репозитория.
---
### 7) Патч с несколькими вариантами и выбором на основе критериев
Иногда есть два подхода, и важно оценить trade-offs. Тогда промпт должен требовать сравнение.
```text
Нужно исправить проблему. Сгенерируй 2 альтернативных патча и сравни их.
ВХОД:
{BUG_DESCRIPTION}
CODE/контекст:
{CODE_SNIPPETS}
Ограничения:
{LIMITATIONS}
ВЫХОД:
1) Option A:
- Summary (2–4 предложения)
- Unified diff в блоке:
```diff
...
- Expected behavior changes:
- Tests to add/run
-
Option B: (аналогично)
-
Comparison:
- Criteria: correctness, performance, maintainability, risk, compatibility
- Таблица 5 строк (можно markdown) с оценками A vs B
- Recommendation:
- Что выбрать и почему (1–2 абзаца)
**Подводный камень:** модель может сделать два варианта слишком похожими. Но это уже проблема формулировки критериев: добавляйте явные различия (например, «Option A — minimal change», «Option B — более структурно, но затрагивает 2 файла»).
---
### 8) Комбинирование ревью и патча: «сначала пойми, потом исправь»
Этот шаблон хорош в ситуации, когда вы получили сомнительный дифф и хотите улучшить его качество.
```text
Я дам тебе:
- DIFF (текущий PR)
- Информацию о баге (как воспроизвести, ожидаемое/фактическое)
Твоя задача:
1) Сделай краткое ревью: что в PR вероятно правильно/ошибочно.
2) Выдели конкретные исправления (список изменений).
3) Сгенерируй unified diff обновления поверх текущего DIFF: только то, что реально нужно, без раздувания.
ВЫХОД:
A) Review bullets
B) Change list (что именно будет поменяно)
C) Unified diff в блоке ```diff
...
D) Tests to run E) Questions (если что-то критичное остаётся неясным)
---
## Практика: снижать хаос за счёт «контракта данных»
Модели плохо работают в режиме «в общем». Они лучше работают, когда вы фиксируете:
- **границы входа** (какой фрагмент кода можно использовать),
- **границы выхода** (точный формат, например diff),
- **границы изменений** (max files changed, no dependencies),
- **границы интерпретации** (не выдумывать контекст; если чего-то нет — спрашивать).
### Типичная проблема: модель отвечает «как думает»
Чтобы этого избежать, в промптах полезно добавлять пункт:
- *“If information is missing, ask clarifying questions instead of guessing.”*
И ещё лучше — лимитировать число вопросов, чтобы не утонуть в уточнениях.
### Типичная проблема: код-ответ не компилируется
Причины:
- не совпал неймспейс/импорты,
- неверный язык/версия,
- модель «додумала» недостающие части.
В промпт можно встроить правило:
- *“Assume nothing about existing imports; either include necessary imports or reference existing ones explicitly from provided snippets.”*
Если вы не дали контекст, попросите модель указать, какие именно фрагменты нужны.
### Типичная проблема: модель генерирует diff, но меняет слишком много
Поэтому:
- *“Max files changed: {N}”*,
- *“Prefer localized changes. Do not refactor unrelated modules.”*
---
## Набор “шаблонов-кирпичиков” для ежедневного применения
Ниже мини‑шаблоны, которые удобно добавлять к любому из сценариев.
### 9) Шаблон «стандартизировать требования к формату»
```text
Формат ответа должен быть строго следующим:
- <Section 1>
- <Section 2>
Не добавляй лишние разделы.
Если не уверен — укажи уровень уверенности и что проверить.
10) Шаблон «ограничить фантазию»
Запрещено:
- выдумывать существующие файлы/функции/типы, которых нет в предоставленном коде
- ссылаться на детали инфраструктуры, если они не указаны
Разрешено:
- делать обоснованные предположения только с пометкой "Assumption:"
- задавать вопросы при критической нехватке данных
11) Шаблон «сделать ответ пригодным для копирования в задачу»
Сделай результат в виде текста, который можно вставить в GitHub comment:
- кратко, по пунктам
- без длинных прелюдий
- с конкретными местами (файл/строки/фрагменты)
Как учиться на промптинге: итерационный протокол
Хорошая практика — относиться к промптингy как к набору гипотез, которые вы проверяете:
- Возьмите реальную задачу (ревью/баг/патч).
- Примените ваш шаблон.
- Зафиксируйте:
- где результат был полезен,
- где модель «сломала» формат,
- где были неточности/галлюцинации,
- где не хватило входных данных.
- Улучшите шаблон: добавьте требования к недостающему (например, «вопросы до патча», «unified diff строго в одном блоке», «no refactor beyond X»).
Со временем вы получаете персональную библиотеку промптов — по сути, внутренний DSL для взаимодействия с моделью.
Частые ошибки разработчиков при промптинге (и как исправить)
Ошибка 1: просить “сделай лучше”, без критериев
Симптом: модель предлагает переработку ради переработки.
Фикс: добавляйте критерии (correctness/security/performance), ограничения (max files changed), желаемые тесты и запрет на рефакторинг.
Ошибка 2: давать только “ошибку”, без контекста
Симптом: модель предлагает «самые частые причины» и уводит в сторону.
Фикс: требуйте шаги воспроизведения, версию окружения, релевантные куски кода и идеальные артефакты (MCVE, минимальный пример, фрагменты логов).
Ошибка 3: просить diff, не задав структуру репозитория
Симптом: diff правдоподобен текстово, но не соответствует реальным путям/импортам.
Фикс: или давайте релевантные файлы/дерево, или требуйте вопросы перед генерацией патча.
Ошибка 4: отсутствие “контракта” на формат ответа
Симптом: результат нужно долго разбирать вручную.
Фикс: фиксируйте формат: “только unified diff в блоке”, “строго разделы A–E”, “без лишних пояснений”.
Заключение
Промптинг для разработчиков работает лучше всего не как магия, а как инженерная практика: вы задаёте модели контракт входа/выхода, фиксируете ограничения изменений, требуете план проверки и заставляете ответы быть структурированными и пригодными для использования в ревью, отладке и создании патчей.
Ваша цель — не получить «самый умный ответ», а сократить время от “у меня есть дифф/ошибка” до “у меня есть обоснованное решение: комментарий в PR или готовый патч с тестами”. Набор шаблонов, приведённый в статье, рассчитан именно на этот практический эффект: снижать хаос и повышать воспроизводимость результата.
Если хотите глубже разобраться в принципах и закономерностях построения таких диалогов с моделью, полезной отправной точкой может стать курс Промпт-инжиниринг: искусство разговора с ChatGPT — но даже без него вы можете использовать эти шаблоны как основу собственной библиотеки промптов и итеративно улучшать её под ваш стек и стиль разработки.
