**400 часов опыта с Claude за 14 минут: Гайд по Vibe Coding — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/400-hours-claude-vibe-coding-guide/

Гайд по эффективной работе с 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 с готовыми скилами, хуками и командами от сообщества.

## Chapters

1. 00:00 Введение и опыт работы с Claude
2. 00:40 Настройка файла cloud.md и правила его использования
3. 01:51 Режим планирования и его преимущества
4. 02:53 Что такое скилы и как их использовать
5. 04:00 Пример скила Feature Search для сбора документации
6. 04:55 Пример скила Deep Review для мультиагентного анализа
7. 05:58 Использование MCP-серверов и их преимущества
8. 07:06 FireScroll MCP и сбор информации с внешних ресурсов
9. 08:14 Работа с контекстом и оптимизация токенов
10. 09:15 Заключение и рекомендации по улучшению workflow

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: Claude Cloud Code скилы MCP-серверы программирование автоматизация workflow гайд монорепо промпты

Учить по этому видео

- [Карточки по этому видео](https://sozai.app/ru/tools/flashcard-maker/?from=transcript&id=79683)
- [Тест по этому видео](https://sozai.app/ru/tools/quiz-generator/?from=transcript&id=79683)
- [Кроссворд по этому видео](https://sozai.app/ru/tools/crossword-maker/?from=transcript&id=79683)
- [Филворд по этому видео](https://sozai.app/ru/tools/word-search-maker/?from=transcript&id=79683)
- [Шпаргалка по этому видео](https://sozai.app/ru/tools/study-guide-maker/?from=transcript&id=79683)

Бесплатно, составлено ИИ по этой расшифровке. Без регистрации.


---
This is the markdown twin of https://sozai.app/transcript/400-hours-claude-vibe-coding-guide/ — the same content, without the markup.
Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back.
Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/