TL;DR
Когда просишь LLM написать код с пожеланием по качеству вроде "сделай быстро" или "обрабатывай ошибки правильно" — результат скачет от попытки к попытке. Если вместо одной фразы дать детальное описание с конкретными правилами и критериями проверки, код становится чище и предсказуемее, а разброс результатов между разными формулировками запроса резко падает.
Однострочные пожелания типа "напиши эффективный код" оставляют слишком много места для угадывания: модель каждый раз по-разному трактует, что значит "эффективно". Хуже — если настойчиво просить "правильно обрабатывать ошибки", модель начинает добавлять избыточные проверки и try/except, которые меняют поведение программы и могут сломать тесты, ожидающие точный результат.
Метод прост: вместо одной фразы про качество дай модели структуру из трёх частей — что это качество значит для задачи, конкретные правила (2-4 пункта), и измеримые критерии проверки, привязанные именно к этому качеству (а не к "прохождению тестов"). Причём формат — обычный текст или JSON — роли не играет. Важно содержание, не упаковка.
Схема метода
ШАГ 1: Назови качество, которое хочешь получить → фраза (например, "читаемость")
ШАГ 2: Опиши смысл — что это значит именно для этой задачи → 1-2 предложения
ШАГ 3: Перечисли конкретные правила (императивные требования) → список 2-4 пункта
ШАГ 4: Задай критерии приёмки — измеримые, привязанные к качеству, НЕ к "тесты прошли" → список
Все четыре шага — в одном промпте, вместе с самой задачей на код.
Пример применения
Задача: Владелец небольшого интернет-магазина просит Claude написать Python-скрипт для обработки файла с заказами (CSV), и хочет, чтобы через полгода в этом коде можно было легко разобраться и что-то поправить — сам он не программист, но код будет отдавать фрилансеру на доработку.
Промпт:
Напиши функцию на Python, которая читает файл orders.csv (колонки:
дата, клиент, товар, сумма) и выводит сводку продаж по товарам за месяц.
Дополнительно — требование к качеству кода:
Качество: поддерживаемость
Смысл: код должен легко читаться и редактироваться человеком, который
видит его первый раз — например, фрилансером, который будет его чинить.
Правила:
- Разбей логику на отдельные функции с одной задачей каждая
- Не делай вложенность условий и циклов больше 2 уровней
- Используй понятные имена переменных, а не x, tmp, data1
Критерии приёмки:
- Каждая функция помещается на экран без скролла
- Нет повторяющихся блоков кода (copy-paste)
- У каждой функции есть короткий докстринг, что она делает
Результат: Модель выдаст код, разбитый на небольшие функции с докстрингами, без глубокой вложенности условий — заметно понятнее, чем если просто попросить "напиши чистый код". При этом правильность самой логики (верно ли считаются суммы) метод напрямую не гарантирует — это нужно проверять отдельно, тестовыми данными.
Почему это работает
Одна фраза "сделай код качественным" — слишком расплывчата. Модель каждый раз по-своему решает, что это значит, и результат непредсказуем.
LLM хорошо следует конкретным, разбитым на пункты инструкциям — чёткие правила и измеримые критерии оставляют меньше места для угадывания.
Метод разбивает мутное пожелание на три чётких компонента (смысл + правила + проверка), и модель перестаёт "гадать", а начинает выполнять конкретный список условий — отсюда меньший разброс между разными формулировками одной и той же задачи.
Рычаги управления: - Название качества → замени на своё ("производительность", "безопасность", "простота использования") - Список правил → добавляй/убирай пункты под конкретную задачу - Критерии приёмки → делай их измеримыми: не "код должен быть хорошим", а "функция не длиннее 20 строк"
🔧 Осторожно с "обработкой ошибок": если тебе важен точный результат работы кода, а не только устойчивость к сбоям — не проси слишком настойчиво "обрабатывать все ошибки". Модель может начать перехватывать исключения там, где ты не ожидал, и это поменяет поведение программы.
Шаблон промпта
{твоя задача на код}
Дополнительно — требование к качеству кода:
Качество: {название качества, например "читаемость" или "надёжность"}
Смысл: {что это значит для этой конкретной задачи, 1-2 предложения}
Правила:
- {правило 1}
- {правило 2}
- {правило 3}
Критерии приёмки:
- {как проверить, что качество достигнуто — конкретно и измеримо}
Подставь свою задачу в {твоя задача на код}, а качество и правила — под то, что важно именно тебе (скорость, читаемость, устойчивость к ошибкам ввода и т.д.).
🚀 Быстрый старт — вставь в чат:
Вот шаблон структурированного требования к качеству кода. Адаптируй под мою
задачу: {твоя задача}. Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какое именно качество тебе важно (скорость? читаемость? надёжность?) и что оно значит для твоей задачи — потому что без этого правила и критерии будет невозможно написать конкретно.
Ограничения
⚠️ Не улучшает правильность работы кода: если важно, чтобы код давал именно нужный результат на конкретных данных — детальное требование к качеству это не гарантирует. Для этого нужны отдельные тесты на реальных примерах.
⚠️ Обработка ошибок может навредить: подробное требование "правильно обрабатывай ошибки" иногда заставляет модель добавлять избыточные защитные проверки, которые меняют ожидаемое поведение программы.
⚠️ Формат не важен: не трать время, превращая требования в JSON или таблицы — обычный подробный текст работает так же хорошо, как структурированный формат.
⚠️ Проверено на небольших самодостаточных задачах (алгоритмические функции вроде "напиши функцию сортировки"). Для больших реальных проектов с множеством файлов эффект не проверялся.
Как исследовали
Исследователи взяли модель gpt-5.4 и попросили её решить 164 стандартные программистские задачки (HumanEval) четырьмя способами формулировки требований к качеству: обычная одна строка ("избегай code smell"), подробный текст на основе стандарта ISO/IEC 25010, и тот же самый контент, но упакованный в JSON. Для каждого варианта прогнали 10 разных формулировок запроса, чтобы проверить, насколько сильно результат зависит от того, как именно сформулирован промпт.
Сравнивали по двум осям: правильно ли решена задача (по тестам) и насколько чистый получился код (по показаниям статического анализатора — сколько "грязных" паттернов и нечитаемых конструкций).
Самое интересное: подробные требования снизили разброс результатов между формулировками и почистили код, но не сделали его более правильным — а для требования "обрабатывай ошибки" даже слегка снизили правильность, потому что модель начинала добавлять защитные конструкции, конфликтующие с точными тестами. Это и есть главный практический вывод: детальность помогает с качеством, но не с корректностью, и для "надёжности" нужно быть особенно аккуратным.
Ресурсы
Pereira, J. P. M., Garcia, V. C. — Does ISO-Grounded NFR Specification Improve LLM Code Generation? (SBCARS 2026, Universidade Federal de Pernambuco, Brazil). Опирается на методологию RobuNFR и стандарт ISO/IEC 25010:2023.