Принципы построения эффективных промптов для кода

Создание эффективных промптов для Claude Code требует перехода от простого описания задачи («напиши функцию») к полноценному техническому заданию. Основной принцип заключается в предоставлении максимально возможного контекста. Когда вы просите ИИ изменить код, он должен понимать не только что нужно изменить, но и как эта часть взаимодействует с остальной архитектурой приложения. Чем меньше догадок остается модели, тем меньше вероятность появления галлюцинаций или нарушения логики в соседних модулях.

Одним из ключевых элементов качественного промпта является четкое определение роли. Вместо того чтобы просто задавать вопрос, начните с установки контекста: «Ты — ведущий инженер по безопасности с 10-летним опытом разработки на TypeScript». Это заставляет модель приоритизировать определенные паттерны проектирования, такие как строгая типизация, обработка исключений и защита от инъекций, вместо того чтобы предложить самое простое, но небезопасное решение.

Структурирование промпта с помощью разделителей (например, XML-тегов или четких заголовков) помогает Claude Code лучше различать инструкции, исходный код и ожидаемый результат. Использование тегов вроде <context>, <requirements> и <constraints> позволяет модели точно сопоставить требования с конкретными участками кода. Это особенно важно при работе с большими файлами, где инструкции могут затеряться среди сотен строк реализации.

Рассмотрим пример промпта для рефакторинга функции с применением принципа единственной ответственности (Single Responsibility Principle).

// Prompt: "Рефактори следующий код, разделив логику валидации и сохранения данных. 
// Используй паттерн Repository. Оберни результат в Try-Catch блок."

async function createUser(userData: any) {
  if (!userData.email || !userData.email.includes('@')) {
    throw new Error('Invalid email');
  }
  const user = await db.users.insert(userData);
  await emailService.sendWelcome(user.email);
  return user;
}

В данном примере код сначала проверяет наличие и корректность email, затем выполняет вставку в базу данных и отправляет приветственное письмо. Логика смешана: валидация, работа с БД и внешние уведомления находятся в одной функции.

Данный подход был выбран для демонстрации типичной «толстой» функции. Мы просим Claude Code применить паттерн Repository, чтобы отделить слой доступа к данным от бизнес-логики, и выделить валидацию в отдельный метод. Это делает код тестируемым: теперь мы можем протестировать валидацию без необходимости запуска базы данных или почтового сервера.

Важным аспектом является описание ограничений (Constraints). Если вы не хотите, чтобы Claude Code использовал определенные библиотеки или менял структуру API, это нужно указать явно. Например: «Не обновляй зависимости в package.json» или «Используй только стандартную библиотеку Python без сторонних модулей». Ограничения сужают пространство поиска для модели и предотвращают внесение нежелательных изменений в инфраструктуру проекта.

Еще одна продвинутая техника — «Цепочка рассуждений» (Chain-of-Thought). Попросите модель сначала описать план действий, прежде чем писать код. Промпт вида «Сначала проанализируй текущую архитектуру, опиши пошагово, какие изменения потребуются, и только после моего подтверждения приступай к кодингу» значительно снижает риск того, что ИИ перепишет половину проекта, чтобы исправить одну опечатку.

Рассмотрим пример реализации сложной бизнес-логики с четким заданием требований.

# Prompt: "Реализуй класс OrderManager. 
# Требования: 
# 1. Метод calculate_total должен учитывать скидку 10%, если сумма > 1000.
# 2. Логирование всех транзакций через стандартный модуль logging.
# 3. Обработка исключения InsufficientFunds при оплате."

import logging

class OrderManager:
    def __init__(self):
        self.logger = logging.getLogger(__name__)

    def calculate_total(self, amount):
        discount = 0.9 if amount > 1000 else 1.0
        return amount * discount

    def process_payment(self, amount, balance):
        if amount > balance:
            self.logger.error("Insufficient funds")
            raise InsufficientFundsError("Not enough money")
        return True

Этот код реализует класс для управления заказами. Метод calculate_total проверяет порог в 1000 единиц для применения скидки. Метод process_payment сравнивает сумму заказа с балансом пользователя и выбрасывает кастомное исключение при нехватке средств, предварительно записывая ошибку в лог.

Мы использовали императивный стиль подачи требований (нумерованный список), так как это минимизирует вероятность пропуска одного из пунктов. Выбор стандартного модуля logging вместо print обусловлен требованиями к промышленному качеству кода (production-ready), что делает решение масштабируемым и удобным для мониторинга.

Общие ошибки новичков при промптинге для кода — это чрезмерная краткость и отсутствие контекста о типах данных. Фразы вроде «Исправь ошибку в этом файле» заставляют Claude Code гадать, что именно считается ошибкой (баг в логике, нарушение стиля или проблема с производительностью). Чтобы избежать этого, всегда указывайте: (1) что происходит сейчас, (2) что должно происходить в идеале и (3) какой конкретный симптом указывает на проблему.

В реальном мире такие принципы промптинга используются при интеграции LLM в CI/CD пайплайны для автоматического написания Unit-тестов. Например, в крупных проектах создаются системные промпты, которые содержат весь Style Guide компании и описание архитектуры проекта. Когда новый код попадает в репозиторий, агент (подобный Claude Code) анализирует его на соответствие этим стандартам, используя строго заданные критерии и ограничения.

Попробуйте это: Возьмите любой существующий в вашем проекте метод, который делает более двух разных вещей (например, парсит данные и сохраняет их). Напишите промпт для Claude Code, используя роль «Архитектор ПО», XML-теги для разделения требований и ограничений, и попросите его провести рефакторинг, предварительно составив план изменений.