Формат ответа

Хороший ответ в неправильном формате — это всё равно работа руками: вытащить нужное, убрать лишнее, переложить в таблицу. В этом уроке — как получать ответ сразу в том виде, в каком он пойдёт дальше: в трекер, в отчёт, в программу.

Просто попросите

Claude умеет отвечать таблицей, списком, JSON, YAML, markdown, CSV, текстом определённой структуры. Ни один из форматов не включается сам — их нужно назвать. «Ответь таблицей с колонками „Требование“, „Приоритет“, „Вопрос клиенту“» даёт таблицу. «Верни JSON с полями title, steps, expected, severity» даёт JSON.

Важно описывать формат так же конкретно, как содержание. «Структурированно» — не формат. «Нумерованный список, в каждом пункте — заголовок жирным и одно предложение пояснения» — формат.

Ответ в XML-тегах

В уроке «Разделяем данные и инструкции» теги помогали модели читать промпт. Тот же приём работает в обратную сторону: попросите модель положить ответ в тег, и вы получите чистые границы.

Напиши короткое описание релиза для клиента по списку изменений ниже.
Само описание помести в теги <release_note>.

<changes>
- Исправлена ошибка при экспорте отчёта в PDF
- Добавлен фильтр по дате в списке заказов
- Ускорена загрузка главной страницы
</changes>

Зачем это нужно? Во-первых, модель перестаёт добавлять вступления и заключения вокруг тега — или, если добавляет, они остаются снаружи, и их легко отбросить. Во-вторых, программа может вытащить содержимое между <release_note> и </release_note> одной строкой кода, не разбирая, где текст, а где комментарии модели. В-третьих, несколько частей ответа получают свои имена: <summary>, <risks>, <questions> — и дальше их можно раскладывать по разным полям.

Если нужно два варианта, попросите два тега: «первый вариант — в <option_1>, второй — в <option_2>». Так вы точно поймёте, где кончился один и начался другой.

Говорите, что делать, а не чего избегать

Форматирование — та область, где позитивные инструкции особенно важны. «Не используй markdown» работает хуже, чем «пиши связными абзацами обычным текстом». «Без списков» хуже, чем «встрой перечисления в предложения».

Ещё один приём — согласовать стиль промпта со стилем ответа. Если ваш промпт сам набит заголовками и буллетами, модель с большей вероятностью ответит тем же. Хотите прозу — пишите промпт прозой. Хотите JSON — покажите пример JSON. Модель отражает то, что видит.

JSON и структурированный вывод

Когда ответ модели будет читать программа, лучший формат — JSON: у него строгие правила, и любой язык умеет его разбирать. Опишите схему словами или примером:

Разбери баг-репорт и верни только JSON без пояснений:
{
  "title": "короткий заголовок до 80 символов",
  "steps": ["шаг 1", "шаг 2"],
  "expected": "ожидаемое поведение",
  "actual": "фактическое поведение",
  "severity": "critical | major | minor"
}

<report>
…
</report>

Современные модели надёжно следуют такой схеме, если она описана ясно. Для продуктов, где ошибка формата недопустима, в API есть режим структурированного вывода (structured outputs): вы передаёте схему, и ответ гарантированно ей соответствует. Для задач классификации тот же эффект даёт инструмент с полем-перечислением допустимых значений. Подробности — в документации. В чате этого режима нет, но словесного описания схемы обычно хватает.

Предзаполнение: как было и почему больше не нужно

В оригинальном туториале эта глава называется «Формат ответа и говорить за Claude». Второй приём — предзаполнение (prefill): разработчик добавлял в конец диалога начало ответа ассистента, например открывающий тег <haiku> или скобку {, и модель продолжала с этого места. Так заставляли пропустить вступление или начать сразу с JSON.

На моделях Claude, начиная с поколения 4.6, предзаполнение последнего хода ассистента не поддерживается — запрос вернёт ошибку. Это не потеря: всё, что делал префилл, теперь делается иначе и надёжнее.

• Без вступления → прямая инструкция: «Отвечай сразу по делу, без фраз вроде „Вот…“ и „Конечно…“».
• JSON без обёртки → инструкция «верни только JSON» или структурированный вывод.
• Начать с тега → «помести ответ в тег <answer>».
• Продолжить оборванный ответ → сообщение пользователя «твой ответ оборвался на „…“, продолжи с этого места».

Если вы встретите префилл в старых статьях, примерах или чужих промптах — вы знаете, чем его заменить.

Стоп-последовательности

Небольшой бонус для разработчиков. В API есть параметр stop_sequences: список строк, на которых генерация останавливается. Если вы попросили ответ в <answer> и передали </answer> как стоп-последовательность, модель остановится, как только закроет тег, и не станет писать заключение. Экономит время и токены. В чате параметра нет, а в консоли — есть.

Пример из работы

Менеджер собирает еженедельную сводку по проекту из сообщений команды. Первый промпт — «сделай сводку» — даёт хороший текст, который каждый раз выглядит по-разному, и его приходится переформатировать под шаблон письма. Второй промпт задаёт формат: «три раздела в тегах <done>, <in_progress>, <blockers>, в каждом не больше пяти пунктов, каждый пункт — одно предложение, без вводных слов». Сводка вставляется в письмо как есть. Экономия — десять минут каждую неделю, и это только один промпт.