Чек-лист

Как применять Claude Opus 5.5 в сложных задачах

Практическая инструкция по выбору режима Claude Opus 5.5 для программирования, работы с визуальными схемами и финансового анализа. Внутри — готовые промпты, способы проверки результата и ограничения, которые нужно учитывать перед использованием модели в работе.

Содержание7 глав
  1. 011. Выбрать задачу и режим
  2. 022. Подготовить задачу до запуска
  3. 033. Превратить нарисованную схему в симулятор
  4. 044. Проверить сложную программную задачу
  5. 055. Провести финансовый анализ по документам
  6. 066. Провести финальную проверку результата
  7. 07Ориентиры для оценки

1. Выбрать задачу и режим

  • Открыть официальный анонс Claude Opus 5.5 и проверить, что модель доступна в используемом интерфейсе Claude.

  • Начать обычную аналитическую или документную задачу в режиме Medium.

  • Medium сопоставляется с максимальным режимом Opus 5 при меньших затратах.

  • При подписке за 20 долларов проверить наличие Opus 5.5 в списке моделей: на дату релиза модель была доступна и на этом тарифе.

  • Переключиться на X-High, Max или Ultra, если задача требует длительного программирования, сложной визуальной интерпретации или нескольких независимых проверок.

  • Max расходует примерно в 4 раза больше рассуждений, чем Medium.

  • Max и X-High показали лучшие результаты среди режимов в приведённом сравнении.

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

  • Не выбирать максимальный режим автоматически: сначала проверить Medium на реальной задаче, затем повышать режим только при недостаточном качестве.

2. Подготовить задачу до запуска

  • Приложить все исходные данные одним сообщением: изображение или схему, выгрузку, примечания и описание требуемого результата.

  • Указать конечный формат: один HTML-файл, интерактивный симулятор, аналитический отчёт или решение для совета директоров.

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

  • Для задачи по изображению сначала поручить модели извлечь структуру схемы, а только затем строить результат.

  • Для большой программной задачи поручить отдельные проверки параллельным субагентам:

  • логика и игровой процесс;

  • ошибки;

  • графика и скорость;

  • изображения;

  • звук;

  • соответствие заданию.

  • Не считать высокий результат бенчмарка гарантией: проверить модель на собственной задаче и по собственным критериям.

3. Превратить нарисованную схему в симулятор

  • Нарисовать схему так, чтобы на ней однозначно читались блоки, стрелки, конверсии и итоговый показатель.
  • Сфотографировать схему целиком без обрезанных подписей и приложить изображение к сообщению.
  • Вставить промпт и при необходимости заменить описание результата и оформления.
Промпт: симулятор воронки из фотографии10 строк · 360 знаков
На фото воронка продаж, нарисованная от руки. Сделай из неё живой симулятор в одном HTML-файле.

Требования:
- блоки стоят так же, как на листе;
- по стрелкам непрерывно движутся частицы;
- наверху показан итог;
- оформление на тёмном фоне;
- схема читается с экрана телефона;
- значения конверсий можно менять;
- итог пересчитывается после изменения значений.
  • Сверить выписанную моделью структуру с фотографией до генерации кода.
  • Проверить, что изменение конверсий пересчитывает количество людей на каждом этапе и конечный результат.
  • Сравнить фотографию и симулятор рядом: расположение блоков, направления стрелок, подписи и числа должны совпадать.
  • Отдельно оценить дизайн. В контрольном запуске логика симулятора работала хорошо, но оформление потребовало доработки.
  • Проверить результат на телефоне и убедиться, что схема читается без горизонтальной прокрутки.

4. Проверить сложную программную задачу

  • Сформулировать задачу одним сообщением и включить в него функциональность, визуальные требования, ограничения и критерии проверки.

  • Попросить модель самой составить план проверок и назначить независимые проверки субагентам.

  • Проверить не только наличие функций, но и поведение системы после действий пользователя.

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

  • Смена дня и ночи, закат, гроза, северное сияние, звук и 3D входили в готовую систему.

  • Проверить производительность готового результата. Контрольный ориентир для игры — 60 кадров в секунду.

  • Проверить отчёт модели о проделанной работе: в примере файл содержал 2 900 строк, а модель выполнила 51 проверку.

  • Не использовать длительность игрового запуска как обещание или норматив: для одного кейса указаны два значения — 27 минут и 40 минут.

5. Провести финансовый анализ по документам

  • Приложить тизер продавца, помесячную выгрузку и примечания бухгалтерии.
  • Использовать режим Medium как стартовый для анализа документов.
  • Вставить промпт, заменив название объекта сделки при необходимости.
Промпт: аналитик на стороне покупателя7 строк · 517 знаков
Выступи как аналитик на стороне покупателя. Нужно решить, покупать ли онлайн-школу английского «Плюс».

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

Проверь каждую цифру и каждую цитату по исходным данным и доступным источникам. Не выдумывай значения. Если данных для вывода недостаточно, прямо укажи, чего не хватает.

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

  • Найти источник для каждой внешней цифры и цитаты. Одна выдуманная цифра делает финансовый отчёт непригодным.

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

  • Контрольный финансовый кейс: решение не покупать; предельная цена — 45 млн рублей; срок окупаемости при этой цене — 36 месяцев даже в осторожном сценарии.

  • Повысить режим рассуждения и повторить анализ, если Medium пропустил несоответствие или не смог обосновать решение.

6. Провести финальную проверку результата

  • Сверить готовый результат с исходными файлами построчно или блок за блоком.
  • Проверить все числа, цитаты, подписи, стрелки и зависимости между показателями.
  • Не принимать короткий ответ за неполный автоматически: Opus 5.5 сокращает водянистые отчёты. Проверять полноту по критериям задачи, а не по объёму текста.
  • Отделить качество логики от качества оформления: корректный расчёт не означает, что дизайн готов к использованию.
  • Для планов помещений и других пространственных схем проверить каждое окно, стену и направление вручную. Известное ограничение: модель ошибочно размещала окна, несмотря на понятный план, и потребовала нескольких часов уточнений.
  • Зафиксировать собственные показатели теста: режим, время, число исправлений, расход лимита и ошибки. Сравнивать модели по одинаковой задаче и одинаковым критериям.
  • Сверить общую оценку модели с независимым разбором Artificial Analysis, но решение о рабочем использовании принимать по собственному тесту.

Ориентиры для оценки

  • Учитывать заявленные изменения относительно Opus 5: примерно на 40% ниже расход в реальной работе и более чем на 30% выше скорость ответа.
  • Учитывать контрольный результат чтения графиков: 64% у Opus 5.5 против 29% у предыдущего Opus.
  • Учитывать проверку отчётов: 16 из 18 отчётов Opus 5.5 прошли порог без выдуманных цифр и цитат; Fable 5.1 и Opus 5 не прошли его ни разу.
  • При сравнении длинных задач учитывать контрольный результат задачи индекса: Opus 5.5 вывел 119 тысяч токенов, а GPT-6 Astra — 27 тысяч.
  • Не переносить эти показатели напрямую на собственную задачу без проверки на своих данных.