Промптинг Claude Fable 5 и Claude Opus 5: практическое руководство

Claude Fable 5 — флагман семейства Claude 5 от Anthropic, Claude Opus 5 — ступень ниже и доступнее. Обе модели текстовые, держат контекст около 1 000 000 токенов и умеют рассуждать, анализировать изображения, вызывать инструменты и функции, искать в вебе, генерировать картинки и уверенно работают с кодом. Обе доступны в GPTunneL — открой чат, выбери модель и пробуй примеры из этого гайда прямо по ходу чтения.

Когда выбирать Fable 5, а когда Opus 5

• Claude Fable 5 — для сложнейших задач: многошаговые рассуждения, глубокий анализ больших документов, архитектурные решения в коде, длинные автономные цепочки с инструментами. Бери его, когда цена ошибки высока, а задачу трудно даже сформулировать.
• Claude Opus 5 — баланс качества и доступности: повседневный код, тексты, разбор документов, структурированное извлечение данных. Для большинства рабочих задач его хватает с запасом.

Практичный подход: начни с Opus 5, и если ответ «не дотягивает» на действительно сложной задаче — повтори тот же промпт на Fable 5.

Что учитывать при промптинге

• XML-теги — фирменная техника Claude. Модели семейства обучены хорошо понимать разметку вида <instructions>, <data>, <examples>, <answer>: она отделяет инструкции от данных и убирает двусмысленность. Подробнее — в гайде Anthropic по XML-тегам.
• Длинный контекст. В ~1 000 000 токенов помещаются целые книги и репозитории. Клади большие материалы в начало промпта, а вопрос и инструкции — в конец, и проси ссылаться на конкретные разделы источника: так ответы точнее.
• Код. Обе модели сильны в коде, но результат заметно лучше, если задать язык, версию, стиль и ограничения («без новых зависимостей», «сохрани публичный API»). Проси объяснять изменения — легче проверять.
• Ясность важнее длины. Явно фиксируй цель, формат вывода и критерии готовности — базовый принцип из обзора промпт-инжиниринга Anthropic.

Техники с примерами

Структурный шаблон

Универсальная заготовка для любой нетривиальной задачи:

<instructions>
Роль: технический редактор. Цель: сократить статью до 800 слов.
Ограничения: сохранить все цифры и цитаты. Формат: Markdown.
</instructions>
<data>{текст статьи}</data>
<answer>Верни только итоговый текст, без комментариев.</answer>

Few-shot: примеры вместо описаний

Когда важен стиль или схема вывода, покажи 1–3 пары «вход → выход» — это работает лучше длинных объяснений:

Классифицируй обращения. Категории: баланс, модели, баг.
<examples>
«Не проходит оплата» → баланс
«Какая модель лучше для кода?» → модели
</examples>
Обращение: «Кнопка отправки не нажимается» →

Управляемое рассуждение с <thinking>

Для задач с подвохом попроси модель сначала рассуждать, потом отвечать:

Сначала разбери задачу шаг за шагом внутри <thinking>…</thinking>:
перечисли известные факты, проверь граничные случаи.
Затем дай финальный ответ внутри <answer>…</answer>.

Префилл ответа

Задай первые символы ответа, чтобы зафиксировать формат и отрезать вступления:

Верни список рисков проекта строго как JSON-массив.
Начни ответ ровно с символов: {"risks": [
Ничего до и после JSON не пиши.

Цепочки self-critique

Разбей работу на «черновик → критика → финал» в одном или нескольких сообщениях:

Шаг 1. Напиши черновик функции по ТЗ ниже.
Шаг 2. В <critique> найди в своём черновике минимум 3 проблемы:
ошибки, краевые случаи, читаемость.
Шаг 3. В <answer> дай исправленную финальную версию.

Готовые промпты — копируй и адаптируй

1. Ревью кода: «Проведи ревью кода в <data>. Для каждой проблемы укажи строку, серьёзность (критично/важно/мелочь) и исправление. В конце — таблица-сводка. Не переписывай код целиком».
2. Выжимка документа: «В <data> — длинный документ. Дай выжимку: 5 главных тезисов, каждый со ссылкой на раздел источника. Потом раздел "Риски и открытые вопросы". Формат — Markdown».
3. Разбор скриншота: «Прикладываю скриншот интерфейса. Опиши, что на нём происходит, найди проблемы UX и предложи 3 конкретных улучшения — от самого дешёвого к самому затратному».
4. Рефакторинг: «Отрефактори код в <data>: убери дублирование, улучши имена, сохрани поведение и публичный API. В <answer> — код, затем список изменений с обоснованием каждого».
5. Поиск с проверкой: «Найди в вебе актуальную информацию по теме X. Для каждого утверждения укажи источник. Отдели факты от оценок. Если данные расходятся — покажи оба варианта».

Диагностика типовых сбоев

Все примеры можно проверить в GPTunneL за пару минут: запусти один и тот же промпт на Claude Opus 5 и Claude Fable 5 и сравни, где разница реально ощутима для твоих задач.