Transcription
К концу этого видео вы значительно улучшите свои навыки составления запросов для модели Claude Opus 4.5, поскольку я рассмотрю множество лучших практик, которыми команда Anthropic поделилась на своем веб-сайте, а также которыми многие их сотрудники поделились в Twitter. Я изложу многие идеи в гораздо более понятном формате с диаграммами, потому что изучение веб-сайта может быть довольно скучным. Но прежде чем начать, я должен сообщить, что прямо сейчас у меня проходит распродажа в Черную пятницу на мой мастер-класс по Claude Code. На этом курсе я подробно рассматриваю каждую функцию Claude Code, а также множество бонусного контента, о котором я раньше не говорил на канале, и который вы не найдете больше нигде на YouTube. У меня также сейчас проходит распродажа в Черную пятницу на мое собственное приложение HyperWhisper, ссылка на него будет ниже. В любом случае, многие идеи, которые мы обсудим, также применимы к Sonnet 4.5 и Haiku 4.5.
Прежде всего, при составлении запросов для модели вы хотите использовать менее агрессивный тон, потому что использование агрессивного тона, например, "вы должны всегда использовать инструмент веб-поиска" или что-то в этом роде, может вызвать у модели страх совершить ошибку, и она активирует инструменты, которые ей на самом деле не нужны, что может привести к более хаотичному результату и, в конечном итоге, к худшей общей производительности. Но если вы используете более директивный запрос, говоря что-то вроде "используй инструмент X, когда выполняется условие Y, иначе отвечай напрямую", то он будет работать намного лучше, потому что он просто может следовать предоставленным вами процедурам. И, конечно же, теперь, поскольку он не использует инструменты без необходимости из страха совершить ошибку, он будет давать вам лучшие и более точные результаты вместо этого. И я подумал, что эта метафора довольно хороша, потому что обращение с моделью как с бунтующим подростком, постоянно крича на нее и говоря: "Ты должен это сделать, должен то сделать", может вызвать у модели больше тревоги и, в конечном итоге, привести к худшей производительности по сравнению с тем, если бы вы обращались с ней как с компетентным сотрудником.
Более года назад некоторые исследования показали, что использование негативных запросов действительно приводило к лучшей производительности моделей, но, похоже, это время медленно подходит к концу, потому что это может привести к чрезмерному использованию инструментов определенным образом и просто к худшему результату в целом, особенно при написании кода. Таким образом, плохими запросами были бы такие, как "вы должны использовать инструмент поиска всякий раз, когда пользователь задает любой вопрос, всегда сначала ищите перед ответом, никогда не пропускайте поиск". Это привело бы к худшему результату и было бы менее эффективно, чем сказать что-то вроде "используйте инструмент поиска, когда вам нужна актуальная информация или факты, в которых вы не уверены".
И одна вещь, которую команда Anthropic сделала и которая будет связана ниже, — это плагин для миграции Claude Code. По сути, установив этот плагин, он изменяет многие системные запросы в вашей кодовой базе, делая их менее агрессивными, потому что они говорят, что агрессивный язык может привести к чрезмерной активации инструментов. И они приводят здесь некоторые примеры того, как можно использовать более мягкий язык.
Далее, вы хотите быть более ориентированным на действия при составлении запросов для модели. Так, ранее, если вы давали более ранней версии модели Claude расплывчатый запрос, например, "можешь ли ты предложить улучшения кода?", то она, вместо того чтобы предлагать улучшения, часто выполняла реализацию для вас. И если вы по-прежнему используете тот же запрос, надеясь, что она выполнит реализацию для вас, она больше не будет этого делать. И она просто даст вам предложения, что именно то, чего хотят некоторые люди, потому что теперь она более точно следует инструкциям. Поэтому, если вы надеялись, что она фактически выполнит улучшения для вас, а не просто предложит их, то вы хотите быть более явным и фактически сказать: "Можешь ли ты переписать этот код и реализовать изменения напрямую?". Ранее фраза "предложить" фактически приводила к выполнению предоставленной вами реализации, но теперь она не будет выполнять реализацию, а просто даст вам предложения.
Еще одна важная идея заключается в том, что Opus 4.5 теперь имеет тенденцию к некоторому чрезмерному проектированию. Например, если вы дали ему открытый запрос, который вы могли бы сделать, сказав что-то вроде "перепиши логику аутентификации", то Claude Opus 4.5, будучи очень eager, чтобы произвести впечатление, может подумать: "Хорошо, я придумаю новый интерфейс, новые вспомогательные классы, новый конфигурационный файл и больше абстракций или что-то в этом роде". И тогда он внесет гораздо больше изменений, чем вы фактически ожидали. А на самом деле вы могли бы хотеть изменить только один или два файла. Поэтому вместо этого вы должны быть более точными и ограниченными в своих запросах. Поэтому вы должны сказать что-то вроде: "Перепиши логику аутентификации, модифицируй на месте, без новых файлов, сохраняй минимализм". И модель ответит: "Хорошо, понято. Мы изменим только существующие файлы". Это довольно важно, если вы раньше не имели привычки ограничивать свои запросы. Вы также можете добавить аналогичную логику в свой файл claude.md для Claude Code, чтобы вам не всегда приходилось это писать.
Еще один важный момент заключается в том, что Opus 4.5 теперь может быть консервативным при исследовании вашего кода. Поэтому вы хотите поощрять исследование, где это возможно. Например, если вы сейчас скажете: "исправь ошибку в модуле пользователя", то вместо того, чтобы смотреть на окружающий контекст и видеть, как файлы связаны с модулем пользователя, он просто придумает какую-то идею о том, как работает остальная часть кодовой базы, основываясь на своих обучающих данных. И это может привести к сломанному исправлению в целом, потому что ему не хватает важного контекста. Он просто угадывает, какие вещи будут включены в другие файлы, и это может привести к большим ошибкам. Но теперь, если вместо этого вы скажете: "прочитай весь модуль пользователя и его зависимости, пойми поток данных, затем предложи исправление", то он фактически начнет исследовать кодовую базу больше, построит ментальную модель того, как все работает и связано друг с другом. И тогда любое исправление, которое он предложит, будет более точным и основанным на всех оставшихся и окружающих файлах.
Конечно, если вы используете режим плана в Claude Code, это активирует под-агентов, которые будут исследовать кодовую базу для вас. Поэтому вам, возможно, не придется так сильно беспокоиться об этом, но если вы не используете режим плана, то вам следует либо активировать под-агента исследования, либо заставить Claude Code самостоятельно провести исследование. И помните, что вы можете вручную активировать под-агента исследования, набрав @, затем explore, а затем просто введя свой запрос.
Теперь, если вы также хотите получать более богатые результаты от моделей, вы должны давать более богатые запросы. Поэтому, если вы просто скажете: "создай мне страницу входа в React", то она даст вам очень простой, базовый результат, очень краткий, без большого количества информации. Но если вы скажете что-то вроде: "создай страницу входа в React, включи полные анимации, валидацию форм, сообщения об ошибках, функции доступности, отполированный визуальный дизайн, выйди за рамки основ", то она даст вам значительно лучший результат, что означает, что Opus 4.5 будет предоставлять комплексные, богатые функциями решения, когда это явно требуется. В конечном итоге он будет более кратким и даст вам более минималистичные результаты, если ваш запрос будет довольно минималистичным и кратким.
Я рассматриваю это в предыдущем видео, где я учу вас использовать совершенно новый навык Claude по дизайну фронтенда для создания лучших дизайнов с помощью Claude Code, но, по сути, то, что происходит сейчас с моделями, заключается в том, что когда вы даете им очень простые минималистичные запросы, вы сталкиваетесь с так называемой "распределительной конвергенцией". Таким образом, у модели есть много обучающих данных, распределенных таким образом. У вас есть уникальные шрифты, жирные цвета, сложные анимации и все такое. И вся эта уникальность как бы смывается, смешивается и перемешивается. И, по сути, вы получаете этот высоковероятностный центр вместо этого. Таким образом, любые шаблоны, которые безопасны, распространены, хорошо используются, популярные шрифты и так далее, все сходятся вместе в минималистичный шрифт Inter с фиолетовым градиентом, потому что такие дизайны универсально приемлемы, но также и очень общие. И это может быть полезно, когда вы пишете код с помощью самого Claude Code, потому что, если вы попросите Claude Code реализовать систему аутентификации для вас, то вы не хотите, чтобы он придумал совершенно новую, странную, уникальную систему аутентификации, потому что это может привести к рискам безопасности. И вы хотите, чтобы Claude Code написал систему аутентификации, которая действительно работает и универсально используется. Но, конечно, теперь, если вы используете ту же логику, которую Claude Code использует для создания безопасной системы аутентификации, которая универсально работает, это может привести к худшей производительности, когда дело доходит до дизайна.
Таким образом, по сути, то, что вы хотите сделать, это предложить Claude Code явные указания, такие как "избегай шрифтов Inter, используй уникальные шрифты, добавляй сложные анимации, создавай смелую цветовую схему", и тогда он избежит многих идей в центре, а затем объединит связанные идеи на краях и в окрестностях имеющихся у него обучающих данных. И это также может привести к лучшему результату в целом, потому что он направлен на выборку из творческих и специфических областей для создания лучших дизайнов, чем выборка из центра облака обучающих данных, которое у него есть. Конечно, это несколько упрощение, но я думаю, что диаграммы помогают вам понять эту идею. Но да, я думаю, хороший способ думать об этом — это то, что когда дело доходит до дизайна, модель будет прилагать больше усилий к своему результату, если вы приложите больше усилий к своему вводу.
Далее, если вы предоставляете модели правила, то если вы предоставляете очень базовое правило, "никогда не используйте сокращения", то модель будет думать: "Черт возьми, почему это правило такое произвольное? Я просто буду следовать ему слепо? Какова здесь мотивация?". Тогда она будет следовать правилу очень слепо и вместо "vs." будет писать "versus", а вместо "etc." для "et cetera" будет использовать полную версию, и это в конечном итоге может привести к очень неловкому результату, которого вы не намеревались получить. Но если вы даете правило, то вы должны дать некоторую мотивацию, почему это правило существует. Поэтому, если вы скажете "никогда не используйте сокращения", добавьте контекст, такой как "для официальных юридических документов, чтобы избежать двусмысленности". И тогда модель ответит: "Да, я понял. Я понимаю, что цель — ясность и формальность. Я буду применять этот принцип широко". И тогда модель поймет "почему" за правилом и обобщит принцип, который вы хотите донести. Для создания более качественных результатов.
Теперь вы, вероятно, думаете, что это означает практически при написании кода. Так, у вас может быть правило, которое гласит: "всегда используйте блоки try-catch вокруг вызовов API". Но после, если вы расширите правило, "всегда используйте блоки try-catch вокруг вызовов API, наша система мониторинга полагается на перехваченные исключения для срабатывания оповещений, а необработанные отклонения вызывают тихие сбои в производстве, которые трудно отладить". Или раньше у вас было бы правило, гласящее: "добавляйте комментарии, объясняющие сложную логику". После этого у вас было бы правило: "добавляйте комментарии, объясняющие сложную логику, особенно бизнес-правила. Наша область обработки страховых случаев имеет неочевидные требования, которые не видны из самого кода, и будущие разработчики не будут иметь доступа к первоначальным заинтересованным сторонам".
И это означает, что когда вы в целом пишете подобным образом, правила обобщаются интеллектуально, что означает, что модели Claude понимают принцип, лежащий в основе правила, а не только само правило. И это позволяет им принимать решения о компромиссах. Например, если у вас есть два правила, которые конфликтуют, и вы не осознавали, что они конфликтуют, то она знает, какая проблема важнее для данного конкретного случая. И тогда она не будет тратить время на замешательство, не зная, какое правило на самом деле применить здесь. Если ваш файл claude.md заполняется или у вас есть много разных вещей в проекте, то некоторые правила могут начать конфликтовать, поэтому важно иметь мотивацию за правилом, написанную вместе с самим правилом. Это также позволяет модели помечать крайние случаи. Поэтому, если есть ситуация, где может быть исключение, потому что какая-то библиотека этого требует или что-то в этом роде, то она сможет пометить это вам. И также она сможет применять дух правила, что означает, что Opus 4.5 сможет обрабатывать новые ситуации, где правило может не применяться точно, но она придумает другую хорошую идею, потому что знает мотивацию за ним. Таким образом, по сути, если вы пишете правило, вы должны указать формулировку правила, бизнес- и техническую причину правила, а затем любые последствия, которые могут возникнуть при его нарушении, или какую другую выгоду приносит его соблюдение.
Далее речь идет о многословности. По умолчанию модели Claude 4.5 стремятся к эффективности и могут пропускать вербальные сводки после двух вызовов и просто переходить к следующему действию. И это может создать более оптимизированный рабочий процесс, но вы можете предпочесть большую прозрачность в отношении того, что на самом деле происходит за кулисами. Например, если вы оставите его на стандартной многословности и скажете Claude Code, поскольку вы используете его для чего-то, не связанного с кодированием, потому что это хороший агент в целом, вы скажете что-то вроде "исследуй конкурентные цены и обнови электронную таблицу". Тогда Claude Code будет максимально эффективным и предоставит вам окончательный результат. И вы будете думать: "Почему я получил такой результат? Почему он такой?". По сути, процесс модели был скрыт после каждого вызова инструмента и каждой информации, которую она получила онлайн. И тогда вы, вероятно, будете больше сбиты с толку тем, почему она дала вам такой результат, потому что вы не можете прочитать никакого обоснования того, что произошло. Но если вы скажете что-то вроде: "исследуй конкурентные цены и обнови электронную таблицу. После каждого основного шага предоставляй краткое резюме того, что ты нашел и что ты сделал". Тогда это будет примерно так: "Хорошо, во-первых, я найду конкурентов, вот их веб-сайты. Затем она найдет данные, извлечет это, и вот эти вариации. И тогда она расскажет вам, что именно она обновила. И когда вы будете просматривать историю, вы сможете прочитать все, что она сделала. И будет казаться, что весь процесс более прозрачен, и вы можете чувствовать себя более уверенно в решении или результате, который я дал, и вы также можете включить что-то вроде этого после завершения задачи, включающей использование инструмента: "предоставь краткое резюме проделанной работы".
Далее речь идет об управлении форматированием ответов, которые дают модели Claude. Вы хотите избегать негативных запросов, когда речь идет о форматировании. Вы могли бы сказать что-то вроде: "не используй маркированные списки или форматирование markdown", и это накладывает множество ограничений на модель. И тогда модель слишком сосредоточена на том, что нельзя делать, и это может привести к более неловким и неестественным результатам и ответам. Но если вы используете более позитивное формулирование и более директивны, говоря что-то вроде: "напиши свой ответ в виде плавных прозаических абзацев, используй полные предложения, которые естественно связывают идеи", то это даст вам значительно лучший результат, чем если вы говорите модели, чего не следует делать. И это может быть довольно важно, когда вы довольно часто используете модели Claude для написания.
Далее, модели Claude 4.5 отлично справляются с параллельным выполнением инструментов. И Sonnet 4.5 особенно агрессивен, когда дело доходит до параллельного запуска нескольких операций, что означает, что если вы используете его для исследований, например, то он может выполнять три или четыре веб-поиска параллельно, которые являются более спекулятивными, в то время как если бы вы заставили его выполнять их по одному, то следующий исследовательский запрос мог бы основываться на результатах предыдущих исследовательских запросов. Например, если вы заставите его прочитать набор конфигурационных файлов и обобщить различия, то часто он будет делать это все параллельно. И тогда это может привести к более хаотичному результату, чем если бы вы заставили его делать это по одному или пошагово.
Более практично это может выглядеть так: когда дело доходит до кодирования, если вы заставите его выполнять несколько команд установки параллельно, то может случиться так, что он установит две вещи, которые в некотором роде конфликтуют, и тогда он застрянет в цикле или в каком-то цикле. Но к счастью, это поведение довольно управляемо, потому что если вы включили этот запрос в свой файл claude.md, то он будет еще более параллелизован и будет делать больше вещей параллельно, когда это возможно. И если вы хотите уменьшить количество параллелизации, потому что вы заметили ухудшение качества результата, то вы можете использовать этот запрос вместо этого, чтобы обеспечить паузы и размышления между каждым шагом.
И еще одна проблема, которая может возникнуть с моделями Claude 4.5, заключается в том, что вы должны стараться избегать использования слова "думай", когда режим мышления отключен в Claude Code, например, особенно при использовании Opus 4.5, потому что он особенно чувствителен к этому слову. По сути, если вы используете слово "думай" с моделью Claude, а режим мышления у вас отключен, и вы говорите что-то вроде "думай шаг за шагом перед ответом", то это может привести к большому количеству шума и длинному ответу, потому что он на самом деле не способен думать. Поэтому, если вам нужно отключить режим мышления, вы должны сказать что-то вроде "тщательно рассмотри и оцени ограничения, затем дай окончательный ответ, без промежуточных рассуждений". Таким образом, слова, такие как "рассмотри", "поверь", "оцени", имеют схожее значение, и это может привести к лучшему качеству результата при отключенном режиме мышления, чем при использовании слова "думай".
Но да, это, по сути, то, как вы можете действительно хорошо составлять запросы для Opus 4.5 и других моделей Claude 4.5. Есть несколько примеров запросов, которые вы можете включить в свой файл claude.md на этой странице, но он очень длинный для чтения, но, возможно, будет полезен для некоторых людей. И помните, что прямо сейчас проходит распродажа в Черную пятницу на мой мастер-класс по Claude Code, а также на мое программное обеспечение HyperWhisper. Оба будут связаны ниже.