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

Шаблон запроса для Opus

Задача: [что нужно сделать].

Материал: [что я даю].

Контекст: [для кого и зачем это делается].

Цена ошибки: [что будет, если ошибиться].

Ограничения: [что нельзя делать].

Формат ответа: сначала анализ, потом риски, потом варианты решения, потом короткий вывод.

Важно: если данных недостаточно, не угадывай. Отметь, что нужно уточнить.

Как сделать дешевле

Даже когда нужен Opus, можно не сжигать лимиты. Не начинайте с огромного хаотичного запроса. Сначала подготовьте материал. Уберите лишнее. Разделите документы. Сформулируйте критерии. Попросите сначала анализ без переписывания. После анализа выберите, что именно нужно делать дальше.

Самая дорогая ошибка - попросить сильную модель сразу выполнить финальную работу по плохо подготовленному материалу. Тогда вы платите за большой контекст, переделки, уточнения и повторные проходы. Гораздо дешевле сначала получить карту проблемы.

Где нужен человек

Финальное юридическое, медицинское, финансовое, налоговое или кадровое решение.

Публичная позиция компании или автора.

Решение, которое влияет на людей, деньги, доступы, увольнения, безопасность или репутацию.

Код, который пойдёт в рабочую систему без тестов.

Текст, где важна авторская интонация и ответственность за смысл.

Opus помогает человеку думать. Он не должен становиться местом, куда человек складывает ответственность, чтобы больше её не видеть.

Короткий вывод

Opus нужен для сложных, дорогих и многоусловных задач: высокая цена ошибки, длинный материал, глубокая редактура, архитектура, стратегия, сложный код. Но даже Opus требует ясной постановки. Сильная модель раскрывается не там, где пользователь просит «сделай хорошо», а там, где он точно объясняет, что значит «хорошо» в этой задаче.

Глава 9. Когда достаточно Sonnet

У многих пользователей есть понятный соблазн: если есть самая сильная модель, надо работать только с ней. Заплатил за серьёзный инструмент - значит, пусть всегда думает на полную мощность. В жизни это похоже на привычку ездить за хлебом на тяжёлом грузовике. Да, он довезёт. Но вопрос не в том, довезёт ли. Вопрос в том, зачем так дорого.

Sonnet - это рабочая середина. В большинстве ежедневных задач именно она оказывается самым разумным выбором: достаточно сильная, достаточно быстрая, достаточно аккуратная и не такая тяжёлая, как старшая модель. Если Opus нужен там, где цена ошибки высока, Sonnet нужен там, где работа повторяется каждый день и должна идти спокойно, без лишнего расхода.

Профессиональный пользователь Claude не спрашивает: «Какая модель умнее?» Он спрашивает иначе: «Какой модели достаточно для этой задачи?» Это более взрослый вопрос. В нём уже есть экономика, понимание риска и уважение к собственным лимитам.

Sonnet как основная рабочая модель

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

Sonnet хорошо подходит для задач, где важна не максимальная интеллектуальная мощность, а стабильная рабочая отдача. Он не должен быть «младшим братом, которого включают от бедности». Его правильнее воспринимать как основной станок в мастерской. Не единственный, не самый тяжёлый, но тот, на котором делается большая часть нормальной работы.

Если пользователь всё делает через Opus, он не становится профессиональнее. Он просто быстрее тратит ресурс там, где можно было обойтись разумнее.

Где Sonnet обычно хватает

деловая переписка и аккуратные ответы клиентам;

структурирование заметок, встреч, созвонов и рабочих мыслей;

планы статей, книг, презентаций, инструкций и регламентов;

черновики коммерческих предложений и описаний услуг;

редактура среднего уровня: убрать повторы, сделать яснее, улучшить логику;

анализ несложных документов без финального юридического вывода;

разбор отзывов, обращений, жалоб и типовых вопросов;

подготовка обучающих материалов и памяток;

кодовые задачи среднего уровня, если проект не требует сложной архитектурной перестройки.

В этих сценариях важнее не «самая умная модель», а хорошо поставленная задача. Плохо сформулированный запрос к Opus может дать хуже результат, чем ясный запрос к Sonnet.

Плохой подход

Всегда включай самую сильную модель. Мне нужен максимум.

Сделай письмо клиенту. Используй самый глубокий режим.

Перепиши этот короткий текст через Opus, потому что так надёжнее.

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

Лучше так

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

Собери из этих заметок план инструкции для сотрудников. Не углубляйся в детали, сначала нужна структура.

Отредактируй текст на ясность: убери повторы, канцелярит и лишнюю саморекламу. Смысл не менять.

Такие задачи хорошо подходят для Sonnet, потому что модель получает не туманное «сделай лучше», а понятную работу. Экономия появляется не за счёт ухудшения результата, а за счёт правильного выбора инструмента.

Sonnet и тексты

Для автора, редактора, предпринимателя и специалиста Sonnet часто становится основной моделью для текстовой рутины. Он может разбирать структуру, предлагать план, переписывать сухие фрагменты, чистить повторы, объяснять сложное, собирать черновики и помогать держать единый тон.

Здесь важно не превращать модель в бездумного переписчика. Если дать команду «сделай красиво», она может сгладить живую фактуру, убрать острые углы, заменить точность общими словами. Если дать задачу точнее, результат будет рабочим.

Отредактируй текст как практическую книгу. Не делай его рекламным. Убери повторы и туман, но сохрани спокойный инженерный тон. Не добавляй обещаний, которых нет в исходнике.

Такой запрос даёт модели границы. Она не должна «улучшать вообще». Она должна улучшать в нужную сторону.

Sonnet и документы

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

Правильная роль Sonnet в таких задачах - помощник, который готовит материал к человеческой проверке. Он ускоряет чтение, но не заменяет профессиональный вывод.

Проанализируй документ предварительно. Не делай вывода, можно ли его подписывать. Выдели: 1) спорные формулировки, 2) неясные обязательства, 3) вопросы, которые нужно задать юристу, 4) места, где не хватает данных.

Sonnet и код

В коде Sonnet может быть хорошим рабочим помощником для небольших исправлений, объяснения функций, написания тестов, поиска очевидных ошибок, подготовки документации, рефакторинга отдельных участков. Но если задача касается архитектуры большого проекта, сложной миграции, безопасности, конкурентного доступа, производительности или критической инфраструктуры, лучше поднимать уровень модели и усиливать человеческую проверку.

Главная ошибка в коде та же, что и в тексте: просить слишком широко. «Почини проект» - плохая команда. «Найди, почему тест падает в этом модуле, предложи причину и минимальный патч» - рабочая команда.

Когда Sonnet уже не хватает

в задаче много взаимозависимых условий;

нужно принять архитектурное решение;

ошибка может привести к юридическим, финансовым или репутационным последствиям;

нужно глубоко сопоставить несколько длинных документов;

требуется не черновик, а сильный финальный разбор;

модель начала путаться, упрощать или терять важные ограничения;

нужно не просто написать, а выстроить стратегию.

В этих случаях Opus может быть оправдан. Но даже тогда сначала полезно подготовить материал через Sonnet: собрать исходные данные, убрать мусор, сделать карту задачи. Тогда тяжёлая модель будет тратить ресурс не на разбор хаоса, а на действительно сложную работу.

Как сделать дешевле

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

Такой подход похож на нормальную работу команды. Не главный инженер сортирует входящую почту, не юрист-партнёр форматирует шапку документа, не архитектор вручную чистит каждую мелкую опечатку. У каждого уровня работы свой инструмент.

Короткий вывод

Sonnet - не компромисс от бедности, а основная рабочая модель для большинства повседневных задач. Она хороша там, где нужна ясность, скорость, аккуратность и нормальная экономия. Opus стоит беречь для задач, где действительно нужна глубина, сложная логика и высокая цена ошибки.

Глава 10. Когда достаточно лёгкой модели

Лёгкие модели часто недооценивают. Пользователь видит в интерфейсе или документации старшие названия, слышит разговоры о «самых умных» версиях и решает, что всё остальное - почти игрушка. Это ошибка. В рабочем процессе лёгкая модель может быть не менее полезной, чем старшая, если поставить её на правильное место.

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

Профессиональная экономия начинается там, где человек перестаёт путать ценность задачи с престижем модели. Если работа простая, её не надо делать дорогим инструментом только потому, что он доступен.

Лёгкая модель как рабочий фильтр

Лёгкую модель удобно использовать как первый слой обработки. Она не обязана принимать сложные решения. Её задача - подготовить материал: разложить, очистить, сократить, привести к форме, на которой дальше может работать человек или более сильная модель.

Например, у вас есть сотня клиентских отзывов. Не обязательно сразу просить старшую модель строить стратегию улучшения продукта. Сначала можно попросить лёгкую модель выделить повторяющиеся темы, сгруппировать жалобы, убрать дубли и собрать первичный список проблем. После этого уже есть материал для серьёзного анализа.

Такой подход снижает расход и одновременно улучшает качество. Сильная модель получает не сырой поток, а подготовленную карту.

Где лёгкой модели достаточно

классификация обращений по темам;

сортировка списка задач по категориям;

первичное сокращение длинного текста;

создание черновых вариантов заголовков;

приведение однотипных описаний к единому формату;

поиск явных дублей и повторов;

разделение отзывов на положительные, отрицательные и нейтральные;

выделение ключевых слов из больших списков;

подготовка простых шаблонов без сложной логики;

черновая разметка материала перед глубокой обработкой.

Плохой подход

Проанализируй эти 300 отзывов, найди стратегию развития продукта, подготовь план изменений и оцени бизнес-риски.

Вот большой договор. Скажи, можно ли подписывать.

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

Для лёгкой модели такие задачи слишком широки или слишком ответственны. Она может сделать вид, что справилась, но результат легко окажется поверхностным. Нельзя путать «дала ответ» и «выполнила работу на нужном уровне».

Лучше так

Раздели эти отзывы на группы по повторяющимся темам. Не делай выводов о стратегии. Только сгруппируй и посчитай, какие темы встречаются чаще.

Сократи текст до 30% объёма, сохрани факты и порядок мысли. Не улучшай стиль, только убери повторы.

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

Здесь лёгкая модель не принимает решения за человека. Она выполняет простую операцию. Именно так её и нужно использовать.

Лёгкая модель и массовая обработка

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

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

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

Правило выборочной проверки

Лёгкая модель особенно хороша там, где её работу можно быстро проверить. Если вы классифицируете отзывы, достаточно посмотреть часть результата и понять, не путает ли она категории. Если сокращаете текст, можно сравнить исходник и итог. Если приводите данные к формату, можно проверить, не добавила ли модель лишнего.

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

Как не перегрузить лёгкую модель

давать одно действие за раз;

не просить стратегию и финальный вывод;

не смешивать анализ, редактуру, проверку фактов и оформление в одном запросе;

ограничивать формат ответа;

запрещать добавлять новые факты;

делить большой материал на партии;

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

Лёгкая модель как помощник для старшей

Хорошая схема работы часто строится в несколько слоёв. Лёгкая модель чистит и группирует материал. Sonnet делает нормальный рабочий разбор. Opus подключается, если нужен сложный вывод или высокая точность. Так экономятся лимиты и снижается шум.

Например, при подготовке большой книги лёгкая модель может найти повторы в списке тем, сгруппировать заметки, привести названия глав к одному виду. Sonnet может развернуть главы и сделать редакторскую правку. Opus можно использовать для анализа общей структуры, слабых мест и финальной концептуальной проверки.

Это не усложнение ради усложнения. Это нормальное разделение труда.

Ошибка, которая сжигает лимиты

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

В профессиональной работе важен не только результат, но и цена получения результата.

Короткий вывод

Лёгкая модель нужна для простых, массовых и хорошо проверяемых операций. Она не заменяет глубокий анализ, но помогает подготовить материал, снизить шум и сэкономить ресурсы. Чем лучше пользователь разделяет работу на уровни, тем меньше он платит за лишнюю мощность.

Глава 11. Что такое токены без технического тумана

Чтобы управлять Claude профессионально, не обязательно быть специалистом по машинному обучению. Но нужно понимать одну простую вещь: ИИ-система работает не с «сообщениями» в бытовом смысле. Она работает с текстом, разрезанным на небольшие части. Эти части называют токенами.

Токены - не мистическая техническая единица. Для пользователя это способ понять вес текста. Чем больше текста вы отправляете, чем длиннее история чата, чем больше файлов, инструкций и уточнений тянется за задачей, тем тяжелее запрос. А тяжёлый запрос расходует больше лимитов, денег и времени.

Если говорить совсем просто: токены - это условные кусочки текста, которые модель читает и создаёт. Входные токены - то, что вы даёте модели. Выходные токены - то, что она пишет в ответ. Для экономики Claude важны оба направления.

Почему нельзя думать только сообщениями

Обычный пользователь думает: «Я отправил всего одно сообщение». Но одно сообщение может быть короткой фразой, а может быть огромным техническим заданием, тремя приложенными документами, длинной историей переписки и просьбой сделать глубокий анализ. Формально это одно сообщение. По весу - совсем другая работа.

Представьте два запроса.

Сократи это письмо до трёх абзацев.

Проанализируй 80 страниц договора, сравни с предыдущей версией, найди риски, подготовь письмо партнёру и список вопросов юристу.

Оба запроса могут быть отправлены одним нажатием кнопки. Но для модели это разные нагрузки. Первый - лёгкая редакторская операция. Второй - большая работа с контекстом, анализом, структурой и выходным текстом.

Что входит в вес запроса

ваше новое сообщение;

предыдущая история диалога, если она сохраняется в контексте;

файлы и фрагменты документов, которые модель должна учитывать;

проектные инструкции и постоянные правила;

системные ограничения и настройки;

описания доступных инструментов;

ответ, который Claude должен создать.

Пользователь видит только окно чата. Модель видит рабочий пакет. Если в этом пакете много лишнего, она всё равно вынуждена тащить это с собой.

Длинная история как скрытый расход

Самая неприятная часть токеновой экономики - старая история. Пользователь может думать, что работает только с последним сообщением. Но если чат длинный, модель должна учитывать предыдущий контекст. В этом контексте могут быть старые решения, отменённые варианты, случайные уточнения, куски текста, которые уже не нужны, и вопросы, давно потерявшие значение.

В результате вы платите не только за текущую задачу. Вы платите за весь хвост, который тянется за ней. Иногда этот хвост полезен. Иногда он превращается в мусор.

Поэтому профессиональный пользователь периодически закрывает старые ветки, просит Claude сделать сжатое резюме состояния и переносит работу в новый чат. Это не прихоть. Это способ не платить за историю, которая уже не работает.

Файлы тоже не бесплатны

Файл в чате не исчезает из экономики только потому, что он прикреплён, а не вставлен вручную. Если Claude должен учитывать документ, его содержание или релевантные части становятся частью работы. Большой документ, несколько версий, длинные приложения, сканы, расшифровки, рукописи, технические задания - всё это увеличивает нагрузку.

Ошибочный подход - прикладывать всё подряд «на всякий случай». Правильный подход - сначала определить, что именно нужно сделать с документом.

Плохо: Вот пять файлов, посмотри, что думаешь.

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

Чем точнее задача, тем меньше модель тратит сил на лишний поиск смысла.

Выходной текст тоже стоит

Пользователь часто думает только о том, сколько текста он отправляет. Но ответ модели тоже расходует ресурс. Если вы просите «подробно, максимально развёрнуто, с примерами, чек-листами, альтернативами и десятью вариантами», выход будет длинным. Иногда это нужно. Иногда это просто раздувание.

Профессиональная экономия - не в том, чтобы всегда просить коротко. Экономия в том, чтобы просить ровно тот объём, который нужен для следующего действия.

Сначала дай краткую карту проблемы на 10 пунктов. Не разворачивай каждый пункт. После этого я выберу, что раскрывать подробно.

Такой запрос помогает не тратить длинный ответ на направления, которые окажутся ненужными.

Токены и качество

Меньше токенов не всегда значит лучше. Если вы слишком сильно обрежете контекст, Claude начнёт угадывать. Если дадите слишком много мусора, он начнёт путаться и тратить ресурс на лишнее. Задача пользователя - не минимизировать текст любой ценой, а сделать контекст чистым.

Чистый контекст - это не короткий контекст. Это контекст, где есть всё нужное и нет лишнего.

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

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

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

Разница может быть огромной. И по качеству, и по расходу.

Проверочный список: не несёте ли вы лишний вес

В чате уже обсуждалось несколько разных задач?

Есть старые решения, которые больше не действуют?

Вы прикрепляете файлы «на всякий случай»?

В постоянных инструкциях есть временные требования?

Вы просите длинный ответ, хотя сначала нужна только карта?

Модель начала ссылаться на старые условия?

Вы сами уже не помните, что находится выше по чату?

Если хотя бы на несколько вопросов ответ «да», пора чистить контекст или переносить работу.

Короткий вывод

Токены - это вес работы Claude. Расходуется не только последнее сообщение, но и история, файлы, инструкции, инструменты и ответ модели. Экономить нужно не через обрезание смысла, а через чистый контекст, ясную задачу и правильный объём ответа.

Глава 12. Почему лимит - это не число сообщений

Один из самых частых источников раздражения у пользователей Claude - лимиты. Человек думает: «Я написал не так уж много, почему всё так быстро закончилось?» На уровне интерфейса может казаться, что лимит связан с количеством сообщений. Но профессионально так думать нельзя.

Лимит - это не просто счётчик фраз. Это отражение веса работы, которую вы поручаете системе. Два пользователя могут отправить одинаковое количество сообщений и потратить совершенно разный объём ресурса. Один задаёт короткие вопросы в чистых чатах. Другой работает с длинной историей, файлами, тяжёлой моделью, инструментами и сложными инструкциями.

Внешне оба «поговорили с Claude». По факту один прошёлся налегке, другой протащил через модель целый архив.

Что реально влияет на лимиты

длина текущего сообщения;

длина всей истории чата, которую нужно учитывать;

количество и объём файлов;

сложность задачи;

выбранная модель;

длина ответа;

постоянные инструкции проекта;

использование инструментов, кода, поиска, связок и дополнительных функций;

частота повторных переделок из-за плохо поставленной задачи.

Поэтому вопрос «сколько сообщений осталось?» сам по себе обманчив. Правильнее спрашивать: «насколько тяжёлую работу я сейчас поручаю?»

Почему длинный чат дороже короткого

Каждое новое сообщение в длинном чате существует не в пустоте. Оно опирается на историю. Иногда это полезно: Claude помнит стиль, решения, ограничения, материал. Но чем длиннее ветка, тем больше в ней случайного: старые версии, споры, отменённые идеи, фрагменты, которые больше не нужны, и повторы.

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