Часть 4: ЗАДАЧА (Task) и Итеративная Магия – Оживляем Код и Проект с ИИ

08 Май, 2025

Итак, у нас есть План (PRD), определяющий "что" и "зачем", и детальный Чертеж (Blueprint), отвечающий на вопрос "как". Оба документа пронизаны уникальными ID, которые ИИ помогал нам создавать и связывать. Настало время самого захватывающего этапа – превращения нашего Blueprint в реальный работающий код с помощью ИИ! Но прежде чем мы бросимся генерировать код, давайте поговорим о "правилах игры" на этом этапе.

4.1. "Контракты" на Каждом Шаге: Гарантия Соответствия

Прежде чем мы начнем "резать" наш Blueprint на задачи для ИИ, важно понять одну ключевую концепцию – идею "контракта" между этапами. Представьте, что каждый созданный нами документ – это не просто описание, а своего рода формальное соглашение:

1. PRD – это "контракт" для Blueprint: Наш Чертеж (Blueprint) обязан технически реализовать все то, что было задумано в Плане (PRD). Если в PRD есть фича `PRD-FEAT-002` (Создание события), то в Blueprint обязательно должны быть соответствующие технические решения (API, экран, база данных и т.д.). Наша система ID помогает это проверить: мы можем отследить, что для каждого важного `PRD-XXX` есть соответствующие `BP-XXX` в Blueprint.
2. Blueprint – это "контракт" для Задач (Tasks): А вот теперь каждая Задача на написание кода, которую мы будем ставить ИИ, обязана точно следовать спецификациям, описанным в Blueprint. Если в Blueprint для API (в нашем "Справочнике API" `BP-API-DIRECTORY-001`) сказано, что эндпоинт `BP-API-ENDPOINT-002` должен принимать определенные данные, то код, написанный по Задаче для этого API, должен делать именно это, и ничего другого.

Эти "контракты" нужны для согласованности: мы строим именно то, что задумали, шаг за шагом. Они снижают риск ошибок и недопонимания, особенно при работе с ИИ. Наша система ID (`PRD-XXX`, `BP-XXX`, и скоро появятся `TASK-XXX`) помогает делать эти контракты явными и отслеживаемыми.

4.2. От Blueprint к Задаче (Task): Режем Слона на Бифштексы для ИИ

Наш Blueprint содержит подробное описание того, как должна работать система. Но даже самый детальный Blueprint обычно слишком велик, чтобы просто сказать ИИ: "Сделай все по этому чертежу!". Нам нужно разбить большие элементы Blueprint на маленькие, конкретные, выполнимые Задачи (Tasks). Это как нарезать большого слона на маленькие бифштексы, которые легко "переварить".

Как разбивать Blueprint на Задачи?

• Фокус на одном действии/компоненте: Хорошая Задача обычно описывает создание или изменение одного небольшого логического блока.
• Понятный результат: Должно быть ясно, что должно получиться в итоге.
• Разумный размер: Задача должна быть достаточно мала для ИИ.

ИИ может сам помочь вам в этой декомпозиции, а также вести учет этих задач в структурированном виде!

Пример декомпозиции API для создания события (и его сохранение в JSON):

• Пользователь: "ИИ, давай теперь займемся реализацией нашего API для создания игровых событий (мы описали его концептуально в Blueprint и договорились, что детали ты ведешь в 'Справочнике API'). Как бы ты предложил разбить эту работу на конкретные Задачи для кодирования? И давай сразу договоримся, что ты будешь сохранять эти задачи в специальный файл, скажем, BP-API-ENDPOINT-002_tasks.json, а также добавлять их в наш общий список задач all_tasks.json."
• ИИ: _"Отличная идея! Для API, который мы обсуждали (и который в Blueprint я пометил как `BP-API-ENDPOINT-002` для 'Создания события'), я предлагаю такую последовательность Задач. Я сохраню их в `BP-API-ENDPOINT-002_tasks.json` и продублирую в `all_tasks.json`:
  • `TASK-001`: Создать модель данных Pydantic (в FastAPI) для приема данных запроса на создание события (поля возьмем из описания `BP-API-ENDPOINT-002` в 'Справочнике API'). Статус: 'todo'. Связан с: `BP-API-ENDPOINT-002`.
  • `TASK-002`: Написать основную функцию-обработчик для API эндпоинта POST /api/events. Она будет принимать модель из `TASK-001` и вызывать (пока заглушкой) функцию сохранения в базу. Статус: 'todo'. Связан с: `BP-API-ENDPOINT-002`.
  • `TASK-003`: Реализовать функцию сохранения данных о событии в базу данных PostgreSQL (в таблицу `BP-DB-TBL-EVENTS-001`). Статус: 'todo'. Связан с: `BP-API-ENDPOINT-002`, `BP-DB-TBL-EVENTS-001`.
  • `TASK-004`: Добавить в функцию из `TASK-002` базовую обработку ошибок. Статус: 'todo'. Связан с: `TASK-002`. Я присвоил этим задачам ID и занес их в указанные файлы. Такое разделение позволит нам шаг за шагом реализовать API."_

Важно понимать, что эти определенные нами Задачи (`TASK-XXX`) – это не просто идеи для следующего промта к ИИ. Каждую из них ИИ зафиксировал (в нашем примере – в JSON-файлах). Это позволяет вам не потеряться в потоке работы и видеть общую картину прогресса, просто спросив ИИ: "Какие задачи у нас сейчас по API создания события?" или "Покажи все задачи со статусом 'todo'".

4.3. Искусство Промптинга для Задач: Даем ИИ Четкие Инструкции на Кодирование

Итак, у нас есть маленькие Задачи (`TASK-XXX`), описанные и сохраненные (например, в tasks.json, который ведет ИИ). Как правильно попросить ИИ написать для них код? Качество промта – ключ к успеху!

Что должно быть в хорошем промте для Задачи:

1. Четкая Цель: Опишите, что конкретно нужно сделать, ссылаясь на суть Задачи (например, "Реализуй сохранение данных о событии в базу"). ИИ, помня контекст и имея доступ к tasks.json, свяжет это с нужной `TASK-XXX`.
2. Контекст: Кратко напомните, к чему относится эта Задача (ИИ сам найдет детали по `TASK-ID`, но человеческое напоминание о фиче PRD или элементе Blueprint может помочь).
3. Технологии: Язык, фреймворк (ИИ должен знать это из `BP-CODESTD-XXX` или `BP-ARCHPRINCIPLE-XXX`).
4. Входные/Выходные данные: Что функция принимает, что возвращает?
5. Требования и Ограничения: Особые условия, обработка ошибок, стиль кода.
6. Комментарии/Документация: Просите ИИ пояснять код.

Пример: Хороший vs. Плохой Промт для Задачи "Реализовать сохранение данных о событии в БД" (наша `TASK-003`)

• Плохой Промт: "ИИ, напиши код для сохранения события в базу."
• Хороший Промт:
  • Пользователь: "ИИ, давай теперь реализуем сохранение данных о событии в базу данных PostgreSQL. Это часть нашего API создания события."
  • ИИ: "Понял. Вы имеете в виду Задачу `TASK-003`: 'Реализовать функцию сохранения данных о событии в базу данных PostgreSQL (в таблицу `BP-DB-TBL-EVENTS-001`)'. Все верно? Готов приступить к деталям."
  • Пользователь (уточняет детали для промта): "Да, все верно для `TASK-003`. Напиши функцию на Python, которая принимает объект с данными события (из модели Pydantic, которую мы сделали для `TASK-001`) и ID пользователя-создателя. Функция должна вставить новую запись в таблицу 'events' (структуру полей мы определили в Blueprint как `BP-DB-TBL-EVENTS-001`). Используй SQLAlchemy (мы это обсуждали для работы с БД). Верни ID созданного события. Не забудь про обработку возможных ошибок при записи в базу и следуй нашему стандарту кодирования (`BP-CODESTD-001`). Добавь docstring к функции."

4.4. Микро-Итерации: "Доводка" Кода с ИИ Сразу После Генерации

ИИ сгенерировал код по вашему промту для Задачи `TASK-XXX`. Отлично! Но это еще не конец. Теперь начинается этап микро-итераций – быстрых циклов обратной связи с ИИ для улучшения только что созданного кода.

• Рефакторинг (улучшение кода):
  • Пользователь: "ИИ, посмотри на код, который ты написал для TASK-003. Можно ли его сделать более читаемым или эффективным?"
• Генерация Тестов:
  • Пользователь: "Для функции сохранения события (из TASK-003), напиши, пожалуйста, несколько unit-тестов с использованием pytest." (Unit-тесты – это маленькие программы, которые проверяют правильность работы других маленьких программ/функций).
• Поиск Ошибок:
  • Пользователь: "Проанализируй код для TASK-003. Видишь ли ты какие-нибудь потенциальные проблемы?"
• Документирование:
  • Пользователь: "Добавь, пожалуйста, еще комментарии к логике обработки ошибок в коде TASK-003."

Эти микро-итерации позволяют "довести до ума" код для каждой Задачи сразу, повышая его качество и надежность.

4.5. Большая Петля Обратной Связи: Поддерживаем Blueprint "Живым"

Разработка – живой процесс. Иногда при реализации Задачи вы (или ИИ) можете обнаружить что-то новое или столкнуться с проблемой, которая требует изменения в вашем первоначальном плане – в Blueprint. Это нормально! Важно иметь механизм обратной связи от Задачи к Blueprint.

Как это работает?

• Пример сценария: ИИ работает над Задачей `TASK-003` (сохранение события). В процессе он "понимает", что для удобного поиска не хватает статуса события ('запланировано', 'прошло', 'отменено').

• Предложение ИИ:

  • ИИ: "Я работаю над `TASK-003` по сохранению события в базу данных (`BP-DB-TBL-EVENTS-001`). Я заметил, что у нас нет поля для статуса события. Это может быть полезно для фильтрации в будущем. Предлагаю добавить поле status (текст) в таблицу `BP-DB-TBL-EVENTS-001`. Это также потребует небольших изменений в API для создания и обновления событий (в нашем 'Справочнике API' `BP-API-DIRECTORY-001`). Как вы думаете, стоит внести эти изменения в Blueprint?"

• Ваше Решение и Критическое Мышление:

  • Вот здесь включается ваше видение! ИИ предлагает, но финальное решение – за вами. Всегда критически оценивайте предложения ИИ. Соответствует ли это изменение целям вашего проекта (нашим `PRD-GOAL-XXX`)? Не усложнит ли это MVP? Действительно ли это нужно сейчас? Задайте ИИ уточняющие вопросы. Вы – главный архитектор своего проекта, а ИИ – очень умный, но все же помощник.
  • Если вы решаете, что изменение нужно, вы даете команду ИИ (или делаете это сами) внести правки в Blueprint.md и, возможно, ИИ сам предложит создать новые Задачи для реализации этих изменений (и добавит их в tasks.json).

Отслеживание Реализации: Как Понять, что Blueprint "Выполнен"?

Еще один важный аспект "живого" Blueprint – это отслеживание прогресса. Как понять, какие части нашего Чертежа уже реализованы?

• Механизм: По мере завершения Задач (`TASK-XXX`), которые ИИ отмечает как 'done' в tasks.json (по вашей команде), мы должны обновлять и наш Blueprint.md.
• Пример диалога с ИИ:
  • Пользователь: "ИИ, мы успешно завершили задачи TASK-001, TASK-002, TASK-003 и TASK-004. Ты уже отметил их как 'done' в tasks.json. Вместе они полностью реализуют API для создания игрового события, описанное в Blueprint как `BP-API-ENDPOINT-002`. Как нам это отразить в Blueprint.md?"
  • ИИ: "Понял. Статусы задач в tasks.json обновлены. Чтобы отразить это в Blueprint.md, вы можете рядом с описанием `BP-API-ENDPOINT-002` добавить метку, например: [Статус: Реализовано (TASK-001, TASK-002, TASK-003, TASK-004)]. Это покажет, что работа по этому элементу Blueprint завершена."

Таким образом, ваш Blueprint становится не только планом, но и отражением текущего состояния разработки. Иногда обратная связь может идти и к PRD, если на этапе Blueprint или реализации выясняется, что первоначальные требования нереализуемы или нелогичны. Эта система Задач и обратной связи (как микро-, так и макро-) позволяет вам гибко управлять процессом разработки с ИИ, постоянно улучшать код и поддерживать ваш проектный план в актуальном и "живом" состоянии.