TL;DR
Когда вы делите сложную задачу на части и просите LLM выполнять их по отдельности — в разных запросах или через разные роли — каждый запрос решает свою часть независимо, без знания о том, какие форматы и структуры выбрала модель в других частях. Это создаёт разрыв совместимости: каждая часть правильная сама по себе, но вместе они не работают.
Главная ловушка: когда части не совпадают, мы инстинктивно показываем модели противоречия — «вот что не сходится, исправь». Это не работает. Исследование показало: добавление отчёта о конфликтах к запросу на исправление даёт нулевой эффект. Модель видит противоречие, но без понимания какая общая структура была задумана изначально не может выбрать правильное решение.
Работает только одно: вернуть полную спецификацию. Когда модель получает полный контекст — явные форматы, структуры данных, ключевые параметры — она восстанавливает совместимость до уровня, как если бы вся задача делалась в одном запросе. Не «вот что не так», а «вот как должно быть целиком».
Схема метода
ШАГ 0 (до разделения задачи):
Сформируй явную спецификацию — ключевые данные, форматы,
термины, структуры → сохрани как "общий бриф"
ШАГ 1 (каждый отдельный запрос):
Вставляй полный бриф + конкретная задача для этой части
→ получаешь часть, совместимую с остальными
ШАГ 2 (если что-то всё же не совпало):
НЕ: "вот конфликты — исправь"
ДА: снова дай полную спецификацию → попроси свести части воедино
Все шаги выполняются в обычных отдельных запросах. Специального инструмента не нужно.
Пример применения
Задача: Стартап Михаила делает мобильное приложение для учёта личных финансов. Нужен питч-дек для инвесторов. Михаил просит ChatGPT написать слайды по очереди: рынок → проблема → решение → unit-экономика → команда. Итог: в слайде «Рынок» TAM — 800 млрд рублей, в «Unit-экономике» почему-то фигурирует 50 млрд. Конкурент на слайде «Решение» — Тинькофф, на слайде «Команда» — уже Сбер. Цифры плавают, термины расходятся.
Промпт:
Общий бриф питч-дека — вставляй в каждый запрос:
ПРОДУКТ: Мобильное приложение «Копейка» — учёт личных финансов
ЦЕЛЕВАЯ АУДИТОРИЯ: Россияне 25–40 лет, доход от 80 000 руб/мес
РЫНОК: TAM — 320 млрд руб/год (рынок финансовых приложений РФ)
КОНКУРЕНТЫ: Дзен-мани, Coinkeeper, встроенный учёт Тинькофф
БИЗНЕС-МОДЕЛЬ: Freemium, подписка 299 руб/мес
КЛЮЧЕВЫЕ МЕТРИКИ: CAC — 350 руб, LTV — 2 100 руб, MAU — 45 000
РАУНД: Seed, ищем 30 млн рублей за 15%
КОМАНДА: Михаил Орлов (CEO, ex-Яндекс), Анна Смирнова (CTO, ex-Сбер)
---
Используя только данные из брифа выше, напиши слайд «{название слайда}».
Не добавляй цифры, которых нет в брифе. Формат: заголовок + 3–5 тезисов.
Результат:
Каждый слайд будет использовать одни и те же цифры, одних конкурентов и единую терминологию из брифа. Когда соберёшь все слайды вместе — они будут согласованы между собой, потому что каждый запрос работал с одной и той же «системой координат».
Если слайды вышли несовместимыми и нужно свести воедино — дай модели весь бриф + все слайды и попроси «привести к единой спецификации», а не «вот где противоречия — исправь их».
Почему это работает
LLM не помнит «договорённость» между запросами. Когда ты просишь написать раздел A, а потом раздел B — каждый раз модель начинает с нуля и самостоятельно выбирает форматы, термины, числа. Даже если ты написал похожий контекст — два запроса независимы. Это не баг, это устройство: модель генерирует следующий токен на основе того, что видит сейчас, а не того, что делала в другом диалоге.
LLM хорошо умеет следовать явным ограничениям внутри одного запроса. Если в запросе написано «конкурент — Дзен-мани» — она не придумает Тинькофф. Если написано «TAM — 320 млрд» — она не возьмёт другую цифру. Модель не «думает самостоятельно» — она следует паттернам из контекста. Чем точнее контекст, тем предсказуемее результат.
Метод использует это: полная спецификация в каждом запросе устраняет неопределённость. Модели не нужно угадывать — всё уже написано явно. А если дать не спецификацию, а «отчёт о конфликтах» — модель видит что не так, но не знает как правильно. Выбор между вариантами без арбитра — случайный. Спецификация — арбитр.
Рычаги управления: - Детализация брифа → больше явных параметров = меньше расхождений. Добавляй всё, что может быть интерпретировано по-разному: форматы дат, единицы измерения, ключевые термины - Инструкция «не добавляй данных вне брифа» → усиливает эффект явной спецификации - Финальный запрос «сверки» → после всех частей попроси LLM проверить соответствие брифу — не ошибки, а соответствие источнику истины
Шаблон промпта
ОБЩАЯ СПЕЦИФИКАЦИЯ ПРОЕКТА:
{ключевые параметры: названия, числа, форматы, термины, структуры данных}
ПРАВИЛА:
- Используй только данные из спецификации выше
- Не добавляй числа и факты, которых нет в спецификации
- Формат вывода: {нужный формат}
ЗАДАЧА ДЛЯ ЭТОЙ ЧАСТИ:
{конкретная задача — один раздел, один блок, один аспект}
Плейсхолдеры:
- {ключевые параметры} — всё, что должно быть одинаковым во всех частях: цифры, формат дат, имена, термины, структуры
- {нужный формат} — как должен выглядеть ответ: список, таблица, абзацы, слайд
- {конкретная задача} — что именно делать в этом запросе: «напиши раздел X», «заполни блок Y»
Для финальной сверки / восстановления после конфликта:
ОБЩАЯ СПЕЦИФИКАЦИЯ (источник истины):
{та же спецификация}
ЧАСТИ, КОТОРЫЕ НУЖНО СОГЛАСОВАТЬ:
{вставь все части}
Приведи все части в соответствие со спецификацией.
Там где части противоречат спецификации — исправь по спецификации.
Там где части противоречат друг другу — используй данные из спецификации как арбитр.
🚀 Быстрый старт — вставь в чат:
Помоги мне создать общую спецификацию для моего проекта,
чтобы я мог создавать разные части согласованно.
Моя задача: {опиши свой проект в 1-2 предложениях}.
Задавай вопросы о ключевых параметрах, которые должны быть
одинаковыми во всех частях.
[вставить шаблон выше]
LLM спросит о ключевых числах, названиях, форматах и терминах — потому что именно эти элементы создают несовместимость когда не зафиксированы явно. Она возьмёт паттерн брифа и поможет заполнить под твою задачу.
Ограничения
⚠️ Координационный налог остаётся всегда: Даже с идеальной спецификацией разделение задачи на части даёт худший результат, чем решение целиком в одном запросе. Если задача позволяет — лучше один большой запрос, чем несколько согласованных маленьких.
⚠️ Структурная несовместимость, не смысловая: Метод отлично ловит форматные расхождения (разные числа, разные термины). Но если две части используют одинаковый формат, но несовместимую логику — это не поймать явной спецификацией. Нужна содержательная проверка.
⚠️ Спецификация работает когда написана явно: «Конкурент — Тинькофф» работает. «Укажи релевантных конкурентов» — не фиксирует выбор и оставляет простор для расхождений. Неявные инструкции не создают координирующего контекста.
⚠️ Не масштабируется на очень длинные брифы: Если спецификация занимает половину окна контекста — в сложных задачах модель начинает «забывать» детали из начала. Держи бриф компактным: только то, что может расходиться.
Ресурсы
Название работы: The Specification Gap: Coordination Failure Under Partial Knowledge in CodeAgents (препринт, 2025)
Репозиторий: github.com/camilochs/the_specification_gap
Авторы: Camilo Chacón Sartori — Catalan Institute of Nanoscience and Nanotechnology (ICN2), CSIC and BIST, Campus UAB, Барселона, Испания
Связанные идеи в работе: ClassEval (бенчмарк для задач на уровне классов), Принцип сокрытия информации Парнаса, Design by Contract Майера — классические концепции из разработки ПО, которые авторы переносят на мультиагентные LLM-системы.