Почти 5 000 промпт-техник из научных исследований

Стратегия B2B-продаж SaaS для малого бизнеса (3–50 сотрудников)

---

Стратегия решения

Диагноз задачи. У вас три взаимосвязанные проблемы: (1) нет структурированной воронки — непонятно, где клиент «застревает»; (2) нет чёткого ценностного предложения под конкретный сегмент; (3) нет системы работы с возражениями. Это классическая ситуация для SaaS на ранней стадии: продукт есть, а продажи идут «по наитию».

Карта методов. Задача распадается на четыре подзадачи, и под каждую есть подходящий инструмент:

• Понять, как разные типы клиентов реагируют на ваше предложение → Direct Distribution Querying даёт распределение мнений по сегментам за один запрос, без двадцати ролевых повторений.
• Выявить реальные возражения и протестировать питч → AI Personas Meta-Prompt симулирует трёх стейкхолдеров с разным уровнем сопротивления — скептика-финдира, осторожного операционщика и энтузиаста-основателя.
• Построить воронку и стратегию по паттернам → HCoT (каталог паттернов) позволяет не придумывать воронку с нуля, а выбрать из типовых паттернов провала и успеха в B2B SaaS.
• Зафиксировать логику квалификации лидов → Prompt-Level Distillation превращает ваши размеченные примеры в чёткие правила, которые работают стабильно.

Синергия. Сначала Direct Distribution Querying даёт карту: кто из ваших сегментов реально готов платить, кто требует триал, кто уйдёт к конкурентам. Это промежуточный результат — понимание распределения реакций. Затем AI Personas использует этот результат: вы создаёте персонажей именно из «трудных» сегментов (высокое сопротивление) и прогоняете через них питч и ценностное предложение. После нескольких итераций у вас накапливаются размеченные примеры — «это возражение мы закрыли вот так». PLD превращает эти примеры в правила квалификации лидов для системного промпта. HCoT работает параллельно: вы строите каталог типовых причин провала сделок в вашей нише и диагностируете каждую застрявшую сделку через три шага (Abstract → Match → Refine).

Чего ожидать. По аналогии с механикой методов: вместо «общих советов по продажам» вы получите конкретную карту возражений по сегментам, рабочий скрипт питча с проверенными ответами на сопротивление, и систему квалификации лидов, которая работает без вас.

---

Вопрос 1: Как понять, кто из моих клиентов реально готов платить — и что их останавливает?

Прямой запрос распределения мнений (Direct Distribution Querying)

Механика. Вместо того чтобы двадцать раз просить модель «сыграть роль скептичного директора», вы задаёте один вопрос: «сколько процентов директоров малого бизнеса выберут вариант А, Б, В — и почему?». Модель переключается из режима актёра в режим социолога: она агрегирует паттерны из тысяч текстов разных людей, а не воспроизводит одного усреднённого персонажа. Два усилителя точности: цепочка рассуждений перед ответом (модель обосновывает логику для каждой группы) и явное разрешение асимметрии («некоторые варианты могут иметь 0%» — иначе модель округляет до удобных 25/25/25/25).

Как применять к вашей задаче:

1. Определите 2–3 сегмента внутри малого бизнеса: например, «владелец розничной точки 5–15 сотрудников» vs «операционный директор IT-компании 20–50 сотрудников» — у них разная логика принятия решений.
2. Сформулируйте 3–4 взаимоисключающих варианта реакции на ваш продукт: «готов платить сразу», «нужен бесплатный период», «слишком дорого — ищу аналог», «цена не важна, важна демонстрация ценности».
3. Добавьте в запрос: «сначала объясни логику рассуждений для каждой группы» + «распределение не обязано быть симметричным, некоторые варианты могут иметь 0%».

Схема промпта:

Роль: эксперт по поведению малого бизнеса в России

Ситуация: [описание вашего SaaS — что делает, цена, без/с триалом]

Варианты реакции:
А) Готов платить — цена разумная
Б) Интересно, но сначала нужен бесплатный период
В) Слишком дорого, пойду искать аналоги
Г) Цена не главное, важна демонстрация ценности

Сначала объясни логику рассуждений для каждой группы.
Затем дай процентное распределение для:
— [Сегмент 1: конкретика — должность, размер компании, город]
— [Сегмент 2: конкретика]

Распределение не обязано быть симметричным. Некоторые варианты могут иметь 0%.

Почему это работает. Исследование Гарварда на 1680 комбинациях «вопрос × группа» показало: прямой запрос распределения точнее ролевого опроса, особенно в передаче разброса мнений внутри группы. Ролевой метод давал нулевую вариацию (20 запросов — 20 одинаковых ответов), прямой — реалистичный разброс.

---

Вопрос 2: Как протестировать питч и ценностное предложение до первых встреч?

Симулятор стейкхолдеров с сопротивлением (AI Personas Meta-Prompt)

Механика. Обычный запрос «сыграй скептика» нестабилен: к третьему вопросу скептик превращается в сочувствующего коллегу — модель возвращается к доминирующему паттерну угождения. Детализированная карточка персонажа работает иначе: конкретный прошлый опыт + триггерные темы + уровень сопротивления не оставляют модели пространства для усреднения. Три персонажа с противоположными позициями создают карту напряжений — вы видите, где интересы конфликтуют, до реальной встречи.

Как применять к вашей задаче:

1. Создайте трёх персонажей из вашего реального сегмента: владелец бизнеса (высокое сопротивление — «уже пробовал похожее»), операционный менеджер (среднее — «открыт, но требует пилот»), бухгалтер/финансист (высокое — «не мой бюджет, не моё решение»).
2. Для каждого пропишите триггерные темы — что они всегда спрашивают: интеграция с 1С, безопасность данных, кто будет обучать сотрудников.
3. Прогоните через них ваше ценностное предложение: «Говорю с [имя]: вот наше предложение — [текст]. Что скажете?»

Схема промпта: Ты — симулятор стейкхолдеров малого бизнеса. Играй персонажей поочерёдно.

ПЕРСОНАЖ 1 — [Имя], владелец [тип бизнеса], [город]

• Мотивация: [чего хочет для себя]
• Поведение: [что всегда делает: требует ROI / ссылается на неудачный опыт / спрашивает про интеграцию]
• Сопротивление: высокое — [конкретная причина]

ПЕРСОНАЖ 2 — [Имя], операционный директор, [город]

• Мотивация: [чего хочет]
• Поведение: [триггеры]
• Сопротивление: среднее — [причина]

ПЕРСОНАЖ 3 — [Имя], главный бухгалтер / финансист, [город]

• Мотивация: [чего хочет]
• Поведение: [всегда переводит на бюджет и согласование]
• Сопротивление: высокое — [не её решение]

КОНТЕКСТ: [описание вашего SaaS — 2-3 предложения]

Жди моих вопросов. Я указываю с кем говорю.

Почему это работает. Исследование показало: без конкретных триггеров и уровня сопротивления модель через 3–5 вопросов начинает угождать. С детализированной карточкой — держит характер весь разговор. Важно: не оптимизируй промпт ради краткости — детали и есть живость персонажа.

---

Вопрос 3: Как построить воронку и диагностировать, где сделки застревают?

Каталог паттернов провала + три шага анализа (HCoT)

Механика. Когда просишь LLM «найди причину, почему клиент не купил» — модель перебирает огромное поле вариантов, и побеждают самые банальные. HCoT заменяет открытый перебор на выбор из конечного каталога: вы один раз составляете 6–8 типовых паттернов провала в вашей нише, и дальше каждая застрявшая сделка анализируется через три шага: Abstract (обобщи суть) → Match (найди паттерн) → Refine (дай конкретные действия). Модель не придумывает — она сопоставляет, и это принципиально точнее.

Как применять к вашей задаче:

1. Составьте каталог паттернов провала для B2B SaaS в малом бизнесе (см. полный промпт ниже).
2. Для каждой застрявшей сделки опишите ситуацию и прогоните через три шага.
3. Переиспользуйте каталог — это разовая работа, которая покрывает большинство случаев.

Схема промпта: Каталог паттернов (составить один раз): ПАТТЕРН 1: [название] — [описание]. Пример: "[типичная фраза клиента]" ПАТТЕРН 2: ... [6-8 паттернов]

Моя ситуация: [описание застрявшей сделки]

Шаг 1 (Abstract) — опиши суть проблемы в общих чертах. Шаг 2 (Match) — найди 1-2 паттерна, объясни почему именно они. Шаг 3 (Refine) — что конкретно изменить: скрипт, оффер, следующий шаг.

Почему это работает. Исследование показало: модель сопоставляет лучше, чем придумывает. На задачах с каталогом паттернов точность в разы выше, чем при свободном анализе. Примеры внутри каждого паттерна сильно повышают качество сопоставления.

---

Вопрос 4: Как зафиксировать логику квалификации лидов, чтобы она работала стабильно?

Компиляция правил из ваших примеров (Prompt-Level Distillation)

Механика. Без зафиксированных правил модель каждый раз квалифицирует лид по-разному — два похожих запроса могут получить разные ответы. PLD переносит вашу логику в системный промпт: вы собираете 15–20 размеченных примеров (этот лид — целевой, этот — нет, вот почему), прогоняете через сильную модель, получаете чёткий список правил «если X и Y — то целевой». Дальше любая модель работает по вашей логике стабильно.

Как применять к вашей задаче:

1. Соберите 15–20 реальных заявок или описаний клиентов, которых вы уже квалифицировали вручную.
2. Прогоните через три шага: извлечение правил → синтез → разрешение конфликтов (2–3 итерации).
3. Итоговый список правил — в системный промпт для квалификации новых лидов.

Схема промпта: Шаг 1 — извлечение: Для каждого примера объясни логику решения и сформулируй абстрактное правило. Примеры: [15-20 пар "описание клиента → целевой/нецелевой/уточнить"]

Шаг 2 — синтез: Объедини дублирующиеся правила. Убери слишком узкие. Формат: "Целевой: если... Нецелевой: если... Уточнить: если..."

Шаг 3 — конфликты: Вот примеры где правила дали неверный результат: [список]. Найди противоречия, обнови правила.

---

Полный промпт: Каталог паттернов провала B2B SaaS + диагностика сделки

Это самый важный инструмент для вашей задачи — он закрывает и воронку, и возражения, и ценностное предложение одновременно.

У меня есть каталог типичных причин, по которым сделки в B2B SaaS для малого бизнеса не закрываются:

ПАТТЕРН 1: Ценность не очевидна за 5 минут Клиент не понимает, что именно изменится в его работе. Продукт кажется "ещё одним инструментом". Пример фразы: "Звучит интересно, но мы пока справляемся".

ПАТТЕРН 2: Страх внедрения Малый бизнес боится не цены, а времени и усилий на переход. Пример: "А кто будет обучать сотрудников? У нас нет на это времени".

ПАТТЕРН 3: Нет срочности Боль есть, но она терпима. Нет триггера "нужно решить сейчас". Пример: "Да, это проблема, но мы как-то живём. Вернёмся к этому в следующем квартале".

ПАТТЕРН 4: Неправильный стейкхолдер Разговор идёт с человеком, который не принимает решение о бюджете. Пример: "Мне нравится, но нужно согласовать с директором / бухгалтером / партнёром".

ПАТТЕРН 5: Недоверие к новому игроку Малый бизнес консервативен. Нет кейсов из их отрасли или города. Пример: "А кто ещё из таких же компаний как мы уже пользуется?"

ПАТТЕРН 6: Ценностное предложение не под их боль Вы говорите про автоматизацию, они думают про деньги. Или наоборот. Пример: "Ну экономия времени — это хорошо, но мне важнее не терять клиентов".

ПАТТЕРН 7: Конкурент уже занял место Есть привычный инструмент (даже Excel), и переключение стоит усилий. Пример: "У нас уже есть [название], мы к нему привыкли".

ПАТТЕРН 8: Цена не привязана к ценности Клиент не понимает, за что именно платит. Пример: "Почему [цена] в месяц? Что конкретно я получаю за эти деньги?"

---

Моя ситуация: [Опиши конкретную сделку или тип клиента: кто, чем занимается, сколько сотрудников, что произошло на встрече / в переписке, что сказал клиент, на каком этапе застряло]

---

Сделай три шага:

ШАГ 1 — ABSTRACT: Опиши суть ситуации в общих чертах — без деталей моего продукта. Что здесь происходит на уровне типа проблемы? Какой архетип клиента и ситуации?

ШАГ 2 — MATCH: Найди 1–2 паттерна из каталога, которые лучше всего объясняют, почему сделка застряла. Объясни: какие именно слова или действия клиента указывают на этот паттерн?

ШАГ 3 — REFINE: Дай конкретные рекомендации для моей ситуации:

• Что изменить в следующем касании (скрипт, вопрос, оффер)?
• Какой следующий шаг предложить клиенту?
• Как переформулировать ценностное предложение под его реальную боль?
• Если паттерн 4 (не тот стейкхолдер) — как выйти на нужного человека?

---

Дополнительные техники

Пять типов клиентских сценариев для ролевых игр (Пятикатегорийная генерация)

Когда готовите скрипты продаж или обучаете менеджеров — не просите «придумай 5 примеров клиентов». Модель выдаст пять вариаций одного и того же. Используйте пять категорий: базовый (типичный владелец кофейни, стандартное «дорого»), сложный (три стейкхолдера с противоречивыми целями — владелец хочет, бухгалтер против), граничный (стартап 3 человека или компания 48 человек на пороге роста), крайний случай (клиент с самописной CRM, которую «жалко бросать»), перегруженные ограничения (франчайзи, где решение принимает головной офис, а не они). Последний тип покажет слепые пятна вашего скрипта.

Мини-схема добавления в любой промпт: Сгенерируй по одному сценарию клиента для каждой категории: базовый / сложный (несколько стейкхолдеров) / граничный (крайние параметры) / крайний случай (редкий, но возможный) / перегруженные ограничения (логически валидный, но ломает стандартный скрипт)

---

Структурированные переговоры с явным отслеживанием другой стороны (Переговоры с LLM)

Когда готовитесь к конкретной встрече с клиентом — используйте режим советника, а не симулятора. Модель анализирует каждое сообщение клиента через State Tracking (что он знает / не знает про вас, каковы его приоритеты) и даёт рекомендацию по тактике следующего хода. Особенно полезно для многопараметрических переговоров: цена + срок внедрения + объём поддержки + условия оплаты. Исходя из механики метода, явное моделирование позиции другой стороны перед каждым ответом снижает реактивность и помогает находить trade-offs: вы уступаете на сроках внедрения (им важно), они соглашаются на предоплату (вам важно).

Мини-схема: После каждого сообщения клиента покажи: STATE TRACKING: что клиент знает/не знает про нас, его вероятные приоритеты РЕКОМЕНДАЦИЯ: цель следующего хода, тактика, конкретные фразы

---

Честный анализ гипотез о рынке (ADI-протокол)

Когда формулируете ценностное предложение — велик соблазн получить от модели уверенный красивый текст, который на деле держится на предположениях. ADI-протокол делает это видимым: гипотезы помечаются как гипотезы, логические выводы — как выводы, а финальная надёжность берётся не как среднее, а как минимум по всем шагам. Используйте для проверки ключевых допущений: «наша аудитория готова платить X рублей», «главная боль — потеря времени, а не денег», «решение принимает владелец, а не бухгалтер». Блок Weakest Link покажет, какое допущение самое слабое — и что нужно проверить в первую очередь.

Мини-схема: Проанализируй гипотезу по ADI-протоколу: АБДУКЦИЯ: 2-3 объяснения [ГИПОТЕЗА, надёжность: 35%] ДЕДУКЦИЯ: проверка на противоречия [ЛОГИЧЕСКИ СОГЛАСОВАНО, X%] ИНДУКЦИЯ: что подтвердит или опровергнет [ЭМПИРИЧЕСКИ ПОДТВЕРЖДЕНО при условии: ...] WEAKEST LINK: надёжность итога = надёжность слабейшего шага

---

Комбинация и порядок действий

Почему именно такой порядок:

1. Начните с Direct Distribution Querying — он даёт карту реакций ваших сегментов за один запрос. Это база: вы узнаёте, у кого высокое сопротивление, кто требует триал, кто уйдёт к конкурентам. Без этого персонажи для следующего шага будут придуманными, а не основанными на реальном распределении.

1. Затем AI Personas — берёте сегменты с высоким сопротивлением из шага 1 и создаёте под них персонажей. Прогоняете питч и ценностное предложение. Фиксируете, какие возражения возникают и как вы на них отвечаете — это сырьё для следующего шага.

1. Параллельно или после — HCoT с каталогом паттернов — составляете каталог один раз и используете для диагностики каждой реальной застрявшей сделки. Этот метод независим от первых двух и может применяться отдельно.

1. Когда накопится 15–20 размеченных примеров — PLD — превращает вашу логику квалификации в стабильные правила. Это финальный шаг: система начинает работать без вас.

Методы, которые усиливают друг друга:

• Direct Distribution Querying + AI Personas: первый даёт статистику по сегментам, второй — живые диалоги с представителями этих сегментов. Вместе они закрывают и «что думает аудитория», и «как она говорит».
• HCoT + ADI-протокол: каталог паттернов диагностирует застрявшие сделки, ADI проверяет, насколько обоснованы ваши выводы о причинах провала.

Методы, которые независимы:

• Пятикатегорийная генерация работает отдельно — используйте когда нужно подготовить обучающие материалы для менеджеров.
• Переговоры с LLM — отдельный инструмент для подготовки к конкретным встречам.

Ожидаемый итог. Если применять всё вместе: у вас появится карта сегментов с реальным распределением готовности платить, скрипт питча проверенный на трёх типах сопротивления, каталог паттернов для диагностики сделок, и система квалификации лидов с зафиксированной логикой. Это не «общие советы по продажам» — это рабочая система, которую можно передать менеджеру.

Мульти-агентная редакционная система: практическое руководство

---

Стратегия решения

Диагноз задачи. Вы проектируете систему из трёх специализированных агентов — редактора, фактчекера и редакционного директора — которые должны работать как единый редакционный процесс, а не три независимых запроса. Здесь три подзадачи: (1) правильно разграничить роли так, чтобы агенты не дублировали друг друга и не смешивались в одну «кашу», (2) выстроить протокол передачи задач с явными точками контроля, (3) создать механизм разрешения конфликтов, который не сводится к «побеждает большинство».

Карта методов. Для разграничения ролей и структуры дебатов подходит SAG (Small Agent Group) — он даёт чёткую архитектуру: кто генерирует, кто проверяет факты, кто ловит риски, кто выносит вердикт. Для разрешения конфликтов между агентами, когда они расходятся во мнениях, нужен AgentAuditor — он учит не считать голоса, а сравнивать силу аргументов в точке расхождения. Для выявления «правого» агента в спорных ситуациях — AceMAD: тот, кто точно предсказал позицию коллег до их ответа, понимает задачу глубже. Для итеративного улучшения текста между раундами — VQQA: диагностические вопросы вместо размытого «улучши».

Синергия. Сначала SAG задаёт архитектуру ролей и раундов — это создаёт скелет системы. Затем AgentAuditor встраивается в точки конфликта между агентами: вместо голосования строит дерево рассуждений и сравнивает аргументы локально. Поверх этого AceMAD добавляет механизм взвешивания: агент, который точнее предсказал позицию коллег, получает больший вес при финальном решении. VQQA работает между раундами — как инструмент редактора для точечных правок без «расползания» изменений.

Чего ожидать. По данным исследований: SAG убирает до 70% галлюцинаций через взаимную критику; AgentAuditor восстанавливает 65–82% правильных ответов в случаях, когда большинство ошиблось; AceMAD даёт +20 процентных пунктов точности над стандартными дебатами на спорных вопросах. Вместе — система, где конфликты разрешаются через доказательства, а не через консенсус.

---

Вопрос 1: Как разграничить роли трёх агентов, чтобы они не дублировали друг друга?

Архитектура ролей с узкой ответственностью (SAG)

Механика. SAG строится на принципе: каждый агент делает одно, но делает это хорошо. Когда одна модель пытается одновременно редактировать, проверять факты и принимать редакционные решения — она когнитивно перегружена и пропускает ошибки. Разделение ролей снимает эту нагрузку: редактор думает только о тексте, фактчекер — только о достоверности, директор — только о редакционной стратегии. Взаимная критика во втором раунде создаёт принудительную проверку: выдуманный факт не выживает под вопросом фактчекера.

Как применять к вашей задаче:

1. Редактор — зона ответственности: структура, логика, стиль, читаемость. Не проверяет факты, не принимает стратегических решений. Его задача — сделать текст ясным и убедительным.
2. Фактчекер — зона ответственности: достоверность утверждений, источники, внутренние противоречия, некорректные обобщения. Не редактирует стиль, не решает публиковать или нет.
3. Редакционный директор — зона ответственности: соответствие редакционной политике, приоритеты публикации, разрешение конфликтов между редактором и фактчекером, финальный вердикт. Не правит текст напрямую.

Критическое правило: роли НЕ должны перекрываться. Если редактор начинает проверять факты — система теряет смысл. Явно запретите каждому агенту заходить на чужую территорию.

Схема промпта:

Ты — [РОЛЬ] в редакционной системе из трёх агентов.

Твоя и ТОЛЬКО твоя зона ответственности:
[Редактор]: структура, логика, стиль, читаемость
[Фактчекер]: достоверность утверждений, источники, противоречия
[Директор]: редакционная стратегия, разрешение конфликтов, финальный вердикт

ЗАПРЕЩЕНО: заходить в зону другого агента.
ЗАПРЕЩЕНО: давать общую оценку "текст хороший/плохой".

Твой вывод — только по своей зоне. Формат:
[РОЛЬ]: [конкретные наблюдения]
Вопрос к [другому агенту]: [если нужна их экспертиза]

Почему это работает: исследование SAG показало, что узкая роль = модель не пытается делать всё сразу. Взаимная критика убирает до 70% галлюцинаций — выдуманный факт разваливается под проверкой фактчекера во втором раунде.

---

Вопрос 2: Как выстроить протокол передачи задач между агентами?

Протокол с раундами и явными точками контроля (SAG + VQQA)

Механика. Передача задач без структуры — главная причина, по которой мульти-агентные системы «расплываются». Агент получает текст, что-то делает, передаёт дальше — и к третьему агенту уже непонятно, что было исправлено, а что нет. Протокол с явными раундами и фиксированным форматом передачи решает это: каждый агент получает не просто текст, а текст + лог предыдущих решений + конкретный вопрос к нему.

Протокол из четырёх раундов:

Раунд 0 — Инициализация (Редакционный директор) Директор получает исходный текст и задаёт параметры задачи: для кого, зачем, какие редакционные приоритеты, какие ограничения. Это контекст, который все агенты получают в начале и не теряют.

Раунд 1 — Независимый анализ (Редактор + Фактчекер параллельно) Оба агента работают с исходным текстом независимо — не видят выводов друг друга. Редактор фиксирует структурные и стилистические проблемы. Фактчекер фиксирует фактические риски. Формат вывода: список наблюдений + оценка критичности каждого (высокая/средняя/низкая).

Раунд 2 — Взаимная критика Редактор читает выводы фактчекера и отвечает: «Это фактическое замечание влияет на структуру текста так-то». Фактчекер читает правки редактора и отвечает: «После этой правки утверждение X стало некорректным». Каждый агент видит полный лог предыдущего раунда.

Раунд 3 — Диагностика и правка (VQQA) Редактор применяет диагностический цикл: не «улучши всё», а конкретные вопросы по низким оценкам. Фактчекер подтверждает, что правки не создали новых фактических проблем.

Раунд 4 — Вердикт (Редакционный директор) Директор получает: исходный текст + итоговый текст + лог всех раундов + список неразрешённых разногласий. Выносит вердикт: публиковать / доработать / отклонить + обоснование.

Схема промпта для передачи задачи: КОНТЕКСТ ЗАДАЧИ (от Директора, Раунд 0): Текст: [вставить] Аудитория: [кто читает] Редакционные приоритеты: [что важно] Ограничения: [что нельзя]

ЛОГ ПРЕДЫДУЩИХ РАУНДОВ: [Раунд 1 — Редактор]: [наблюдения] [Раунд 1 — Фактчекер]: [наблюдения] [Раунд 2 — Взаимная критика]: [обмен]

ТВОЯ ЗАДАЧА (Раунд [N]): Роль: [Редактор / Фактчекер / Директор] Вопрос к тебе: [конкретный вопрос] Формат ответа: [список / вердикт / правки]

---

Вопрос 3: Как разрешать конфликты между агентами?

Аудит в точках расхождения, а не голосование (AgentAuditor)

Механика. Когда редактор говорит «этот абзац нужно переписать», а фактчекер говорит «этот абзац точен и его нельзя трогать» — голосование бессмысленно: у вас два агента, и ничья. AgentAuditor предлагает другой подход: не считать голоса, а построить дерево рассуждений и сравнить аргументы в точке расхождения. Кто обоснован сильнее — тот и прав, независимо от того, сколько агентов его поддерживает.

Как применять к вашей задаче:

1. Зафиксируй точку расхождения. Директор формулирует: «Редактор предлагает X, Фактчекер возражает Y. Точка конфликта: [конкретный элемент текста]».

1. Построй локальный контекст. Что общего у обоих агентов до точки расхождения (shared prefix)? Что именно они предлагают после неё (branch evidence)?

1. Аудит ветвей по критериям:

• Фактическая точность: чья позиция опирается на проверяемые данные?
• Логическая связность: чей вывод следует из предпосылок?
• Соответствие редакционным приоритетам (из Раунда 0): чья позиция ближе к заявленным целям?

1. Правило: Evidence over popularity. Если фактчекер обоснован сильнее — его позиция побеждает, даже если редактор и директор склонялись к другому.

Схема промпта для разрешения конфликта: КОНФЛИКТ МЕЖДУ АГЕНТАМИ:

Точка расхождения: [конкретный элемент — абзац, утверждение, правка]

Shared prefix (что общего до конфликта): [что оба агента признают верным]

Позиция Редактора: Аргумент: [1-2 предложения] Основание: [структура / стиль / читаемость]

Позиция Фактчекера: Аргумент: [1-2 предложения] Основание: [источник / данные / логика]

АУДИТ:

1. Чья позиция фактически точнее?
2. Чья логика связнее?
3. Чья позиция ближе к редакционным приоритетам: [приоритеты из Раунда 0]?

ПРАВИЛО: игнорируй кто "главнее" — смотри только на силу аргументов. ВЕРДИКТ: [победившая позиция] + [почему именно она]

---

Вопрос 4: Как определить, чьей позиции доверять больше в спорных случаях?

Взвешивание через предсказание позиций (AceMAD)

Механика. Стандартная проблема мульти-агентных систем: все три агента могут ошибиться одинаково, потому что порождены одной моделью с одними предубеждениями. AceMAD решает это через мета-когнитивный тест: перед тем как агенты читают выводы друг друга, каждый предсказывает, что скажут коллеги. Тот, кто точно предсказал разногласие — реально понял задачу. Тот, кто ожидал согласия и не получил его — демонстрирует слабую позицию. Это не красноречие решает, а точность прогноза.

Как применять к вашей задаче:

1. Перед Раундом 2 (взаимная критика) добавь шаг: каждый агент пишет прогноз — что скажет другой агент о тексте. Прогнозы пишутся до чтения чужих выводов.

1. После Раунда 2 директор сравнивает прогнозы с реальными позициями:

• Редактор ожидал, что фактчекер скажет X — фактчекер сказал X? Высокая точность.
• Фактчекер ожидал согласия редактора — редактор возразил? Низкая точность.

1. Взвешивание при конфликте:

• Высокая точность прогноза → вес ×3
• Средняя → вес ×1.5
• Низкая → вес ×1

1. Применяй только к спорным случаям — там, где аудит по AgentAuditor не дал однозначного ответа.

Схема промпта (шаг предсказания): ДО чтения выводов другого агента — напиши прогноз:

Я ([Редактор / Фактчекер]) ожидаю, что [другой агент] скажет: "[конкретная позиция]"

Потому что: [1-2 предложения — почему ты так думаешь]

[После чтения реальных выводов]

Мой прогноз совпал / не совпал потому что: [анализ]

---

Полный промпт для самого важного метода — Протокол редакционной системы

Это интегрированный промпт, который запускает всю систему за один сеанс:

═══════════════════════════════════════ ТЕКСТ ДЛЯ РЕДАКТУРЫ: [вставить текст]

РЕДАКЦИОННЫЙ КОНТЕКСТ: Аудитория: [кто читает — например, профессионалы в области X] Цель публикации: [информировать / убедить / обучить] Приоритеты: [точность / читаемость / краткость — выбери 1-2] Ограничения: [что нельзя менять — например, фирменный стиль] ═══════════════════════════════════════

РАУНД 0 — РЕДАКЦИОННЫЙ ДИРЕКТОР: Параметры задачи

Прочитай контекст выше. Сформулируй:

1. Главный критерий успеха для этого текста (одно предложение)
2. Что НЕ подлежит изменению (список)
3. Приоритет при конфликте редактора и фактчекера:

═══════════════════════════════════════

РАУНД 1 — НЕЗАВИСИМЫЙ АНАЛИЗ

РЕДАКТОР (только структура, логика, стиль — не проверяй факты):

Проверь по каждому пункту:

• Структура: есть ли логическая последовательность? Где теряется нить?
• Стиль: соответствует ли аудитории? Где язык слишком сложный / простой?
• Читаемость: где читатель споткнётся?
• Убедительность: где аргумент слабый?

Формат: [Проблема] → [Критичность: высокая/средняя/низкая] → [Конкретное место в тексте]

ФАКТЧЕКЕР (только достоверность — не редактируй стиль):

Проверь по каждому пункту:

• Утверждения: какие требуют источника и его нет?
• Противоречия: есть ли внутренние несоответствия?
• Обобщения: где "всегда", "никогда", "все" — некорректны?
• Цифры и даты: есть ли подозрительные данные?

Формат: [Утверждение] → [Риск: высокий/средний/низкий] → [Что именно вызывает вопрос]

═══════════════════════════════════════

РАУНД 1.5 — ПРОГНОЗЫ (до чтения выводов друг друга)

РЕДАКТОР — напиши прогноз: "Я ожидаю, что Фактчекер скажет: [конкретная позиция], потому что..."

ФАКТЧЕКЕР — напиши прогноз: "Я ожидаю, что Редактор скажет: [конкретная позиция], потому что..."

═══════════════════════════════════════

РАУНД 2 — ВЗАИМНАЯ КРИТИКА

Теперь агенты читают выводы друг друга.

РЕДАКТОР отвечает Фактчекеру:

• Какое фактическое замечание влияет на структуру текста?
• Где правка ради точности сломает читаемость?
• Мой прогноз совпал / не совпал: [анализ]

ФАКТЧЕКЕР отвечает Редактору:

• Какая стилистическая правка создаст фактическую проблему?
• Где редакторское упрощение исказит смысл?
• Мой прогноз совпал / не совпал: [анализ]

═══════════════════════════════════════

РАУНД 3 — ДИАГНОСТИКА И ПРАВКА (Редактор)

Возьми только замечания с критичностью "высокая" из Раундов 1-2.

Для каждого: Вопрос: [конкретный измеримый вопрос — "есть ли в абзаце X конкретный пример?"] Оценка: [0-100] Что не так: [если ниже 75]

Перепиши только проблемные места. Не трогай то, что получило оценку выше 80. Покажи: [было] → [стало]

Фактчекер подтверждает: правки не создали новых фактических проблем? [Да / Нет + что именно]

═══════════════════════════════════════

РАУНД 4 — ВЕРДИКТ (Редакционный директор)

Ты видишь: исходный текст + итоговый текст + лог всех раундов.

1. Оценка точности прогнозов:

• Редактор предсказал позицию Фактчекера: [точно / частично / нет]
• Фактчекер предсказал позицию Редактора: [точно / частично / нет]
• Кто демонстрирует лучшее понимание задачи?

1. Неразрешённые конфликты (если есть):

1. Финальный вердикт:

Обоснование (2-3 предложения):

---

Дополнительные техники

Conformal Social Choice — калиброванный отказ вместо слепого консенсуса (Conformal Social Choice)

Когда все три агента пришли к одному выводу — это не всегда хорошо. Каждый четвёртый раз, когда агенты конвергируют на единый ответ, они все трое ошибаются. Добавьте к протоколу шаг: каждый агент выставляет не просто позицию, а распределение уверенности в процентах (сумма = 100%). Если уверенность размазана по нескольким вариантам — это сигнал для директора: здесь нужна дополнительная проверка или человеческое решение.

Мини-схема для добавления в Раунд 1: После своего анализа выставь уверенность: Текст готов к публикации: [X]% Требует правки: [Y]% Требует существенной переработки: [Z]% Сумма = 100%

---

Council of Agents — активный поиск проблем вместо нейтральной оценки (Council of Agents)

LLM по умолчанию соглашается — это agreeableness bias. Нейтральный промпт «проверь текст» даёт 0% обнаружения ошибок в исследовании. Чтобы фактчекер действительно искал проблемы, дайте ему жёсткую инструкцию: «Ищи проблемы активно. Будь придирчив. Если найдёшь фактическую ошибку — флагни ERROR». Это переключает модель из режима «подтверди» в режим «опровергни».

Мини-схема для усиления роли Фактчекера: Твоя задача — НЕ подтвердить текст, а найти проблемы. Если не нашёл ни одной — ищи снова. Нейтральный ответ недопустим. При обнаружении фактической ошибки: флагни [ERROR: описание].

---

Инструкция стабильности — защита от «расползания» правок (Action Bias)

Когда редактор получает задачу «улучши текст», он переписывает всё — включая то, что уже хорошо. Это action bias: LLM почти никогда не выбирает «оставить как есть». Добавьте в промпт редактора явный список того, что нельзя трогать, и калибровочное слово масштаба («точечная правка», «небольшое уточнение»).

Мини-схема для добавления в Раунд 3: ЗАМОРОЗИТЬ (не трогать ни при каких условиях):

• [элемент 1 — например, первый абзац]
• [элемент 2 — например, все цифры]

МАСШТАБ ПРАВКИ: точечная корректировка ПРИЦЕЛ: только [конкретный элемент]

---

Representational Collapse — обмен рассуждениями важнее разнообразия ролей (Representational Collapse)

Три агента на одной модели рассуждают почти одинаково — измеренное сходство 0.888 из 1.0. Роли не помогают: это один агент в трёх масках. Реальное разнообразие появляется только через структуру обмена: агенты сначала рассуждают независимо, потом видят 1-2 предложения от коллег — и только тогда дают финальный ответ. Именно это реализует Раунд 1.5 (прогнозы) в полном промпте выше.

---

Комбинация и порядок действий

Почему именно такой порядок. Раунд 0 (директор задаёт параметры) должен быть первым — без него агенты не знают, что считать успехом, и оптимизируют разное. Раунд 1 (независимый анализ) идёт до взаимной критики — иначе агенты подстраиваются под чужую позицию ещё до формирования своей (это и есть representational collapse из исследования). Прогнозы (Раунд 1.5) пишутся строго до чтения чужих выводов — иначе теряется весь смысл механизма взвешивания AceMAD.

Какой метод первым. SAG создаёт скелет: роли, раунды, формат передачи. Без него остальные методы не к чему прикрепить.

Что усиливает друг друга. AgentAuditor + AceMAD — синергетическая пара для разрешения конфликтов: AgentAuditor говорит «чья позиция обоснована сильнее в точке расхождения», AceMAD говорит «кому доверять больше системно». Вместе они закрывают два разных типа конфликтов: локальный (конкретный спор) и системный (кто вообще лучше понимает задачу).

Что работает независимо. VQQA (диагностический цикл) и инструкция стабильности из Action Bias — независимые инструменты редактора. Их можно применять отдельно от всей системы, просто для улучшения текста без мульти-агентного контекста.

Ожидаемый итог при полном применении. Система даёт три вещи, которых нет в одиночном агенте: (1) принудительную проверку фактов через специализированную роль, (2) разрешение конфликтов через доказательства, а не иерархию, (3) защиту от консенсусных ошибок через механизм взвешивания. По аналогии с данными исследований — исходя из механики методов — ожидайте существенного снижения пропущенных фактических ошибок и более обоснованных редакционных решений по сравнению с одним агентом-«универсалом».