План вместо промпта: как ставить нейросети задачу собрать продукт
Показываю на своих планах — ColorMods, FERRO, лицензионный сервер QoLab — из чего состоит документ, по которому нейросеть собирает продукт по шагам и не сваливается на второй фиче.
Почему длинный промпт разваливается
Когда я прошу нейросеть «сделай мне лицензионный сервер», получаю правдоподобный набросок, который сыпется на второй фиче. Модель угадывает мои намерения и угадывает неверно. Проблема простая: структуру продукта я держу в голове, а наружу отдаю одно предложение.
Я перестал писать промпты и начал писать планы. План — это документ, по которому ассистент собирает продукт по шагам. Ниже разберу, из чего он состоит, на своих реальных кейсах.
Начинаю с цели
Первая строка плана отвечает на вопрос «что и зачем», одним абзацем. В плане ColorMods 2.0 у меня стоит: «Заменить захардкоженные списки движком пользовательских правил раскраски… через тестируемую библиотеку PoeRedux.Core». Здесь есть и результат, и причина, и намёк на то, каким способом я хочу его получить.
Цель держит модель на курсе. Когда через двадцать шагов она решает, куда свернуть, она сверяется с этой строкой. Без цели каждый шаг превращается в самостоятельную догадку.
Описываю архитектуру и границы
Дальше идёт раздел, который экономит мне больше всего времени, — архитектура. Я говорю, куда класть код и где проходят границы. В том же ColorMods: «Вынести чистую строковую логику в новую библиотеку PoeRedux.Core (net10.0, без WPF)». Модель теперь знает стек, знает, что WPF в ядро не тащим, знает имя проекта.
В плане FERRO я иду дальше и объявляю скелет контрактом: «Скелетные файлы менять НЕЛЬЗЯ (только читать). Если контракта не хватает — реализуй обходным путём в своих файлах и явно отметь это в отчёте». Это спасает от любимого поведения ассистента — переписать половину проекта, чтобы «стало чище».
Режу на задачи с чекбоксами
Продукт целиком модель не удержит. Я режу работу на задачи и ставлю перед каждой чекбокс - [ ]. В плане лицензионного сервера QoLab шаги идут именно так: подписал токен через Ed25519, экспортировал публичный ключ для .NET-клиента, поднял эндпоинт. Чекбокс — это и граница задачи, и способ отследить прогресс, когда я возвращаюсь к работе через день.
Одна задача — один законченный кусок, который можно проверить. Если задачу нельзя проверить в изоляции, она слишком крупная, и я её дроблю.
Прописываю процесс работы
Вверху плана я задаю, каким способом работать. В QoLab это строка: «REQUIRED SUB-SKILL: test-driven-development for every logic task». В ColorMods — «Use executing-plans to implement this plan task-by-task».
Разница огромная. Без этой строки модель пишет код и объявляет его готовым. С ней она сначала пишет тест, смотрит, как он падает, потом реализует. Библиотеку PoeRedux.Core я специально вынес отдельно и покрыл юнит-тестами xUnit — тестируемость заложена в архитектуру с самого начала.
Короткий шаблон
Свои планы я собираю по одной рыбе:
- Goal — что и зачем, один абзац.
- Architecture — стек, куда класть код, границы и запреты.
- Contract — что трогать нельзя, что можно читать.
- Задачи — список с
- [ ], каждая проверяема в изоляции. - Процесс — TDD, пошаговое исполнение, формат отчёта.
Сначала пишу этот документ сам, вычитываю его как ТЗ для живого разработчика, и только потом отдаю нейросети. Час на план окупается тем, что мне не приходится переделывать три дня сгенерированного кода.
Главный сдвиг для меня оказался простым: ассистент собирает ровно то, что я описал. Расплывчатое описание даёт расплывчатый продукт. Точный план даёт продукт по плану.