Промптинг 101 | Кодим с Claude

Коротко

Доклад от Anthropic — практический разбор prompt engineering на реальном кейсе шведской страховой компании, где Claude должен оценивать формы ДТП и схемы аварий. Спикеры (Кристиан и Ханна) проходят через 4 версии промпта, последовательно добавляя контекст задачи, тональность, фоновые данные о форме, примеры, пошаговые инструкции и форматирование вывода. Главный приём — итеративная разработка: начинают с минимального промпта (Claude ошибочно решает, что это лыжная авария), и через 10 структурных компонентов доводят до уверенного, форматированного вердикта в XML-тегах. Подчёркивается, что в API-режиме нужен one-shot результат без диалога, поэтому структура промпта критична. В финале — упоминание prefill ответа и extended thinking в Claude 3.7/4 как дополнительных инструментов.

Главный тезис

Prompt engineering — это итеративная эмпирическая наука: хороший промпт строится не сразу, а наращивается по 10 структурным компонентам (task context, tone, background data, examples, conversation history, immediate task, step-by-step, output formatting, prefilled response, extended thinking), где каждое добавление решает конкретную проблему, выявленную на предыдущей итерации.

Ключевые идеи

• 0:52 — Лучший способ изучить prompt engineering — практика; теория без итераций не работает.
• 2:52 — Без контекста Claude уверенно галлюцинирует: интерпретирует форму ДТП как отчёт о лыжной аварии на улице Чаппанган, потому что не дано рамок задачи.
• В API-сценариях нужен one-shot результат без диалога, поэтому промпт должен содержать всё необходимое сразу, в отличие от чат-режима.
• 4:24 — Task description в начале промпта: кто Claude, какая роль, какую задачу решает сегодня.
• 6:05 — Tone context задаёт поведение: Claude должен оценивать фактологично и уверенно, но при недостатке данных — отказываться от вердикта, а не угадывать.
• 9:01 — Статичные данные (структура формы, которая никогда не меняется) кладутся в system prompt и кешируются через prompt caching — экономия токенов и времени.
• 9:46 — Claude любит структуру: XML-теги как делимитеры лучше markdown, потому что в самом теге можно указать тип контента (<user_preferences>).
• 13:11 — Few-shot examples — мощнейший механизм управления; особенно для grey-zone случаев, где человеческая разметка даёт правильный ответ, а Claude сам бы ошибся.
• 16:06 — Финальные reminder-инструкции в конце промпта работают как анти-галлюцинационный фильтр: «отвечай только при уверенности», «ссылайся на конкретные пункты формы».
• 17:26 — Порядок анализа критичен: сначала форма (даёт контекст), потом схема (интерпретируется через форму) — повторяет человеческую логику работы со сложными документами.
• 20:06 — Output formatting: вывод оборачивается в <final_verdict> XML-теги, чтобы downstream-приложение могло парсить только нужное и игнорировать reasoning.
• 22:24 — Prefilled response (assistant prefill): начать ответ Claude с [ или <tag> — самый надёжный способ форсировать JSON или XML-структуру вывода.
• 23:21 — Extended thinking в Claude 3.7 и 4 — не только улучшает точность, но и даёт прозрачность: можно прочитать reasoning trace и понять, как улучшать system prompt.
• 3:22 — Prompt engineering = эмпирическая наука с feedback loop: ловишь ошибку → добавляешь пример в system prompt → проверяешь, что следующий аналогичный случай отрабатывает корректно.

Почему это важно

Это методичка от Anthropic для enterprise-разработчиков, которые встраивают Claude в production-пайплайны (страховые, банковские, документ-процессинг). Победители — компании, которые перестают воспринимать LLM как чёрный ящик и начинают строить системы вокруг промптов как версионируемого артефакта с регрессионными тестами. Anthropic заинтересован в этом подходе, потому что он показывает Claude в его сильнейшей конфигурации (system prompt + caching + extended thinking + tool use) и привязывает клиентов к best practices, оптимизированным именно под его модели — XML-теги, например, специально натренированы у Claude и работают хуже у конкурентов.

Идеи

• Начальная ошибка Claude (лыжная авария вместо ДТП) — диагностический сигнал: показывает, какие предположения модель делает «по умолчанию» в отсутствие контекста.
• Температура 0 и большой max_tokens на старте — стандартная настройка для отладки промптов: убирает шум вариативности.
• Форма всегда одна и та же → её описание идёт в system prompt → кешируется → каждый последующий запрос дешевле и быстрее.
• Структура формы (17 чекбоксов, 2 столбца Vehicle A / Vehicle B) описывается Claude вербально один раз, чтобы он не тратил токены на «прочитать и понять» каждый раз.
• Языковой барьер не проблема: спикер не говорит по-шведски, но Claude умеет — это разделение труда между человеком-инженером и моделью.
• Human-filled formы означают грязные данные: галочки, обводки, каракули — Claude нужно явно предупредить о вариативности маркировки.
• Реализм «300 примеров для серых случаев» — намёк на то, что серьёзные production-промпты ближе к набору данных, чем к одному тексту.
• Conversation history можно подмешивать в system prompt для обогащения контекста — даже если приложение не диалоговое.
• Reminder в конце промпта борется с «забыванием» инструкций при длинном контексте — особенно когда между задачей и ответом много данных.
• Инструкция «опиши каждый чекбокс» сработала слишком буквально — Claude стал перечислять все 17, хотя нужен был только итог. Слишком детальные инструкции дают over-compliance.
• Пошаговое мышление (form → sketch → verdict) явно прописывается в промпте, а не оставляется на усмотрение модели.
• XML-обёртка <final_verdict> позволяет одной regex-строкой выдернуть нужное из любого многословного reasoning.
• Prefill <final_verdict> гарантирует, что Claude не начнёт с преамбулы «Конечно, вот мой анализ…».
• Extended thinking transcript — это инструмент дебага промптов, а не только улучшения качества: видно, где модель спотыкается.
• Кейс намеренно «причёсан» — реальный клиентский кейс упрощён для демо, но архитектурные приёмы переносятся как есть.
• Документация на сайте Anthropic содержит больше примеров — спикер призывает фотографировать слайды или идти на сайт, что выдаёт ориентацию на разработчиков-практиков.
• Промпт V2 показал важный паттерн: Claude правильно отказался выносить вердикт из-за недостатка данных — это успех, а не провал.
• В V3 контекст про форму перенесли из user-промпта в system prompt — это и про caching, и про семантическое разделение «что неизменно» vs «что меняется по запросу».
• Промпт V4 не только улучшил качество, но и сократил вывод — структура заставила Claude быть лаконичнее.
• Сессия завершается анонсом демо Claude, играющего в Pokémon — Anthropic сознательно микширует enterprise-кейсы с публичной narrative-демонстрацией возможностей.

Инсайты

• Качество промпта = качество предметной модели, которую инженер вложил в текст. Промпт V4 хорош не потому, что «лучше написан», а потому что в нём закодирована человеческая логика работы страхового оценщика.
• System prompt — это код, user prompt — это данные. Это разделение даёт и архитектурную ясность, и экономические выгоды через caching.
• LLM-приложение — это система с обратной связью, где промпт эволюционирует по мере обнаружения failure modes на реальных данных; разработка промпта похожа на регрессионное тестирование.
• Уверенный отказ модели — это feature, а не bug. Хороший промпт оптимизируется не только на правильные ответы, но и на корректные «не знаю» — иначе production-система начнёт молча галлюцинировать.
• Порядок информации в контексте влияет на reasoning не меньше, чем содержание. Дать схему до формы — получить хаос; дать форму до схемы — получить интерпретацию.
• XML-теги — это контракт между моделью и downstream-кодом. Они превращают свободный текст в парсимый артефакт без необходимости function calling.
• Few-shot examples — самый плотный способ передачи tacit knowledge. То, что нельзя объяснить инструкцией, передаётся через 5-10 размеченных кейсов.
• Extended thinking меняет роль инженера с автора промптов на их аудитора: вы смотрите, как модель думает, и точечно патчите system prompt.
• Hallucination — это следствие неопределённости задачи, а не свойство модели. Чем плотнее контекст и чётче критерии уверенности, тем меньше додумываний.
• Prompt caching сдвигает экономику LLM-приложений: стабильные большие system prompts становятся дешевле, чем динамическая сборка коротких промптов.

Фреймворки

10 компонентов хорошо структурированного промпта (порядок важен):

1. Task context — роль и цель Claude
2. Tone context — характер ответов (фактологичность, уверенность)
3. Background data / documents / images — статичный контекст (в system prompt)
4. Detailed task description & rules — пошаговые правила
5. Examples — few-shot, в XML-обёртке
6. Conversation history — если применимо
7. Immediate task description — динамический запрос
8. Step-by-step thinking — явная последовательность рассуждений
9. Output formatting — XML/JSON-структура
10. Prefilled response — assistant prefill для форсирования формата

Итеративный цикл разработки промпта:

• V1: минимальный промпт → диагностика failure mode
• V2: добавить task + tone context → проверить
• V3: вынести стабильные данные в system prompt + XML-структура
• V4: пошаговые инструкции + reminder + output formatting

Цитаты

«プロンプトエンジニアリングを学ぶ最良の方法は、実際にやってみることです» — 0:52 Лучший способ изучить prompt engineering — это практика.

«プロンプトエンジニアリングが多くの点で非常に反復的な経験科学であることがわかります» — 3:22 Prompt engineering — во многом итеративная эмпирическая наука.

«クロードは構造化つまり整理整頓が大好きです» — 9:46 Claude любит структуру — а именно, порядок.

«クロードが見ているものを理解できない場合推測して誤解を招くようなことは避けたいのです» Если Claude не понимает, что видит, мы не хотим, чтобы он угадывал и вводил в заблуждение.

«この情報を分析する順序が非常に重要であるということです» — 17:26 Порядок анализа этой информации крайне важен.

«幻覚を防ぐためです» — 16:06 Это нужно, чтобы предотвратить галлюцинации.

«常にアプリケーションの限界を押し広げフィードバックループを構築し» — 14:12 Постоянно раздвигай границы приложения и строй feedback loop.

«例、つまりいくつかのショットは、ステアリングクラウドにおいて非常に強力なメカニズムだと思います» — 13:11 Примеры, то есть few-shot, — крайне мощный механизм управления Claude.

«XMLタグはタグ内に何を書くかを指定できるという点で便利です» — 10:18 XML-теги удобны тем, что внутри тега можно указать, что именно ты пишешь.

«トークン効率が向上するだけでなく» — 24:04 Это не только повышает токен-эффективность.

«クロードが期待通りの手順で推論を進められるように» — 23:09 Чтобы Claude вёл рассуждение по ожидаемой нами процедуре.

«事実に基づく主張をする際には、フォームで見た内容を参照するように指示することもできます» — 16:45 При фактологических утверждениях можно требовать ссылки на конкретное содержимое формы.

Факты

• Кейс основан на реальном клиенте Anthropic — шведская страховая компания, обрабатывающая автостраховые претензии.
• Форма ДТП содержит 17 чекбоксов и 2 столбца (Vehicle A / Vehicle B).
• Демо проводится в Anthropic Console (новой) на новейшей модели Claude.
• Настройки демо: temperature = 0, максимальный бюджет токенов.
• Спикеры — Кристиан (Chris-chan) и Ханна (Hannah), оба сотрудники Anthropic.
• Промпт прошёл через 4 версии: V1 (минимальный) → V2 (task+tone) → V3 (system prompt с описанием формы) → V4 (step-by-step + output format).
• В V1 Claude интерпретировал форму как отчёт о лыжной аварии на улице Чаппанган в Швеции.
• Prompt caching упоминается как механизм оптимизации для статичной части system prompt.
• Claude 3.7 и Claude 4 — оба гибридные reasoning-модели с поддержкой extended thinking.
• В демо отмечены чекбоксы №1 (Vehicle A) и №12 (Vehicle B); в финальной версии Claude уверенно определяет виновным Vehicle B.
• Финальный вердикт оборачивается в XML-тег <final_verdict>.
• После сессии анонсировано отдельное демо: Claude играет в Pokémon и сессия про промпты для агентов.
• В сессии не было Q&A — спикеры приглашают подходить лично.

Источники

• Anthropic Console — интерфейс для разработки и тестирования промптов.
• Документация Anthropic — упоминается как источник детальных примеров prompt engineering.
• Claude 3.7 и Claude 4 — модели, упомянутые в контексте extended thinking.
• Демо Claude Plays Pokémon — упомянуто как следующая сессия конференции.

Итог

Хороший промпт — это не формулировка, а архитектура из 10 слоёв, наращиваемая итерациями вокруг наблюдаемых ошибок модели.