TL;DR
Vibe-proving — это рабочий процесс итеративной проверки, где LLM не даёт финальный ответ за один запрос, а работает в цикле: сгенерировать черновик → попросить модель найти в нём дыры → починить конкретную дыру → повторить. Ключевое отличие от обычного "попроси и получи": каждый вывод модели считается кандидатом, а не истиной, пока не проверен.
Главная боль: Когда задача сложная — с развёрнутым анализом, аргументацией, юридическими деталями или стратегией — модель выдаёт уверенно звучащий текст, в котором спрятаны тихие ошибки. Пропущенное условие, неправильное следствие, недоказанное утверждение. Без специального процесса проверки эти дыры остаются невидимыми — и ты уходишь с красивым, но неверным результатом.
Метод решает это тремя рычагами: параллельные сессии (одну проблему отправляешь в несколько независимых чатов и сравниваешь ответы), ограниченные рефери-проходы (просишь "найди всё неверное" в свежем чате — но не бесконечно, это даёт убывающую отдачу), и версионирование (фиксируешь каждый исправленный черновик, чтобы новые правки не ломали уже проверенные части).
Схема метода
[Отдельные запросы / сессии ChatGPT или Claude]
ШАГ 1 — SCAFFOLDING (один запрос):
Дай модели: цель + контекст + известный подход к задаче
→ Получи: стратегию / план / структуру
ШАГ 2 — GENERATE (один запрос, та же или новая сессия):
Попроси черновик по стратегии из шага 1
→ Получи: первый кандидат-результат
ШАГ 3 — REFEREE (новая свежая сессия!):
Вставь черновик → попроси гиперкритический разбор
→ Получи: список конкретных дыр, пропущенных допущений, слабых мест
ШАГ 4 — PARALLEL REPAIR (несколько независимых сессий):
Возьми ОДНУ конкретную дыру из шага 3
Открой 2-3 отдельных чата → задай один и тот же вопрос
→ Принимай только патч, который: (а) повторяется в нескольких сессиях
или (б) ты можешь проверить сам
ШАГ 5 — VERSIONING + REPEAT:
Зафикисруй исправленную версию
Повтори шаги 3-4 для следующей дыры
→ Стоп-сигнал: рефери начинает находить мелочи вместо реальных ошибок
Шаги 3 и 4 всегда выполняются в отдельных свежих сессиях. Это принципиально — модель в новом чате не "помнит" своих предыдущих ошибок и даёт независимую оценку.
Пример применения
Задача: Ты готовишь инвестиционный меморандум для венчурного фонда по своему стартапу — доставка еды в B2B-сегменте (корпоративные обеды). Документ нужен на питч-сессии. Цена ошибки — провал перед инвесторами.
Промпт — Шаг 1 (Scaffolding):
Я готовлю инвестиционный меморандум для венчурного фонда.
Стартап: B2B-доставка корпоративных обедов в офисы в Москве.
Целевой инвестор: фонды стадии Pre-A, чек 30–80 млн рублей.
Известный шаблон структуры: Problem → Solution → Market → Traction →
Business Model → Team → Ask.
Вот мои данные: [вставь ключевые цифры и факты о своём стартапе]
Предложи стратегию того, как мне выстроить аргументацию,
чтобы каждый раздел усиливал следующий.
Где самые слабые места в типичных меморандумах такого типа?
Промпт — Шаг 3 (Referee, новая сессия):
Я — инвестор венчурного фонда. Передо мной инвестиционный меморандум стартапа.
Моя задача: найти все слабые места, противоречия, недоказанные утверждения
и пропущенные допущения — до того, как меморандум попадёт на питч-сессию.
Будь гиперкритичным. Не хвали. Составь список обязательств:
— что не доказано
— какие цифры требуют источника
— где логика рвётся
— что инвестор точно спросит, а я не отвечаю
Вот меморандум:
[вставь текущий черновик]
Промпт — Шаг 4 (Parallel repair, три отдельных чата):
В инвестиционном меморандуме есть конкретная проблема:
[вставь одну дыру из списка рефери — например:
"TAM посчитан без источников и выглядит взятым с потолка"]
Предложи как исправить именно этот фрагмент.
Вот контекст: [вставь только нужный кусок меморандума]
Требования к патчу:
— конкретная правка, не советы
— логика проверяема
— не меняй другие части документа
Результат: Модель в шаге 3 выдаст структурированный список дыр — конкретные пункты с объяснением почему это слабое место. В шаге 4 три независимых сессии предложат три варианта правки одного фрагмента. Ты смотришь: что повторяется в двух-трёх ответах — это надёжный патч. Что появляется только в одном — перепроверяешь сам. После 2-3 итераций документ будет закрывать большинство очевидных дыр до питча.
Почему это работает
LLM плохо проверяет себя в одном контексте. Когда модель генерировала черновик, она "выбрала" определённую логику и дальше её держится. Попросить критику в том же чате — всё равно что попросить автора найти ошибки в собственном тексте: он читает то, что хотел написать, а не то, что написал. Свежая сессия убирает этот контекстный якорь.
Параллельные сессии работают как независимые эксперты. Если три независимых "эксперта" (три сессии) сходятся на одном и том же патче — это сигнал надёжности. Если расходятся — значит, задача неоднозначна и требует твоего суждения. Это не магия: просто статистика вместо одной точки данных.
Ограниченный рефери — ключевой рычаг. После того как главные дыры закрыты, повторные "найди всё неверное" начинают возвращать стилистические придирки и ложные срабатывания. Это сигнал остановиться. Бесконечная критика = шум, не улучшение. Используй рефери-проход как диагностику, а не как молитву.
Рычаги управления: - Количество параллельных сессий → 2 дают проверку, 3+ дают статистику; больше 4 — убывающая отдача - Формулировка обязательства в шаге 4 → чем конкретнее дыра, тем точнее патч. "Что-то не так с числами" → плохо. "TAM в разделе 3 посчитан без методологии" → хорошо - Стоп-критерий рефери → сам определяешь: "остановись, когда рефери находит только мелочи" - Степень гиперкритичности → можно попросить "найди только критические ошибки" (быстро) или "найди всё, включая мелкие допущения" (глубоко)
Шаблон промпта
Scaffolding (Шаг 1):
Я работаю над {тип документа/задачи}.
Цель: {что должен делать финальный результат}
Контекст: {ключевые данные, ограничения, аудитория}
Известный подход: {шаблон / метод / структура, если знаешь}
Вот материал: {данные}
Предложи стратегию: как выстроить аргументацию?
Где типичные слабые места в задачах такого типа?
Referee (Шаг 3, новая сессия):
Ты — строгий эксперт в {область}. Твоя задача: найти всё неверное
в {тип документа} до того, как он попадёт к {аудитория}.
Будь гиперкритичным. Не хвали. Составь список:
— что не доказано или не обосновано
— где логика рвётся
— какие допущения пропущены
— что {аудитория} точно спросит, а я не отвечаю
Вот {тип документа}:
{текущий черновик}
Parallel Repair (Шаг 4, отдельный чат):
В {тип документа} есть конкретная проблема:
{одна дыра из списка рефери — максимально конкретно}
Предложи как исправить именно этот фрагмент.
Контекст: {только нужный кусок}
Требования:
— конкретная правка, не советы
— не меняй другие части
— объясни логику правки в одном предложении
Плейсхолдеры:
- {тип документа/задачи} — меморандум, стратегия, анализ, статья, договор
- {область} — инвестиции, юриспруденция, маркетинг, стратегия
- {аудитория} — инвестор, клиент, партнёр, редактор
- {одна дыра} — берёшь из вывода рефери, формулируешь максимально конкретно
🚀 Быстрый старт — вставь в чат:
Вот шаблон рабочего процесса vibe-proving для сложных аналитических задач.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит о типе задачи, аудитории и известных подходах к ней — потому что без этого она не сможет настроить scaffolding-промпт и правильно сформулировать роль рефери.
Ограничения
⚠️ Задачи без структуры: Метод работает лучше всего, когда есть конкретная цель и известный шаблон подхода. Если задача полностью открытая ("придумай что-нибудь интересное") — рефери-проход даст мало, потому что нет критерия правильности.
⚠️ Длинные алгебраические/технические развёртки: В сложных вычислениях модель систематически пропускает промежуточные шаги. Рефери это поймает, но починить такой фрагмент без внешней проверки (калькулятор, специалист) сложно — патчи тоже могут ошибаться.
⚠️ Убывающая отдача рефери: После 2-3 итераций повторные "найди всё неверное" начинают возвращать стилистические замечания вместо реальных ошибок. Не зацикливайся.
⚠️ Ты остаёшься проверяющим: Метод не заменяет твою экспертизу. Параллельные сессии дают сигнал надёжности, но финальное решение "принять патч или нет" — за тобой.
Как исследовали
Команда из Vrije Universiteit Brussel (Бельгия) и Harvard не планировала эксперимент заранее — они просто "вибировали" с ChatGPT-5.1 (Thinking) на реальной исследовательской задаче из теории матриц. Когда поняли, что модель предлагает жизнеспособный подход к нерешённой задаче, переключились на систематическую документацию.
Итог: 7 задокументированных ChatGPT-треда и 4 версии черновика доказательства — полностью аудируемые, с публичными ссылками на все сессии. Исследователи не просто получили результат — они зафиксировали каждый шаг, чтобы другие могли воспроизвести процесс.
Самый показательный момент: Лемма 4 заняла непропорционально много итераций — одно небольшое техническое обязательство ("в каком квадранте находится арктангенс?") потребовало отдельного треда и полной перестройки структуры аргумента. Это иллюстрирует ключевой вывод: узкое место — не генерация, а верификация. Модель быстро предлагает глобальную структуру, но застревает на нескольких технически сложных точках, которые человек должен проверять вручную.
Важное наблюдение о границах инструмента: когда исследователи просили "гиперкритичный обзор" снова и снова на финальных версиях, модель начинала находить стилистические замечания вместо реальных ошибок — сигнал остановиться, а не продолжать.
Оригинал из исследования
Авторы формулируют рекомендации практикам ("Checklist for Vibe-Proving"), раздел 4.6:
1. Start from scaffolding. Prefer problems where you can state a concrete
target theorem and where a recognizable reduction/template exists.
2. Turn critique into obligations. Convert "this seems wrong" into an
explicit obligation list (domains, branch conventions, positivity checks
before squaring/cross-multiplying, endpoints).
3. Use parallel patch search. Treat independent sessions as competing patch
generators; adopt only patches that you can verify locally.
4. Control regressions. Keep versioned drafts and re-check downstream
dependencies after each patch; prefer Lamport-style decomposition to
expose dependencies.
5. Mechanize the bottleneck. Offload expansions and inequality-domain checks
to CAS / certified checkers; reserve human time for conceptual choices
and boundary cases.
Контекст: Это итоговый чеклист из анализа 7 ChatGPT-сессий и 4 версий математического доказательства. Написан как практическое руководство для любого, кто использует LLM для сложных аналитических задач.
Адаптации и экстраполяции
1. Адаптация: Lamport-стиль для сложных документов
Авторы упоминают "Lamport-style decomposition" — запрос к модели сделать зависимости между частями документа явными.
💡 Адаптация для юридических договоров или стратегий:
Перепиши {документ} в Lamport-стиле:
— каждый пункт должен явно указывать, от каких предыдущих пунктов он зависит
— если пункт B следует из пункта A — напиши "Зависит от: пункт A"
— если пункт B противоречит пункту A — пометь как "Конфликт с: пункт A"
Цель: сделать логическую структуру видимой, чтобы я мог
проверять каждый элемент локально.
Вот документ:
{текст}
Это особенно ценно для длинных договоров и стратегических документов — где изменение одного пункта незаметно ломает другие.
2. Техника: превращай "что-то не так" в конкретное обязательство
🔧 Техника: Obligation Framing — от ощущения к задаче
Ключевой инсайт исследования: "это кажется неправильным" → бесполезно. "Вот конкретная проверка, которую нужно пройти" → полезно.
Промпт для трансформации:
У меня есть ощущение, что в {фрагмент} что-то не так,
но я не могу сформулировать что именно.
Помоги превратить это в список конкретных обязательств для проверки:
— что именно нужно проверить (да/нет)
— какое условие должно выполняться
— как узнать, что условие выполнено
Вот фрагмент: {текст}
После этого — берёшь каждое обязательство и запускаешь в параллельные сессии.
Ресурсы
Early Evidence of Vibe-Proving with Consumer LLMs: A Case Study on Spectral Region Characterization with ChatGPT-5.2 (Thinking)
Brecht Verbeken, Andres Algaba, Brando Vagenende, Marie-Anne Guerry, Vincent Ginis
Data Analytics Lab & imec-SMIT, Vrije Universiteit Brussel, Belgium; School of Engineering and Applied Sciences, Harvard University, USA
Препринт: February 24, 2026 | brecht.verbeken@vub.be
Публичные транскрипты: Transcript 1 · Transcript 2 · Transcript 3
Связанные работы: Ran & Teng (2024) — Conjecture 20; Dmitriev & Dynkin (1946) — тригонометрический метод; Карпелевич (1951)