Plan-and-Solve Prompting

1. Обзор концепции и системная проблема

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

Такой сугубо реактивный подход вызывает критические сбои:

1. Нарушение порядка зависимостей: Агент изменяет компонент интерфейса до того, как обновил схему базы данных или создал необходимые типы TypeScript.
2. Циклические правки: Модель исправляет одну ошибку, ломая другой связанный файл, и застревает в бесконечном латании синтаксиса без понимания общей картины.
3. Потеря первичной цели: После 10 шагов поиска багов контекст забивается сообщениями компилятора, и модель забывает начальную задачу пользователя.

Plan-and-Solve устраняет эту проблему через классический принцип инженерии: Разделение стратегического проектирования (Planning) и тактической реализации (Execution).

2. Архитектурная таксономия и ментальная модель

Паттерн реализуется через три взаимодополняющие фазы:

• 1. Фаза исследования и планирования (Discovery & Planner Phase): Агент анализирует запрос, предварительно читает файловую систему (Read-Only) и генерирует четко структурированный граф действий: массив шагов с обозначением целей, критериев успеха и необходимых файлов.
• 2. Фаза выполнения шагов (Solver / Execution Phase): Специализированный исполнитель берет первый открытый пункт плана, вызывает необходимые инструменты (редактирование файлов, запуск сборки), убеждается в выполнении подзадачи и помечает пункт как завершенный.
• 3. Фаза динамического перепланирования (Replanning & Feedback Phase): Если во время выполнения шага возникает ошибка, которую невозможно решить простым повтором (например, обнаружена недостающая библиотека в системе), репланер пересматривает остальные пункты плана, добавляя шаг установки зависимостей.

3. Технический пайплайн и внутренняя механика

Жизненный цикл работы по паттерну Plan-and-Solve:

1. Plan Generation (Генерация структурированного плана): Модель формирует валидный JSON-объект с массивом задач: tasks: [{ id: 1, title: "DB Schema", status: "pending" }, { id: 2, title: "API Route", status: "pending" }].
2. State Injection (Инициализация трекера): План записывается в состояние агента. Пользователь видит визуальный прогресс выполнения в виде интерактивного чеклиста.
3. Execution Loop (Итеративное прохождение): Оркестратор выбирает следующую задачу со статусом pending. Контекст очищается от старых деталей отладки, фокусируясь только на текущей задаче и финальной цели.
4. Invariant Check & Status Transition (Контроль инвариантов): После завершения шага запускается линтер или юнит-тест. Если проверка успешна — статус изменяется на completed. Если нет — вызывается метод replan(), который корректирует невыполненные шаги.

4. Практические инженерные сценарии в продакшене

01. Комплексная миграция кодовой базы

Переход проекта с Next.js Pages Router на App Router:

• Шаг 1: Аудит структуры папки pages/ и выделение общих Layouts.
• Шаг 2: Создание корневого app/layout.tsx и базовых стилей.
• Шаг 3: Поэтапное перенесение статических страниц.
• Шаг 4: Переписывание динамических маршрутов и API Routes в route.ts.
• Шаг 5: Полный билд проекта и удаление устаревших файлов.

02. Создание новых функций по спецификации (Spec-Driven Development)

Агент получает бизнес-требование. Сначала он пишет документацию и схемы Zod, согласует их с пользователем, и лишь после получения одобрения пошагово генерирует бэкенд, клиентские хуки и UI-компоненты.

03. Инфраструктурное развертывание серверов

Поэтапное закаливание Linux VPS:

• Генерация плана из 6 этапов (SSH-ключи, UFW-файрвол, fail2ban, обновление пакетов, создание non-root пользователя, отключение парольного доступа).
• Каждый пункт выполняется отдельно с обязательной проверкой статуса порта перед отключением предыдущего метода связи.

5. Подводные камни, типовые ошибки и безопасность

• Планирование вслепую (Premature Planning): Составление плана без предварительного анализа файлов репозитория. Модель может спланировать использование библиотек, которых нет в проекте. Решение: обязательный шаг «Исследование» (Discovery) перед запуском планировщика.
• Чрезмерная жесткость (Plan Rigidity): Агент настойчиво пытается выполнить Шаг 3, когда на Шаге 1 выяснилось, что архитектура требует принципиально другого подхода. Обязательно внедряйте хуки динамического перепланирования.
• Микроменеджмент на 30 шагов: Слишком мелкие шаги (например, отдельный шаг для импорта каждого типа) сжигают время и деньги. Держите уровень абстракции на уровне логических функциональных блоков.