Хороший промт для написания кода содержит цель, минимальный контекст, ограничения, примеры входа и выхода, критерии приёмки и команду проверки. Просите сначала короткий план, затем патч и тесты. Не заменяйте точные требования фразами «сделай красиво» или «напиши лучший код».
Модель не видит замысел автора, если его нет в сообщении или доступном репозитории. Чем шире формулировка, тем больше решений выглядят допустимыми. Сильный промт сужает пространство: указывает язык и версию, существующий интерфейс, файлы в области изменения, нежелательные зависимости и наблюдаемый результат. После первого ответа промт уточняют по фактическому расхождению, а не начинают заново.
Технологии, версия, файл и существующий контракт.
Что должен увидеть тест, API или пользователь.
Команды тестов, линтера и негативные сценарии.
Промты для написания кода: универсальный шаблон
Скопируйте структуру и замените квадратные скобки фактами проекта. Если модель работает внутри репозитория, всё равно укажите конкретные файлы и запрет на несвязанные изменения. Для маленькой задачи план может занимать три пункта. Для исправления бага добавьте точный текст ошибки и воспроизводимый сценарий.
Задача:
[одно наблюдаемое изменение]
Контекст:
- язык и версия: [например, Python 3.12]
- файлы в области: [paths]
- существующий контракт: [входы, выходы, API]
Ограничения:
- не добавляй зависимости
- не меняй публичный интерфейс
- комментарии пиши по-русски
Критерии приёмки:
1. [позитивный сценарий]
2. [негативный сценарий]
3. [граничное значение]
Проверка:
- выполни [команда тестов]
- покажи изменённые файлы и остаточные риски
Сначала дай план из 3 пунктов, затем внеси минимальный патч.- Ответ ограничен нужными файлами и содержит тестируемый результат
- Расхождения можно указать одной короткой итерацией
Для генерации новой функции приложите сигнатуру и два примера. Для бага добавьте expected и actual. Для рефакторинга зафиксируйте поведение, которое нельзя менять. Если ответ слишком большой, не просите «короче» абстрактно. Укажите формат: только diff, таблица решений или список из пяти рисков. Официальные рекомендации по prompting также советуют отделять инструкции от входного контекста и показывать желаемый формат примером.
Три промта под разные задачи
| Элемент | Что означает | Что делать |
|---|---|---|
| Новая функция | Сигнатура, примеры, сложность | Код плюс unit-тесты |
| Исправление бага | Ошибка, шаги, expected/actual | Минимальный патч и регресс-тест |
| Рефакторинг | Инварианты и границы | Та же функциональность, чище структура |
| Code review | Diff и стандарты | Замечания по приоритету с файлами |
| Объяснение | Уровень читателя | Трассировка на одном входе |
Просьба «думай пошагово» не заменяет исходные данные. Для современных reasoning-моделей часто полезнее чёткий результат и ограничения, чем длинные общие инструкции. Добавляйте только контекст, который влияет на решение. Большой дамп репозитория ухудшает фокус и увеличивает стоимость или память локальной модели.
Практика: соберите промт по шаблону и проверьте патч своей командой тестов
Возьмите одну маленькую задачу в своём репозитории, например функцию разбора даты из строки. Напишите два промта: слабый в одну фразу и структурированный с блоками Задача, Контекст, Ограничения, Критерии приёмки и Проверка. Успех: у структурированного промта патч проходит вашу команду тестов за одну-две итерации и не трогает лишние файлы.
- Задача одним изменением. В блоке Задача опишите одно наблюдаемое изменение: какая функция, какой вход, какой выход и что она делает на мусорной строке. Слов вроде красиво и лучший код в этом блоке быть не должно.
- Контекст: версия и файлы. Заполните контекст: язык и версия, конкретные пути файлов в области изменения и существующий контракт с сигнатурой и типом возврата. После этого ответ перестаёт расползаться по соседним модулям.
- Ограничения без новых зависимостей. Добавьте запреты: не добавлять зависимости, не менять публичный интерфейс, комментарии писать по-русски. Если в патче всё равно появился сторонний пакет, ограничение сформулировано слишком мягко или утонуло в лишнем контексте.
- Три критерия приёмки. Пропишите позитивный сценарий, негативный и граничное значение, например заведомо несуществующую дату. Теперь у ответа есть проверяемая цель, а не общее ощущение готовности.
- Команда проверки и план. Закончите блоком Проверка: команда тестов, показать изменённые файлы и остаточные риски, сначала план из трёх пунктов, потом минимальный патч. Прогоните команду тестов сами: зелёный прогон и есть результат промта.
Сломайте промт намеренно: уберите блок критериев приёмки и повторите ту же задачу. В ответе останется только счастливый путь, разбор корректной строки будет, а поведение на пустом вводе и на несуществующей дате придётся дописывать руками. Вторая проверка: замените весь контекст на роль вида ты гениальный senior и посмотрите, как патч уходит в чужие файлы и лишние абстракции. Верните блоки на место и сравните два патча по числу правок.
Дальше сделайте три заготовки под разные задачи: новая функция с сигнатурой и двумя примерами, баг с текстом ошибки, шагами воспроизведения и регресс-тестом, рефакторинг со списком инвариантов. Для code review просите замечания по приоритету со ссылкой на файлы, для объяснения кода просите трассировку на одном входе. Контекст держите узким: дамп всего репозитория ухудшает фокус и раздувает стоимость или память локальной модели. Токены, ключи и персональные данные в промт не вставляйте, используйте безопасные примеры и placeholders.
Частые ошибки и почему они появляются
Плохой промт часто пытается описать роль модели вместо задачи: «ты гениальный senior». Это не сообщает контракт. Другая ошибка состоит в просьбе написать весь проект одним ответом. Третья появляется, когда пользователь принимает код без запуска и просит модель оценить собственную корректность тем же контекстом.
API библиотек меняются. Укажите язык, runtime и существенные версии зависимостей.
Без него модель оптимизирует только счастливый путь и пропускает ошибки данных.
Не вставляйте токены и персональные данные. Используйте безопасные примеры и placeholders.
Самопроверка
Что важнее в промте: роль senior или контракт задачи?
Роль вида ты гениальный senior не сообщает модели ни входов, ни выходов, ни границ изменения. Работают точная задача, версия языка, файлы в области, запреты и критерии приёмки, потому что именно они сужают пространство допустимых решений.
Как исправить неверный ответ модели?
Неверный ответ правят по факту: покажите конкретное расхождение expected и actual и попросите тест, который его фиксирует. Переписывать промт с нуля не нужно, достаточно уточнить одно место, где ответ разошёлся с ожиданием.
Зачем в промте команда проверки?
Команда проверки превращает ответ из правдоподобного текста в воспроизводимый результат: вы запускаете тесты и видите зелёный прогон или конкретное падение. Без неё код принимают по внешнему виду, а модель оценивает саму себя тем же контекстом, в котором ошиблась.
Сколько кода давать модели в контексте?
В контекст идут только файлы и интерфейсы, которые влияют на решение, плюс текст ошибки и сценарий воспроизведения. Большой дамп репозитория ухудшает фокус ответа и заметно увеличивает стоимость или расход памяти локальной модели.
Помогает ли фраза думай пошагово?
Фраза думай пошагово не заменяет исходные данные: без контракта и ограничений модель подробно рассуждает не о том. Для современных reasoning-моделей полезнее чёткий ожидаемый результат, границы изменения и пример нужного формата ответа.
Можно ли вставлять в промт ключи и данные клиентов?
Токены, ключи и персональные данные в промт вставлять не надо, даже во время быстрой отладки. Замените их placeholders и безопасными примерами: для задачи важна структура данных, а не реальные значения.
Что делать дальше
Возьмите одну небольшую задачу и прогоните слабый и структурированный промт. Сравните число правок, тесты и остаточные вопросы. Практиковать реальные функции и тесты можно на курсе GenAI. Следом разберите обучение с AI и локальную работу в VS Code.