TL;DR
Когда просишь LLM проверить что-либо, результат кардинально зависит от одного: есть ли у модели явный список требований или она ищет проблемы "на глаз". Дать модели конкретный список правил и попросить проверить каждое по отдельности — не просто лучше, а на порядок лучше. Это работает везде, где есть критерии оценки: код, документы, планы, тексты.
Главная находка — модель, которой говорят "проверь граничные случаи" без явных правил, находит лишь часть проблем. Не потому что ленивая, а потому что не знает что именно пропустил автор. Она угадывает — и угадывает правильно примерно в половине случаев. Хуже всего то, что промахи происходят именно там, где автор сам что-то забыл: неочевидные случаи, которые никто не формулировал явно.
Решение простое: вместо "найди проблемы" — "вот список N конкретных требований, проверь каждое по очереди". Контент спецификации — вот что делает всю работу. Даже обычный абзац с требованиями лучше, чем развёрнутая инструкция "думай о крайних случаях". А структурированный список на порядок эффективнее абзаца.
Схема метода
ШАГ 1: Составить спецификацию → явный список требований (N правил)
Можно в отдельном запросе: "Дай список критериев для [задачи]"
ШАГ 2: Передать модели спецификацию + проверяемый материал
→ Для каждого правила: найти нарушение или подтвердить соответствие
→ Вывод: конкретные нарушения с указанием правила
ШАГ 3: Исправить материал на основе найденных нарушений
→ Только целевые правки, не переписывать всё с нуля
Шаги 1 и 2 можно объединить в одном запросе, если критерии уже известны. Если нет — сначала получи список критериев, потом запускай проверку.
Пример применения
Задача: Написал коммерческое предложение для крупного клиента на 200 тыс. рублей. Хочу проверить перед отправкой — не хочу слышать "в целом хорошо", хочу знать что конкретно не так.
Промпт:
Ты — опытный менеджер по продажам, который оценивает коммерческие предложения перед отправкой клиенту.
Вот список требований к сильному КП:
1. Чётко сформулирована боль клиента — не наш продукт, а его проблема
2. Конкретный измеримый результат (цифры, сроки, единицы)
3. Объяснено ПОЧЕМУ именно мы, а не конкуренты
4. Прозрачная структура цены — клиент понимает за что платит
5. Указан конкретный следующий шаг с дедлайном
6. Нет корпоративного канцелярита ("осуществляем", "в рамках", "является")
7. Объём — не больше одной страницы A4
Проверь моё КП против каждого из этих 7 правил по очереди. Для каждого правила: статус (✅ выполнено / ⚠️ частично / ❌ нарушено) и конкретное пояснение что именно не так.
Вот КП:
[текст коммерческого предложения]
Результат:
Модель пройдёт по каждому из 7 правил отдельно. Для каждого — статус и конкретика: не "слабовато описан результат", а "в правиле 2 отсутствуют цифры — написано 'повысим эффективность', но не указано на сколько процентов и за какой срок". В конце — список именно тех мест, которые нужно переписать, с указанием правила.
Почему это работает
LLM без явных критериев — как редактор, которому сказали "проверь текст". Он проверит то, что сам считает важным. Если автор забыл указать цену — редактор может пропустить это, потому что в его картине мира цена "обычно есть". Модель не знает, что именно автор пропустил — она не телепат.
Когда даёшь явный список правил, происходит другое: каждое правило становится отдельным запросом проверки. Модель не выбирает что проверять — она проверяет всё. Неочевидный случай ("а что если клиент зашлёт пустую строку?") становится явным ("правило 4: обработка пустого ввода"). Модель не может его пропустить.
Рычаги управления промптом: - Количество правил → 5–10 оптимально. Меньше — пропустишь важное. Больше 15 — модель начинает быть менее внимательной к каждому - Детализация правил → Чем конкретнее формулировка ("цифры и сроки" вместо "конкретика"), тем точнее проверка - Формат вывода → Добавь "выведи только нарушения" для быстрого результата или "выведи всё с объяснениями" для полного аудита - Источник правил → Правила можно взять из стандарта, методологии, чеклиста клиента — и они уже будут явными критериями
Шаблон промпта
Проверь {что проверяем} против следующего списка требований.
Требования:
1. {требование_1}
2. {требование_2}
3. {требование_3}
[... все требования]
Для каждого требования по очереди:
- Статус: ✅ выполнено / ⚠️ частично / ❌ нарушено
- Конкретное объяснение: что именно не так (если не выполнено)
- Цитата из материала, которая демонстрирует проблему (если применимо)
В конце — краткий список правок: что именно переписать и как.
Вот материал для проверки:
{текст / план / документ}
Плейсхолдеры:
- {что проверяем} — "коммерческое предложение", "продуктовое ТЗ", "статью", "бизнес-план"
- {требование_N} — конкретные критерии под задачу (можно попросить LLM сначала сгенерировать список)
- {текст / план / документ} — сам материал для проверки
🚀 Быстрый старт — вставь в чат:
Вот шаблон Specification Grounding — проверки материала против явного списка критериев.
Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какой материал проверяем и есть ли у тебя критерии — потому что без списка требований метод не запустится. Если критериев нет, она сначала предложит их сгенерировать под твою задачу, а потом применит шаблон проверки.
Ограничения
⚠️ Алгоритмическая логика: Метод помогает там, где есть спецификация — чёткие требования к поведению. Для задач, где главная трудность в алгоритме ("придумай как оптимизировать..."), а не в соблюдении правил — эффект минимален или отсутствует.
⚠️ Качество спецификации: Если правила неполные или размытые — результат такой же. "Текст должен быть хорошим" — не правило. "Каждый абзац начинается с тезиса, который объясняется в следующих предложениях" — правило.
⚠️ Ложные тревоги без спецификации: Без явных правил LLM не только пропускает реальные проблемы, но и чаще указывает на несуществующие. В исследовании — 33% ложных тревог у "проверяй края" против 0% у проверки по правилам. Правила дают модели якорь: "это нарушение правила N" вместо субъективного суждения.
⚠️ Субъективные критерии: Если правила описывают вкус или стиль ("текст должен быть живым"), модель будет менее точной, чем с объективными критериями.
Как исследовали
Команда из TD Bank поставила изящный эксперимент: одна переменная, всё остальное зафиксировано. Взяли 18 задач на написание небольших функций Python. Каждую функцию генерировала LLM — и почти всегда делала правильно для обычных случаев, но забывала краевые. Дальше запускали два подхода проверки на одном и том же коде: FREE+ ("проверь граничные случаи") и SPEC (тот же тестировщик, та же модель, тот же бюджет тестов — но с явными правилами). Правильность определял независимый "золотой" тест-сьют, который модели никогда не видели.
Что удивило: удвоение количества тестов дало почти ноль (+4 пп). Объединение 8 независимых наборов "проверяй края" — не дотягивало до одного прохода по правилам. Исследователи ожидали, что количество поможет — нет. Помог только контент спецификации.
Дополнительно проверили: может, дело в формате, а не в содержании? Дали модели спецификацию одним связным абзацем (не списком) — она всё равно нашла 27 из 30 проблем. Дали только план задачи без спецификации — 2 из 30. Это ответ на вопрос "почему": модель не додумывает что автор пропустил. Ей нужно явно сказать.
Эффект воспроизвёлся на трёх семействах моделей (Claude, GPT, Gemini) и на задачах, спецификации для которых брались из публичных стандартов (RFC, CSS, ISO) — то есть исследователи не могли "подыграть" методу, придумывая удобные правила.
Оригинал из исследования
SPEC arm prompt structure (from paper §3.3):
- Receives: the prose ticket + the specification enumerated into K discrete rules
- Task: write one test per rule
- Expected value: computed from the ticket/rules, never from the candidate code
FREE+ arm prompt structure (fair baseline):
- Receives: only the ticket
- Additional instruction: "cover invalid inputs and edge cases"
- Same K tests, same tester model, same repair loop
Key ablation results (§4.2):
- Plan only (task decomposition, no spec): 2/30 bugs caught
- Spec as plain paragraph: 27/30 bugs caught
- Spec as enumerated checklist (one test per rule): 30/30 bugs caught
Контекст: Исследователи показывают точные промпт-структуры двух comparisons — SPEC и FREE+. Разница между ними ровно одна строка: наличие спецификации как чеклиста. Аблация показывает, что не формат (список vs абзац), а именно контент спецификации несёт 90% эффекта.
Адаптации и экстраполяции
1. Адаптация: генерация спецификации перед проверкой
Если правил нет — попроси LLM их придумать, потом примени.
💡 Двухшаговый SPEC:
Шаг 1:
Я хочу проверить {что проверяем} перед финальной версией. Составь список из 7-10 конкретных, проверяемых критериев качества для {тип материала}. Каждый критерий должен быть объективным: можно ответить ДА или НЕТ.Шаг 2: используй полученный список в основном шаблоне проверки.
2. Техника: "SPEC для оппонента"
🔧 Используй требования клиента/аудитории как спецификацию → проверка с их позиции
Вместо своих критериев — явные возражения или требования другой стороны:
Вот список типичных возражений инвестора на питч-сессии в России: 1. Рынок слишком маленький — меньше 1 млрд рублей 2. Нет защиты от копирования крупным игроком (Яндекс, Сбер) 3. Юнит-экономика не сходится при масштабировании 4. Команда без опыта в этой индустрии 5. Зависимость от одного канала привлечения клиентов Проверь мой питч против каждого возражения. Для каждого: закрыто ли оно в питче и насколько убедительно?
3. Экстраполяция: SPEC + итеративное улучшение
Стандартный SPEC — проверка и список правок. Можно добавить петлю исправления:
[Промпт SPEC-проверки]
После проверки: исправь все пункты со статусом ❌ и ⚠️.
Выведи исправленную версию и список изменений.
Потом пройди по списку требований ещё раз — убедись, что все ❌ стали ✅.
Это аналог repair loop из исследования — только в одном диалоге. LLM сначала находит нарушения, потом чинит, потом перепроверяет себя.
Ресурсы
Статья: "Specification Grounding Drives Test Effectiveness for LLM Code"
Авторы: Amin Haeri, Mahdi Ghelichi — Model Development Innovation, TD Bank, Toronto, Canada
Контакты: amin.haeri@td.com, mahdi.ghelichi@td.com
Связанные работы, упомянутые в статье: - AlphaCodium (Ridnik et al., 2024) — итеративная генерация кода с тестами - Self-Refine (Madaan et al., 2023) — самокоррекция LLM - Reflexion (Shinn et al., 2023) — итерация на основе обратной связи - EvalPlus (Liu et al., 2023) — расширенные тест-сьюты для оценки кода - TiCoder (Lahiri et al., 2022) — формализация намерения через тесты с участием человека