Исследователи взяли 164 задачи по программированию и переписали их в четыре разных формата: обычный текст, JSON, Markdown, YAML. Пятый вариант — промпты, которые «улучшила» другая нейросеть (Mistral). Каждый промпт прогнали через GPT-4o 10 раз, чтобы проверить, насколько стабильны ответы. Итог: структурированный формат (особенно JSON) ускоряет генерацию кода и делает ответы более похожими друг на друга, но почти не влияет на то, правильно ли код решает задачу.
Главная боль, которую нашли: когда просишь одну модель «улучшить» технический промпт для другой модели, результат становится хуже — заметно хуже, а не «чуть-чуть». Причина простая: при переформулировании модель меняет мелкие детали формулировки задачи (примеры, ограничения, формат вывода), а для кода эти детали критичны — в отличие от текстовых задач, где перефразирование обычно не страшно.
Вывод из этого: если задача техническая и точная — не давай AI «улучшать» твой промпт. Зато можно просто переупаковать промпт в чёткую структуру (списки полей: описание, входные данные, примеры, ограничения) — это не меняет смысл, но помогает модели быстрее и стабильнее выдавать результат.
Схема метода
ШАГ 1: Возьми задачу для кода как есть (сохрани смысл) → не меняй формулировки
ШАГ 2: Разбей на явные поля → «Описание», «Входные данные», «Примеры», «Ограничения»
ШАГ 3: Оформи как структурированный список или JSON-подобный блок → консистентный формат
ШАГ 4 (чего делать НЕ надо): Не проси другую модель «сделать промпт лучше» → риск потерять точные детали задачи
Все шаги — это редактирование одного промпта, без диалога и без агентов.
Пример применения
Задача: Вы просите Claude или ChatGPT написать скрипт для автоматизации — например, парсер, который вытаскивает цены товаров с Ozon и складывает в таблицу.
Промпт (плохой вариант, размытый текст):
Напиши скрипт на Python, который парсит цены товаров с сайта Ozon
по ссылкам из списка, и цена должна быть с рублями, а ещё нужно
чтобы он не падал если товар не найден, и сохранял в CSV файл,
названия колонок сделай понятные.
Промпт (структурированный, по принципу из исследования):
Задача: написать скрипт на Python для парсинга цен товаров.
Описание: скрипт принимает список URL товаров Ozon и извлекает цену.
Входные данные: список URL (строки) в файле urls.txt.
Ожидаемый результат:
- CSV-файл result.csv с колонками: url, название_товара, цена_руб
- Если товар не найден — строка с пометкой "не найдено", без падения скрипта
Ограничения:
- Цена — только число в рублях, без символов
- Использовать библиотеки requests и BeautifulSoup
Результат: Модель получает точное, однозначное техническое задание вместо потока смешанных требований. Ответ придёт быстрее и будет более предсказуемым, если вы зададите тот же вопрос повторно — код с меньшей вероятностью «поплывёт» по структуре между запросами.
Почему это работает
LLM генерирует код, опираясь на паттерны из обучающих данных — а огромная часть технической документации, API-спецификаций и багтрекеров написана в структурированном виде: списки полей, JSON, таблицы. Когда промпт выглядит так же — модели легче «узнать» задачу и меньше приходится угадывать, что относится к описанию, а что к примеру.
Слабость модели — она чувствительна к тому, как сформулирован запрос, даже если смысл не меняется. Особенно опасно для кода: там даже незначительная перефразировка примера или условия может привести к другому пониманию задачи. Текстовые задачи (вопрос-ответ) переносят перефразировку легче — код нет.
Рычаг управления: если хотите более стабильный результат при повторных запросах на кодовые задачи — не переписывайте промпт своими словами каждый раз, а держите один структурированный шаблон и просто меняйте в нём данные (как плейсхолдер).
Шаблон промпта
Задача: {краткое название задачи}
Описание: {что должен делать код, без деталей реализации}
Входные данные: {что подаётся на вход — формат, тип}
Ожидаемый результат: {что должно получиться на выходе — формат, тип}
Примеры:
- Вход: {пример входа} → Выход: {пример выхода}
Ограничения: {что нельзя делать, какие библиотеки использовать/не использовать, обработка ошибок}
Подставьте свою задачу в каждое поле. Главное — не просите другую модель «улучшить» этот промпт, если задача техническая и точная. Формулируйте сами или адаптируйте вручную.
🚀 Быстрый старт — вставь в чат:
Вот шаблон структурированного промпта для кодовой задачи. Заполни поля
под мою задачу: {твоя задача}. Задавай вопросы, если чего-то не хватает.
[вставить шаблон выше]
LLM спросит про входные данные, ожидаемый формат результата и ограничения — потому что без этих полей структура промпта неполная, а именно она даёт эффект стабильности.
Ограничения
⚠️ Эффект на качество решения минимальный: форматирование ускоряет генерацию и делает ответы более похожими друг на друга, но почти не увеличивает долю правильных решений. Не ждите, что просто переформатировав промпт, вы получите принципиально лучший код.
⚠️ Проверено только на коротких задачах и одной модели: исследование тестировало GPT-4o на компактных функциях Python (задачи типа HumanEval). Для больших проектов или других моделей эффект может отличаться.
⚠️ «Улучшение» промпта чужой моделью — риск, не гарантия: если вы просите нейросеть переформулировать точное техническое задание, есть шанс, что она незаметно исказит детали — итоговый код может работать хуже, даже если промпт выглядит «более грамотно».
Как исследовали
Команда взяла классический датасет HumanEval — 164 задачи на Python — и сделала из него пять версий: обычный текст, JSON, Markdown, YAML и версию, переписанную моделью Mistral. Каждую из 164 задач в каждом формате прогнали через GPT-4o 10 раз подряд в «чистом» чате без истории — всего 8200 запросов. Замеряли: сколько ответов проходят тесты (правильность), сколько времени уходит на генерацию и проверку кода, и насколько похожи друг на друга 10 ответов на один и тот же промпт (метрика ROUGE-L — совпадение по подстрокам текста).
Результат удивил в двух местах. Во-первых, JSON оказался самым «удобным» форматом для модели — быстрее и стабильнее, хотя интуитивно кажется, что человекочитаемый Markdown должен быть лучше. Во-вторых, версия промптов, «улучшенная» другой LLM, оказалась худшей по качеству решений — при том что цель тюнинга была прямо противоположной. Вывод исследователей: автоматическое переформулирование промпта нейросетью — не безопасная операция для точных задач, оно может незаметно потерять критичные детали.