Урок 1. Повторение: приёмы, которые действительно работают

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

Поэтому первый урок — короткая ревизия. Шесть приёмов, на которые мы будем опираться дальше. Если какой-то из них вы «знаете, но не применяете» — это как раз тот, который стоит вернуть в работу.

Приём 0. Генератор промптов

Самый быстрый способ не залипнуть на пустом листе — Console → «Generate a prompt». Вы описываете задачу словами, Claude собирает черновик промпта, уже устроенный по хорошим практикам: отдельно инструкция, отдельно данные в тегах, место для рассуждений.

Например, из запроса «определить, фейковая ли новость» генератор делает примерно такое:

Твоя задача — определить, является ли новостная статья фейком.

Вот текст статьи:
<article>
{{ARTICLE_TEXT}}
</article>

Внимательно прочитай статью и обрати внимание на признаки:
- сенсационный или эмоционально заряженный язык
- отсутствие проверяемых источников
- фактические ошибки в базовых сведениях

Опиши ход рассуждений в секции <reasoning>.
Итоговый вывод — ФЕЙК или НАСТОЯЩАЯ — в секции <answer>.

Здесь сразу три приёма: чёткая формулировка задачи, XML-теги для разделения данных и инструкций, заданная структура ответа.

1. Ясно и прямо

Самый важный приём — и самый скучный. Пишите инструкции, в которых нечего додумывать: формат, длина, стиль, что делать с краевыми случаями. Claude не знает вашего контекста, если вы его не дали.

Плохо — менеджер продукта хочет разобрать отзывы пользователей:

Claude выдаст какое-то резюме. Скорее всего адекватное — и совершенно не то, с чем можно прийти на планирование спринта.

Хорошо — тот же запрос с требованиями:

Проанализируй отзывы о последнем релизе:
<feedback>{{CUSTOMER_FEEDBACK}}</feedback>

Сделай отчёт из разделов:
1. Резюме (50–100 слов): общее настроение и главные темы.
2. Фичи: топ-3 хвалимых и топ-3 ругаемых (списком).
3. Проблемы UX: топ-3 проблемы, к каждой — вариант решения в скобках.
4. Тональность: положительных X%, нейтральных Y%, отрицательных Z%.
5. Выводы к действию: 3–5 пунктов.

Оберни разделы тегами для парсинга:
<summary></summary>, <features></features>,
<ux></ux>, <sentiment></sentiment>, <insights></insights>

Разница не в вежливости формулировок, а в том, что здесь заданы: природа входных данных, формат вывода, лимиты по объёму и структура ответа. Генератор промптов такое сам не придумает — требования всё равно формулируете вы.

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

2. Структура через XML

Сложный промпт — это всегда смесь: инструкции, ваши данные, примеры, требования к формату. Если всё это лежит одним куском текста, модели приходится угадывать, где кончаются данные и начинается задание. Иногда угадывает неверно.

XML-теги решают проблему дёшево: <defect_report>…</defect_report> — и границы очевидны. Никакой магии в самом XML нет, подойдёт любая последовательная разметка. Просто теги короткие, самоописательные и Claude их хорошо понимает.

Плохо — менеджер по качеству смешал всё в кучу:

Хорошо — то же самое, но разложено по полкам:

Проанализируй проблемы качества часов SmartTime 3000.

<defect_report>
- Производственный брак: 30% партии
- Батарея: 12 часов (заявлено 48)
- Данные здоровья: погрешность 25%
- ПО: массовые падения приложения
</defect_report>

<inventory>
- На складе: 50 000 штук
- В пути: 100 000 штук
</inventory>

<financials>
- Розничная цена: 299
- Себестоимость: 120
</financials>

Сделай отчёт:
1. <defect_analysis> тяжесть каждого дефекта и влияние на бренд </defect_analysis>
2. <financial_impact> потери от возвратов, гарантии, упущенных продаж </financial_impact>
3. <action_plan> приоритезированные действия со сроками и оценкой стоимости </action_plan>

Заодно теги в ответе дают побочный бонус: результат легко распарсить и положить в отчёт или в следующий шаг пайплайна.

3. Примеры

Иногда проще показать, чем описать. Два-три примера желаемого вывода заменяют абзац объяснений про тон и структуру — и работают надёжнее.

Пример без примеров (простите за каламбур): «Напиши анонс нашей новой CRM на ИИ, AcmeAI: ключевые фичи, выгоды, призыв к действию, профессионально и живо». Claude напишет приличное письмо. Но не ваше: не тот тон, не та структура, нет привычных блоков.

С примерами промпт выглядит так (второй пример сокращён):

Напиши анонс продукта в стиле и структуре этих примеров:

<examples>
<example>
Тема: Представляем AcmeDataPulse: аналитика в реальном времени

Уважаемый партнёр,

Мы запускаем AcmeDataPulse — платформу аналитики в реальном времени.

[Ключевые возможности]
- Потоковая обработка: решения на 80% быстрее
- ИИ-инсайты: собственные алгоритмы находят скрытые закономерности
- Масштабируемость: от гигабайтов до петабайтов

[Выгоды]
- Быстрые решения: данные в действие за секунды
- Экономия: платите только за использованное
- Интеграция: REST API и готовые коннекторы

AcmeDataPulse доступен от 499/месяц. Запишитесь на демо.

С уважением,
Команда Acme
</example>

<example>
… второй пример в том же формате — сокращён …
</example>
</examples>

Теперь напиши анонс нашей новой CRM на ИИ — AcmeAI.

Три правила хороших примеров:

• Похожесть — примеры должны напоминать реальные входы и выходы, а не сферические примеры в вакууме.
• Разнообразие — включите краевые случаи, иначе модель обобщит слишком узко.
• Количество — ориентир 3–5 примеров. Жёсткого правила нет, но один пример уже лучше, чем ноль.

4. Дать Claude подумать

Chain of thought — это когда вы явно просите разложить задачу на шаги и проговорить рассуждение до ответа. Там, где цена ошибки высока, путь к выводу важен не меньше самого вывода: его можно проверить, оспорить, показать аудитору.

Два рабочих способа:

1. Написать «продумай шаг за шагом» — и обязательно добавить, как именно думать: какие факторы учесть, что сравнить.
2. Дать место под мысли: <thinking> для рассуждений, <answer> или <recommendation> для итога.

Вот как это выглядит на задаче про выход компании на новый рынок:

Мы рассматриваем выход на азиатский рынок. Нужен анализ для совета директоров.

<company_data>{{ACMEFLOW_DATA}}</company_data>
<market_research>{{ASIA_TECH_MARKET}}</market_research>

Продумай анализ до ответа: потенциал рынка, конкуренция,
регуляторные риски, финансовая модель.
Ход рассуждений помести в <thinking></thinking>,
итоговую рекомендацию — в <recommendation></recommendation>.

В ответе получаются две разделённые части: внутри <thinking> — пронумерованные шаги разбора (рынок → конкуренты → регуляторка → финансы), внутри <recommendation> — короткий вывод с опорой на эти шаги. Первую часть читает разработчик, когда чинит промпт. Вторую — забирает продукт.

5. Роль в системном промпте

Дать Claude роль — значит задать точку зрения, уровень экспертизы и тон. Роль можно написать и в пользовательском сообщении, но в продакшене её место — system: там она действует одинаково во всех запросах и не тонет в переменных данных.

Кризисная ситуация: в электромобиле нашли баг с самопроизвольным ускорением, нужно заявление для прессы. Плохой промпт: «У нас баг, машина сама разгоняется. Напиши заявление, дело серьёзное, сделай нормально». Что такое «нормально» — модель не знает.

С ролью и структурой:

Заметнее всего роль помогает на технических задачах (логика, математика, код) и там, где важны тон и стиль. Если вы не экономите каждый токен — причин отказываться от роли почти нет.

6. Длинный контекст

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

Два правила:

• Каждый документ — в собственный тег, все документы — во внешний контейнер: <reports> → <report_1>, <report_2>, <report_3>.
• Длинные документы ставьте в начало промпта, инструкции и примеры — после них. На больших объёмах (порядка 30 тысяч токенов и выше) это заметно улучшает результат.

<reports>
  <report_1>{{GLOBAL_TECH_TRENDS}}</report_1>
  <report_2>{{CRM_MARKET_ANALYSIS}}</report_2>
  <report_3>{{COMPETITOR_LANDSCAPE}}</report_3>
</reports>

Проанализируй отчёты перед запуском AcmeAI и сделай разбор:
1. Резюме (100–150 слов)
2. Возможности рынка: объём, рост, доля по регионам
3. Конкуренты: топ-3, их ИИ-возможности против наших, пробелы
4. План запуска по кварталам
5. Риски: SWOT по ИИ-специфике и меры смягчения

Каждый раздел оберни в теги <section></section>.

Упражнения

Откройте Workbench или claude.ai и попробуйте сами.

Упражнение 1.1 — Починить размытый промпт

Есть промпт: «Вот письма из поддержки за неделю. Что там происходит?» Перепишите его так, чтобы результат можно было без правок вставить в еженедельный отчёт: задайте структуру, объём и теги для парсинга.

<tickets>
{{SUPPORT_TICKETS}}
</tickets>

Разбери обращения в поддержку за неделю для еженедельного отчёта.

1. <summary> Резюме, 60–80 слов: главное настроение и тренд недели. </summary>
2. <top_issues> Топ-5 проблем: формулировка, число обращений, тяжесть. </top_issues>
3. <new_issues> Проблемы, которых не было на прошлой неделе. </new_issues>
4. <actions> 3 действия на следующую неделю с указанием команды. </actions>

Если данных для раздела не хватает — так и напиши, не додумывай.

Упражнение 1.2 — Роль плюс рассуждение

Соберите промпт для проверки договора аренды: роль в системном промпте, документ в тегах, рассуждение отдельно от вывода. Модель — на ваш выбор из claude-haiku-4-5, claude-sonnet-5, claude-opus-5; подумайте, какая тут уместна.

<contract>
{{LEASE_TEXT}}
</contract>

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

Ход разбора помести в <thinking></thinking>.
Итог — в <risks></risks>: список рисков, каждый с пометкой
высокий / средний / низкий и предлагаемой правкой формулировки.

Что запомнить

• Генератор промптов в Console — хорошая стартовая точка, но не финальный промпт.
• Ясность — это конкретика: формат, объём, структура, поведение в краевых случаях.
• XML-теги отделяют данные от инструкций и делают ответ парсабельным.
• Три-пять релевантных и разнообразных примеров объясняют формат лучше любого описания.
• Рассуждение в <thinking>, итог — в отдельном теге: одно для отладки, другое для продукта.
• Роль живёт в системном промпте — и только роль.
• Длинные документы ставим в начало промпта, инструкции — после.