Transcription
Вот всё, что вам нужно знать о vibe-кодировании. Хорошо, во-первых, какой инструмент вы собираетесь использовать? Есть несколько вариантов того, что вы можете здесь сделать. Во-первых, я использую Windsurf и Cursor, но в основном Windsurf в последнее время. Windsurf – это редактор кода. Это также форк VS Code, самого популярного редактора кода на планете. Поэтому, если вы уже используете VS Code, это естественное расширение того, что вы уже делаете.
Теперь другой вариант – использовать расширение в самом VS Code. Так что, если вы не хотите полностью менять IDE и хотите продолжать использовать VS Code, вы можете использовать что-то вроде Klein. Я слышал о нём очень хорошие отзывы, немного тестировал, но не очень extensively. Ещё один вариант – использовать Replit. Replit – это полностью онлайн-редактор кода. Крутая вещь в Replit – вы также можете очень легко развертывать свои приложения, так как всё находится в облаке.
Теперь последний и, наверное, самый простой способ начать – использовать функцию canvas в вашем любимом хостинге ИИ. Вот Claude. Вы можете просто ввести всё, что хотите. Вот пример: "Напишите код 3JS для самой крутой вращающейся 3D-фигуры, которую вы можете создать". Теперь, когда вы закончили, вы можете открыть его в canvas и запустить прямо из браузера. Вот пример того, что я закодил примерно за 20 минут.
Есть ограничения. Вы можете запускать только HTML и JavaScript, но, поскольку JavaScript – самый популярный язык программирования на планете, вы можете на самом деле сделать довольно много, запуская его прямо в браузере. И не только это. У ChatGPT есть функция canvas, и Google только что выпустила свою собственную функцию canvas. Поэтому всё чаще вы можете писать и выполнять код, не выходя из браузера. Но для более сложных проектов я всё ещё буду использовать один из других инструментов, которые я упомянул.
Также эти другие инструменты – это агенты. Когда вы вводите запрос в Claude, ChatGPT или Google, чтобы он написал код, а затем выполнил этот код, он на самом деле не будет итерироваться по коду. Он просто не настолько агентивный, как Windsurf или Cursor. И говоря о Windsurf, спасибо Windsurf за спонсирование этого видео. Я также просто люблю использовать Windsurf. Windsurf – фантастический. Я использую его для vibe-кодирования всё время. Вы можете легко переключаться между режимами чата, записи и legacy. У них есть множество различных вариантов моделей, таких как Cloud 3.7 Thinking, Cloud 3.7, Cloud 3.5, модели OpenAI, и вы можете использовать правильную модель для правильной задачи.
Они также только что выпустили множество новых функций, связанных с автодополнением, таких как табуляция для перехода, табуляция для импорта, и функциональность табуляции, автодополнение имеет контекст не только вашей кодовой базы, не только того, что находится в вашем терминале, но и того, что вы пишете в Cascade. Они также только что выпустили функциональность предварительного просмотра в браузере, что очень приятно. Cascade автоматически предложит окно браузера, чтобы вы могли посмотреть на проект, который вы строите, по мере его построения, и вы можете дать ему конкретную обратную связь, нажимая на области, которые вы говорите: "Это неправильно", или "Это правильно, но я хочу добавить эту другую функцию". Плюс вы можете вставлять URL-адреса в документацию библиотеки, документацию API, всё, что вам нужно, чтобы просто дать ему дополнительные знания о том, как писать код так, как вы хотите. Поэтому спасибо Windsurf за спонсирование этого видео. Перейдите на wind.surf/matthewberman, скачайте Windsurf прямо сейчас и начните vibe-кодирование или традиционное программирование прямо сейчас.
Хорошо, дальше. Вы решили vibe-кодировать. Какой язык программирования вы на самом деле выберете? И не только язык программирования, но и какой стек кода, потому что в вашем проекте будет несколько частей: например, фронтенд и бэкенд. И как вы на самом деле выбираете язык программирования, особенно если у вас нет опыта ни с одним из них? Я скажу вам, есть одно простое правило: вы хотите выбрать самый популярный язык программирования, потому что это означает, что у ИИ было больше примеров кода для обучения, что, вероятно, означает больше опыта и может написать лучший код. Самый популярный язык программирования в мире – JavaScript. Поэтому, если вы vibe-кодируете и хотите написать это на JavaScript, это отличный вариант.
Другой вариант, и действительно де-факто язык программирования искусственного интеллекта – Python. И мне очень нравится Python. Поэтому стек кода, который я обычно использую, – это Python для бэкенда и HTML и JavaScript для фронтенда. Но вам не обязательно использовать Python для бэкенда, вы можете использовать JavaScript также для бэкенда, используя что-то вроде NodeJS. Но суть в том, чтобы выбрать что-то популярное. И я нашёл очень крутую графику под названием GitHut 2.0, и она в основном показывает вам все самые популярные языки программирования, так что вы можете видеть здесь Python, Java, Go, JavaScript, C++, TypeScript и так далее. И я оставлю эту ссылку в описании ниже.
Хорошо, так вы выбрали инструмент, который вы будете использовать, скажем, Windsurf. Вы выбрали свой стек кода, вы будете использовать Python для бэкенда, JavaScript и HTML для фронтенда. Что дальше? Вы хотите составить план. Вы действительно хотите потратить много времени на этот шаг. Вам нужен подробный, тщательный план, который вы можете передать ИИ, чтобы он точно знал, что вы хотите создать. Вы хотите попытаться продумать все пограничные случаи и записать их, чтобы приложение вело себя именно так, как вы ожидаете. Но вам не нужно писать всё это сами, вы можете использовать ИИ, чтобы помочь вам.
Для этого я обычно обращаюсь к Grok за помощью. Вот пример: "Напишите подробный план спецификации для SaaS-приложения, которое я хочу создать, где я могу оставлять ссылки на статьи, видео YouTube, научные работы, а затем оно использует ИИ для их суммирования и может использовать релевантный поиск, чтобы помочь мне искать среди всех сохранённых статей, а затем я наконец добавлю вопросы, чтобы заполнить любые пробелы в том, чем должно быть это приложение". Grok может на самом деле помочь вам выяснить все различные функции и функциональные возможности, которые вы хотите добавить сюда, и вам не нужно просто брать первую вещь, которую он говорит. Вы можете работать с ним туда-сюда, пока не придумаете действительно хороший план.
Здесь вы можете увидеть множество вопросов, которые он задаёт мне, и мы можем ответить на них по мере наших возможностей. Очевидно, некоторые из них будут немного более техническими, и если у вас нет этих технических навыков, снова просто работайте с Grock и попросите его объяснить вам, что означают каждое из понятий. Затем в самом конце я скажу: "Напишите это в формате PRD, который является документом требований к продукту, и мы будем использовать формат файла MD Markdown". И вот так. И как только он напишет всё, мы скопируем его и поместим прямо в каталог, в котором мы строим свой проект, и мы сохраним его на потом. И я объясню, как его использовать позже. А затем я попрошу его придумать пошаговый список дел для создания этого в формате MD, ещё раз, потому что MD просто очень хорошо работает с искусственным интеллектом.
Хорошо, так мы видим здесь наш контрольный список, наш список дел, пошаговую настройку того, что нам нужно, чтобы запустить это приложение. Теперь у него есть ETAs, которые нам, очевидно, не нужны. Поэтому снова просто работайте с Grock, скажите ему, что вам нужно, и доведите дело до того, чтобы у вас был общий план и список дел. Я не могу достаточно подчеркнуть, насколько важно потратить время и инвестировать время на этом этапе. Вы действительно хотите продумать каждую возможную функцию, которую вы можете захотеть, каждый пограничный случай, каждую перестановку, о которой вы только можете подумать. Это действительно то, что касается традиционного кодирования: эти пограничные случаи, эти детали – вот где у вас будут проблемы в будущем, если вы не подумаете о них сейчас. Они появятся в будущем, и внесение изменений в будущем всегда будет сложнее, чем подумать об этом и реализовать это с самого начала.
Теперь хорошая вещь в наличии плана, хорошая вещь в наличии списка дел – вы всегда можете попросить ИИ вернуться и сослаться на него, чтобы он оставался на правильном пути более эффективно. И по мере того, как вы vibe-кодируете, по мере того, как вы продвигаетесь в своём проекте, вы всегда можете вернуться и обновить свой план, если вы поймёте, что вам не нужна функция, или вы поймёте, что хотите добавить другую функцию, или вы хотите, чтобы что-то вело себя по-другому. Вернитесь, внесите изменения в документ, внесите изменения в план.
Хорошо, дальше поговорим о контроле версий. Это то, что спасёт вас от многих головных болей и вашего рассудка в будущем. Теперь, если вы совсем не знакомы с кодированием, контроль версий – это именно то, что он означает. Он позволяет вам, по сути, сохранять свой код в разных точках по мере построения. Почему это важно? Это важно не только для vibe-кодирования, это крайне важно для любого кодирования, традиционного кодирования, vibe-кодирования, что бы это ни было. Вам нужен способ хранить свой код и сохранять его в определённые моменты его жизни. Потому что, если что-то пойдёт не так, вы всегда можете откатиться назад. Вы можете найти предыдущую точку, в которой вы знаете, что код работал так, как вы ожидали, и просто вернуть код в эту точку и начать заново. Это особенно важно для vibe-кодирования, потому что ИИ действительно иногда вносит огромные изменения в вашу кодовую базу и просто полностью ломает код.
Поэтому, если это произойдёт, вместо того, чтобы входить в эти действительно длинные циклы "нет исправления", "нет, это не сработало", "исправить ещё раз", "попробовать что-то новое", "исправить ещё раз", вы просто отбрасываете последние изменения и начинаете с вашего самого последнего стабильного кода. Если вы никогда в жизни не программировали, вы можете слышать или не слышать о чем-то, называемом Git. Git – это программное обеспечение для контроля версий по умолчанию, которое, по сути, использует каждый. Он позволяет вам сохранять свой код в разных точках и делать много других действительно крутых вещей. И это также очень ценно, когда ваша кодовая база становится очень большой, и вы хотите работать над разными функциями или разными частями функциональности одновременно, а затем собрать всё вместе в конце. Но Git также может быть довольно сложным. Хорошая вещь заключается в том, что вы можете на самом деле попросить своего помощника по кодированию ИИ или своего агента помочь вам написать код Git, так что вам не обязательно нужно полностью понимать, что он делает. И я знаю, что многие из вас, программисты, вероятно, кривятся от этого утверждения. И позвольте мне сделать паузу на секунду. На самом деле хорошо изучать все эти традиционные методы кодирования, но если вы не хотите, вам не нужно. Если вы просто пытаетесь создать игру для себя и не собираетесь выкладывать её и показывать миру, это нормально. Просто делайте всё возможное, запустите что-нибудь и получайте удовольствие. Я бы порекомендовал просто выучить основную терминологию Git, например, commit, revert, logs и тому подобное. Но после этого вам действительно не нужно знать более сложные вещи.
Поэтому первое, что вы хотите сделать, прежде чем что-либо кодировать, это установить Git. У меня есть существующий проект, с которым я просто быстро поигрался. Я не устанавливал Git. Позвольте мне показать вам, как это сделать, и это действительно должно быть так же просто, как сказать своему агенту ИИ сделать это. Поэтому я просто скажу: "Установите Git". И он говорит здесь: "Git обычно предварительно установлен в Mac OS, но позвольте мне проверить, установлен ли он". Так что он просто всё для вас обработает. Git – это команда, git --version просто убеждается, что он установлен правильно. Так что он говорит, что он уже установлен. Затем я просто говорю: "Добавьте Git в этот проект". Так что он запускает команду git init, которая инициализирует, и он создаёт файл git ignore, что означает файлы, которые вы не хотите включать в Git, запускает новую ветку. Опять же, вы узнаете всю эту терминологию по мере продвижения, и если у вас есть какие-либо вопросы, просто спросите свой ИИ, и он уже делает свой первый коммит. Так что это ваша первая точка сохранения. И это всё. Это так же просто, как просто поговорить со своим ИИ и заставить его сделать это для вас.
Теперь, если вы используете Git, всё будет храниться на вашем компьютере, вашей локальной машине, но вы действительно хотите более безопасное хранилище кода, чем это. Поэтому я использую GitHub. Это просто означает взять ваш Git, взять ваш код и передать его в облако, и вы храните его там. Это как Google Docs для кода, и это бесплатно. Зарегистрируйтесь в GitHub, и вы можете попросить ИИ помочь вам настроить его.
Хорошо, дальше позвольте мне поговорить о правилах. Большинство из этих инструментов Vibe-кодирования, Cursor, Windsurf, Client, поддерживают то, что называется правилами. Правила позволяют вашему агенту кодирования ИИ писать код так, как вы хотите, следуя структуре, которую вы хотите, и следуя рабочему процессу, который вы хотите. Это как написание системного запроса для вашей большой языковой модели. Это то, что будет включено в каждый отдельный запрос, который отправляется в ИИ. Так что это действительно как системный запрос.
В зависимости от того, какой инструмент вы используете, ваши правила будут отображаться в разных местах. Позвольте мне показать вам Windsurf. Внизу справа вы найдёте эти настройки Windsurf. Вы нажмёте на него, и здесь написано "Память и правила". Нажмите "Управлять". Также здесь можно найти память. По крайней мере, с Cascade, когда он разрабатывает проект, он будет хранить воспоминания о вашем проекте, и если вы обнаружите, что память неправильная, вы можете просто удалить её и начать заново. Внизу вы увидите правила, определённые пользователем. У вас есть глобальные правила и правила рабочей области. Глобальные правила означают правила, которые применяются ко всем проектам, а правила рабочей области – это правила, которые применяются только к определённому проекту. Позвольте мне показать вам некоторые из моих глобальных правил. Конечно, это в файле Markdown, его очень легко редактировать, это всё естественный язык.
Вот первое: "После внесения изменений всегда убедитесь, что запустили новый сервер, чтобы я мог протестировать его". Я обнаружил, что он будет вносить изменения, а затем мне приходилось вручную либо завершать работу существующего сервера и запускать новый, либо просто запускать новый. Поэтому я хотел, чтобы он просто делал это для меня каждый раз. Каждый раз, когда он вносит изменения, он запускает для меня новый сервер и открывает окно от моего имени. Другая проблема, с которой я столкнулся, заключалась в том, что я бы говорил ему внести обновление, и вместо того, чтобы искать существующий код для эволюции или итерации, он просто писал совершенно новый код, чтобы удовлетворить мой запрос. Поэтому я всегда хотел сначала посмотреть на существующий код и посмотреть, можно ли его изменить, прежде чем писать новый код. И я много раз сталкивался с этой проблемой. Поэтому я действительно собрал несколько из этих правил вместе, чтобы убедиться, что он смотрел и пытался использовать существующие шаблоны, прежде чем изобретать новые. "Не изменяйте резко шаблоны, прежде чем пытаться итерироваться по существующим шаблонам". У меня также есть такие вещи, как: "Всегда предпочитайте простые решения, избегайте дублирования кода". Очевидно, он должен делать это по умолчанию, но я обнаружил, что уделение большего внимания этому с помощью правил просто заставляет его писать лучший код. Вот очень важный для меня: "Пишите код, который учитывает разные среды: разработку, тестирование и производство".
Так что просто очень краткий обзор того, что это значит, но, конечно, если вы хотите более подробно узнать, спросите Grok, спросите Claude, они объяснят. Среда разработки означает среду, в которой вы кодируете. Когда вы открываете localhost и видите запущенный код, это ваша среда разработки. Ваша тестовая среда – это среда, которую используют ваши тесты, и мы ещё не рассматривали тесты, я доберусь до этого через несколько минут. А ваша производственная среда – это то, что вы будете развёртывать, и мир увидит. Поэтому вы относитесь ко всем трём из них отдельно. И опять же, если вы не знакомы с кодированием, вам может быть непонятно, почему вам нужны эти три среды, но я призываю вас понять это, попросите ИИ объяснить, в каких случаях вам могут понадобиться разные среды.
Затем у меня есть некоторые правила, которые я ввёл после многого vibe-кодирования и просто заметив тенденции, особенно Claude 3.7 Thinking, где он бы делал вещи, и я думал: "Нет, мне не нравится, как ты это делаешь, убедись, что я не буду делать этого в будущем". И я бы замечал это, записывал это как правило, и тогда он больше этого не делал. Вот одно: "Избегайте написания сценариев в файлах, если это возможно, особенно если сценарий, вероятно, будет выполнен только один раз". Если мне нужно было что-то изменить, и ИИ написал для этого скрипт, он бы записал его в файл, и файл оставался бы там навсегда, и я бы просто находил все эти скрипты, которые я никогда не использовал более одного раза. Поэтому я не хотел, чтобы он делал это. Просто запустите скрипт самостоятельно в консоли или удалите файл после того, как закончите с ним.
Теперь вот действительно важный момент: вы хотите, чтобы ваши файлы были очень короткими. Я сказал от 200 до 300 строк кода, вы можете даже сделать 100 строк кода. Это просто делает код более модульным, это также позволяет ИИ писать и итерировать код быстрее. Некоторые из вас в моём последнем видеоуроке по Vibe-кодированию попросили этот файл, поэтому я помещу его в gist и оставлю его внизу в описании. Это все правила рабочего процесса, это все общие правила, которые я всегда хочу, чтобы мой помощник по кодированию ИИ следовал, но есть некоторые правила и лучшие практики, которые специфичны для языка программирования, и позвольте мне показать вам, где их найти. Я нашёл этот потрясающий репозиторий на GitHub, и он называется awesome-cursor-rules. Он относится не только к Cursor, но и к Windsurf, и это просто файлы Markdown, которые специфичны для языков программирования и просто излагают лучшие практики в зависимости от вашей среды или вашего языка программирования.
Если вы немного прокрутите вниз, вот фреймворки и библиотеки front-end. Допустим, вы решили использовать React, который является библиотекой JavaScript front-end. Нажмите на него, и вот множество правил, которым нужно следовать. Это просто лучшие практики, специфичные для языка программирования. Если мы вернёмся назад, мы можем найти back-end и full-stack. Вот Python с FastAPI, множество отличных правил: используйте функциональные компоненты, используйте декларативные определения маршрутов. Если вы никогда раньше не программировали, вы можете не знать, что всё это значит, но вы можете использовать это. Они предварительно проверены, и если они включены в эти awesome-cursor-rules, они, как правило, довольно хороши.
Хорошо, теперь давайте поговорим об общем рабочем процессе Vibe-кодирования. Помните, первое, что вы собираетесь сделать, это сохранить план проекта и список дел. Я взял план проекта из Grok, пришёл сюда и скажу: "Создайте файл под названием prd.md и поместите это в него". И я просто вставил его. Очевидно, вы можете сделать это вручную, но я использую подход vibe-кодирования, действительно не писать никакого кода сам, и вот он, prd.md, хорошо отформатированный. Так что теперь у нас есть план проекта. Следующее, что мы собираемся сделать, это создать файл to-do.md.
Вернёмся к Grok, я выберу всё это. Мне не нужны вещи после запуска, потому что опять же мы просто vibe-кодируем, поэтому я не думаю о получении отзывов пользователей и всех этих вещей. И так я скажу: "Теперь создайте to-do.md с этим", и вставил его, нажал Enter, и он создаст этот файл. И вот он, вот файл to-do. Так что мы можем принять код. Теперь у нас есть план проекта и наш список дел. Теперь общий рабочий процесс, которому вы будете следовать, таков: вы будете заставлять своего помощника ИИ читать ваш план проекта, читать список дел и разрабатывать одну вещь за раз. Я не могу достаточно подчеркнуть это: одну функцию за раз.
Первоначально, когда вы только начинаете свой проект, ему, возможно, придётся создавать своего рода структуру для выполнения многого из этого, поэтому это будет больше, чем одна, но после этого, когда вы добавляете в него вещи, одна за раз. Далее, как только вы добавите функцию, вы добавите тесты. Если вы никогда в жизни не программировали, просто подумайте о тестах как об отдельном коде, который убеждается, что ваш фактический код работает так, как ожидалось. Это очень важно – писать тесты по ходу дела и на каждом шаге, потому что как только у вас будет код, который работает так, как вы ожидаете, вы убедитесь, что он работает с помощью этих тестов, и в будущем, когда вы вносите изменения, если какой-либо из этих тестов ломается, это говорит вам, что функциональность, которая у вас была ранее, больше не работает так, как ожидалось, и в этот момент вы можете либо изменить тест, чтобы обновить его на основе изменённой функциональности, либо вернуться назад и исправить то, что, возможно, было сломано. Все эти вещи могут быть сделаны вашим помощником по кодированию ИИ.
Хорошо, вот небольшая забавное моделирование, с которым я игрался вчера. Позвольте мне показать вам, как выглядит написание теста. Я просто говорю: "Напишите тест, чтобы убедиться, что это приложение работает так, как ожидается". Хорошо, мы видим, что Windsurf написал для нас множество тестов. Если мы посмотрим на левой стороне, здесь, в тестах, мы видим все написанные тесты. Все тесты готовы, давайте запустим их. Запустим тесты. После того, как все тесты были запущены, мы видим, что есть 11 неудачных тестов, и так как это наш первый раз, когда мы пишем тесты, вы можете сказать: "Исправьте тест". Когда вы начнёте, вы можете сделать дополнительный шаг, сказав: "Объясните, почему тест не пройден, и решите, хотите ли вы исправить тест или исправить фактический код, который сломал тест". Но это общий поток, а затем, как только все ваши тесты пройдут, вы делаете коммит. Это команда Git. Вы просто говорите: "Сделайте коммит кода". Поэтому он пройдёт весь процесс поиска всех изменённых файлов, их коммита, написания сообщения о коммите, а затем, если у вас есть GitHub, отправьте его на GitHub.
Давайте ещё раз пройдёмся по общему потоку. Обратитесь к плану, проверьте свой список дел и создайте следующую функцию. Затем напишите тесты для новой функции. Затем запустите тесты для этой функции. Если всё прошло успешно, отлично, переходите к следующему шагу. Если нет, исправьте тест. Затем запустите тест для всей кодовой базы. Если все тесты пройдут, отлично, переходите к следующему шагу. Если нет, исправьте тест, который не прошёл. Затем сохраните свой код, сделав коммит в Git. Затем промойте и повторите. Делайте это снова и снова. Это общий поток, но иногда ваш код доходит до состояния, которое просто невозможно исправить. Иногда ИИ делает это, он просто ломает ваш код, и вы ничего не можете сделать. Поэтому вам нужно будет откатиться к предыдущему коммиту. Это просто означает, что все новые изменения, которые вы только что внесли, будут стёрты. Вы можете сохранить их, если хотите, это называется git stash, и вы можете использовать это тоже. И опять же, всё это вам на самом деле не нужно знать команды Git для этого. Вы просто говорите своему ИИ сделать это. Но в противном случае вы говорите: "Откатитесь к предыдущему коммиту", и это избавит вас от всего вашего недавнего кода и вернётся к стабильному месту, которое, как вы знаете, работало.
Хорошо, теперь я хочу рассказать вам несколько дополнительных вещей, которые просто улучшат ваш опыт кодирования, а также дадут вам больше возможностей. Во-первых, я хочу поговорить о режиме чата и режиме записи. Запись означает, что он будет писать код, и вы можете попросить его не делать этого, но если вы находитесь в режиме записи, вы в основном хотите, чтобы он писал код за вас. Теперь, если вы переключитесь в режим чата, это просто задавание вопросов. Это по сути то же самое, что и прямой чат с большой языковой моделью, за исключением того, что вы также предоставляете контекст вашей кодовой базы. Вы также можете выбрать все разные модели, которые хотите использовать прямо здесь. Теперь я обнаружил, что Claude – лучший кодер. Многие люди говорят, что Cloud 3.5 всё ещё лучший, но мне очень нравится Cloud 3.7 Thinking.
Одна вещь, которую я заметил в последнее время, это то, что ИИ на самом деле не может кодировать красивые front-end. Он может кодировать действительно базовые вещи, и это здорово, но если вы хотите чего-то действительно красивого, лучший способ сделать это – это на самом деле найти бесплатный шаблон в Интернете, со всеми дизайнами, уже созданными для вас, а затем просто загрузить его, поместить его в свою папку, рассказать ИИ об этом и сказать: "Хорошо, теперь я хочу создать это, используйте все компоненты, которые можно найти в этой библиотеке". Просто поищите бесплатные темы Bootstrap или что-то в этом роде, и вы сможете найти это. Все эти маленькие компоненты, графики, диаграммы, шрифты – всё предопределено. Вы можете купить это здесь, вы можете найти много бесплатных тоже.
Ещё один совет – давать своему агенту конкретные части кода, которые вы хотите обновить или исправить. Очевидно, вам нужно иметь хорошее понимание вашей кодовой базы, чтобы иметь возможность сделать это, но вы делаете это, просто набирая "@" и вы можете добавлять файлы, каталоги, документы, контекст и веб-ссылки. Так что не забывайте, что вы можете это сделать. Я видел, как много людей vibe-кодируют игры, и они в основном используют эту библиотеку под названием 3.js. Это 3D-библиотека JavaScript. Большинство ИИ уже умеют её использовать, и она сейчас переживает свой момент. Так что это действительно крутая библиотека, обязательно проверьте её. И чтобы сослаться на неё, вы можете просто сделать: "Создайте мне игру X, а X описывает игру, используя 3JS", и она будет использовать эту библиотеку.
Теперь давайте поговорим о безопасности и поддержке. Я видел, как многие традиционные программисты очень негативно отзываются о Vibe-кодерах, потому что они говорят, и, вероятно, справедливо, что этот код не будет поддерживаться, и код действительно небезопасен, то есть как только вы выложите его, вас взломают, ваш пароль будет украден, вы будете атакованы DDoS, потому что вы просто не знаете, как человек, который, возможно, никогда в жизни не программировал, некоторые из этих лучших практик. Есть несколько вещей, которые можно сделать здесь, чтобы помочь себе. Во-первых, обязательно потратьте некоторое время на изучение некоторых лучших практик, но это также хорошее время для использования правил. Добавьте правила: никогда не делайте этого, всегда делайте это, и это лучшие практики, но как вы узнаете, что это лучшие практики? Ну, вы можете попросить ИИ написать это для вас. Но этот человек, Джек Фрикс, также подготовил несколько действительно полезных советов, и вы можете найти больше в Интернете. Например, ограничение скорости всех конечных точек API, использование безопасности на уровне строк, всегда захват на всех маршрутах аутентификации и страницах регистрации и так далее. И их гораздо больше, чем эти несколько, но вы можете найти их, вы можете искать их в Интернете, вы можете спросить Perplexity, вы можете спросить Claude и просто получить список этих лучших практик и убедиться, что вы их используете, а затем также добавить их как правила.
Давайте поговорим о поддержке. Да, код ИИ не всегда красив, но просто имейте в виду, что это худшее, что когда-либо будет.
Это только начало, будет лучше. И когда вы создаёте кодовую базу, если вы занимаетесь vibe-кодингом и на самом деле не знаете, как кодить, это может оказаться довольно хрупкой кодовой базой. Но знаете что? Это нормально, это часть процесса обучения. И вы можете попросить ИИ рефакторить ваш код. Рефакторинг просто означает сделать его более лаконичным, более модульным, не использовать дублирование кода и другие лучшие практики. И опять же, всё это добавляется в файл правил, который у вас есть. Вы также можете попросить ИИ провести для вас аудит безопасности: просто посмотрите весь мой код и скажите мне, где я уязвим с точки зрения безопасности. Вот ещё несколько лучших практик для безопасности. Это от Теда Уорбла. Не делитесь фотографией, подобной той, что ниже. Поэтому, каждый раз, когда у вас есть ключи API, это ключи прямо здесь, не делитесь ими публично. Я не могу достаточно подчеркнуть это. Эти ключи, даже на изображении, могут быть взяты, и они будут использовать ваши кредиты на любом API, который вы используете. Вы также никогда не захотите сохранять свои ключи в Git. Для этого и существует файл .gitignore.
Если всё это звучит для вас как абракадабра, не волнуйтесь, просто попросите ИИ объяснить это вам. Он также рекомендует использовать npm run audit, если вы используете node-приложение. Он также рекомендует: не создавайте свою собственную аутентификацию – это отличный совет практически для всего. Не создавайте своё собственное ничего, если это действительно не нужно. «Создать своё собственное» означает построить своё собственное. Используйте что-то вроде Clerk, настройте IP-адреса, лимиты на основе пользователей, защиту от DOS-атак, брандмауэры, мониторинг и аналитику. И опять же, используйте ИИ, чтобы узнать всё это. И вот в чём дело с vibe-кодингом: вам не обязательно нужно всё это изучать, но это приятно. Я нахожу все эти вещи такими интересными, я люблю кодить с подросткового возраста. Поэтому, надеюсь, с vibe-кодингом вы познакомитесь с этим и полюбите это тоже. И всегда пишите автоматизированные тесты для частей вашей кодовой базы, где цена сбоя высока, например, платежи, управление подписками, отслеживание использования и т.д. Отличные советы от Теда, спасибо.
Теперь последнее, о чём я хочу поговорить, это MCP-серверы. Если вы не знакомы с MCP, это способ предоставить вашим агентам дополнительные инструменты. Вы можете настроить MCP-сервер прямо здесь, в Windsurf. Вы нажимаете на него, и вы можете попросить ИИ помочь вам это написать. Но вы можете добавить действительно крутые инструменты к вашему агенту ИИ. И позвольте мне показать вам пару крутых примеров. Это от Билавала, это Unity MCP. Итак, это инструмент, который может по сути подключаться прямо к Unity. Давайте посмотрим. Теперь у него есть прямой доступ к Unity, и вы по сути занимаетесь vibe-кодингом в Unity. Это довольно круто. Так что вам на самом деле не нужно уметь использовать Unity. И опять же, если вам действительно нравится Unity и вам действительно нравится создавать эти 3D-модели, начните изучать это, занимаясь vibe-кодингом. Вот ещё один пример использования инструмента Firecrawl MCP. Посмотрите. Он проводит глубокое исследование, Firecrawl – глубокое исследование. Так что теперь ваш агент ИИ в Windsurf, в курсоре, может выйти, использовать этот инструмент Firecrawl и получить кучу информации. Вот и всё. Поэтому обязательно экспериментируйте с инструментами MCP. Это скорее расширенная функция, когда вы действительно хорошо освоите vibe-кодинг, но я рекомендую это.
Вот и всё. Надеюсь, вы много узнали о vibe-кодинге. Я призываю вас попробовать vibe-кодинг. Если вы опытный программист, это просто весело и расслабляюще. Если вы только учитесь, это отличный способ познакомиться со всем этим и начать свой путь обучения. И если вам понравилось это видео, пожалуйста, поставьте лайк и подпишитесь, и увидимся в следующем.