Transcription
Итак, директор Google Cloud недавно выпустил свою библиотеку навыков для продакшн-класса, основанную на лучших практиках разработки программного обеспечения в Google. И сегодня мы собираемся протестировать ее. Честно говоря, многие из существующих инструментов для оркестрации ваших рабочих процессов кодирования или ИИ-кодирования становятся все более сложными, и эта сложность не всегда приводит к улучшению результатов. Именно поэтому эта библиотека выглядит для меня очень здорово, потому что это, по сути, набор навыков, которые мы можем предоставить кодирующим агентам, обеспечивая гибкость между различными этапами этих процессов. На высоком уровне, это всего семь команд слэш, которые запускают все это, а внутри них 19 различных навыков, составляющих эти семь областей. Так что, если вы устали топтаться на месте, постоянно ища что-то лучшее, это может быть именно то, что вам нужно. Мы рассмотрим все эти команды и то, как они работают, различные навыки, работающие в каждом из этих этапов, и мы создадим новые функции в этом приложении, над которым я работал.
Структура этого действительно напоминает мне GitHub's spec kit, который я до сих пор использую, когда хочу сделать что-то действительно надежное и убедиться, что в реализации нет действительно важных вещей. Работает это так: сначала мы уточняем или определяем идею, что именно мы пытаемся сделать, и результатом этих навыков является PRD (Product Requirements Document). Как только у нас есть PRD, мы можем перейти к созданию плана. Этап планирования приведет к тому, что все в этой спецификации будет преобразовано в серию поэтапных задач. Это будут небольшие, ограниченные задачи, разбитые на разные этапы. Теперь, когда у нас есть эти этапы и задачи внутри них, мы можем перейти к инкрементальной сборке. Инкрементальная сборка означает создание вертикальных срезов. Если вы новичок в этом, есть разница между горизонтальным и вертикальным нарезанием сборки. Лучший способ понять, что делает срез вертикальным: предположим, я хочу создать весь процесс онбординга для моего приложения. Если бы я нарезал это горизонтально, я бы создал все различные фронтенд-компоненты. Например, компоненты регистрации, компоненты входа, возможно, различные компоненты фронтенда для управляемого онбординга. Я бы создал все это, а затем, например, создал бы все это для бэкенда: фактический процесс регистрации, фактический процесс онбординга с бэкенд-логикой, API, схему базы данных, все это. В то время как вертикальное нарезание означало бы: я создам весь срез аутентификации. Я создам фронтенд, я создам бэкенд, я создам все это одновременно.
Таким образом, мы переходим к реализации всех этих задач с помощью вертикальных срезов. Как только мы закончили и фактически создали эти вещи, запускается фаза верификации. Она фактически протестирует все и, возможно, отладит найденные проблемы. Затем у нас есть дополнительная функциональность для обзора. То есть, проведение надлежащего QA-обзора, уточнение кода, упрощение его, и тогда мы можем выпустить. Это будет похоже на фактическое размещение в GitHub, например, управление различными ветками продакшена и стейджинга и всем таким.
Все это очень здорово на высоком уровне, но не имеет особого значения, если мы не знаем, какие навыки в него входят, и именно на это мы посмотрим дальше. Как я уже сказал, их 19. Я не буду охватывать их все. Я охвачу те, которые, по моему мнению, действительно ценны.
Первый навык — уточнение идеи. Если вы не начинаете с четкой идеи и примерно знаете, что хотите сделать, но это немного расплывчато, уточнение идеи поможет вам превратить эту расплывчатую вещь в конкретную концепцию того, что вы собираетесь построить. Теперь, когда у вас есть это, вы можете использовать навык разработки на основе спецификаций. Эта вещь пройдет и напишет ваш PRD. У нее есть своя версия, которая, возможно, немного отличается от того, что вы видели в других инструментах или даже в других рабочих процессах, которые я демонстрировал на канале раньше. Она создает этот PRD для вас, и вы можете использовать его, независимо от того, работаете ли вы над новым проектом, новой функцией в существующем проекте (что мы скоро рассмотрим) или просто вносите большие изменения во что-то уже существующее.
Как только у нас есть спецификация, которая является основным результатом этапа определения, мы переходим к планированию. Этот навык возьмет эту спецификацию и разобьет ее на небольшие задачи, которые можно проверить и которые имеют четкие критерии приемки. Конечным результатом этого должно быть то, что мы сможем выполнить эту задачу и проверить, что она была выполнена должным образом. Если бы это была просто настройка проекта, это могло бы быть обеспечение прохождения всего линтинга, первая сборка приложения, такие вещи. Возможно, если бы мы создавали API-эндпоинты в рамках задачи, это могло бы быть обеспечение того, что при отправке определенного полезного груза мы получаем нужный тип ответа, что сервер работает должным образом, такого рода вещи.
Затем мы переходим к набору навыков для построения, в котором много всего, но есть два основных навыка, которые используются при использовании команд для построения, которые мы рассматривали ранее. Первый — инкрементальная реализация. Это навык, который проходит и выполняет эти вертикальные срезы. Он реализует вещь, тестирует ее, проверяет, что было сделано, а затем фиксирует изменения. Это делается в контексте цикла разработки, управляемого тестами. Он следует циклу "красный, зеленый, рефакторинг". Если вы не знаете, что это такое, это означает, что вы сначала пишете тест, который не проходит. Затем вы пишете минимальную логику, которая фактически заставляет вещь функционировать и проходить тест, а затем вы рефакторите.
Существуют и другие навыки, которые вы можете вызвать или которые будут вызваны в зависимости от того, что делается. Некоторые из них включают инженерию контекста (например, извлечение правил и тому подобного по мере необходимости), фронтенд-инженерию пользовательского интерфейса. Всякий раз, когда вы работаете над компонентами, системами дизайна, как вы будете управлять состоянием на фронтенде, обеспечивая его отзывчивость, все это. По сути, всякий раз, когда вы создаете пользовательский интерфейс, он будет вызывать это. И аналогично для бэкенда, всякий раз, когда мы работаем с API, различными границами между тем, что мы строим на бэкенде, он будет вызывать этот навык проектирования API и интерфейсов.
Затем, когда дело доходит до проверки и обзора всего, есть набор других навыков, которые помогают нам выполнять части этого процесса. Тестирование в браузере с использованием MCP Chrome, рабочие процессы отладки, которые помогают нам действительно сузить круг поиска первопричины фактической проблемы, с которой мы имеем дело, обзоры качества кода, упрощение, безопасность и защита, оптимизация производительности. В нем действительно есть куча действительно классных вещей, которые помогают нам взять то, что мы получили из этого начального этапа сборки, и убедиться, что это действительно хорошо и будет работать так, как мы хотим.
Итак, сказав все это, давайте перейдем к нашему проекту и попробуем эти навыки, начиная с этапа спецификации. Прежде чем мы перейдем к первому навыку, я покажу вам приложение, с которым мы работаем, чтобы у вас был контекст. Оно помогает нам настраивать и создавать рецепты. Под капотом происходит некоторая инженерия промптов, чтобы убедиться, что рецепт, который мы хотим приготовить, действительно хорош. Например, если бы я сказал: "Приготовь мне французский луковый суп с бурбоном", он бы начал потоковую передачу ответов от Claude, а затем у него есть этот небольшой генеративный пользовательский интерфейс, который пройдет, и как только он получит полный поток ответа, он сгенерирует карточку рецепта с ингредиентами, шагами и вкусовым профилем, а также несколькими другими вещами. И теперь, когда это сделано, мы видим, что он генерирует эту карточку для нас. Бурбон, французский лук, что угодно. У него есть ингредиенты, разные шаги, а внизу есть опция сохранить рецепт.
И это будет фокусом того, что мы делаем здесь, потому что одна вещь, которую я хочу иметь здесь, — это возможность итераций рецептов, верно? Например, я пробую это, но я корректирую это или хочу скорректировать это в будущем, но хочу иметь след этой вещи. Моя мысль о том, как бы я это сделал, если бы строил это только для себя, была бы сделать это как интерфейс в стиле Git, но для пользователя, я думаю, это, вероятно, было бы довольно... И поэтому нам нужно подумать, как мы собираемся это сделать. И поэтому мы спустимся сюда, хорошо? Я очищу все, что у нас есть, а затем мы используем первый навык, который был для идей. Этот навык назывался "уточнение идеи", и я скажу ему точно то, что только что сказал вам. Я хочу иметь опцию в стиле форка, где пользователи могут создавать варианты рецепта и сохранять информацию о том, от какого корневого рецепта он был получен. Он показывает все варианты рецепта на исходном. И под этим я подразумеваю, что если я нахожусь на этой карточке рецепта, и я не уверен, куда именно это пойдет в пользовательском интерфейсе, но это должно показать мне, например, вот, знаете, пять вариантов, которые вы приготовили в прошлом, в основном, это то, что я думаю.
Эта вещь запускается, и теперь она пройдет, и у нее есть определенные способы, которыми она думает об этом, и она формулирует все через эту идею "как мы можем", а затем говорит: "Хорошо, как мы можем позволить пользователям делать то, что я только что описал?" Она исследует кодовую базу, а затем предложит нам несколько различных вариантов, обычно от трех до пяти вариантов, которые представляют собой разные, скажем так, системные направления, которые мы могли бы взять. И вот, вопросы поступают, и мы можем ответить на них. Первый вопрос: что запускает это? Происходит ли это через чат? Происходит ли это на самой странице рецепта? Где мы запускаем этот форк в первую очередь? Думая о MVP, я не хочу переусложнять это инструментами и маршрутизацией намерений пользователя и всем этим сумасшествием. Поэтому я просто скажу, что они идут и нажимают "форк" на рецепте, а затем он загружает его в чат с контекстом этого рецепта и говорит: "Эй, что вы на самом деле хотите сделать здесь?" Мне это нравится. Как должны отображаться варианты на исходной странице рецепта? Опять же, я думаю, я выберу самый простой вариант, который является простым списком. Могут ли пользователи форкать рецепты других людей или только свои? Теоретически, если у нас есть социальные функции, они должны иметь возможность форкать рецепты других людей, но нам нужно будет подумать о том, как мы будем обрабатывать безопасность на уровне строк в нашей базе данных для этого? Так что, вероятно, будет немного больше всего. Но пока что я скажу, давайте позволим это для будущего, но сейчас я буду использовать эту вещь, и я не хочу переусложнять то, что мне не нужно прямо сейчас. Должны ли форки иметь возможность форкать? То есть, можно ли создавать варианты вариантов? Я бы сказал, да. Я не вижу причин, почему бы не сделать это. Так что мы можем сказать "неограниченная глубина", хорошо?
Итак, давайте отправим все эти ответы. Он подумает об этом, а затем вернется и даст нам наши, скажем так, проектные направления для этой вещи, что мы видим сейчас. И весь этот поток, через который он проходит, он прошел и сказал: "Хорошо, вот семь различных направлений, а затем давайте оценим их и сойдемся на одном окончательном направлении, которое мы возьмем". Все это встроено в навык, поэтому он проходит через эти конкретные этапы, что приятно, потому что вы можете быть уверены, что он будет работать так для вас, когда вы будете его запускать. Давайте посмотрим на направления и выберем одно. По сути, то, как это работает, заключается в том, что он взял все вопросы, на которые мы ответили, и теперь говорит: "Ну, вот различные направления, которые вы могли бы взять. Это своего рода UX или дизайн системы. Вот как вы могли бы взять эту вещь". Самым простым будет эта базовая возможность ремикса, где вы нажимаете "форк", и он делает именно то, что мы описали. ИИ спрашивает, что вы хотите изменить. У него есть ссылка на родительский рецепт, а затем на исходной странице рецепта отображается раздел вариантов с карточками, очень просто, а затем мы можем получить другие, скажем так, немного более острые. Ха-ха, игра слов. Мы можем сделать это более острым, как мы хотим это сделать, верно? Мы могли бы показать разницу, но я бы не хотел, чтобы это выглядело слишком технически, поэтому это должно быть читаемо для человека. Вот что вы изменили. Ну, это вариант. Различие вкусов, подчеркните, что вы изменили во вкусовом профиле. Мне кажется, это немного трюк для меня. Меня это сейчас не особо волнует. Исследователь родословной, то есть есть куча других идей, которые, по-моему, немного сумасшедшие. Я хочу чего-то простого для этого. Я действительно хочу. И поэтому я думаю, что направление А — это то, что я бы предпочел. Меня не волнует форк с учетом вкуса. Так что мы просто скажем "чистый форк". Мы будем двигаться вперед. И снова, мы на этапе идеи. Вот что я имею в виду, когда говорю, что мы можем перейти от расплывчатой идеи к чему-то очень конкретному и тому, что вы можете предпринять действия. Так что очень приятно, что это помогает нам продумать такой тип вещей, в то время как многие библиотеки на самом деле этого не делают. Вы просто говорите, что хотите, а затем LLM делает предположения и выходит и делает это. Мне очень нравятся библиотеки, которые имеют такой подход к вещам, основанный на опросах и противостоянии.
Следующее, что мы собираемся сделать, поскольку у нас есть эта идея, которая была проработана. Они хранят это, кстати, в вашем проекте. Итак, мы находимся в документах, идеях, форкинг рецептов. Теперь я запущу их навык разработки на основе спецификаций. И это позволит нам детализировать, что это реально означает? Какие вещи пользователь должен иметь возможность делать? Каковы критерии приемки? Как мы будем это проверять? Все это будет проработано. Он исследует кодовую базу, посмотрит, что у нас есть, какая у нас схема, какие файлы у нас есть, как все структурировано, а затем он создаст спецификацию или PRD для нас. Итак, то, что мы получаем на выходе, это, как я уже сказал, PRD. Какова цель того, что мы собираемся попытаться построить? Как выглядит успех? Каковы основные критерии приемки? Какой тип технологий будет задействован? Каковы параметры или соглашения по стилю кода, которые у нас есть в проекте? Каковы границы этой вещи? То есть, что она всегда должна делать? Что ей нужно спрашивать у нас, прежде чем она это сделает? Чего ей никогда не следует делать? Например, обходить политики безопасности строк. Итак, мы получаем эту детализированную версию того, что нужно сделать, но этого недостаточно для построения. То есть, вы не захотите взять это и сказать: "А теперь постройте это", верно? Потому что мы хотим создать, опять же, вертикальные срезы, которые мы можем реализовать, где у нас есть очень проверяемые, тестируемые вещи. И если бы мы просто отправили это, мы не обязательно получим это. И поэтому следующий шаг в этом процессе заключается в том, что нам нужно сначала очистить наш контекст. И теперь мы собираемся перейти к этапу планирования. И поэтому мы вызовем следующий навык, который называется "планирование и разбивка задач", и мы просто передадим контекст конкретного плана, над которым мы работаем, который является этим форкингом. И теперь, если бы мы вернулись в этот репозиторий GitHub, мы могли бы увидеть, что именно он собирается сделать и какой именно процесс он собирается пройти. Он будет использовать режим планирования. Он определит граф зависимостей. То есть, из всех вещей, которые мы собираемся построить, что от чего зависит и как это повлияет на последовательность построения. Он нарежет его вертикально и даст примеры того, что является плохим примером, как горизонтальное нарезание, о котором мы говорили ранее, где мы бы создали все для базы данных, все API-эндпоинты, все UI-компоненты, а затем соединили бы все это вместе, вместо того, чтобы сказать: "Эй, пользователь может создать учетную запись". Круто. Нам нужна схема, нам нужен API для нее, и нам нужен UI для нее. Вот в чем разница между горизонтальным и вертикальным. Затем он запишет все задачи в этом конкретном формате, и как только у нас будет это, мы сможем перейти к фактическому построению.
Итак, теперь, когда это сделано, у нас есть план для нашей сборки, записанный в документации нашего проекта. И поэтому, если бы мы посмотрели на это, у нас есть обзор того, какие важные архитектурные решения были приняты, но затем какие различные этапы сборки? И поэтому эти вещи теперь организованы на основе зависимости того, что нужно сделать. Итак, наш первый этап будет посвящен основам, обеспечению настройки нашей базы данных и типов. Этап два будет основной сборкой бэкенда. Этап три будет фактическим UI чата, и он просто продолжается и продолжается. Итак, что мы будем делать дальше, это вернемся в нашу консоль. Я очищу это. И теперь мы будем использовать фактическую команду сборки. Все, что я собираюсь сделать, это передать команду {slash} agent skills build, а затем мы укажем ей репозиторий, над которым мы работаем, и скажем "сборка фазы один". Я действительно рекомендую вам явно указывать фазы, над которыми нужно работать, потому что я обнаружил, что с этой библиотекой, если вы этого не сделаете, она попытается пройти и построить весь план сразу, и это, очевидно, очень плохо для вашего контекста. И все жалуются на то, как Claude сжигает свои контекстные окна в наши дни. Так что убедитесь, что мы этого не делаем.
Итак, первая фаза была завершена довольно быстро, очистив контекстное окно, и теперь мы запускаем ту же команду, но я говорю "фаза два". И еще одна вещь, которую я добавляю, — это убедиться, что она фактически использует навык для проектирования API и интерфейсов, где это применимо, потому что я обнаружил, что иногда лучше, если вы знаете, что хотите, чтобы навык использовался, просто сказать ему сделать это и не полагаться на то, выберет ли он использовать этот навык, когда вам действительно нужно, чтобы он это сделал. Просто скажите ему использовать его. И теперь, что круто в этом, что мы можем видеть, пока это происходит, это то, что он использует этот подход разработки, управляемого тестами, пока это происходит. Поэтому, когда он начал выполнять задачу шесть в этой фазе, которая заключается в форкировании контекста или форкировании контекста в системном промпте и в API чата, сначала он напишет тесты, которые не проходят, верно? А затем он пройдет и убедится, что они не проходят, а затем он реализует логику, которая заставит этот тест фактически пройти. Итак, теперь, когда это сделано, мы переходим к фазе три, которая больше связана с фронтендом этой сборки. И я делаю то же самое. Я говорю: "Эй, фаза три сейчас", но убедись, что ты используешь навык инженерии фронтенд UI. Итак, если бы мы фактически посмотрели на этот навык, причина, по которой я действительно люблю такой тип библиотеки, заключается в том, что она гибкая, но также и в том, что она помещает просто хорошие способы делать вещи в систему. Например, документирование того, как должны выглядеть паттерны фронтенд-компонентов, чтобы они были сделаны хорошо. Убедитесь, что мы отделяем получение данных от фактического представления вещи. Убедитесь, что когда мы собираемся работать над этим управлением состоянием, которое в данном случае может быть всем, что происходит с форкингом, мы используем подход, который действительно имеет смысл на основе контекста приложения. Убедитесь, что экраны ошибок или обработка ошибок, которые он создает, имеют смысл и не просто выдают ошибку и показывают нам пустой экран. Так что все это очень важно, и это встроено в навык, который сейчас используется. Итак, мы видим, что навык был вызван, и теперь он проходит и просто строит все на основе этих параметров. Итак, теперь, когда это сделано, он переходит к фазе четыре.
Хорошо, ребята, момент истины, мы можем проверить это. У нас есть этот рецепт. Мы видим кнопку "форк рецепта". Если мы нажмем на нее, она должна создать новый чат. Она должна иметь этот форк в URL, что она и делает. Пока не похоже, что она что-то делает, но я дам ей секунду и посмотрю, может быть, есть небольшая задержка, и если она начнет отправлять сообщение. Да, мы видим это прямо здесь. Очевидно, что это время нужно обновить. Так что она спрашивает нас, что мы хотим сделать, и дает нам несколько вариантов, как мы могли бы это изменить. Так что я мог бы сказать что-то вроде "сделай его более сытным рецептом, больше похожим на рагу, чем на суп". Используй О, мы возьмем эту говядину. Используй говядину в качестве мяса, хорошо? И теперь, надеюсь, это пройдет и создаст нам новый рецепт. Давайте посмотрим. Она спрашивает нас больше информации, что приятно. Выбирайте. Мне все равно. Я просто хочу протестировать логику всего этого. Хорошо, генерируем новую карточку рецепта, что хорошо. Надеюсь, это пройдет и сработает, и бум. Итак, мы видим, что теперь мы можем сохранить рецепт. Хорошо, рецепт сохранен. Тушеное мясо из говядины с французским луком и бурбоном. Итак, мы можем посмотреть на это. Он не ссылается на родительский рецепт, но, возможно, если мы вернемся к рецептам, это очень медленно, кстати, рендерит все. Так что, очевидно, есть вещи, которые мне нужно оптимизировать, что мы посмотрим через секунду, что мы можем сделать для этого. Если мы зайдем в исходный рецепт, хорошо, так что он не рендерит UI для них. Так что, правильно, он должен показывать нам список рецептов, которые были форкнуты от родительского, но теперь мы можем вернуться и фактически использовать этот навык отладки. Я просто скажу ему, что именно происходит. Я не буду сходить с ума. Он должен показывать список рецептов, которые были форкнуты от родительского. Я почти уверен, что у нас это было в планах, и этого нет, верно? То есть, я должен увидеть это где-то здесь в UI как прокручиваемую сетку. И поэтому он пройдет и попытается понять, в чем именно заключается первопричина проблемы. Пока это происходит, кажется, что он построил большую часть этого, но не рендерит. То есть, это есть в API. Он должен срабатывать, когда варианты.длина больше одного, но этого не происходит. И поэтому кажется, что конечная точка, которую у нас есть, не соответствует тому, что он искал. И поэтому он сузил проблему и проходит и пытается ее исправить. Так что они пытаются мне здесь сказать? Но это Похоже, проблема в том, что корневой рецепт. То есть, если мы посмотрим на эту говядину или тот исходный рецепт, этот, от которого он был "форкнут". Поскольку это оригинал, у него есть нулевое поле в идентификаторе корневого рецепта. И поэтому, когда он вызывает это, он возвращает ноль и не работает должным образом, как кажется. Итак, он утверждает, что нашел первопричину и собирается попытаться ее исправить. И поэтому мы посмотрим на это после того, как это будет сделано. Хорошо, похоже, это исправило. Так что это действительно хороший навык, который у нас есть, чтобы действительно найти первопричину и просто исправить вещь, а не копаться в 50 миллионах разных вещей. Итак, у нас есть два разных варианта. У нас есть этот летний травяной, который я сделал за кадром, а затем у нас есть тушеное мясо из говядины с французским луком. Мы можем нажать на него и посмотреть, и он показывает нам, от чего он был форкнут. Так что, возможно, мы можем сделать так, чтобы это выглядело немного лучше, но что касается основной логики, все работает.
Итак, теперь, когда у нас есть это, давайте посмотрим, какие еще навыки мы можем использовать как небольшое дополнение. Я уже проверил все это вручную, так что я не буду проходить через это. У нас есть два других набора навыков. У нас есть навыки, ориентированные на обзор, где мы можем посмотреть на качество того, что мы написали, и я знаю, что, вероятно, есть некоторые проблемы с тем, что у нас есть. Мы на самом деле не касались создания индексов для базы данных на случай, если она станет больше, и нам нужно будет иметь возможность эффективно работать внутри базы данных. А затем у них также есть навыки для отправки этой вещи. Например, если бы я хотел отправить это в Vercel прямо сейчас, но убедиться, что все тесты пройдут перед развертыванием, как я могу это сделать? Давайте посмотрим на навыки обзора, а затем посмотрим на этот финальный навык отправки. И поэтому мы можем спуститься вниз и просто запустить этот навык обзора. И пока это происходит, мы можем посмотреть, что именно он просматривает. Он запускает то, что называется пятиосевым обзором. И поэтому он будет смотреть на все, что у нас есть в нашей кодовой базе, по этим измерениям. Номер один, это правильность. Делает ли он то, что он утверждает, что делает? Номер два, читаемо ли это и просто ли это? Если бы кто-то другой посмотрел на это прямо сейчас, имело бы это смысл? И есть много соглашений, которые объясняют, как он определяет, что это читаемо и просто. И номер три, соответствуют ли какие-либо из изменений, которые мы внесли, поскольку это должно запускаться в ветке, какие-либо из этих изменений общему дизайну системы? Соответствует ли это нашим существующим паттернам? Поддерживает ли это границы между различными модулями и тем, что они должны обрабатывать? Ввели ли мы какие-либо уязвимости безопасности? И затем у него есть навык, который может помочь в этом и исправить такие вещи. И затем детальная оптимизация производительности через этот навык оптимизации производительности. И поэтому, опять же, он будет смотреть на кучу разных вещей. И затем, в зависимости от размера изменения, я думаю, в данном случае мы смотрим, вероятно, на тысячу строк, которые мы изменили в этой ветке, над которой мы работали. У него есть различные механизмы для эффективного просмотра вещей. Итак, это то, что он делает, пока он проходит и просматривает вещи. Итак, у него есть процесс, через который он работает, а затем это общий процесс обзора, который он будет использовать. И поэтому это очень важно запустить, потому что, очевидно, у нас появились некоторые вещи, которые мы действительно должны решить. Например, мы не используем ORM с Supabase. Это помогло бы нам избежать таких вещей, как уязвимость к SQL-инъекциям. И поэтому, насколько бы умными мы ни думали, что такие инструменты, как Claude Code и тому подобное, являются, они будут делать такие ошибки. И поэтому крайне важно, чтобы мы запускали такой процесс и видели, что это за вещи, и строили реальный план для решения всех этих проблем. И поэтому, опять же, он смотрит на каждый из этих параметров. Итак, правильность, делает ли он то, что должен делать? Читаемо ли это и просто? Работает ли это в рамках архитектуры, которую мы фактически имеем? И затем снова, проблемы безопасности, которые нужно решить. Итак, это все проблемы, которые, прежде чем мы фактически отправим это, нам нужно убедиться, что все это исправлено. И поэтому, используя эту библиотеку, мы могли бы использовать навык планирования агента и сказать: "Создай мне всеобъемлющий план для решения всех критических проблем". Прямо сейчас он пройдет, используя тот же процесс, который мы прошли ранее, но с точки зрения исправления этих потенциальных проблем безопасности.
Теперь, поскольку я разрабатывал это локально, у меня нет конвейера развертывания, подключенного к GitHub или чему-либо подобному. Поэтому, пока это происходит и делает это, мы можем посмотреть на последний навык, который предназначен для настройки конвейера непрерывной интеграции и развертывания. И поэтому мы собираемся перейти и создать новый репозиторий GitHub. У меня есть пустой репозиторий здесь. Я назвал его forkcast V2. И поэтому мы пройдем и просто запустим эти команды. Мы вернемся в наш терминал. Я открою новое окно. Мы добавим origin, создадим нашу основную ветку. Хорошо, эта вещь теперь реализует эти изменения. И поэтому мы собираемся просто перейти к этому, создать новый экземпляр Claude Code в том же каталоге. Мы скажем ему использовать навык для создания нашего конвейера CI/CD с использованием GitHub actions. Убедитесь, что у нас есть надлежащая стратегия ветвления для управления тестами перед слиянием в main. Так что мы будем использовать этот навык для выполнения основной работы по фактическому построению инфраструктуры, которая нам нужна. В основном, для чего я это хочу, это для построения GitHub actions, чтобы, когда мы отправим это в GitHub, он автоматически запускал все наши тесты и делал все это, прежде чем мы фактически сольем это в нашу основную производственную ветку, которую мы используем.
В зависимости от сложности приложения и всего такого, существуют различные структуры, которые это может использовать. В нашем случае у нас нет настроенных сквозных тестов. Это просто личный проект для меня и так далее. У меня его нет. И поэтому у нас не будет какой-то супер-пупер надежной многоэтапной системы тестирования. И поэтому это знает, верно? Он делает определенные предположения на основе того, что он прочитал в нашем проекте, и рекомендует нам создавать функции в ветках функций. Они сливаются в ветку разработки, где происходит все тестирование и тому подобное. А затем, когда все будет хорошо, мы сливаем это в нашу основную ветку. И поэтому он просто проходит и строит все это. И поэтому, если бы мы посмотрели в наш проект сейчас, у нас есть каталог GitHub, который содержит эти конфигурации для того, как мы фактически будем отправлять вещи в наш репозиторий GitHub и убеждаться, что мы правильно запускаем все тесты и тому подобное. И снова, все это было настроено для нас с использованием этого навыка, что довольно здорово. И через секунду, как только мы закончим эти исправления, мы фактически отправим все, что у нас есть, и запустим тесты и посмотрим на результаты.
Итак, теперь, когда мы находимся в нашем проекте и отправляем изменения, скажем, в нашу кодовую базу, и мы хотим слить в main из ветки разработки, у нас есть все эти различные тесты, которые должны пройти, прежде чем это может произойти. Так что у нас не может быть ситуации, когда мы просто отправляем вещи в нашу производственную кодовую базу, которая просто не работает. И поэтому все это было сделано этим навыком, который позволил нам создать эти GitHub actions, эти CI (непрерывная интеграция) и CD (развертывание) actions, которые будут запускаться всякий раз, когда мы пытаемся сделать push. Так что мы можем зайти и фактически посмотреть на это и увидеть: хорошо, весь линтинг прошел, все проверки типов прошли, все тестирование прошло, и теперь он пытается фактически запустить сборку, чтобы убедиться, что финальная сборка проходит. И поэтому есть вещи, которые мы можем сделать, чтобы зайти сюда и еще больше заблокировать ветки, чтобы убедиться, например, что вам даже не разрешено напрямую отправлять в main, чтобы вы никогда не совершили ошибку, но это видео для другого дня. Так что у меня будет ссылка на этот репозиторий в описании ниже. Обязательно подпишитесь, если вам нравятся более длинные видео, подобные этому, где мы разбираем что-то в реальном контексте, потому что если есть одна вещь, которую я ненавижу, то это видео, ориентированное на список дел, которое непрактично ни в каком смысле и пропускает все действительно важные вещи. Так что, если вам нравится такой тип вещей, обязательно подпишитесь, и где-то над моей головой YouTube будет рекомендовать видео, которое вам может понравиться. Так что обязательно проверьте и его. Но на этом все для этого видео. Увидимся в следующем.