Skip to content
Get App

400 часов опыта с Claude за 14 минут: Гайд по Vibe Coding

Гайд по эффективной работе с Claude: настройка cloud.md, скилы, MCP-серверы и оптимизация workflow для быстрой разработки.

Key Takeaways

  • Правильная настройка cloud.md и его конкретность существенно повышают качество генерации кода Claude.
  • Использование скилов и MCP-серверов автоматизирует рутинные задачи и ускоряет разработку.
  • Режим планирования помогает безопасно работать с продакшн-кодом без риска сломать что-то.
  • Не стоит пытаться создать идеальный скилл с первого раза — лучше итеративно улучшать его.
  • Оптимальное количество MCP-серверов — 3-5, чтобы не перегружать контекст и сохранять производительность.

What the video covers

  • Автор делится опытом сотен часов работы с Claude и рассказывает, как правильно настроить рабочий процесс для повышения продуктивности.
  • Рекомендуется использовать файл cloud.md для хранения ключевых правил и инструкций, чтобы не повторять их каждый раз.
  • Важно держать cloud.md компактным (до 150 строк) и конкретным с примерами из собственного кода.
  • Можно создавать отдельные cloud.md для подпапок в монорепо или больших проектах.
  • Режим планирования позволяет агенту исследовать файлы и создавать план без изменения кода, что безопасно для продакшн.
  • Скилы — это расширенные промпты с шаблонами и вспомогательными файлами, которые автоматизируют рутинные задачи.
  • Примеры скилов: Feature Search для сбора всей документации по задаче и Deep Review для мультиагентного анализа кода.
  • MCP-серверы расширяют возможности Claude, позволяя подключаться к внешним сервисам, браузеру и собирать данные с сайтов.
  • Рекомендуется использовать 3-5 MCP-серверов одновременно, чтобы не перегружать контекст и не тратить лишние токены.
  • Есть GitHub репозиторий Awesome Cloud Code с готовыми скилами, хуками и командами от сообщества.

Answers

Questions about this video

Что такое файл cloud.md и зачем он нужен?

cloud.md — это файл с ключевыми правилами, командами и описаниями сервисов, который Claude читает в начале каждой сессии. Он помогает избежать повторения одних и тех же инструкций и ускоряет разработку.

Как использовать скилы в работе с Claude?

Скилы — это папки с шаблонами, примерами и описаниями, которые автоматизируют рутинные задачи. Claude может вызывать их автоматически или через slash-команды, что повышает качество и скорость работы.

Что такое MCP-серверы и как они помогают?

MCP-серверы расширяют возможности Claude, позволяя подключаться к внешним сервисам, браузеру и собирать данные. Это облегчает работу с проектом и позволяет выполнять сложные задачи напрямую через агента.

Full Transcript — Download SRT & Markdown

00:00
Speaker A
Я провёл сотни часов с Cloud Code, делал фичи на реальных проектах с миллионами пользователей и пилил свой собственный продукт. И за это время я понял одну вещь. Если Cloud не понимает тебя и генерирует мусор, то проблема в твоём сетапе. Сегодня я покажу всё, что реально ускорило мою разработку и что я использую каждый день в своей работе.
00:16
Speaker A
Первое, от чего я устал, — это повторять одни и те же инструкции каждый раз, исправлять одни и те же неточности.
00:23
Speaker A
Каждый раз объяснять Cloud, какой кодстайл я использую, какой у меня стек, какая структура файлов. Это трата времени и решение создать файл cloud.md.
00:29
Speaker A
Это постоянная память для твоего агента, и он читает этот файл в начале каждой сессии. Вот так выглядит пример моего файла. Правила, команды, описание сервисов. Несколько важных правил по cloud.md, которые я вывел из своего опыта. Первое — это не перегружать его и
00:40
Speaker A
держать примерно до 150 строк. Если сложить туда всю информацию о проекте, то контекстное окно будет перегружено и завалено информацией, которая будет мешать тебе разрабатывать. Второе — быть конкретным. Не нужно писать просто: "Используй лучшие практики программирования". Используй конкретные примеры, которые можно взять из своего
00:57
Speaker A
же кода. Чем точнее инструкция, тем лучше результат. Третье. Можно создавать cloud.md для подпапок. Например, если в проекте монорепо либо разные модули в проекте, для каждого можно создать свой файл и описать правила работы именно с этой частью приложения. И ещё один
01:16
Speaker A
приём, который может сэкономить очень много времени. Не пытаться самому заранее написать супердетальный промпт. Можно начать с простого и попросить Cloud разработать его, уточнить и улучшить. Мы можем попросить Cloud задать нам уточняющие вопросы, что поможет сделать более детальный и точный
01:34
Speaker A
промпт. То есть начинаем с чего-то простого, просто описываем свою идею, просим Cloud не начинать реализацию, а именно первым шагом подготовить сам промпт для агента. И ключевой шаг — прочитать, что получилось, очистить контекст и передать уже готовый промпт к
01:51
Speaker A
лоду. Ещё одна базовая, но очень полезная вещь — это режим планирования. Shift + Tab два раза идёт переход в режим, в котором он не может изменять файлы, но может читать их, проводить исследования и создавать план реализации задачи. Это критически важно, например, когда мы
02:07
Speaker A
работаем с продакшн-кодом. Здесь мы явно ничего не сломаем, пока сами не одобрим изменения. И ещё одна основная команда, которую часто упускают, — это команда Insights. Cloud анализирует прошлые сессии и показывает, что можно улучшить в твоём workflow. Например, он может
02:25
Speaker A
заметить, что ты постоянно повторяешь какие-то циклы в своей работе и может посоветовать вынести определённые флоу в отдельные скилы, которые улучшат качество кода и скорость работы.
02:42
Speaker A
Например, мне Insights помог увидеть, что я трачу много времени на циклы Фигма, код, сравнения, тесты. Об этом расскажу чуть дальше. И это стало одним из самых частых скилов, которые я использую сейчас. Вещь, которая реально изменила мой workflow, — это скилы. И skill — это
02:53
Speaker A
не просто файл с промптом. Это целая папка, в которую можно положить шаблоны, примеры, вспомогательные файлы и, конечно, само описание скила. Cloud может вызывать скилы автоматически, когда выполняемая работа подходит под описание этого скила, либо через slash-команду.
03:09
Speaker A
Давайте я покажу два скила, которые я реально использую в работе. Первый скилл — это Feature Search. Незаменимая вещь, потому что экономит буквально часы работы. Вот ситуация. Ты получаешь новую задачу в Gicket, в которой можно найти ссылки на документацию, на Confluence,
03:26
Speaker A
на Фигму, на какие-то другие тикеты, например, связанные с бэкендом и другими частями приложения. Раньше я тратил много времени просто на сбор контекста, на удерживание информации в голове, либо структурировал её где-то. Но теперь этот скилл делает всё за меня. Я вызываю
03:43
Speaker A
команду через slash, передаю номер тикета и дальше автоматически знает, как собрать всю информацию и подготовить нужную документацию для работы с этой фичей. И вот что происходит. Через MCP он идёт в Git, достаёт текст, связанные задачи, ссылки и далее. Параллельно
04:00
Speaker A
агенты читают Confluence, составляют документацию, смотрят дизайн Фигмы. И если, например, задача связана с созданием новых контент-моделей, например, в Contentful, то он идёт, изучает существующие и предлагает свои решения.
04:17
Speaker A
На выходе папка с готовыми документами, с требованиями, с тесткейсами, с эджкейcами и планом реализации по шагам.
04:31
Speaker A
И это, по сути, расширенная версия того двухшагового промпта, о котором я говорил в начале. Идея такая же. Перед началом работы мы создаём детальную документацию с описанием того, что нам нужно сделать, основанную на исследовании. Второй пример — это Deep Review, мультиагентное CDW.
04:39
Speaker A
Сначала Cloud собирает контекст, смотрит, какие части приложения затронуты. Например, я использую его в монорепо, который есть платёжный сервис, backend-сервис, Telegram Bot-сервис и сервис работы с AI. И для каждого из них запускается свой специализированный агент, у которого есть знания, связанные
04:55
Speaker A
именно с этой частью приложения. И также для каждого агента мы можем задать определённые настройки. Например, агент, который собирает Git diff и определяет, какие файлы были затронуты, использует модель Haiku, которая попроще. А агент, который следит за безопасностью приложения, работает уже на модели OPUS.
05:14
Speaker A
И после прохождения ревью всеми агентами есть ещё фаза валидации. Новый отдельный агент проверяет, насколько критичны, вообще важны замечания, которые нашли эти агенты. Возможно, это и не проблема на самом деле. То есть финальный шаг — это определённый фильтр для того, чтобы
05:32
Speaker A
получить более качественный результат. В примере с этими двумя скилами они покрывают два важнейших этапа разработки. Это подготовка и ревью.
05:48
Speaker A
Между ними, конечно, есть написание кода, и для него существуют отдельные скилы. И ещё что я понял, что не нужно пытаться написать идеальный скилл с первого раза. Лучше потратить какое-то количество итераций и найти ту комбинацию инструментов и подходов, которая реально работает. И, кстати,
05:58
Speaker A
есть отличный GitHub Repo, Awesome Cloud Code, где есть множество готовых скилов, хуков и команд от community. Наверное, один из самых мощных апгрейдов, который можно сделать, — это MCP-серверы Model Control. Объясню просто: когда ты работаешь с Cloud, у него есть доступ к
06:14
Speaker A
твоим файлам и терминалу. MCP-серверы расширяют его возможности и позволяют подключаться к внешним сервисам напрямую, предоставляя Cloud определённый набор тулзов для работы с ними. Это может быть приложение, это может быть просто сайт, это может быть документация, что угодно. Чтобы
06:32
Speaker A
подключить MCP-сервер, нужно написать mcpd, указать имя и команду запуска. Например, я чаще всего использую Playwright и Chrome DevTools MCP. Они позволяют подключаться к браузеру и выполнять определённые действия, такие же, которые может выполнять обычный юзер. Открывать страницы, кликать,
06:48
Speaker A
делать скриншоты. Но с помощью DevTools MCP также можно инспектировать консоль, network и элементы. Это классно работает в комбинации с FigM MCP. То есть Cloud сначала пишет код и потом проверяет, что он сделал уже в браузере. Другой пример — Fire. Не совсем про код, а скорее про
07:06
Speaker A
общее пользование Cloud. FireScroll MCP даёт возможность быстро собирать информацию с любых ресурсов, например, изучить документацию, собрать все URL с сайта или построить карту какого-то ресурса или, например, изучить лендинг своих конкурентов. Например, в комбинации со скилом, про который я
07:23
Speaker A
рассказывал, Feature Search. Такой кроулер можно использовать для сбора документации о каком-то сервисе или для исследования лучших подходов к решению определённой проблемы. Всегда, когда начинаете работать с каким-то новым сервисом, имеет смысл поискать, нет ли у него своего MCP, которое облегчит и
07:41
Speaker A
улучшит работу с ним. И есть важный момент: нужно стараться не ставить 15 серверов сразу. Каждый сервер будет занимать токены в контексте, что ухудшит работу Cloud. В моём опыте идеально использовать три-пять серверов, которые реально нужны для текущей задачи и
07:58
Speaker A
проекта.
08:14
Speaker A
проекта. Работа с контекстом. Плохая работа с контекстом может сделать так, что вы будете ненавидеть клод и то, что он делает. А правильный подход поможет писать код быстро и качественно. У клода есть контекстное окно, 200.000 токенов, и туда попадает всё документация,
08:30
Speaker A
описание задачи и так далее. И чем больше забито это окно, тем хуже результат выдаёт Клод. И особенно при определённом количестве итерации работы с свечой, оно будет забиваться всё сильнее и сильнее, особенно если в какой-то момент работы пришлось править
08:46
Speaker A
баги, возвращаться и продолжать работу. У Клода есть команды Compact и Clear, но в моём опыте, мне кажется, лучший подход - это делать максимально детальную хорошую документацию и разбивать задачи на подзадачи. То есть первым шагом мы обсуждаем архитектуру нашей фичи,
09:05
Speaker A
подход, который мы хотим использовать, создаём файлы с документацией и описанием процесса работы. Далее мы чистим контекст либо вообще перезапускаем терминал с клодом.
09:15
Speaker A
Возможно, разбиваем задачу на подзадачи и запускаем уже отдельных агентов, которым передаём документацию, которую мы сгенерировали. То есть перед началом работы в промт лучше добавлять инструкцию, чтобы cloud сохранил все результаты исследования в определённые файлы. Итак, субагенты. Я частично уже
09:36
Speaker A
упомянул их, но давайте разберём немного подробнее, потому что там есть множество разных нюансов. Субагенты - это отдельные инстансы клода, которые работают параллельно с основным агентом.
09:46
Speaker A
И я думаю, раньше повсеместно использовался подход, где мы описывали агента так: "Ты профессиональный архитектор, фронт, бэкэнд". приложений, которые проектируют лучшие в мире архитектуры. В моём опыте это работает не очень хорошо, и более эффективным было описывать агента как исполнителя
10:03
Speaker A
какой-то маленькой задачи со специфичным набором тулзов и возможностей. То есть, например, не просто ты лучший ревьювер кода, а проверь изменения на соответствие принципам feature slide design. Вот пример промпта, который я использую для кодрев. Первый шаг запуская лёгкого хайкуагента, который
10:22
Speaker A
просто возвращает список путей ко всем clд-файлам. Второй шаг параллельно, если есть PR, читаем его заголовок и описание для контекста. Одновременно агент смотрит div через MCP и возвращает sumary изменений. Третий шаг - это четыре агента параллельно. Два саet агента проверяют соответствие D. Один
10:41
Speaker A
опусгент ищет баги только в дифе, другой OPUS-агент ищет проблемы безопасности и некорректную логику в новом коде.
10:49
Speaker A
Ключевой принцип: субагенты для конкретных задач с чёткой структурой оркестрации, а не для размытых ролей.
10:56
Speaker A
Описывайте, кого запустить, что они должны сделать и в каком порядке. Хуки. Хуки - это скрипты, которые запускаются автоматически на определённых шагах работы клода, например, в тот момент, когда клод пытается вызвать какую-то команду. И в отличие от инструкции, как
11:11
Speaker A
клодм MD, например, или скилов, хуки будут выполнены гарантированно. Скилы расширяют то, что может сделать клод. А хуки могут ограничить то, как он это делает, добавляя безопасности в нашей работе. Вот один из примеров хуков, который есть в моём проекте. Был случай,
11:27
Speaker A
что Клод перед миграцией просто стёр всю тестовую базу, в которой были тысячи строк данных, используемых для работы. И я решил сделать хук, в котором мы проверяем, вызывает ли Клод команду для работы с базой данных. Если он вдруг хочет очистить её или запушить какую-то
11:46
Speaker A
сомнительную миграцию, мы его останавливаем. Ещё классические примеры - это, например, блокировка Gitpit-команд, чтобы ClД без вашего ведома не отправил что-то в репозиторий. И также я использовал в работе Hook, который обновлял документацию проекта после каждой законченной фичи, например, перед
12:04
Speaker A
комитом. И с хуками мы можем давать клоду больше свободы, потому что уверены, что он не совершит каких-то вредных действий. плагины и продвинутый workflow. Если всё, что я рассказывал, звучит как много настроек, то есть способ упростить это. Плагины - это
12:20
Speaker A
пакеты, в которые как раз упакованы все команды, скилы, хуки и разные настройки MCP-серверов. Например, мы можем упаковать сетап, который собирали на протяжении всей работы с приложением, и использовать его одной командой. И есть ещё один плагин, который реально улучшил
12:37
Speaker A
качество моего кода, помог сэкономить множество токенов и сократить время на разработку. Плагин называется RF loop.
12:44
Speaker A
Идея этой техники в том, что мы держим агента в цикле до выполнения определённого условия. Принцип такой же, как в работах хука. То есть мы передаём промт агенту и не выпускаем его из цикла, пока определённое условия не выполнено, например, пока агент не
13:00
Speaker A
вернул определённую фразу. Один из подходов - это, первое, сгенерировать суперподробную документацию того, что ты хочешь сделать, создать или попросить Клода сгенерировать тесты, тесткейсы и потом уже передать описание того, что нужно сделать через RF loop в Клода, и не выпускать его из цикла, пока все
13:21
Speaker A
тесты не станут зелёными. Работа с продакшн-кодом. И если вы уже знаете, что вы делаете, я бы на самом деле добавил только один пункт, про который я уже говорил - это режим планирования. И да, это означает вручную проверять каждый шаг того, что сделал Клод. Это
13:40
Speaker A
звучит не очень весело, но на самом деле такая проблема даже для продакшн-кода решается хорошим сетапом. Работая с одним проектом долгое время, мы неизбежно наберём набор правил, набор частых багов и проблем, в которые мы упирались. И на основе этого мы можем
13:57
Speaker A
создать большой набор различных скилов, инструкций и хуков, которые сделают нашу работу безопасней. И другой критичный момент - это разбивать задачу на маленькие части. За маленькой задачей легче следить, клод будет использовать меньше контекста, и мы будем чувствовать, что реально контролируем
14:13
Speaker A
процесс. И это то, что реально изменило мою работу с клодом. Работа с памятью, правильная работа с контекстом, скилы, чтобы избежать рутины, правильно подобранные MCP, хуки для безопасности, хорошая документация, план-режим. Всё это несложно настроить. Каждая вещь по отдельности даёт небольшой буст, но всё
14:32
Speaker A
вместе это реальный workкflow для качественной, приятной работы с клодом. Если было полезно, подписывайтесь, рассказывайте, какие сетапы используете в своей работе. И спасибо. Увидимся. y
Topics:ClaudeCloud CodeскилыMCP-серверыпрограммированиеавтоматизацияworkflowгайдмонорепопромпты

Get More with the SozAI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries and speaker detection. 30 minutes free.

Or transcribe another YouTube video here →