TL;DR
VeriRefine — это метод, который заставляет модель сначала описать поведение каждого сигнала в отдельной строгой таблице, и только потом писать код. Вместо того чтобы сразу переводить спецификацию на Verilog (язык описания железа), модель для каждого сигнала фиксирует: тип логики, привязку к тактовому сигналу, поведение сброса, и список условий-действий — каждое из которых обязано ссылаться на буквальную цитату из исходного текста.
Главная проблема, которую нашли авторы: когда LLM пишет код прямо по описанию, она одновременно пытается понять задачу и писать код. Ошибка понимания тонет в коде и всплывает только при запуске — то есть слишком поздно, когда весь цикл генерации нужно начинать заново. Модель может, например, включить сигнал на цикл позже, чем требуется, потому что не разделила "что должно произойти" и "как это записать технически".
Метод решает это, вынося понимание в отдельный проверяемый шаг: сначала модель заполняет структурированную карточку по каждому сигналу (с цитатами-доказательствами из текста), эту карточку прогоняют через пять проверок на полноту и противоречия, и только после того как карточка "чистая" — генерируют код. Если код всё-таки не работает, ошибку классифицируют: это ошибка понимания (правим карточку) или ошибка кода (правим код) — и чинят именно там, где возникла проблема.
Схема метода
ШАГ 1: Классификация типа задачи → определяет какой шаблон карточки использовать (отдельный шаг/промпт)
ШАГ 2: Заполнение карточки по каждому сигналу → JSON-документ: тип логики + условия-действия + цитата-доказательство (один промпт)
ШАГ 3: Проверка карточки по 5 критериям (полнота, непротиворечивость, соответствие тексту и др.) → если есть нарушения — возврат на Шаг 2 с конкретной правкой
ШАГ 4: Генерация кода на основе проверенной карточки → готовый код
ШАГ 5: Тест кода → если не работает, определяем: ошибка в понимании (→ Шаг 2) или в самом коде (→ Шаг 4)
Все шаги выполняются в рамках одного диалога с моделью — это цепочка отдельных запросов, где вывод одного шага становится входом следующего.
Пример применения
Задача: Вы описываете дизайнеру или разработчику ТЗ на сложный сценарий — например, логику начисления кэшбэка в банковском приложении с кучей условий (разные категории трат, лимиты, периоды акций) — и хотите, чтобы перед написанием кода все правила были явно разложены и сверены с текстом ТЗ, а не додуманы.
Промпт:
Вот моё техническое описание логики начисления кэшбэка:
{текст ТЗ}
Прежде чем писать код, сделай следующее:
1. Найди в тексте все переменные/параметры, от которых зависит начисление кэшбэка
(категория, сумма, лимит, период и т.д.)
2. Для каждой переменной составь карточку:
- Тип: постоянная величина / зависит от условия / накопительная (меняется со временем)
- Условия и правила в порядке приоритета: если выполняется условие А — действие А,
иначе если условие Б — действие Б, и так далее
- Для каждого правила процитируй ТОЧНУЮ фразу из ТЗ, которая его подтверждает
3. Если для какого-то правила в тексте нет прямой цитаты — не выдумывай его,
а пометь как "требует уточнения"
4. Проверь карточки на противоречия между собой (например, два правила
не должны конфликтовать в одном случае)
5. Только после того как карточки готовы и проверены — переходи к написанию кода
Начни с шага 1.
Результат: Модель выдаст таблицу или список переменных с их карточками, где видно, откуда взято каждое правило. Вы сразу увидите, где модель что-то "додумала" без опоры на текст (это будет помечено), и сможете исправить ТЗ или подтвердить правило до того, как появится код. Затем модель пишет код на основе уже проверенной логики.
Почему это работает
LLM плохо совмещает два разных вида мышления одновременно: понимание смысла задачи и синтаксически точную запись решения. Когда модель делает это одним махом, ошибка понимания прячется внутри правильно выглядящего кода — и её не видно, пока код не сломается на практике.
Модель хорошо умеет следовать явной структуре и цитировать источник, если её об этом прямо попросить. Требование "процитируй точную фразу" заставляет модель либо найти реальное подтверждение в тексте, либо честно признать, что его нет — вместо того чтобы правдоподобно выдумать поведение.
Метод использует это: разделяет "понять" и "написать" на два отдельных шага с проверкой между ними. Ошибку понимания ловят на шаге проверки карточки — до того как она "зашита" в код, где её сложно найти.
Рычаги управления: - Число проверочных критериев (в оригинале — 5: полнота, непротиворечивость, соответствие тексту, целостность состояний, базовые правила) → можно сократить до 2-3 для простых задач, если не нужна такая строгость - Требование "цитируй точную фразу" → можно ослабить до "укажи откуда это взято" для нетехнических задач, где буквальное цитирование избыточно - Порядок приоритета условий → критично сохранять, если правила могут конфликтовать; для простых линейных сценариев можно убрать - Разделение ошибок на "ошибка понимания vs ошибка исполнения" при отладке → это ключевой принцип, применимый в любой задаче с проверкой результата: не чинить код наугад, а сначала спросить "это модель не поняла задачу или правильно поняла, но неправильно написала?"
Шаблон промпта
Вот моя задача с множеством условий и правил:
{описание задачи}
Прежде чем выполнять задачу, сделай так:
1. Выдели все ключевые переменные/сущности, от которых зависит результат.
2. Для каждой переменной составь карточку:
- Тип поведения: {постоянная / зависит от условия / накопительная}
- Список правил в порядке приоритета: если условие 1 — то действие 1,
иначе если условие 2 — то действие 2, и так далее
- Точная цитата из исходного текста, подтверждающая каждое правило
3. Если цитаты нет — не выдумывай правило, помечай как "требует уточнения".
4. Проверь все карточки на противоречия друг с другом.
5. Покажи мне карточки. Я подтвержу или поправлю их.
6. Только после моего подтверждения — выполняй задачу целиком.
Начни с шага 1 по тексту: {текст задачи}
Плейсхолдеры: {описание задачи} — краткое описание того, что нужно сделать; {текст задачи} — полный текст исходного документа (ТЗ, регламент, договор, сценарий).
🚀 Быстрый старт — вставь в чат:
Вот шаблон метода проверки понимания перед выполнением сложной задачи.
Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие переменные/сущности важны в твоей задаче и есть ли у тебя исходный текст для цитирования — потому что без этого невозможно построить карточки с доказательствами. Она возьмёт паттерн из шаблона и адаптирует под задачу.
Ограничения
⚠️ Нужен исходный текст для цитирования: метод работает только если есть письменный документ (ТЗ, регламент, спецификация), из которого можно брать точные цитаты. Для задач "придумай с нуля" без опорного текста метод не применим.
⚠️ Избыточен для простых задач: если правил мало и они не конфликтуют, дробление на карточки и проверки — трата времени и токенов. Метод раскрывается на задачах с множеством взаимосвязанных условий.
⚠️ Специфичен для технической области: оригинальный метод создан для генерации кода на Verilog (язык описания микросхем), где важна предельная точность привязки к тактам и сбросам. В саммари адаптация — под задачи с чёткими правилами, но не факт, что перенос сохранит всю силу метода для творческих или неоднозначных задач.
Ресурсы
VeriRefine: A Progressive Approach to Synthesizable RTL Design Generation Using LLMs. Xiangfei Kong, Tasnim Tabassum, Marwan Abdelwahab, Hao Zheng — University of South Florida. Тестировали на Claude Sonnet 4.6, бенчмарки RTLLM v2.0 и VerilogEval-Human v2.