Перевод с разбором · для Вани

Примеры в промпте (few-shot)

Идея в одном абзаце

Когда вы что-то просите у Claude, самый надёжный способ задать стиль, тон и структуру ответа — показать примеры того, что вам нужно. Не «опиши формат словами», а «вот два-три готовых образца — сделай так же». Этот приём в документации называется few-shot («несколько примеров в промпте») или multishot prompting. Слово shot здесь означает один пример, не «выстрел» в смысле попытки.

Что говорит Anthropic

Цитата из Claude prompting best practices:

Примеры — один из самых надёжных способов управлять форматом, тоном и структурой ответа Claude. Несколько хорошо продуманных примеров (известных как few-shot или multishot prompting) могут кардинально повысить точность и консистентность.

Добавляя примеры, делайте их:

• Релевантными: близко отражайте ваш реальный сценарий использования.
• Разнообразными: покрывайте граничные случаи и варьируйте примеры так, чтобы Claude не ухватил непредусмотренные паттерны.
• Структурированными: оборачивайте примеры в теги <example> (несколько примеров — в теги <examples>), чтобы Claude мог отличить их от инструкций.

Почему это работает

Claude — большая языковая модель. Она хорошо подхватывает паттерн, если вы его явно показали. Словесное описание («сделай в таком-то стиле, с такими-то полями, без markdown») всегда оставляет зазор интерпретации. Пример этот зазор закрывает: модель видит конкретный эталон и копирует его форму.

Три качества из цитаты выше — релевантность, разнообразие, структура — это не три абстрактных пункта, а три способа промахнуться:

• Не релевантные примеры — вы показали Claude детские задачи, а потом ждёте, что он продолжит так же на сложных. Он продолжит, но в стилистике детских задач.
• Не разнообразные примеры — все три примера про один и тот же случай. Claude решит, что других случаев не бывает, и будет переносить чужой паттерн на новые ситуации.
• Не структурированные примеры — примеры свалены в один абзац вперемешку с инструкциями. Claude может перепутать, где задание, а где образец.

Как это выглядит на практике

Типовая структура few-shot-промпта выглядит так. Внутри блока — английский, потому что это формат, который модель понимает напрямую; ваши собственные данные подставляются внутрь тех же тегов:

<examples>
  <example>
    <input>...</input>
    <output>...</output>
  </example>
  <example>
    <input>...</input>
    <output>...</output>
  </example>
</examples>

Now process this input:
<input>...</input>

Здесь внешний контейнер — <examples>, каждый пример — пара <input> / <output> внутри <example>. Дальше идёт реальное задание (тоже в <input>), и модель достраивает <output> в том же стиле, что и в примерах.

Пример в твоём стеке: попросить Claude Code написать тест

Самая практичная ситуация для few-shot в вашей работе — когда вы просите Claude Code сгенерировать новый класс или тест в стиле того, что у вас уже написано. Словами объяснить «пиши в моём стиле» почти бесполезно: у проекта десятки незаписанных конвенций. Гораздо проще показать живой образец.

Скажем, у вас в проекте есть интеграционный тест для OrderService, и вы хотите, чтобы Claude Code написал аналогичный для MaterialService. Промпт в чате с Claude Code может выглядеть примерно так (русский — это инструкция, английский внутри тегов — структура, которую модель видит как разметку):

Напиши интеграционный тест для MaterialService по образцу.
Структура и стиль должны точно совпадать с примером.

<example>
  <file_path>src/test/kotlin/.../OrderServiceIT.kt</file_path>
  <content>
    // ... содержимое существующего теста, который наследует
    // IntegrationTestBase, использует JdbiExtension и т.д.
  </content>
</example>

<task>
  Создай аналогичный файл MaterialServiceIT.kt.
  Покрой методы: создание материала, обновление цены,
  применение markupMaterialsPct при расчёте.
  Тот же стиль ассертов и наименований, что в примере.
</task>

Здесь работают все три критерия Anthropic: пример релевантен (тот же фреймворк, тот же базовый класс IntegrationTestBase), структурирован (теги <example> и <task> отделяют образец от задания), и если вы захотите большей надёжности — добавьте второй пример с другим сервисом (например, OrderCalculationService), чтобы Claude увидел разнообразие и не зацепился за случайные детали одного-единственного образца.

Когда few-shot особенно полезен

• Жёсткий формат вывода. Например, вы хотите, чтобы Claude вернул JSON определённой формы, или markdown с фиксированным набором заголовков. Один-два примера правильного вывода работают лучше любого описания.
• Стиль кода. Имена переменных, способ обрабатывать ошибки, структура слоёв (OrderRepository → OrderService → ручка). Покажите Claude один существующий слой — и он повторит конвенцию для следующего.
• Пограничные случаи. Если у вас в реальных данных бывает «пустой заказ», «заказ только из работ без материалов», «отменённый заказ» — соберите по одному примеру каждого случая, чтобы Claude не считал, что бывает только «обычный» вариант.
• Стилистика тестов. Один образец в духе JwtFilterTest избавляет от длинного объяснения «у нас JUnit 5, Kotest-ассерты, заголовки авторизации мокаем так-то».

Чего не делать

• Не давать один пример и ждать обобщения. Один пример Claude скопирует слишком буквально. Минимум — два, лучше три-пять, и они должны различаться по содержанию, но совпадать по форме.
• Не смешивать примеры с инструкциями в одном абзаце. Оборачивайте в <example> или хотя бы визуально отделяйте.
• Не подсовывать «плохие» примеры в надежде, что Claude угадает, что они плохие. Если все примеры из набора верные, модель усваивает «вот так правильно». Если хотите показать контр-пример — пометьте его явно: «вот пример того, как делать не надо».

Короткое резюме

Few-shot — это «покажи, а не расскажи» в применении к промптам. 3–5 примеров, релевантные, разнообразные, обёрнутые в <example>-теги. В вашей работе с Claude Code Desktop этот приём чаще всего приходит в форме «вот существующий файл — сделай аналогично», и это абсолютно валидный способ его применять.