TL;DR
Probe-and-Refine — техника улучшения системных инструкций через искусственные провалы. Метод генерирует синтетические тест-кейсы, прогоняет через них текущие инструкции, диагностирует где они дают сбой, и патчит конкретные проблемные места. Три-пять итераций таких циклов превращают общие инструкции в операционно точные.
Главная находка: не важно есть ли у тебя инструкции или нет — важно как они сделаны. Инструкции, сгенерированные за один проход ("напиши мне хороший системный промпт"), иногда работают хуже нуля — LLM следует им буквально, даже когда они ведут в тупик. Проблема в том, что одноразовая генерация выдаёт общие советы: "проверяй факты", "анализируй тщательно". Это звучит разумно, но не говорит что именно делать в конкретных ситуациях.
Probe-and-Refine решает это через обратную связь от failures: генерируй тест-кейсы → смотри где инструкции не справляются → добавляй конкретные правила. Контент-анализ 104 добавленных правил через всю процедуру показал три устойчивых категории: процедурные правила (47% — "сначала воспроизведи ошибку, потом фикси"), структурные ссылки (30% — конкретные файлы, части, модули контекста), гейты качества (23% — "показывай реальный вывод, не придумывай").
Схема метода
Выполняется в одном разговоре с LLM или за 3–5 итераций отдельных сессий
ИТЕРАЦИЯ (повторить 3–5 раз):
ШАГ 1: Генерация проб → 5–10 синтетических тест-кейсов по твоей задаче
ШАГ 2: Симуляция → для каждого пробы: попытка решить по текущим инструкциям
ШАГ 3: Диагностика → СИЛЬНЫЙ / ЧАСТИЧНЫЙ / ПРОВАЛ + причина провала
ШАГ 4: Патч → конкретные добавления в инструкции (макс. 5 правок)
СТОП: если две итерации подряд — нет изменений
Пример применения
Задача: Паша — продакт в небольшом агентстве. Настроил Claude Project для анализа брифов от клиентов и подготовки предложений. Написал инструкции за 10 минут — "анализируй задачи клиента, формулируй ценность, предлагай решение". Claude выдаёт общие предложения, не учитывает индустрию клиента, не структурирует по разделам. Паша хочет улучшить инструкции, но не знает что именно не так.
Промпт:
У меня есть инструкции для Claude Project:
---
[ТЕКУЩИЕ ИНСТРУКЦИИ]
Анализируй бриф клиента. Выяви ключевую задачу.
Предложи решение. Сформулируй ценность для бизнеса.
---
Моя задача: анализировать брифы от клиентов B2B-агентства и готовить
коммерческие предложения.
Проведи зонд-итерацию:
**ШАГ 1. Синтетические пробы.**
Сгенерируй 5 тест-кейсов — разных по типу задач, которые
я могу получить. Каждый: заголовок + краткое описание ситуации +
что должны правильно обработать инструкции.
**ШАГ 2. Симуляция.**
Для каждой пробы: симулируй ответ по текущим инструкциям.
Оцени: СИЛЬНЫЙ / ЧАСТИЧНЫЙ / ПРОВАЛ.
**ШАГ 3. Диагностика.**
Для ЧАСТИЧНЫЙ и ПРОВАЛ: 1–2 предложения — чего именно
не хватило в инструкциях.
**ШАГ 4. Патч.**
Предложи до 5 конкретных правок. Категории:
- Процедурные: пошаговые рабочие цепочки ("сначала X, потом Y")
- Структурные: специфичные под мой контекст (разделы, типы клиентов)
- Гейты качества: стандарты вывода ("всегда указывай ...", "не пиши ...")
**ШАГ 5. Обновлённые инструкции.**
Покажи патченную версию — не длиннее 1500 символов.
Результат: Модель покажет 5 симулированных ситуаций с оценками, для каждого провала — конкретный диагноз (например: "инструкции не задают структуру разделов предложения" или "нет правила про индустриальный контекст клиента"). В финале — обновлённые инструкции с процедурными правилами ("сначала определи индустрию, потом боль, потом формат"), структурными ссылками под твою специфику и гейтами качества.
Почему это работает
Слабость LLM: модель следует инструкциям буквально. Если написано "анализируй тщательно" — она так и делает, но по своему усмотрению интерпретирует что значит "тщательно". Общие инструкции оставляют слишком большое пространство для интерпретации, и модель заполняет его своими паттернами — часто не теми.
Сильная сторона LLM: модель хорошо симулирует выполнение задачи по заданным правилам и хорошо диагностирует почему правила не сработали. Она может одновременно выступить исполнителем, судьёй и редактором инструкций.
Как метод использует это: вместо того чтобы думать "что написать в инструкциях", мы даём модели задачи, смотрим где инструкции не срабатывают, и патчим именно эти места. Каждая итерация сужает пространство интерпретации — от общих советов к конкретным операционным правилам.
Рычаги управления: - Количество проб (5 vs 10) → больше проб = глубже диагностика, но дольше. Для начала хватает 5 - Число итераций → стоп после 2 итераций без изменений — хороший критерий для любой задачи - Лимит символов инструкций → важно ограничивать. Длинные инструкции не лучше коротких — лучше правильные короткие - Категории патчей → можно убрать "структурные" если нет специфического контекста, или добавить свою категорию ("примеры формата вывода")
Шаблон промпта
У меня есть инструкции для {название_проекта/задачи}:
---
{текущие_инструкции}
---
Моя задача: {описание_чем_занимается_проект}.
Проведи зонд-итерацию:
**ШАГ 1. Синтетические пробы.**
Сгенерируй {5-10} тест-кейсов — разных по типу ситуаций.
Каждый: заголовок + краткое описание + что должны обработать инструкции.
**ШАГ 2. Симуляция.**
Для каждой пробы симулируй ответ по текущим инструкциям.
Оцени: СИЛЬНЫЙ / ЧАСТИЧНЫЙ / ПРОВАЛ.
**ШАГ 3. Диагностика.**
Для ЧАСТИЧНЫЙ и ПРОВАЛ: чего именно не хватило в инструкциях (1–2 предл.).
**ШАГ 4. Патч.**
Предложи до 5 конкретных правок. Категории:
- Процедурные: пошаговые рабочие цепочки
- Структурные: специфичные под мой контекст
- Гейты качества: стандарты вывода
**ШАГ 5. Обновлённые инструкции.**
Покажи патченную версию — не длиннее {лимит} символов.
Плейсхолдеры:
- {название_проекта} — например "Claude Project для работы с клиентами"
- {текущие_инструкции} — твои актуальные инструкции, даже если они короткие и неидеальные
- {описание_чем_занимается_проект} — 1–2 предложения про тип задач
- {5-10} — количество проб. 5 для быстрого прохода, 10 если инструкции сложные
- {лимит} — рекомендую 1000–2000 символов. Длиннее — не лучше
После первой итерации — вставь обновлённые инструкции обратно в шаблон и повтори. 3 итерации обычно достаточно.
🚀 Быстрый старт — вставь в чат:
Вот шаблон Probe-and-Refine для улучшения инструкций.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какие у тебя текущие инструкции и чем занимается проект — потому что без этого невозможно генерировать релевантные тест-кейсы и диагностировать провалы. Она возьмёт паттерн из шаблона и адаптирует под твою специфику.
Ограничения
⚠️ Нетривиальная задача: Для простых инструкций ("отвечай кратко") метод избыточен. Probe-and-Refine работает там где есть реальная сложность — многошаговые задачи, специфический контекст, разные типы входящих запросов.
⚠️ Качество проб зависит от описания: Если ты нечётко описал задачу в шаге 1 — модель сгенерирует нерелевантные тест-кейсы и диагностика будет мимо. Придётся уточнять.
⚠️ Инструкции под одну модель: Инструкции, отточенные под Claude, могут работать хуже в ChatGPT и наоборот. Исследование подтвердило: guidance, откалиброванный под одну модель, дестабилизирует другую. Если переключаешься между LLM — запусти итерацию заново.
⚠️ Не панацея для длины: Просто добавить больше текста в инструкции не помогает, а иногда вредит. Ценность Probe-and-Refine — в правильном контенте, не в объёме.
Ресурсы
Название: Probe-and-Refine Tuning of Repository Guidance for Coding Agents (2026, препринт)
Авторы: Asa Shepard, Jeannie Albrecht — Williams College
Код: github.com/asashepard/probe-and-refine-tuning
Бенчмарк: SWE-bench Verified
Упомянутые смежные работы: Meta Context Engineering (Ye et al., 2026), SWE-ContextBench (Zhu et al., 2026), Self-Refine (Madaan et al., 2023), Reflexion (Shinn et al., 2023)