Секрет эффективного вайбкодинга - документация для нейросетей

Давайте немного разберёмся с документацией, которую мы пишем для нейронок, потому что именно в ней кроется вся магия эффективного вайбкодинга. И, например, вот такой

вайбкодинга. И, например, вот такой лендинг был сделан буквально за один промт, основываясь на подготовленной документации. Даже если это не финальный

документации. Даже если это не финальный вариант, то неплохая точка отчёта, чтобы доделать и пустить в prodдаction.

Лендинг для validated Vibe, сервис, который мы вайп-кодим с вами в других видео, я сделал аналогичным образом.

Точно также на основе документации, промтами. Ну, тут, конечно, я потратил

промтами. Ну, тут, конечно, я потратил немного больше времени на доработку, но в целом вы можете заметить, что структура практически такая же, как в лендинге, который был сделан за один

промт. Ну разве что немножко подправлена

промт. Ну разве что немножко подправлена э структура и визуал. Хотя карточки

здесь выглядят, может быть, даже интереснее, чем у меня. Собственно, вот

он весь промт, который был задан нейронке для создания лендинга.

Основываясь на документации, создай landing page в папке frontend. Мы её с вами скоро удалим и сделаем это заново.

Сейчас давайте перейдём непосредственно к документации. Панель с иишкой я пока

к документации. Панель с иишкой я пока скрою. А здесь в структуре папок можно

скрою. А здесь в структуре папок можно увидеть четыре папки: курсор, backend, doc, frontend. Фн и backend мы пока что

doc, frontend. Фн и backend мы пока что трогать вообще не будем. Документация у

нас лежит в доксах, а в курсорах у нас лежат правила. Так вот, в правилах

лежат правила. Так вот, в правилах указаны м общие правила по разработке.

Ну, что-то типа пиши чистый код и пояснение, что такое чистый код. Э в

мейне указаны пути до документации, которую мы сейчас будем разбирать, и описание, что это за файл, когда в него смотреть. Также у нас есть описание

смотреть. Также у нас есть описание проекта, который мы программируем.

Напоминаю, что Validated Vipe, который мы вместе с вами делаем - это сервис для поиска прибыльных идей, которые можно завайпкодить, на которые есть спрос, и

тем самым не билдить проекты, которые никому не нужны. Вместе с этим в результате мы как раз-таки будем получать там практически всю документацию, про которую мы сейчас будем говорить, но это будет немного

позже, когда мы закончим с этим проектом. А, в общем, main здесь в

проектом. А, в общем, main здесь в основном ссылка на документацию.

Документация документация документация. Вот и всё. Описание

документация. Вот и всё. Описание

проекта. Tailwin 4 - это файлик с правилами для написания Тейвинда в четвёртой версии. У них в четвёртой

четвёртой версии. У них в четвёртой версии обновилась структура вообще стилей. И курсор далеко не всегда

стилей. И курсор далеко не всегда понимает, что нужно писать по-другому.

Использует подходы из Тайлвенда третьего. И, собственно, они не

третьего. И, собственно, они не работают. Ссылки на ресурсы с правилами,

работают. Ссылки на ресурсы с правилами, в частности, для Tailн четвёртого и в целом для разработки, для курсора, я опубликовал у себя в Telegram-канале Годный Вайб-кодинг. Ссылка на пост в

Годный Вайб-кодинг. Ссылка на пост в описании. Переходите, смотрите,

описании. Переходите, смотрите, подписывайтесь. Давайте перейдём к

подписывайтесь. Давайте перейдём к основной папке Docs. В ней у нас хранится документация по маркетингу и девелопменту. В маркетинге мы описываем,

девелопменту. В маркетинге мы описываем, кто наша целевая аудитория, какая у них есть проблема. как мы её решаем и сколько мы просим за это денег.

Желательно перед тем, как это всё писать, провести необходимый resarch рынка. Можно это сделать с помощью

рынка. Можно это сделать с помощью нейронок. Также мы делаем, собственно,

нейронок. Также мы делаем, собственно, интерфейс validated vibe, с помощью которого это всё будет автоматизировано.

И на выходе вся эта документация будет в готовом виде. Её можно будет просто

готовом виде. Её можно будет просто скачивать и там править по мелочи, если это вдруг нужно. Но давайте вкратце. Э,

все файлы мы сейчас разбирать не будем, потому что все файлы, ну, достаточно большие, и проходиться полностью по ним будет тяжеловато. Я сейчас вкратце

будет тяжеловато. Я сейчас вкратце расскажу, что вообще нужно указать, потому что, на самом деле, вы можете указывать это в произвольной форме, не обязательно придерживаться там какого-то одного формата. Но ещё раз, стоит

одного формата. Но ещё раз, стоит указать нашу целевую аудиторию, стоит указать их проблему, которую мы решаем, и написать, как мы её решаем, то есть описать какой-то вот функционал. Это у

нас находится в PRD product requirement document, то есть здесь уже более техническим языком у нас описывается наше решение, наши фичи, которые мы

будем пилить. Но пока что мы здесь

будем пилить. Но пока что мы здесь сильно глубоко в код не лезем. Ну и

вообще его, наверное, здесь пока не обязательно даже писать. Э желательно

описать просто функционал, который мы хотим реализовать в нашем сервисе, приложении. Ну, может быть, какую-то ещё

приложении. Ну, может быть, какую-то ещё дополнительно техническую документацию здесь указать. Но основная техническая

здесь указать. Но основная техническая документация у нас будет в папке девелопа. А так, пока что закрываем. У

девелопа. А так, пока что закрываем. У

меня здесь лежит ещё файлик сравнения платного и бесплатного планов тарифных для сервиса. Ну, это, в принципе, не

для сервиса. Ну, это, в принципе, не обязательно, но поскольку я его написал, я его здесь оставил. Также здесь ещё есть папка с ресерчем. Аэ, здесь есть,

э-э, некая визуализация, э- действий нашей целевой аудитории, что, э-э, просто наглядно демонстрирует, какую проблему мы решаем. Собственно,

девелоперы что-то разрабатывают, тратят на это кучу времени, а потом оказывается, что это никому не надо.

Это, в общем-то, не очень хороший подход. гораздо лучше сначала проверять

подход. гораздо лучше сначала проверять э нишу, сначала искать и валидировать проекты, после этого уже основываясь на этой документации, делать проект - это и

проще, и эффективнее, и шансов, что проект никому не нужен, гораздо меньше.

Возвращаемся. Также есть ещё в маркетинге у нас описание болевых точек, поскольку у нас целевая аудитория в данном проекте Вайп-кодеры, мы здесь описываем болевые точки вайп-кодеров, которые хотят запустить свой проект.

Ладно, от маркетинга пока что мы отойдём. Э, суть, я думаю, понятна. Это

отойдём. Э, суть, я думаю, понятна. Это

можно делать в произвольной форме. Файлы

можно называть тоже по-своему. Писать

лучше на английском, потому что английский язык требует меньше токенов для обработки. А поскольку это те файлы,

для обработки. А поскольку это те файлы, которые будут каждый раз прикрепляться к основному промту, то, мм, чтобы не занимать весь контекст окна, лучше писать на

английском. Больше информации влезет в

английском. Больше информации влезет в окно. О'кей, переходим к папке

окно. О'кей, переходим к папке Development. В папке developпмен у нас

Development. В папке developпмен у нас уже гораздо более техническая документация по разработке. Вот на

неё-то в основном наша нейронка и будет основываться, когда она будет пилить нам ндоOS за один промт, ну или сервис за несколько промтов. Ну, может быть,

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

эта документация нам очень сильно поможет. Я думаю, вы и так уже

поможет. Я думаю, вы и так уже понимаете, что чем больше информации и конкретики мы даём нейронке, тем лучше получается результат. Это работает не

получается результат. Это работает не только с неронками, но и с людьми. В

целом, э, любому сотруднику, естественно, лучше дать как можно более точное задание. Так вот, чтобы не писать

точное задание. Так вот, чтобы не писать нам каждый раз кучу информации в этих промтах, гораздо проще сделать папочку с документацией, записать туда один раз всё и пусть Неронку туда смотрит. Так

вот, что у нас здесь находится. У нас

есть папка backend, frontend, landing, cradmap, wireframes. Ну, папки могут

cradmap, wireframes. Ну, папки могут быть, опять же, произвольны, я их разделил так. То есть в бэкэнде у нас

разделил так. То есть в бэкэнде у нас документация для серверной части, во фронтде для части во фронтде. Причём это

сейчас основной файл, но можно здесь дополнять ещё, делать дополнительные файлы, э, с более какими-то уточняющими э документациями. То есть, если вам

э документациями. То есть, если вам нужно для какой-то конкретной библиотеки или какого-то конкретного процесса или конкретной фичи что-то описать, ну, можно создать отдельный файл, тогда у вас будет просто лучше разбита

архитектура. Пока что у нас здесь по

архитектура. Пока что у нас здесь по одному файлу во фронтнде, в бэкэнде, э, чтобы не перегружать вас, потому что и так достаточно много информации. О'кей.

А лендинг. В лендинге у нас описан такой произвольный гайд по визуальной визуальному отображению и эмоциональному, так сказать. воздействию

на человека, что пользователь должен чувствовать, когда он заходит на этот лендир. Ну, это тоже помогает нейронке

лендир. Ну, это тоже помогает нейронке при выборе каких-то цветов или каких-то других компонентов.

Аэ сюда, опять же, глубоко пока что лезть не будем. На самом деле большая часть этой документации сгенерирована с помощью клода. Конечно, я потом

помощью клода. Конечно, я потом прошёлся, посмотрел, поудалял лишнее, но всё-таки ээ какой-то стартовый файл проще писать не с нуля, а когда клод

накидал какую-то базу. О'кей. Э-э, чуть

позже, может быть, к этому вернёмся.

Дальше у нас есть Roadmap. Вот здесь

хочу немножко заострить ваше внимание, потому что у нас есть, ээ, описание всего функционала, у нас, ээ, есть какое-то описание технических

требований, но чтобы нейронка лучше понимала, в какой последовательности всё это выполнять, и чтобы она могла фокусироваться на задачах, лучше предоставить ей какой-то Roadmap.

Roadmap выглядит, ну, примерно следующим образом. Опять же, он может быть

образом. Опять же, он может быть примерно, ну, в произвольном формате.

желательно в формате маркдауна, то есть там со всякими заголовками, выделениями, потому что, ну, неронка это вроде как понимает. Поэтому здесь мы можем как-то

понимает. Поэтому здесь мы можем как-то лучше структурировать именно этот текстовый файл. Хотя, в принципе, если

текстовый файл. Хотя, в принципе, если бы он был в TXT, ну, я думаю, там не принципиально, ну, в Маркдауне и нам с вами это удобнее, потому что можно сделать вот так и посмотреть это в

человеческом виде. Ну, давайте так и

человеческом виде. Ну, давайте так и глянем. Собственно, это Radmap. Здесь у

глянем. Собственно, это Radmap. Здесь у

нас описано, ну, какие-то примерный план, фазы. Первая, четвёртая, первая,

план, фазы. Первая, четвёртая, первая, вторая, третья, четвёртая. Ну, недели,

конечно, это написала неронка. На самом

деле это делается гораздо быстрее с помощью и агента. Там гораздо меньше, чем 1.4 VIк. А, о'кей. Ну и здесь, собственно, да, вот фаза первая. Мы

здесь делаем usр интеграцию юзера, логин, сессии для авторизации. Потом на второй фазе мы

авторизации. Потом на второй фазе мы делаем core validation. Это, ну,

validation engine - это, собственно, механизм валидации, про который я говорил. Поиск идей. валидации их, ну,

говорил. Поиск идей. валидации их, ну, типа, есть ли на это спрос, готовы ли люди за это платить или, может быть, столько, сколько они готовы за это платить, не устроят нас и не окупит нам вообще никак не разработку, ни

привлечение новых пользователей. Ну,

поэтому, да, э движок валидация делаем.

Потом третья фаза - это делаем анализы, репорты. Ну, короче, в каждом проекте

репорты. Ну, короче, в каждом проекте Roadmap будет, естественно, свой.

Желательно просто разбить это всё на какие-то этапы, разбить на задачи.

Причём потом, э, если проект большой, то можно даже эти этапы отдельно вот разбивать по задачам в каких-то отдельных файлах. Вот пока что я это

отдельных файлах. Вот пока что я это сделал в одном. У меня здесь это заняло 400 почти строк кода. Ну, э что есть, то есть, его можно было бы разбить, можно

было бы не разбивать, но, в принципе, неронка с этим справится. О'кей. Суть.

Делаем, в котором описываем этапы и задачи в каждом этапе. Можно, а,

наверное, даже лучше разбивать этот roadmap. Ну, можно в одном файле, но

roadmap. Ну, можно в одном файле, но разбивать на категории, что вот по фронтэнду вот это надо в этом этапе сделать, по бэкэнду вот это в этом этапе надо сделать, чтобы она их не путала вместе, чтобы она сначала там занималась

фронтэндом, потом бэкэндом или наоборот.

Аа чем лучше, и точнее вы это распишите, тем лучше она будет понимать, в общем-то, последовательность процессов и что в каких ээ этапах нужно делать

во фронтнде, в бэкэнде, в общем, все задачи. О'кей. И дальше у нас есть папка

задачи. О'кей. И дальше у нас есть папка Wireframes. Здесь у нас есть два

Wireframes. Здесь у нас есть два Wфрейма. По сути, это макеты, ну, без

Wфрейма. По сути, это макеты, ну, без визуальной составляющий. Сейчас вы

визуальной составляющий. Сейчас вы поймёте, о чём я говорю. Например,

посмотрим лендинг. Э, вот так выглядит макет лендинга. Сейчас мы обратим с вами

макет лендинга. Сейчас мы обратим с вами внимание, что итоговый лендинг выглядит примерно так же. То есть, ну, точнее, не примерно, а по содержанию он выглядит практически один в один, как этот wireframe.

Смотрим. Validated wipe, stop builting products, nobody want ons wants и так далее. Здесь он, конечно, написал это

далее. Здесь он, конечно, написал это огромными буквами, но stop building product, nobody wants. Yes, дальше идёт какое-то описание, идут кнопки getма,

пожалуйста, вот эти кнопки и так далее.

То есть так каждый блок лендинга у нас расписывается. Здесь расписывается

расписывается. Здесь расписывается текст, расписываются заголовки, расписываются какие-то эмодзи. Ну,

эмодзи можно заменить потом на иконки. В

принципе, нейронка с этим тоже вполне справится. Просто сказать ей, где взять

справится. Просто сказать ей, где взять иконки. Там можно скинуть ей конкретную

иконки. Там можно скинуть ей конкретную библиотеку, которую вы можете поискать там, например, для React JZ или ещё для чего-то, какой-нибудь там или что-то

ещё, не суть. Э-э, про варфреймы. Очень

классная штука. Почему с ней можно работать как самому, так и нейронкой. То

есть, допустим, мы можем открыть чат с нейронкой, ээ, создать там новый чат, да, и попросить, э-э, да, всё поехало из-за того, что ширины не хватает, и попросить нейронку заменить что-нибудь

там в каком-то блоке, да, там вот взять и сказать там поменяй что-нибудь, ээ, сделай другой текст или что-то ещё. То

есть здесь можно работать с вот этими макетами, э, информационными без визуала, но редактировать содержимое, разбивать по блокам. Собственно,

очевидно, я тоже не руками делал эти варфреймы. Я максимум какие-то слова

варфреймы. Я максимум какие-то слова здесь поменял, но в основном это всё было сделано с помощью клода. Можно

делать это в курсоре, можно делать это в приложении клода. В целом без разницы,

приложении клода. В целом без разницы, хоть в чате GPT, хоть где. Я думаю, что, э, такую аски визуализацию любая нейронка, практически лэмка

поймёт. Просто просите создать аски

поймёт. Просто просите создать аски визуализацию там для лендинга.

О'кей. Аа, собственно, я думаю, вы уже, ну, потихонечку начинаете чувствовать и понимать, да, что мы большую часть работы подготовительной здесь уже сделали. То есть, э, неронки не нужно

сделали. То есть, э, неронки не нужно думать, какую информацию ввести на лендинге, какие блоки там сделать, какие сделать. Кнопки какого цвета? Кстати,

сделать. Кнопки какого цвета? Кстати,

вот к этому сейчас давайте вернёмся, да, потому что, да, вот здесь мы описали ей информацию, разделили всё по блокам, это она поняла, всё круто, но дальше, а,

далеко не всегда нейронка генерит что-то красивое, даже если вы попытаетесь ей объяснить это в двух словах, что типа сделай мне красивый лендинг или сделай мне там гласморфизм или неоморфизм, ну,

она не всегда это понимает, не всегда понимает это так, как нам хочется.

Поэтому, э, конкретно в этом примере я решил, во-первых, сам попробовать, убедиться, что это действительно работает, показать вам следующее. У нас

здесь есть файл design requirements.

Design requirements. Ну, я даже пока не буду в него сейчас детально углубляться, я просто расскажу, как я его сделал. Я

зашёл в кт и попросил его поискать информацию о гласморфизме и сделать гайд по этому. Потому что если я просто

по этому. Потому что если я просто напишу в курсор, сделая в стиле глаз морфизма, он не всегда это понимает.

Иногда он делает это достаточно топорно.

Поэтому нужно им объяснить, что такое глазморфизм. Клод посмотрел кучу

глазморфизм. Клод посмотрел кучу каких-то сайтов, выявил основные принципы и подходы в глаз морфизме, описал, что это такое, сделал мне вот такой вот файлик, я его скачал. Тут у

нас записаны какие-то CSS-стили, какой-то, ну, вот background blurр, какой-то конкретный бэкграунд, как нам делать бордеры и так далее. Ну, в

принципе, фундаментально нам этого достаточно. То есть дальше описаны

достаточно. То есть дальше описаны какие-то дизайн-принциплы, что вот это там стекло, оно имеет какой-то прозрачность в Лайтмоде такое-то, в дармоде такое-то, ну, какие-то там

соотношения он делает. В общем, описал примерно, что такое глазморфизм текстом, потому что не всегда картинки, их тоже можно прикладывать в курсор как

референс, но не всегда он воспринимает их так, как нам бы хотелось. Поэтому

описываем, что такое гласморфизм текстом. Качаем этот файл. Ну, здесь он

текстом. Качаем этот файл. Ну, здесь он его немножко переделал. Тут был в общем-то прямо один в один вот этот файл. Я ему сказал: "Блин, посмотри вот

файл. Я ему сказал: "Блин, посмотри вот сюда, сделай этот гит для разработки, ну и поменять там в документации, если там что-то было не сказано об этом, чтобы это было указано именно вот так он это

сделал". В итоге получился вот такой

сделал". В итоге получился вот такой design requirements document. Э, точно

также можно сделать там с каким-нибудь неоморфизмом, с минимализмом, там с брутализмом, с чем угодно. Эн, в

принципе, это сможет сделать. Здесь у

нас получается есть описание стилистики.

А, да, и всё, в общем-то. Основываясь на

этом, курсор уже генерирует что-то интересное. Что-то интересное вы уже

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

для дальнейшей реализации. Точно также

через промты э можно это всё дальше докручивать. О'кей. Возвращаемся к нашей

докручивать. О'кей. Возвращаемся к нашей документации. documentation git. Вот

документации. documentation git. Вот

здесь э да, я даже забыл немножко, что он писал здесь. Э, что я с нейронкой здесь писал.

здесь. Э, что я с нейронкой здесь писал.

А, да, в общем, тоже просто как что внедрять. Давайте так на этом

внедрять. Давайте так на этом остановимся. Тут про MCPхи с кдом он

остановимся. Тут про MCPхи с кдом он что-то пишет, технические документации.

Давайте немножко посмотрим а другие файлы. О'кей. Core Business Logic Spec.

файлы. О'кей. Core Business Logic Spec.

А здесь у нас описана бизнес-логика. То

есть, ээ, у нас есть workflow. Ну, ой,

чат нам не нужен. У нас описано workflow пользователя, да, что у нас есть первая стадия - это мы, э, Market Discovery и ICP Creation. То есть мы изучаем Market,

ICP Creation. То есть мы изучаем Market, изучаем ниши, которые подходят пользователю на основе его персональных данных, чтобы максимально подходящую нишу ему подобрать, максимально подходящих подходящую целевую аудиторию

подобрать, с которыми ему будет комфортно работать, для которых ему комфортно будет делать продукт. А после

этого идёт, что у нас дальше идёт? Stage

2 - это идея проекта, валидация и генерация Go to Market стратегии. Ну, на

самом деле, помимо Go to Market стратегии, там ещё генерируется пачка э промтов и инструкций, вот по типу таких, которые мы сейчас с вами разбираем.

Просто их не нужно писать там руками самостоятельно, нам архивчиком, ну или по файликам это всё будет генерироваться. Это мы с вами уже

генерироваться. Это мы с вами уже сделаем в других видосах. посмотрим, э,

уже детально в них. Вот. Э, собственно,

да, здесь идёт документация по э бизнес-логики. Здесь описывается наш

бизнес-логики. Здесь описывается наш функционал, какие-то данные, которые нам будут приходить, в каком формате они будут приходить. На самом деле формат

будут приходить. На самом деле формат здесь упарываться не обязательно пока что, да. Для этого можно отдельный

что, да. Для этого можно отдельный какой-то файлик создать по форматам, по структурам там моделей в базе данных, если вам это надо, потому что не все вообще готовы э заниматься тем, чтобы

придумывать эти модели, придумывать форматы вопросов-ответов. Если вы не

форматы вопросов-ответов. Если вы не хотите это делать, ну, например, вы вообще не разбираетесь в базах данных, то лучше не надо этого делать. Ну, то

есть неронка с этим, в принципе, неронка разберётся. Самое главное ей описать,

разберётся. Самое главное ей описать, что мы делаем, описать ей, какой функционал мы реализуем. И этого ей будет уже достаточно, чтобы, основываясь на это, на этом подробном описании,

самостоятельно придумать все эти форматы. Либо вы можете вместе с ней

форматы. Либо вы можете вместе с ней просто посидеть и эти форматы нагенерировать, основываясь опять же на тех же самых документах, там по маркетингу ээ с нашей Product requirement documents, да, посидеть в

общем, скинуть ей всю инфу, которая у вас есть, и сказать: "Блин, давай продумаем теперь форматы вопросов-ответов, там какие нам нужны ээ какая нам нужна информация от пользователя там, ну или что вы делаете там в своём проекте". То есть, ээ,

разобраться с этим. Ещё раз, это то, на что реально стоит уделить время. В

начале я занимался этой документацией в течение там 2 недель, наверное, а программировал лендинг там в течение 2ву дней. И потом мы с вами делаем на видео

дней. И потом мы с вами делаем на видео уже непосредственно сам этот сервис интерфейса. Ну, сколько там на видосах,

интерфейса. Ну, сколько там на видосах, там где-то час-полтора. И у нас уже есть какой-то MVP, ну, интерфейса пока что нерабочего, но час-полтора. Камон, это

немного.

Поэтому, чем лучше вы здесь пропишете документацию, чем более точно вы расскажете нейронке, что вы хотите сделать, какие какой функционал вы хотите заложить, какие требования вы

ждёте, да, в какой стилистике, какие библиотеки вы хотите использовать.

Давайте, кстати, вот про это сейчас про библиотеки поговорим. А здесь во

библиотеки поговорим. А здесь во фронтенде, например, да, у нас есть вот Command do Dogs. Здесь мы сразу указываем, что мы используем Frev Nextjs. Ну, я указал, потому что у меня

Nextjs. Ну, я указал, потому что у меня с ним много опыта. Мне он, в принципе, и понятен, почему бы и нет.

Typeescriptрипt Tailwin для стилизации.

Ну, это уже немножко такая техническая документация. Если вы не разработчик, то

документация. Если вы не разработчик, то можете на это особо внимание не обращать. Вы можете попросить там опять

обращать. Вы можете попросить там опять же того же клода: "Побери оптимальную конфигурацию для моего проекта". Вот что

я хочу сделать. Скидывайте ему ээ непосредственно вот эти данные маркетинга, да? То есть с описанием

маркетинга, да? То есть с описанием функционала, с описанием там своей целевой аудитории, э-э с описанием, ну вотще про проекта, который вы хотите сделать, и сказать: "Блин, напиши вот

максимально подходящую эту ээ техническую документацию под это. Я, в

общем, не понимаю, просто сам разберись с этим". Он, в принципе, нормально

с этим". Он, в принципе, нормально напишет. Дальше UI components. Ну, я

напишет. Дальше UI components. Ну, я

указал, есть здесь SHCN UI. Давайте

посмотрим, что такое CNUI. Э, достаточно

популярная библиотека для, э, графических элементов. То есть тут

графических элементов. То есть тут всякие календарики есть, графики. Что

тут ещё есть?

Ну, графики, календарики, всякие готовые компоненты. Поэтому можно, э,

компоненты. Поэтому можно, э, аналогичным образом использовать другие библиотеки. Просто сказать: "Используй

библиотеки. Просто сказать: "Используй там вот эту библиотеку для графиков". Вы

можете посмотреть, ну, допустим, для э JavaSрипта он для Reactта, да? React UI

Components.

Э- ну, допустим, просто первое, что попалось, э, move faster with intuitive React Tools. Вот, пожалуйста, вот

React Tools. Вот, пожалуйста, вот какая-то библиотека UI компонентов. Можете использовать её

UI компонентов. Можете использовать её либо другую, да? То есть, если вы, допустим определились со своим там фреймворком, на котором вы пишите, ну, ищете для него библиотеку компонентов и всё. Либо там просто

поясите там для UI компонента для Джаваскрипта и так далее. Иконки тоже.

Вот я использую Lucid Dreac.

React, ну, библиотека иконок, пожалуйста. Вот открываем. Здесь можно

пожалуйста. Вот открываем. Здесь можно

посмотреть на эти иконки. Чтобы каждую

иконку отдельно не искать, используйте библиотеку иконок вставляйте их как компоненты в том же Реакте. И так можно делать со всеми, э, библиотеками, которые вы находите. Говорите: "О, вот

это прикольно, давай вот это используем". Просто добавляете в

используем". Просто добавляете в документацию. Ну, лучше не переборщить

документацию. Ну, лучше не переборщить лишни там совсем уж много библиотек может быть и не стоит, но, по крайней мере, собрать вот этот вот свой стек библиотек, да, очень даже. Дальше здесь

описана структура папок. Опять же, это я писал не руками, я с ней согласен с этой структурой. Это о'кей, нормально, но это

структурой. Это о'кей, нормально, но это писала неронка. Почему бы и нет? Ну, то

писала неронка. Почему бы и нет? Ну, то

есть, если мы заранее поговорим с ней и попросим: "Давай сделаем архитектуру, сейчас с тобой продумаем". Она её

сделает, всё, потом не будет к этому вопросов. Потом вам не нужно будет там

вопросов. Потом вам не нужно будет там отдельно писать, что давай компоненты вот сюда или ещё что-то. Всё, оно есть в документации. У нас уже есть заданная

документации. У нас уже есть заданная структура папок. Всё, мы по ней

структура папок. Всё, мы по ней работаем. Круто, не надо про это больше

работаем. Круто, не надо про это больше писать. И точно так же про все про все

писать. И точно так же про все про все другие задачи. Если вы понимаете, что

другие задачи. Если вы понимаете, что вам приходится там уже хотя бы два раза писать и объяснять, что-то неронки, что нужно сделать, да, господи, вынесите просто это в документацию и всё.

Ну, собственно, примерно так. Дальше

здесь идут всякие требования по фронт. Я

думаю, что пока не надо их разбирать.

Суть в том, что все свои требования здесь лучше описать. У нас тут про стейты, про использование там библиотек, про тейлвинды, про локализацию. Вот

здесь что, давай хранить для английскую здесь, русскую здесь и так далее.

А то же самое у нас есть для бэкэнда. Мы

для бэкэнда тоже описываем там общую, что нам, что мы хотим, что мы хотим на питоне, мы хотим вот на джан. Ну можно и gs, и что угодно, на самом деле можно.

Просто, ну, в моём случае я выбрал pтоon хотя мог бы и на ноде то же самое сделать. Вот. описали ему, что мы хотим.

сделать. Вот. описали ему, что мы хотим.

Хотим базу данных пост SQL. Э, у нас будет там NGK. Ну, это это сложные слова, которые, возможно, вам даже и не нужно знать. Поэтому, если вы этого не

нужно знать. Поэтому, если вы этого не знаете, это писать не обязательно.

Просто если у вас есть реальные требования, опишите их. Если у вас их нету, можете не писать. Неронка сама

выберет что-нибудь подходящее. Ну да,

здесь у нас уже детально описано, какие у нас там будут в Джанга апы, какая у нас будет бизнес-логика в Коре.

Ну, в общем, детали всей этой реализации. Поэтому лучше всё это

реализации. Поэтому лучше всё это заранее описать, потому что потом, когда вы будете делать какую-то новую фичу, нейронка посмотрит в эту документацию и скажет: "Вот, так я всё и так уже понимаю, не нужно мне ничего объяснять".

О'кей. А теперь давайте примерно мы поняли, что там за документация хранится в этих секретных папках, и поняли, что чем лучше мы её опишем, тем лучше будет результат. Теперь давайте попробуем

результат. Теперь давайте попробуем удалить вообще всё, что у нас есть во фронтде. Предварительно я, э-э,

фронтде. Предварительно я, э-э, закрою э наши консоли, терминалы, точнее, э мы удалим весь наш проект

э вот этого лендоса. Так, у нас осталась папка nextj. Move to trash. О'кей,

папка nextj. Move to trash. О'кей,

возвращаемся к нашей лендингу, к нашему.

Копернём просто вот этот тот же самый пром просто. Ээ так, давайте заново.

пром просто. Ээ так, давайте заново.

Раз, раз. Вот так. Всё. Bas it on the documentation. Create a landing bench

documentation. Create a landing bench for our in the, ну вот frontend in the frontend folder. Всё. И это всё, что мы

frontend folder. Всё. И это всё, что мы от неё попросим. Сейчас мы нажмём Enter, она будет достаточно долго думать и вернёмся, когда она что-то нам родит.

Погнали.

Обратите внимание, что неронка начала смотреть нашу документацию по сервису.

Она начала её смотреть, потому что мы указали в main. э MDC путь к файлам нашей документации и объяснили ей, что,

когда и где использовать. Вот поэтому

она поняла, что туда, что там смотреть.

Может быть, она бы и сама догадалась, но поскольку мы указали это в правилах, ей это было проще сделать.

Ну что ж, давайте посмотрим, что у нас получилось. Неронка говорит, что она

получилось. Неронка говорит, что она закончила. Давайте попробуем открыть

закончила. Давайте попробуем открыть терминал и ээ запустить сервер. Для

этого нам нужно перейти в папку frontend. А так сделать npm install. Это

frontend. А так сделать npm install. Это

тоже займёт какое-то время. Хотя,

конечно, странно, что оно этого не сделала, но о'кей. Э, и запустить сервер. Что ж, зависимости установились.

сервер. Что ж, зависимости установились.

Теперь давайте запускать север. Посмотрим, что

у нас получилось. Local host 300 предлагает она нам посетить.

Ну о'кей. Э такое бывает. Неронка вывалила

о'кей. Э такое бывает. Неронка вывалила

нам ошибку. Ну точнее ошибку вывалила нам не неронка. Ну мы просто и говорим фикс.

Ой, ну ладно, поймёт.

Такое бывает. Где-то не закрыла скобку, где-то что-то ещё сделала, что-то сломалось. Unexpected token

что-то сломалось. Unexpected token section. Ну, сейчас узнаем, что она нам

section. Ну, сейчас узнаем, что она нам поправит.

Итак, мы попытались запустить. У нас

выскочила ещё одна ошибка, но ничего страшного. Мы точно так же отправляем её

страшного. Мы точно так же отправляем её нейронки, и сейчас она её исправит.

Задача достаточно большая. С нуля

развернуть сервер в пустой папке, сделать полностью лендинг. Она, конечно, умная, разбивает

лендинг. Она, конечно, умная, разбивает всё на подзадаче, но иногда бывают ошибки. Ничего страшного, сейчас она их

ошибки. Ничего страшного, сейчас она их исправит.

О'кей. говорит, что, кажется, всё готово. Сейчас мы это проверим.

готово. Сейчас мы это проверим.

Опа. И вот что у нас получилось.

Ну да, здесь, конечно, некоторые слова сливаются, и, в принципе, с этим нужно ещё будет работать. Но для первой точки отчёта вполне неплохо. Как вы можете

заметить, здесь всё те же э заголовки, та же информация, что у нас была описана в варфрейме. И да, это уже выглядит

в варфрейме. И да, это уже выглядит неплохо. Некоторые блоки вообще хорошо.

неплохо. Некоторые блоки вообще хорошо.

Конечно, первый вступительный блок надо будет подправить, но согласитесь, прикольно. И да, не получилось делать

прикольно. И да, не получилось делать это за один промт. Такое случается.

Иногда неронка при больших задачах выдаёт там какие-то ошибки, но эти ошибки точно также можно скормить ей, и она их исправит.

Я думаю, на этом можно заканчивать. В

принципе, силу документации, я думаю, вы поняли и прочувствовали. И, конечно, в каждом конкретном случае, в каждом конкретном проекте документация может быть своя, и расписывать её можно тоже по-своему. Нету каких-то строгих правил.

по-своему. Нету каких-то строгих правил.

Вы можете это писать на собственном языке. Суть в том, чтобы описать то, что

языке. Суть в том, чтобы описать то, что вы хотите максимально подробно сохранить это в Markдау файлы и указать нейронки, в каких файлах что написано, что вы делаете, чтобы она могла на это

ориентироваться. И всё. И результат

ориентироваться. И всё. И результат

будет гораздо лучше. Тем более, что сейчас мы можем этот лендинг дальше докручивать, делать какой-то сервис. И

мы, собственно, так и делаем в других видео. И нам не нужно каждый раз писать

видео. И нам не нужно каждый раз писать о том, что мы хотим сделать. Неронка и

так уже прекрасно это всё понимает, и сам процесс вайп-кодинга становится гораздо проще. В Telegram-канале

гораздо проще. В Telegram-канале ГоныйВайп-кодинг я опубликовал список ресурсов, где можно посмотреть готовые промты, готовые правила для курсора.

Ссылка на пост в описании к этому видео.

На этом всё. Подписывайтесь, ставьте

лайки, пишите вопросы, смотрите другие видео. Впереди много годноты. Всем пока.

видео. Впереди много годноты. Всем пока.

M.