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

Промпт для программирования — это спецификация, а не просьба. Модель не видела ваш проект, не знает, какую версию языка вы используете, и не может уточнить, что должно происходить при пустом вводе. Всё, что вы не указали, она заполнит самым частым вариантом из своих обучающих данных, а это часто не ваш вариант. Поэтому в материале Coddy разбирается, как строить запросы так, чтобы модель меньше угадывала. Пример строится из блоков роль, задача, контекст, ограничения и формат. Нужно попросить небольшую функцию parse_duration, которая превращает строку вида "1h30m", "45m", "2h" или "90s" в число секунд, где "1h30m" даёт 5400. В контексте перечисляются допустимые входы и порядок частей, в ограничениях — версия Python, только стандартная библиотека, ValueError с исходным вводом в сообщении при неверных данных и запрет десятичных значений вроде "1.5h". В формате — сначала функция, затем тесты pytest на примеры и три неверных входа, и не больше одного предложения объяснений. Четыре детали делают основную работу. Примеры с результатами дают модели, на чём проверить собственный код, и снимают вопросы о единицах. Версия языка и разрешённые библиотеки спасают от кода, который вы не сможете запустить. Указание, что считать неверным вводом и что тогда делать, закрывает обработку ошибок, которую модель легко опускает. Просьба о тестах превращает «выглядит правильно» в то, что можно выполнить: если тест падает, вы возвращаете ошибку в диалог, и это гораздо полезнее, чем «не работает». Отдельно отмечена проверка на пустые группы совпадений: шаблон подходит и к пустой строке, ведь каждая часть необязательна, и именно строка про пустой ввод заставляет этот случай появиться в коде. Далее говорится о версии, стеке и существующем коде. Модели тянутся к стилю, который чаще встречался в обучающих данных: в JavaScript это может быть require в проекте с ES-модулями, в Python — устаревший API библиотеки (частый пример — Pydantic 1 против 2), а в быстро меняющихся фреймворках — шаблоны двухлетней давности. Одна строка про версию Node и модули обычно снимает проблему. Если вы добавляете что-то в существующий проект, модели нужно показать те части, которых касается новый код: сигнатуру функции, форму данных, файл с вашими соглашениями. Лишние файлы лучше не прикладывать: каждую постороннюю строку модель может попытаться переиспользовать. Главная ошибка «vibe coding» — просить всё приложение сразу. Тогда модели приходится в одном ответе выбрать фреймворк, базу данных, структуру папок и десяток функций, и в ответ часто приходит только набросок: например, структура проекта с React, Node.js, Express и MongoDB, где настоящая работа оставлена комментариями. Маленький шаг даёт код, который можно запустить и на который можно опереться дальше, вставив в следующий запрос текущую версию файла. Это ручное связывание промптов: вывод одной просьбы становится отправной точкой следующей. Для всего крупнее одной функции стоит сначала попросить план — какие файлы будут изменены и что даст каждая правка, без кода, — потому что план читается и правится быстро. Проверять результат всё равно нужно: модель может вызвать несуществующую функцию или импортировать несуществующий пакет с правдоподобным именем, поэтому неизвестные импорты смотрят до установки. Бывают и тихие пограничные случаи вроде падения на пустом списке — их дешевле всего закрыть, перечислив их в промпте и попросив тесты. И осторожность с правками в длинных файлах: при просьбе что-то исправить модель может заодно переименовать или переставить лишнее.