Transcription
Codeex CLI или Claude Code, противостояние, которое может соперничать с Pepsi и Coke, Microsoft и Apple, или если бы Орлы могли просто донести Фродо до Роковой Горы в «Властелине колец». Ну, на какой бы стороне этих споров вы ни оказались, набор инструментов для речи от GitHub, несомненно, порадует. Итак, если вы новичок в мире программирования на основе ИИ, или даже если вы просто время от времени испытываете трудности, разработка, управляемая спецификациями, должна стать вашим новым лучшим другом, потому что я слышал много отзывов из вселенной ИИ-кодирования о том, что часто вещи просто не получаются так, как вы надеялись. И по моему опыту, это почти всегда сводится к тому, как вы планируете и выполняете этот план. Вот почему 20% видео на моем канале посвящены именно планированию по стилю. Итак, в этом видео я покажу вам, как вы можете реально увеличить свою производительность в 10 раз с помощью одного бесплатного инструмента. Итак, мы разберем каждый из пяти шагов SpecKit, выполним их по порядку и покажем, как каждый этап подпитывает следующий, и мы сделаем все это с помощью Codeex CLI. Итак, еще раз, эта система действительно будет отличной для вас, если вы пытаетесь создавать крутые вещи, но вы просто чувствуете, что ваши системы слишком шаткие, чтобы когда-либо завершить что-то целое. Итак, как я уже сказал, мы будем запускать этот проект с помощью Codeex CLI, который является агентом кодирования от OpenAI, который работает на вашем компьютере, очень похоже на Claw Code или Gemini CLI. Теперь причина, по которой я показываю это именно с этим инструментом, заключается в том, что в ИИ-кодировании или кодировании по стилю или контекстном инжиниринге, или как бы вы это ни называли, самым большим препятствием, с которым вы столкнетесь, является выполнение крупномасштабных многофайловых операций, которые требуют много контекста для правильного выполнения. И сделать это хорошо может быть серьезной проблемой даже в таком инструменте, как Claude Code, который, по моему мнению, делает это лучше всего из коробки. И я уверен, что вы видели это в своих проектах раньше, когда вы даете ему подсказку, которая довольно подробна, относительно говоря, но он все равно иногда допускает ошибки при выполнении довольно серьезным образом. Вы можете сказать: «Эй, мне нужно создать эту новую функцию, которая делает вот это, и просто интегрировать ее в мой существующий бэкэнд, а затем, как только вы это сделаете, она выйдет из-под контроля, и она не сделала того, что вы хотели, и она не обязательно сделала это так, как вы хотели». И поэтому с Codeex CLI все действительно не отличается. он может обрабатывать отдельные задачи, такие как создание этого файла, например, довольно хорошо, но оркестрация значимых изменений во всех ваших файлах — вот где все имеет тенденцию рушиться, особенно для новичков или даже для среднего уровня. Итак, задача тогда, если мы сможем преодолеть это, все изменится для вас, и, по моему опыту, разработка, управляемая спецификациями, действительно помогает нам преодолеть эти проблемы. Итак, решение здесь: мы хотим использовать мощь такого инструмента, как codec CLI, в рамках spec kit от GitHub. Итак, давайте приступим и сделаем это. Теперь шаг номер один — это, очевидно, загрузить это на ваш компьютер, для чего у меня есть другое видео, где я прохожу через spec kit и показываю это. Так что я не буду делать это прямо здесь. Я предполагаю, что у вас есть codeex или cloud code или что-то еще, и что у вас также установлен spec kit на вашем компьютере. Итак, оттуда первый этап этого процесса — указать, что именно мы хотим построить на высоком уровне. Итак, мы начнем с запуска codeex. И теперь со speckit, способ сделать это в любом другом инструменте, кроме codeex, — это с помощью команды слэш. Итак, вы бы пришли сюда и набрали бы /specify, а затем сказали бы, что вы хотите сделать, и он бы сделал это. Проблема с codeex заключается в том, что в настоящее время он не поддерживает команды слэш. Итак, я покажу вам, как сделать это по-другому. Теперь вместо этого мы наберем mention. И тогда, когда мы поднимемся в наш каталог codeex, в этом примере внутри prompts, мы увидим, что у нас есть все эти подсказки, которые были сгенерированы при установке этого. И поэтому, тот, на который мы хотим сослаться, — это тот, который называется specify.mmarkdown. И поэтому я приду сюда. Я наберу specify.md. И теперь мы фактически используем эту команду для этого файла, и мы можем передавать аргументы. Итак, что мы будем строить в этом примере? Итак, в этом случае мы работаем внутри существующего проекта, который у меня есть, где люди хранят подсказки, а затем я начинаю добавлять функцию за функцией, где мы можем использовать языковые модели для улучшения подсказок, улучшения определений агентов, проведения исследований, чтобы сделать их в целом лучше со временем. И поэтому то, что я хочу сделать для этой функции, это сделать так, чтобы я мог выделить определенные части этой подсказки, например, этот фрагмент, и передать его в качестве контекста языковой модели, а затем позволить языковой модели фактически улучшить эту часть контекста. Так что это, по сути, система улучшения подсказок будет MVP этой функции. И тогда, как только это будет настроено, и у нас будет оркестрация агентов и все такое, тогда мы сможем перейти и начать добавлять все остальные функции, такие как агент исследований и другие вещи, которые мы можем захотеть иметь. Итак, мы видим, что я здесь написал, что я хочу, чтобы он сделал. Так что это агентский улучшитель, который в начале будет просто простым запросом к языковой модели. Так что это на самом деле не будет агент. И он работает внутри представления редактирования подсказок, которое мы смотрели. И он позволяет пользователям выделять разделы текста в формате markdown. А затем он передает это в OpenAI, чтобы улучшить подсказку. Он возвращает обновленную подсказку в ее целостности. Итак, мы можем нажать go. И теперь он сделает следующее: он отправится. Он будет использовать все инструменты, скрипты, шаблоны, которые были загружены вместе с этим репозиторием при его загрузке с GitHub. И он построит спецификацию того, что мы намерены построить, а затем оттуда мы перейдем к следующему этапу. Итак, теперь, что следует иметь в виду, пока это обрабатывается в фоновом режиме, заключается в том, что он использует мощь любого инструмента кодирования, который вы используете. Так что в этом случае он использует мощь codeex и кодировочной модели codeex специально для выполнения всех этих задач. И поэтому на самом деле то, что мы делаем с GitHub spec kit, это у нас просто много интеллектуальных подсказок, определений и шаблонов, которые передаются системе, но в конце концов она все еще использует мощь любой кодировочной модели, которую вы предоставляете, для выполнения запроса. Хорошо, эта штука только что закончила работу, и теперь мы заметим, что у нас есть каталог под названием specs. В моем случае я запускал это несколько раз в этом проекте. Итак, я на третьем определении. И поэтому, если мы зайдем в наш spec.markdown, мы увидим, что у нас есть спецификация для этой конкретной функции с небольшими инструкциями о том, что это такое и что следует учитывать. Теперь мы заметим, что мы спускаемся сюда, и у нас есть раздел для уточнений. И что это означает, так это то, что есть некоторые неоднозначности в функции, которую вы хотите построить. Хорошим примером этого может быть, знаете ли вы, что происходит, если у вас есть два разных пользователя с одинаковыми уровнями разрешений, пытающихся выделить один и тот же фрагмент текста одновременно? Или вы хотите иметь функцию предварительного просмотра перед тем, как это будет отправлено? И действительно ли важно, чтобы фактическое форматирование XML было сохранено? Это все очень важные вопросы для этой функции, которые, если бы мы не использовали такой инструмент, мы бы, вероятно, просто пошли и сказали: «Эй, создай эту функцию, которая делает вот это», и она просто сделала бы предположения. И поэтому именно этого мы в конечном итоге избегаем здесь. А затем мы спускаемся и можем просмотреть все пользовательские истории, которые у нас есть. Теперь, для целей этого видео, я не буду читать каждую из них и ее крайние случаи, но, по сути, мы говорим, что должно быть правдой, чтобы мы считали, что мы построили это должным образом. Это, по сути, наши сценарии принятия. Затем мы говорим о некоторых крайних случаях, как их следует обрабатывать. А затем, каковы все различные функциональные требования, различные сущности, с которыми нам нужно будет взаимодействовать или создавать, и так далее. Теперь очевидная вещь здесь заключается в том, что нам нужно уточнить эти функции, верно? И поэтому мы открываем наш терминал, и снова мы будем использовать это обходное решение для упоминания файла, и я считаю, что он называется clarify.markdown, что так и есть. Итак, мы запустим эту команду. И теперь происходит то, что он прочитал этот файл спецификации и задает нам вопросы о областях, которые требовали уточнения. И он даже дает нам возможные решения. Например, может ли пользователь выделить пять разных разделов одновременно и отправить их все или только по одному? Теперь, опять же, он дает нам три варианта ABC или своего рода альтернативу, которая заключается в том, что вы можете предоставить свой собственный вариант. Для моих целей в этом, я думаю, я конкретно хочу выбрать вариант C. Итак, я скажу C. И теперь он сделает следующее: он пройдет и обновит нашу спецификацию проекта, зная, что именно так будет обрабатываться эта конкретная ситуация, и он обновит функциональные требования. И теперь он будет повторять этот процесс для каждого вопроса, который у него был. Итак, я пройду и просто быстро отвечу на них, а затем перейдем к следующему шагу. Хорошо. Хорошо. Итак, на этом этапе мы можем продолжить, мы можем продолжать возвращаться и решать любые вопросы, которые он считает еще нерешенными. Итак, примером этого может быть, как мы будем обрабатывать, например, ограничение скорости. Опять же, для моих целей я не буду проходить через это. И поэтому мы перейдем к следующему шагу, который будет упоминанием, в данном случае, нашего файла plan.Mmarkdown. И поэтому в этом разделе, что вы хотите сделать, это предоставить любые важные детали, в первую очередь в отношении технологий, которые вы используете. Итак, я люблю просто напоминать ему, что на самом деле это приложение Nex.js, и я хочу, чтобы вы использовали OpenAI в качестве основного интерфейса языковой модели для таких обновлений. Помимо этого, здесь не будет особо новых технологий. Он будет использовать то, что у нас уже есть. Так что я не очень беспокоюсь о детальном описании вещей. Единственное, что я добавил сюда, и мне интересно, как он с этим справится, на самом деле, потому что я обычно делаю это на предыдущем этапе. Итак, мы увидим вместе, как это пойдет. Я прошу его добавить функциональность, где пользователь может выбирать между двумя или тремя популярными моделями от OpenAI в зависимости от сложности того, что он хочет сделать. Так что, если это очень простой запрос, возможно, они будут использовать базовую модель. Но если они делают что-то, что требует много размышлений, они могут фактически выбрать более дорогую модель. И тогда последнее, потому что для некоторых из этих функций у меня уже есть некоторые вещи, и поэтому я хочу убедиться, что он просто перерабатывает компоненты, чтобы они были повторно используемыми, когда это возможно, вместо создания новых компонентов, которые просто дублируют уже сделанный мной код. Итак, после того, как мы все это указали, мы просто нажмем go, и мы позволим ему работать. Теперь, что круто в этом, так это то, что он проходит многоэтапный процесс при планировании. Итак, он проводит исследование по этой теме и выбору технологий, которые вы делаете. Он создает наши модели данных. Он сообщает системе, как фактически начать использовать эту функцию. И он заранее создает контракт API, чтобы фронтенд знал, что ожидает бэкэнд, а бэкэнд знал, что ожидает фронтенд обратно. Так что это довольно круто. И это одна из вещей, которая действительно делает это как бы пуленепробиваемой системой. Теперь, пока это работает, я пойду и запущу новый терминал. И причина, по которой я это делаю, заключается в том, что есть еще один этап, который технически следует запускать перед тем, как углубляться в планирование. И этот этап — конституция. Хорошо? Так что конституция — это, по сути, создание принципов и руководящих указаний, которым все должно следовать. Так что, если у вас есть конкретные технологические соглашения, способы работы ваших API, соглашения о кодировании, все это важное, вы должны, очевидно, указать все это. И поэтому мы делаем это, запуская эту команду /constitution. И технически это должно быть сделано первым в процессе, но, эй, иногда мы делаем вещи не по порядку. Так что мы вернемся и просто запустим это. Позвольте этому пройти. И тогда, как только у нас будет наш план, мы будем ссылаться на план против конституции, чтобы убедиться, что мы все еще следуем соглашениям, которым должны следовать. Итак, теперь, когда план закончен, мы можем увидеть, что у нас создано много разных файлов, и мы собираемся их посмотреть. Итак, первое — это исследование, верно? Потому что мы сказали ему, что хотим использовать OpenAI. И поэтому он пойдет и посмотрит на различные модели, к которым у него есть доступ, а затем, как я просил, он проведет исследование: какие три модели должны быть доступны пользователям? Итак, он даст вам решение, обоснование, почему он считает, что это было хорошее решение, а затем какие другие альтернативы он рассматривал при принятии этого решения, и он продолжит этот процесс для всех основных вещей, которые ему нужно создать. Верно? Итак, внутри моего проекта у меня есть что-то под названием code mirror, и он проведет исследование этого и убедится, что это действительный относительно этого плана, который мы составляем, и что нет чего-то еще, что мы должны использовать. Итак, он пройдет, он сделает это довольно подробно. Затем он пройдет и создаст все наши модели данных, которые, я думаю, являются чем-то, с чем многие люди склонны бороться — это бэкэнд, верно? Например, вы создаете все эти фронтенд-вещи, а затем начинаете пытаться отправлять запросы на бэкэнд и начинаете получать все эти нарушения ключей, и вам нужно сделать кучу миграций, и вы не совсем понимаете, как они работают, и это может стать немного кошмаром. И поэтому у нас есть все основные таблицы и какие различные столбцы и какие все различные столбцы в этих таблицах будут. А затем контракт API, который указывает, например, эй, мы сделаем GET-запрос по этому конечной точке. Мы сделаем POST-запрос по этой конечной точке. Вот что это делает. А затем все различные схемы данных, которые он принимает и отправляет обратно в качестве ответа. И поэтому это ключевой момент, потому что когда мы перейдем к созданию фронтенда, не будет угадывания, верно? Бэкэнд уже проверен с точки зрения того, что он ожидает и как это будет работать с кодом бэкэнда. И теперь фронтенд просто будет использовать этот код. И тогда, как я сказал, у нас есть руководство по быстрому запуску, просто показывающее это. Вот как вы делаете свои миграции и все остальное, что вам может понадобиться сделать. И поэтому оттуда у нас есть наш план, верно? У нас есть очень четкий план. Следующий шаг — это, ну, нам нужно теперь разбить этот план на отдельные задачи, которые могут быть выполнены. И поэтому, возвращаясь к первому шагу, который, опять же, если вы начинаете с существующего проекта, очень ценно сделать, если это совершенно новый проект, не так важно, если вы пропустите его в начале, потому что вы еще ничего не построили или никаких соглашений, но все же может быть полезно запустить, чтобы у вас были базовые принципы, с которых вы начинаете. Но теперь, когда он прошел и создал все эти принципы для нас, например, как вы можете получить доступ к схеме, как на самом деле работают рабочие процессы журнала подсказок, все эти вещи, которые у нас есть в нашем проекте, которые являются важными принципами, которым нужно соответствовать. Я просто вернусь и обновлю план, что не является шагом, который вам нужно будет сделать, если бы вы сделали это в первый раз. Хорошо. Итак, теперь, когда все это улажено, я просто быстро сверну контекст, а затем мы перейдем к генерации задач. Теперь все, что нам нужно сделать снова, чтобы сделать это, это просто использовать наше обходное решение mention task.markdown, и мы скажем ему запустить рабочий процесс внутри подсказки. Теперь, опять же, что круто в этом, так это то, что он берет все другие файлы, которые мы создали. Итак, он смотрит на план, он смотрит на модели данных, он смотрит на исследование, которое мы провели, руководство по быстрому запуску, все, что мы сделали до сих пор, он втягивает на этом этапе, чтобы у него была высокая степень соответствия нашему первоначальному плану. Итак, теперь, когда этот процесс завершен, у нас есть полностью настроенный поэтапный список задач для выполнения этой функции. Теперь, что довольно круто, это то, что мы получаем эти флаги на некоторых из этих задач, которые имеют букву P. И что это означает, так это то, что система, если она поддерживает это, может запускать все эти задачи одновременно. Например, если бы мы собирались создавать тесты, которые работают на отдельном файле, нет никакого вреда в их одновременном запуске. вам не нужно беспокоиться о том, что они внесут одно и то же изменение в один и тот же файл или разные изменения, соответственно, в один и тот же файл, и это что-то испортит. Так что это довольно круто, и это позволяет нам проходить вещи гораздо быстрее. Итак, теперь у нас есть этот гигантский список задач. Что делать дальше? Итак, у нас есть два варианта. Во-первых, опять же, если бы мы использовали встроенную систему, мы могли бы просто запустить /implement или в этом случае нам пришлось бы упомянуть файл implement, и мы могли бы просто запустить это, и он пройдет и фактически будет управлять выполнением всего списка. Другой вариант заключается в том, что мы могли бы фактически пройти по каждой задаче из этого списка и сказать ему обрабатывать ее поэтапно, если бы мы хотели быть немного более точными в отношении того, что именно он делал и что происходило на каждом этапе. Теперь вопрос, который я получаю от многих людей, прежде чем мы это запустим, заключается в том, что делать со всеми этими другими определениями агентов и другими подсказками, которые довольно потрясающие, которые мы использовали в других видео? Например, для создания UX в UI в соответствии с нашими фактическими стандартами. И если вы хотите ссылку на эти подсказки и эти определения агентов, они находятся в группе ниже или, извините, по ссылке ниже в описании. А затем я также размещу видео где-нибудь здесь, где вы можете увидеть, как мы используем эти вещи. Но что вы можете сделать, это просто пройти сюда, например, для нашей философии дизайна UX и принципов UX. Мы можем пройти и скопировать их, а затем этот файл фактически принимает аргументы. Итак, мы можем сказать: «Эй, запустите этот файл, рабочий процесс в этом файле, с дополнительным контекстом ниже». И тогда мы можем фактически просто вставить все эти стандарты, и он интегрирует их при запуске. Или мы могли бы фактически оставить их в нашем репозитории и сослаться на файл и сказать: «Эй, это мои руководства по UX. Ссылайтесь на них, прежде чем создавать что-либо, что касается фактического пользовательского интерфейса». Итак, мы можем нажать go на этом и позволить ему сделать свое дело. Ладно, ребята. Итак, наступил следующий день. Мы просто дали этому полному выполнению задач пройти. Было немного туда-сюда, я, вероятно, потратил 15 минут на отладку небольшой мелочи здесь, которую я покажу вам. Но давайте посмотрим, что это построило. Когда мы нажимаем edit, теперь у нас есть этот раздел, который появился здесь, где мы можем, знаете ли, выбрать модель, которую мы хотим, а затем у нас есть эта опция для запуска улучшения. И поэтому у меня есть подсказка, которая является своего рода старой версией подсказки менеджера продукта. И проблема, с которой мы столкнулись, заключается в том, что это выделение не работало. И поэтому мне пришлось немного походить туда-сюда, честно говоря, чтобы это заработало. Но теперь, когда мы это сделали, мы можем выделить раздел, а затем он как бы сохраняет его в этом фиолетовом стиле шрифта. Теперь мы можем перейти и сказать, что мы хотим предварительно просмотреть улучшение. И поэтому мы получаем этот приятный маленький пользовательский интерфейс, который он генерирует, чтобы мы знали, что что-то происходит. А затем бац, он возвращается, и у него есть именно то, что мы просили. Итак, у нас есть старая подсказка на левой стороне, а затем новая подсказка на правой стороне. И мы можем видеть, я имею в виду, он вырезал хорошую часть, оптимизируя это. А затем мы можем получить приятный предварительный просмотр того, как на самом деле выглядит улучшенный выбор. Теперь единственное, чего здесь не хватает прямо сейчас, и на что мы собираемся посмотреть, это то, что на самом деле нет кнопки для сохранения этого обновления. Итак, он показывает нам обновление, но на самом деле не позволяет нам внести это обновление. Итак, это то, что мы собираемся сделать. Итак, мы вернемся в codeex и просто скажем ему именно это. Итак, вот что мы скажем им. Функция предварительного просмотра изменений работает нормально, но на самом деле у нее нет возможности сохранить ее прямо сейчас. И мы должны были построить все это с помощью нашего бэкэнд-конечной точки. Итак, я просто сошлюсь здесь на план, который мы разработали в SpecKit. А затем мы позволим этой штуке построить. Ладно, ребята. Итак, похоже, что это на самом деле было там все время. Решение было внутри нас все время. Итак, если мы поднимемся и перейдем к предварительному просмотру улучшения, то, что происходило, это то, что мой экран был слишком увеличен. И поэтому, когда это генерируется, посмотрите, это выглядело так, как будто его там не было, но если вы уменьшите масштаб, он там есть. Теперь, очевидно, это своего рода стилизация, которую нам нужно будет пройти и исправить, что я и сделаю, но в конечном итоге это действительно здесь. Так что это хорошо. Итак, да, действительно конкретный пример того, как мы можем использовать такой инструмент, как specket, для перемещения и создания, я имею в виду, в некоторой степени значимой существующей функции в приложении, не ломая вещи. Итак, это все, ребята, действительно приятная простая система для интеграции разработки, управляемой спецификациями, в существующий проект, или вы можете даже использовать ее для совершенно нового проекта. Итак, мой вызов вам: попробуйте это в одном из ваших проектов и дайте мне знать, как это прошло, потому что небо — это предел. И если вы хотите получить обратную связь о том, что вы строите, у нас есть бесплатная группа внизу в описании, где люди каждый день почти делятся тем, над чем работают, просят обратную связь, дают обратную связь. Это отличное место для построения вашей сети, обучения вместе с другими людьми, которые пытаются делать то же самое, и, честно говоря, для получения первоначальных пользователей даже для некоторых из ваших проектов. Кто этого не хочет? И о да, пока я здесь, если вам нравятся практические вещи, такие как это, обязательно подпишитесь на меня, чтобы ваша лента наполнилась практическими руководствами, которые действительно работают в реальной жизни. Итак, это все для этого видео. Увидимся в следующем.