Transcription
Облачные рабочие процессы появились около недели назад, и им уделяется недостаточно внимания. Думаю, причина в том, что они могут казаться немного абстрактными: "Эй, теперь ты можешь запустить что-то под названием рабочий процесс, и он сожжет миллионы токенов". Но есть и настоящие жемчужины, которые, осмелюсь сказать, меняют правила игры. Поэтому я собираюсь подробно рассказать, что такое рабочие процессы на самом деле, как они работают, и шесть шаблонов, которые вы можете использовать для их создания с реальными примерами. И если вам нужны какие-либо из тех, что я покажу, ссылка будет в описании ниже. И поэтому, отдавая должное, лучшее описание того, что это такое и как вы можете их использовать, исходит от самого Anthropic. Так что многие вещи, которые я собираюсь рассмотреть в этом видео, основаны на этой документации.
На самом абстрактном уровне Cloud Code сам по себе является каркасом агента, который в основном предназначен для кодирования, даже если есть другие варианты использования и типы задач. Но неизбежно существуют определенные типы задач, которые вы, возможно, захотите выполнять очень хорошо, и с которыми сам Cloud Code "из коробки" не очень хорошо справляется. Например, исследования, анализ безопасности, использование команд агентов, проведение обзоров кода — это те типы задач, для которых сам Cloud Code не очень хорошо подходит для выполнения в глубину. И поэтому рабочие процессы позволяют вам динамически создавать эти различные каркасы на лету, так что довольно простым способом вы можете создавать эти повторно используемые каркасы, которые могут решать довольно сложные проблемы гораздо более простым способом.
Так что некоторые плагины, например, Compound Engineering, пытались встроить эти типы рабочих процессов в свои файлы навыков и использовать субагентов, но теперь эти вещи поддерживаются напрямую в Cloud Code. Один пример, чтобы заземлить все, о чем мы собираемся говорить, — это новое глубокое исследование, которое было выпущено с Opus 4.8, и эти выпуски рабочих процессов являются примером динамического рабочего процесса. Так что конкретно делает эта штука: она может разветвляться и выполнять множество различных веб-поисков. Она может получить все источники. Затем она враждебно проверяет утверждения с помощью отдельных субагентов, а затем, наконец, синтезирует все это обратно для вас в отчете со ссылками. Так что это пример динамического рабочего процесса. И это то, что вы могли бы попытаться собрать в прошлом с помощью различных навыков и команд, пытаясь вручную вызывать их и связывать вместе. Но теперь это лучше, это более бесшовно, это поддерживается нативно, и вам легко создавать эти вещи с помощью естественного языка.
Итак, как они работают? Во-первых, вам нужен агент, который, очевидно, обеспечивает работу всего этого. Но затем есть две вещи, которые делают это отличным и составляют рабочий процесс. Во-первых, он может выполнять задачи параллельно. И в этом случае вы можете передать ему все эти различные вещи, которые ему нужно выполнить, и он может выполнять их все одновременно, а затем ждать, пока все они завершатся. Например, если бы вы собирались запустить отчет о глубоком исследовании, он бы вышел, выполнил все эти поисковые запросы и исследовал ваш кодовую базу и все такое одновременно, а затем ждал бы, пока все они вернутся. Вторая часть — это конвейер. И в случаях, когда задачи не должны ждать завершения всех, и их можно выполнять по порядку, мы запускаем конвейер. Теперь, когда мы работаем с рабочими процессами, ему не нужно иметь оба этих компонента. Любой из них может использоваться индивидуально или, в зависимости от рабочего процесса, они могут быть объединены.
Вот очень конкретно, как это может выглядеть на практике. Если бы вы, например, спросили: "Стоит ли нам мигрировать нашу службу оформления заказов к новому поставщику" в рамках статического традиционного каркаса Cloud Code? Это могло бы превратиться в пять различных веб-поисков. Он получает лучшие результаты из этих веб-поисков. Он проверяет то, что нашел, а затем обобщает это для вас и дает вам общий отчет об исследовании. И, например, у вас мог бы быть навык, который инструктировал бы его: "Эй, тебе нужно пройти через эти этапы".
Итак, что отличает рабочий процесс? В динамическом рабочем процессе он может сначала выйти и прочитать нашу текущую интеграцию Stripe или код биллинга. Возможно, он определит, что в приложении есть три разные основные функции, которые обрабатывают эти вещи. Затем он берет все это в качестве контекста и проверяет каждую из наших функций по документации нового поставщика, которого мы рассматриваем. У него также есть отдельный агент, который пытается рассчитать, исходя из нашего объема, каковы затраты. А затем, возможно, запускается этап враждебного обзора, который берет весь индивидуальный контекст, который он получал из этих различных разделов, и, возможно, пытается привести аргументы против миграции. И результатом этого является то, что вы получаете гораздо более конкретный набор рекомендаций. Так что это фундаментально то, что отличает статический каркас от этих настраиваемых каркасов через динамический рабочий процесс.
Итак, через некоторое время мы рассмотрим некоторые очень конкретные примеры этих вещей. Но сначала я хочу провести вас через шесть шаблонов, которые могут быть использованы для построения любого количества рабочих процессов. Итак, опять же, одно, что нужно помнить, когда я прохожу через все эти вещи, это то, что они могут и, вероятно, должны быть объединены. Итак, мы снова рассмотрим некоторые из этих классных вариантов использования после того, как поговорим о том, что на самом деле представляет собой каждая из этих вещей.
Итак, первый шаблон называется "Классифицировать и действовать". И здесь вы вводите некоторую задачу. Затем он может классифицировать эту задачу и то, что она на самом деле означает, а затем маршрутизировать эту задачу к конкретным агентам в зависимости от логики, которую вы установили, как он решает маршрутизировать что-то. Очень простой пример чего-то подобного может быть обработка ошибок и крайних случаев в вашем приложении. Так что у вас может быть рабочий процесс, который классифицирует эти ошибки на основе их серьезности или сложности, а затем, в зависимости от того, где именно они попадают в этот спектр. Возможно, вы передаете определенные вещи Haiku для решения очень простых задач, возможно, вы передаете средние ошибки Sonnet с навыком систематического отладки, а затем, возможно, ваши самые сложные проблемы передаются Opus, например. Так что это был бы пример шаблона "Классифицировать и действовать".
Следующий называется "Разветвление и синтез". И здесь вы берете задачу, разбиваете ее на последовательность более мелких шагов. Каждый из этих шагов выполняется индивидуально как субагенты, а затем результаты всех из них передаются синтезатору, который возвращает вам конечный результат, который вы искали. Опять же, очень известный пример этого — рабочий процесс в стиле исследования. Так что, возможно, он сначала выходит и исследует вашу кодовую базу. Затем он извлекает фактическую документацию от поставщиков, возможно, используя что-то вроде Context 7. Затем он ищет распространенные варианты использования, которые циркулируют в Интернете. А затем, после того, как у него есть все эти вещи, он синтезирует все это в окончательный результат и сообщает вам.
Номер три, и один из моих любимых, — это тип враждебного обзора и проверки. И один из больших недостатков языковых моделей заключается в том, что они действительно склонны зацикливаться на нарративах. Это означает, что если что-то выходит из контекста, который вы генерировали, он может найти одну нить, превратить ее в какую-то историю, а затем начать вдалбливать эту историю вам в глотку, когда на самом деле утверждение не так уж и проверено, и оно просто зациклилось в каком-то направлении, и теперь у него "шоры", и оно не будет рассматривать ничего за пределами этого. И поэтому круто в этом враждебном подходе то, что мы можем оспаривать все утверждения и предпосылки с помощью свежей проверки или "противника", который на самом деле является "функцией принуждения". Как будто он заставляет модель спорить туда и обратно с собой со свежим контекстом, так что любое "нарративное зацикливание", которое происходило, исчезает. И вы можете запустить множество таких одновременно. Так что, например, каждая из этих различных враждебных проверок может иметь разные определения и области применения того, что они на самом деле ищут при оценке этого утверждения.
Четвертый называется "Генерация и фильтрация". Это то, что, по моему мнению, Compound Engineering делает очень хорошо, где у нас есть разные агенты, которые исключительно отвечают за генерацию идей, например, с различными подсказками о том, как они конкретно думают о генерации идей. Затем вы получаете большой список идей, и вы можете фактически отфильтровать их на основе рубрики, набора критериев, пересечения между ними, а затем, наконец, из этого вы получаете лучшие идеи, а те, которые не соответствуют вашим критериям, отбрасываются. И поэтому вы можете представить, что вы хотите провести мозговой штурм различных подходов к некоторой функции, которая у вас есть на уме. Вы могли бы запустить три разных субагента, которые думают о том, как решить эту проблему с разных точек зрения. А затем вы могли бы отфильтровать все идеи, которые выходят с другой стороны, на основе контекста вашего приложения, того, что можно и нельзя делать в вашем приложении, возможно, ваших бизнес- или маркетинговых стандартов, в зависимости от варианта использования, для которого вы это применяете, потому что это не только для кодирования. И снова, вы возвращаете только лучшие идеи, где, возможно, вы хотите взять эту функцию, возможно, какой должен быть подход к UX для этой функции. Возможности безграничны, если вы проявите творческий подход к тому, как вы хотите использовать эти вещи.
Итак, снова, через несколько минут мы перейдем к тому, как вы можете объединить все эти вещи. Но сначала давайте закончим с последними двумя. Итак, пятый называется "Турнир", и здесь вы запускаете агентов для соревнования над одной и той же задачей. Каждый агент здесь пытается решить одну и ту же задачу, используя разные подходы. А затем у нас есть модель-судья, которая оценивает результаты всех этих вещей и пытается определить, кто на самом деле победитель. Этот почти кажется комбинацией "Генерации и фильтрации" и "Враждебной проверки". Но разница в том, что мы проходим раунды. Например, у нас есть две разные конкурирующие идеи, которые приводят к одному победителю. Но затем у нас был этот вторичный раунд, который имел свой собственный тест, который он запускал, что привело к своему собственному набору победителей. И теперь мы будем сопоставлять этих двух победителей друг с другом в битве, пока не получим окончательный результат. Так что, возможно, вы пытаетесь провести мозговой штурм лучших подходов к UX для вашего приложения. И каждая из этих различных попыток, которые вы запускаете, — это разный подход к тому, как вы можете думать о пользовательском опыте, а затем мы берем этих победителей, сталкиваем их друг с другом и, наконец, приходим к тому, что на самом деле является лучшим подходом к UX для этой функции или для приложения в целом. Или, возможно, вы пытаетесь провести мозговой штурм вирусных крючков для вашей маркетинговой кампании на основе библиотеки крючков, которую вы взяли у вашего любимого ютубера. Такая система сработала бы одинаково хорошо.
Последнее, что у нас есть здесь, называется "Цикл до завершения". И это, пожалуй, самое часто используемое с другими. Так что это довольно просто, что делает эта штука. Она будет непрерывно проходить через проблему, пока не будет достигнут установленный критерий приемки, и она знает, что она завершена. Так что, например, вы понимаете, что вы только что построили все приложение и не следовали подходу разработки, управляемой тестами, и теперь у вас нет тестирования во всем вашем приложении. Вы могли бы запустить агента, который предназначен для обнаружения всех областей вашего приложения, которые не протестированы. А затем для всех этих новых находок вы могли бы запустить субагента, чья единственная ответственность — найти самые рискованные области вашего приложения, которые не протестированы. И он просто продолжает циклически проходить через это, пока, например, у него не будет определенный процент тестового покрытия по всей различной функциональности вашего приложения. Так что эта штука кажется немного похожей на цикл Ральфа, но она немного более гибкая, я думаю, в том, как вы можете ее вызвать и в логике, которую она использует для выполнения задач.
Как я уже говорил, есть много вариантов использования, где вы можете объединить эти вещи. Давайте рассмотрим несколько из них и поговорим о том, какие из них они объединяют. Один хороший пример — встроенный рабочий процесс глубокого исследования. Итак, скажем, например, у вас есть приложение, которое использует языковую модель, и вы понимаете, что вы можете быть неэффективны с количеством ходов, которые совершаются, как оно обобщает информацию, как оно кэширует токены, все такое, и вы знаете, что вам нужно включить что-то подобное в свой проект, чтобы ваши расходы не взлетели до небес. Ну, вы могли бы запустить рабочий процесс глубокого исследования, который сначала разветвляется и синтезирует. Он разберет, что такое запрос, например, методы оптимизации подсказок для приложения, которое делает X, Y и Z. И, возможно, он определит, что ему нужны шесть разных субагентов, которые выйдут и будут смотреть на различные компоненты того, что вы запросили. После того, как он учтет все эти исследования, возможно, затем он запустит его через враждебный обзор. И этот обзор смотрит на контекст вашей кодовой базы, соглашения, которые у вас уже есть, проблемы, которые ваше приложение на самом деле должно решать, технологический стек, который вы на самом деле используете, и он будет проверять каждый из этих утверждений, которые пришли из этапа разветвления, чтобы убедиться, что они на самом деле точны и имеют смысл, учитывая контекст вашего проекта в частности. А затем, после того, как все это будет сделано, он синтезирует это в набор конкретных рекомендаций для вас.
Одна из вещей, которая делает это, я думаю, немного сильнее, чем что-то вроде навыка, заключается в том, что по мере того, как находки выходят из исследования или враждебного обзора, он может продолжать итерировать и улучшать качество того, что происходит. И мы посмотрим на пример этого через секунду, когда я покажу вам, я думаю, третий пример, который у меня есть, где он начинает запускать множество различных субагентов для решения проблем, которые возникают в реальном времени.
Другой вариант использования этих вещей, объединенных вместе, может быть проверка ваших мета-подсказок. Я думаю, что одна из вещей, которую люди любят делать, — это говорить своему инструменту, чтобы он вышел и исследовал что-то, а затем создал навык, который заменяет 20-летний опыт в какой-либо области. И снова, эти модели склонны к нарративному зацикливанию. Так что, если вы не проверяете эти вещи и не проверяете все, что закодировано в этих подсказках или навыках, вы можете делать вещи, которые просто неверны, потому что модель убедила себя, что объединение этих вещей на самом деле имеет смысл, когда на самом деле это может не иметь смысла. Например, у вас может быть шаблон "Классифицировать и действовать", который фактически проверяет эту мета-подсказку или навык и ищет все вещи, которые утверждаются как факт, а затем на основе всех этих фактов, которые он обнаруживает, он может действовать в направлении враждебного обзора, который затем фактически проходит и смотрит на все эти утверждения, исследует их и убеждается, что они на самом деле имеют смысл и интегрируются с навыком, который у вас был в первую очередь.
Теперь мы рассмотрим два реальных конкретных примера этих вещей, которые я сделал для себя, которые объединяют, я думаю, по три шаблона каждый. Первый — это извлечение из истории сеансов обновлений, которые должны быть внесены в ваш файл Markdown Claude. Многие люди создают файл Markdown Claude один раз и забывают о нем навсегда. И файл Markdown Claude — одна из самых важных вещей, которую нужно держать в актуальном состоянии, если вы хотите кодить как полный Чэд и не стать мемом, о котором кто-то говорит в Твиттере, имея "AI-шлак" и тому подобное. И причина в том, что вы действительно хотите документировать шаблоны и соглашения внутри вашего проекта, которые не очевидны. Так что Claude Code и действительно любые инструменты, это относится в равной степени к чему-то вроде Codeex. Они действительно хорошо понимают вещи, которые являются очень четкими шаблонами, но в любое время, когда им приходится читать много всего, чтобы понять что-то, что можно просто объяснить в одном-двух предложениях, или если есть вещи о вашем проекте, которые не будут очевидны для языковой модели, просто читающей ваш проект, это те вещи, которые вы хотите иметь в своем файле Markdown Claude.
И вот что делает этот рабочий процесс. Шаг номер один — "Обнаружить и переварить". Так что мы можем думать об этом как о шаблоне "разветвление", где он возьмет последние 20 разговоров в рамках этого проекта, сеансов, которые у меня были в этом проекте, а затем он пройдет через все эти сеансы с параллельными агентами, которые читают части сеанса и затем предлагают все, что вышло из этого сеанса, что является потенциальным кандидатом для включения в файл Markdown Claude на основе правил, которые я ему дал, которые в данном случае были вещами, которые нелегко вывести из того, что уже есть в проекте. Итак, мы берем все наши чаты. Мы ищем возможности для потенциального обновления файла Markdown Claude, а затем мы проходим через враждебную проверку, где он возьмет всех этих кандидатов, а затем у него есть два разных "скептических линзы", через которые он будет смотреть, нужно ли это отклонить. Первая — это "линза структуры", которая попытается увидеть, легко ли выводится из того, что у нас уже есть в проекте, то, что мы говорим, должно попасть в этот файл Markdown Claude. А затем у него есть другая, которая смотрит на "новизну или истинность" того, что на самом деле вышло в этом цикле майнинга. Итак, есть ли это уже в файле Markdown Claude? Является ли это не настоящим шаблоном, который нужно документировать, или он просто не поддерживается доказательствами? Затем он продолжает этот процесс в течение двух раундов, видя, например, если я пройду через это снова, нахожу ли я что-то новое, и снова, это все свежие агенты, так что свежий взгляд, а затем, когда все это будет сделано, он синтезирует это в отчет для нас. Так что это хороший пример того, где мы используем по крайней мере три разных шаблона, и мы делаем что-то, что было бы очень запутанным и трудным для воспроизведения в чем-то вроде навыка. И я расскажу в конце этого видео о лучших практиках, чтобы эти вещи не выходили из-под контроля и не сжигали миллионы токенов, потому что, честно говоря, этот использовал миллионы токенов для этого. И причина в том, что я не следовал своим собственным лучшим практикам, которые я собираюсь обсудить с вами.
Так что, если мы хотим посмотреть, как на самом деле выглядит вывод. Эта штука работала, я думаю, около 20, да, 26 минут. Она прочитала 20 сеансов, с которыми я ее загрузил. Она прошла через шесть разных циклов, что определенно избыточно. И она нашла 10 кандидатов, которые пережили два разных враждебных прохода. Итак, в данном случае, проект, который мы здесь используем, это один из моих платных плагинов, которые люди получают в моем сообществе, и у меня есть определенные соглашения, которых я люблю придерживаться, когда я улучшаю это и выпускаю обновления и делаю все такое. И поэтому то, что она искала в данном случае, — это мой собственный файл Markdown Claude для поддержания этой штуки, которую я строю для других людей. И поэтому я нашел множество различных вещей: проблемы с инструментами и средой выполнения в проекте, инварианты между файлами, вещи, которые отличаются и нарушают шаблоны и соглашения, детали того, как различные плагины и навыки на самом деле работают вместе, что неочевидно без фактического чтения этих файлов навыков. А затем она фактически нашла некоторые вещи, которые теперь устарели. Так что я на самом деле не обновлял свой файл Markdown Claude, и теперь то, что я там указываю, на самом деле неверно. Например, у меня есть этот навык "Цикл визуальной проверки", который изначально был заглушкой, когда я создавал эту штуку, но теперь у меня есть полная версия. И поэтому файл Markdown Claude, говорящий, что это заглушка, больше не является точным. Так что это все вещи, которые я хотел бы затем пройти и обновить. И снова, мы перейдем к лучшим практикам этого через секунду. Но прежде чем я это сделаю, я хочу провести вас через еще один рабочий процесс, который, я думаю, довольно крутой.
Итак, этот называется "Турнир рефакторинга React". И поэтому то, что он будет делать, это вызывать навык "Лучшие практики React" от Vercel. Итак, то, что он будет делать, это идентифицировать кандидатов на оптимизацию с помощью этого навыка "Лучшие практики React". У него будут судьи, которые определят, какие из них на самом деле являются более серьезными проблемами в проекте, исходя из контекста проекта и серьезности проблемы. У него будет один победитель из этого, а затем он будет продолжать возвращаться через этот цикл идентификации проблем, запускать их через этот турнир и находить победителя на столько циклов, сколько мы ему скажем. В данном случае он по умолчанию использует три цикла, чтобы он не сошел с ума. И поэтому, если бы мы хотели заглянуть и посмотреть, как это выглядит во время работы в реальном времени, у них есть эта поэтапная система, где мы можем видеть, какие этапы этого рабочего процесса на самом деле выполняются. В данном случае он сначала определяет фактическую область действия. Затем он переходит к этапу обнаружения и находит все возможности для того, где мы вообще хотели бы применить эту штуку. Часть навыка, который я определил, заключается в том, что все, что он находит, он записывает в бэклог, чтобы мы всегда могли вернуться и сослаться на эти вещи и не пришлось повторно запускать навык. А затем он фактически запустит его через турнир и внесет исправления. Итак, мы дадим этой штуке поработать некоторое время, а затем вернемся и посмотрим на результаты.
И поэтому мы можем видеть в данном случае, что все эти различные раунды турнира выполняются практически одновременно. Они не обязательно должны выполняться в строгом конвейере, где один должен ждать или что-то в этом роде. Все это выполняется параллельно. Так что, когда мы говорим о том, почему эти вещи могут потреблять токены, количество задач, которые будут выполнены, может быстро раздуться, если вы не будете действительно осведомлены о том, какой тип рабочего процесса вы запускаете. Так что, если идея запуска 19 различных субагентов одновременно пугает вас, опять же, мы перейдем к лучшим практикам в отношении того, как вы можете контролировать эти вещи, чтобы у вас не получилось сеанса, который просто безумно сжигает токены. Одна вещь, которую я скажу, это то, что в данном случае, например, "Лучшие практики React" дают вам действительно хорошее подробное руководство о том, что делать, и они дают примеры типов исправлений. Так что, честно говоря, если бы мы запустили это на Sonnet, это, вероятно, дало бы такое же качество работы, я думаю, без необходимости сжигать столько токенов Opus. Так что это те вещи, которые вы можете объяснить на естественном языке, когда вы создаете эти рабочие процессы, какие модели вы хотите использовать для конкретных раундов рабочего процесса, все эти типы вещей, вы можете контролировать и настраивать эти вещи.
Последнее, что мы посмотрим, пока это работает, — это то, как выглядит этот файл. Итак, эти рабочие процессы создаются как файлы JavaScript. Так что мета рабочего процесса у вас есть имя, описание, когда использовать, если это не то, что вы хотите специально запускать, и это нужно учитывать. Эти рабочие процессы будут запускаться сами по себе. И поэтому вы хотите быть очень четкими в отношении поля "когда использовать", чтобы он не ушел и не сделал сумасшедших вещей. Но затем у нас есть, какие различные этапы будут фактически выполняться внутри этой штуки. И вот как мы получаем эту структуру внутри этого рабочего процесса, где у нас есть область действия, обнаружение, бэклог, турнир, исправление. Все это было создано на естественном языке мной, описывающим, что я хотел, чтобы произошло. А затем остальная часть этого файла просто дает ему логику того, как он на самом деле будет работать. Он очень строг в отношении схемы вещи, так что он будет работать немного более детерминированно, и он не будет выходить из-под контроля и делать случайные вещи. Так что он очень строг, но опять же, все эти вещи создаются для вас. Например, в фазе один, в области действия, есть очень четкие инструкции о том, как выполняются вещи, каковы задачи. Так что все эти вещи и конфигурации, сколько раундов он запускает в циклах и все эти вещи, указаны в этом файле.
Теперь, если это вас пугает, вам не обязательно читать это, но вы должны хотя бы знать, что это находится в вашем проекте в каталоге "claw" в папке "workflows". И поэтому теперь то, что происходит, это то, что исправления фактически выполняются в отдельных рабочих деревьях, и они фиксируются по мере их выполнения. И поэтому существует действительно бесконечное количество возможностей для того, как вы можете объединить все эти различные типы рабочих процессов, чтобы создать действительно отличные, которые помогут вам решать сложные проблемы. Но, как я уже говорил несколько раз, вам нужно знать о лучших практиках и о том, как вы можете контролировать эти вещи, чтобы они не выходили из-под контроля и не сжигали токены, потому что я обещаю вам, что это произойдет, если вы не будете знать, что вы можете контролировать.
Итак, эти лучшие практики снова исходят непосредственно от Anthropic. Итак, номер один — это подсказки. Вы должны быть очень подробны в том, как вы говорите ему, как настроить вещи. Я фактически использую точные формулировки из них, когда описываю, что я хочу, чтобы он сделал. Например, с рабочим процессом турнира, который мы только что рассмотрели, я сказал ему: "Я хочу, чтобы вы использовали турнир с парными судьями, которые делают X, Y и Z". Так что будьте очень конкретны в том, как вы подсказываете вещи. Вы также можете сказать ему, что вы хотите, чтобы это был быстрый рабочий процесс, который не сходит с ума. Так что, я думаю, это часть того, где весь аргумент "он будет сжигать токены" отпадает. Вы можете заставить его делать вещи так, как вы хотите. Если вы дадите ему открытую задачу, да, он может случайно запустить 150 агентов, но вы должны видеть, что это происходит, если вы обращаете внимание на то, что происходит, а затем просто зайдите и измените рабочий процесс, чтобы исправить это.
Номер два — использование целей и циклов. Итак, с точки зрения циклов, если вы создаете рабочий процесс, возможно, вы создали какой-то рабочий процесс, который может смотреть на неудачные запросы на слияние, и он проходит через какой-то рабочий процесс для их разрешения так, как вы хотите, вы можете запускать его в цикле, например, который будет искать неудачные запросы на слияние с определенным интервалом, а затем запускать его через ваш рабочий процесс. Другое, что вы можете сделать, — это использовать команду /goal внутри Cloud Code, чтобы установить фактическое жесткое измеримое требование завершения, чтобы рабочий процесс имел контекст, когда останавливаться.
Номер три, и я думаю, это самый важный вывод, — вы можете сказать ему, что у него есть бюджет токенов. Например, если вы пройдете и скажете: "Вы можете использовать только 10 000 токенов, вы можете использовать только 100 000 токенов для всего этого запуска", он фактически будет придерживаться этого. Так что это действительно мощная вещь. Если вы боитесь количества токенов, которые будут использованы, или чего-либо еще, просто скажите ему, какой у вас порог для того, чтобы эта штука работала должным образом, и тогда вам не придется с этим иметь дело.
И последнее, но не менее важное: вы можете сохранять рабочие процессы. Итак, вы можете сохранять рабочие процессы, вы можете делиться рабочими процессами, и это очень легко сделать. Например, если бы мы вернулись в этот конкретный навык, если бы я нажал "Сохранить", я могу дать ему имя. И теперь этот навык будет сохранен в нашем проекте. А затем мы можем повторно использовать его, делиться им, поместить его в репозиторий и делиться им с другими, что угодно. Возможности безграничны. Так что, как говорится, это целый новый мир. Я думаю, что он заимствует шаблоны из того, что пытались сделать другие плагины, но теперь это расширение Claude Code, и оно фактически будет работать таким образом по умолчанию, и у вас есть большой контроль над системой. Опять же, если вы хотите два рабочих процесса, которые я рассмотрел, и вы хотите настроить их, что я рекомендую вам сделать, вы можете найти ссылки на них в описании ниже. Если вы пытаетесь повысить свою квалификацию от базового кодирования до более продвинутого "инженерного кодирования", как я это называю, вы должны сокрушить кнопку подписки. Но это все для этого видео. Увидимся в следующем.