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 кроків: Занадто дрібні кроки (наприклад, окремий крок для імпорту кожного типу) спалюють час і гроші. Тримайте рівень абстракції на рівні логічних функціональних блоків.