Plan-and-Solve Prompting

Суть в двух словах

Plan-and-Solve помогает, когда модель:

• пропускает шаги;
• путает порядок действий;
• рано прыгает к ответу;
• в целом "понимает" задачу, но плохо удерживает структуру.

Особенно хорошо техника работает в:

• расчётах;
• аналитических задачах;
• structured writing;
• support и ops workflows;
• сценариях, где нужен проверяемый порядок действий.

Сначала составь краткий план решения, потом выполни его по шагам.

Компания продала 240 лицензий по 12 000 ₽. 18% клиентов получили скидку 20%. 6% оплат не прошли и не вошли в выручку. Себестоимость сервиса составляет 22% от оплаченной выручки. Найди валовую прибыль.

Что именно улучшает Plan-and-Solve

Проблема single-pass prompting в том, что модель часто делает три вещи одновременно:

• интерпретирует задачу;
• придумывает план;
• выполняет шаги.

Когда всё это смешано в один поток, модель легко теряет структуру. Plan-and-Solve снижает хаос за счёт явной двухфазности:

1. plan
2. execute

Это делает reasoning менее импульсивным и лучше управляемым.

Где техника окупается лучше всего

PS и PS+

В оригинальной работе обычно различают:

• PS — сначала план, потом решение;
• PS+ — более дисциплинированная версия с акцентом на переменные, промежуточные значения и аккуратное выполнение.

В прикладной практике 2026 PS+ почти всегда полезнее базового PS, если задача:

• численная;
• policy-heavy;
• procedural;
• чувствительна к пропущенным условиям.

Когда техника не помогает

Plan-and-Solve не стоит переоценивать. Он мало полезен, если:

• задача чисто factual;
• ответ короткий и прямой;
• проблема не в порядке шагов, а в нехватке внешних данных;
• нужно не планирование, а decomposition на независимые ветки;
• prompt already over-constrained и дополнительный план только раздувает ответ.

Хороший prompt pattern

Практически устойчивый шаблон обычно такой:

1. Составь только план.
2. Не решай задачу в фазе плана.
3. Выдели ключевые сущности, переменные или критерии.
4. Выполни шаги плана по порядку.
5. В конце дай отдельно финальный answer.

Production-версия техники

В проде Plan-and-Solve особенно полезен, когда план сам по себе является артефактом:

• plan for support workflow;
• plan for investigation;
• plan for report generation;
• plan for incident response;
• plan for content draft.

Это позволяет:

• логировать план отдельно;
• ревьюить его человеком;
• роутить отдельные шаги в tools или sub-agents;
• отклонять execution, если план плохой.

Сравнение с близкими техниками

Частые ошибки

Ещё три частых проблемы:

• план слишком абстрактный и не помогает исполнению;
• execution не привязан к шагам плана;
• финальный answer появляется без сверки с планом.

Техническая реализация

Простой двухфазный паттерн

def plan_and_solve(task, plan_fn, execute_fn):
    plan = plan_fn(task)
    solution = execute_fn(task=task, plan=plan)
    return {"plan": plan, "solution": solution}

Где лучше делать app-side split

Разделять planning и execution в коде особенно полезно, если:

• задача high-stakes;
• execution включает tool calls;
• план нужен для approval;
• шаги должны логироваться и повторяться;
• вы хотите selective retry only for execution.

Что валидировать в плане

Минимальный набор checks:

• план покрывает исходную задачу;
• шаги не дублируют друг друга;
• порядок реалистичен;
• есть явный финальный synthesis step;
• шаги достаточно конкретны для исполнения.

Полезный production routing

• Direct answer для простых задач;
• Plan-and-Solve для procedural reasoning;
• Least-to-Most для зависимых промежуточных вычислений;
• BSM для multi-criteria evaluation;
• DECOMP для сложной modular orchestration.

Где техника сочетается с tool use

Plan-and-Solve хорошо работает в agentic сценариях, где:

• шаг 1 — составить план;
• шаг 2 — выбрать инструменты;
• шаг 3 — выполнить инструменты по порядку;
• шаг 4 — собрать final answer.

Это уже близко к lightweight workflow engine, а не просто к prompt trick.