Transcription
90% кода с использованием ИИ терпит неудачу из-за одного простого ингредиента — структурированного контекста, потому что он заставляет вас думать о том, что именно вы предоставляете модели. Поэтому неудивительно, что, когда IDE Kira была выпущена Amazon, все были в восторге. Единственная проблема заключалась в том, что если вы не присоединились в первый же день, вы, вероятно, не получили к ней доступа. Так грустно. Но пока все борются за доступ к Kira, GitHub бесплатно выпустил свою собственную версию. Итак, в этом видео я покажу вам, как превратить Cursor, Gemini CLI или Cloud Code в производственную систему разработки всего за 15 минут. Мы пройдемся по каждому из трех этапов: определение того, что строить, планирование того, как это строить, а затем постановка задач для выполнения. Это видео будет очень полезно для вас, если вы уже пишете код с помощью этих инструментов, но у вас все еще бывают те разочаровывающие моменты, когда вы тратите часы и часы на код, который в итоге приходится выбрасывать. Итак, третий этап использует скрытую структуру подсказок, которая, на мой взгляд, является ключом к тому, почему эта система работает так хорошо. Так что обязательно оставайтесь с нами. Итак, теперь мы приступим и установим эту штуку. Одна из самых больших проблем, с которой сталкиваются кодеры, заключается в том, что они подходят к проекту, как будто это поток сознания. Но когда вы пытаетесь создавать высококачественное программное обеспечение или что-то более крупное, такой подход вызывает множество проблем, потому что вы начинаете собирать все вместе как Франкенштейна, и вы испытываете значительную потерю контекста. И вы, вероятно, знаете, о какой боли я говорю. В тот момент, когда вы очищаете контекст или начинаете новый чат с Gemini, Claude или Cursor, он начинает предлагать шаблоны или создавать вещи, которые противоречат тому, что вы только что построили. И поэтому разработка, основанная на спецификациях, может помочь нам преодолеть эти проблемы, потому что мы подробно прорабатываем детали и планируем по слоям, а затем уточняем этот план по мере продвижения, прежде чем начать строить. Другими словами, вместо того, чтобы просто направлять нашу реализацию, спецификации становятся тем, чему система фактически следует. Таким образом, specit имеет три основных этапа: Specify (Указать), Plan (Планировать) и затем Tasks (Задачи). Сначала мы хотим описать, что мы хотим построить на высоком уровне, верно? Что и почему. Затем мы хотим уточнить это в план, а затем разбить этот план на задачи. Единственное предварительное условие здесь — это то, что у вас должен быть загружен UV. Я оставлю ссылку на это ниже. Если вы используете Homebrew, вы можете установить его довольно легко с помощью их команды здесь, но у них есть много разных вариантов в зависимости от точной системы, с помощью которой вы предпочитаете его загружать. Итак, это первое, что вам нужно иметь установленный UV. Отсюда все, что вам нужно сделать, это скопировать эту команду. И затем мы перейдем в наш терминал и инициализируем эту штуку. Самый простой способ сделать это — просто перейти в каталог, с которым вы хотите, чтобы это работало. Вставьте эту команду. А затем после init type dash здесь, он проведет вас через определение того, какой ИИ-ассистент вы используете. Мы можем сказать cloud code. Я выберу bash для своего скриптинга. И затем он пройдет через все, и все будет настроено и сконфигурировано. Итак, давайте посмотрим, что у нас есть. И первое, что вы заметите в вашем дереве файлов, это то, что у вас теперь есть каталог под названием specify, а затем он также создал три команды в стиле слэш внутри claude. Эта система — действительно секретный соус, который заставляет все это работать, потому что они загружают шаблоны того, как выполнять эти различные части, скрипты, которые система может использовать для фактического выполнения различных частей. А затем он ведет постоянную память о важных вещах, связанных с вашим проектом, которые вы можете изменить. И затем все это фактически выполняется через команды claude, в данном случае, потому что мы используем claude. Таким образом, мы по сути просто установили младшего архитектора, который никогда не забудет ваш контекст. Но теперь, когда он фактически подключен, давайте заставим его работать. Возвращаясь и ссылаясь на этот репозиторий GitHub, первое, что мы хотим сделать, это использовать команду specify. Итак, мы хотим точно сказать ему, что мы хотим построить, потому что без этой специфичности мы полагаемся на интерпретацию языковой модели, чтобы заполнить эти пробелы за нас. Что вызывает вопрос: строим ли мы приложение мы, или мы просто передаем все принятие решений языковой модели, которая просто сделает то, что захочет? Ну, мы действительно хотим управлять этой системой, потому что если вы этого не сделаете, вы получите много результатов, которые вам не понравятся, потому что каждое неоднозначное требование фактически превратится в 100, 200, 300 строк неоднозначного кода, который даже не делает того, что вы хотели. Так что, если вы пропустите это, вы в конечном итоге будете перестраивать одну и ту же функцию три, четыре, пять раз, а у кого есть на это время. Итак, давайте используем это, чтобы добавить функцию в существующее приложение. Вот базовое приложение, которое у меня есть, которое я использую для себя, и мы будем использовать его, чтобы добавить новую функцию в наше приложение, потому что многие из вас спрашивали, вы, кажется, каждый раз строите все с нуля. Как мы можем просто добавлять существующие функции в приложения с помощью этих инструментов? Итак, вот что я покажу. Когда я впервые построил это, у меня была идея, что у меня будет история версий. То есть, если я внесу изменения в эту подсказку, а затем буду использовать ее и захочу увидеть, какие подсказки на самом деле дают мне лучшие результаты с течением времени, я смогу отслеживать это, а затем возвращаться к предыдущим версиям подсказок, которые я часто использую. Итак, мы создадим эту функцию истории версий. Я буду подсказывать это здесь с помощью /specify, а затем я введу то, что я намерен построить. Я хочу добавить в приложение функцию, которая отслеживает историю версий изменений подсказок, и пользователь должен иметь возможность просматривать, например, сравнение бок о бок этих изменений. Итак, я нажму Enter и запущу это. Как только эта штука закончит работу, вы заметите, что у нас появился новый каталог specs, который был создан, а затем внутри него у нас есть первая спецификация функции под названием spec.markdown. Что действительно приятно в этом, так это то, что он проходит, смотрит на то, что вы намерены построить, а затем оставляет все эти области, где написано "требуется уточнение". Это как бы конкретные вопросы, которые система задает вам, которые вам нужно заполнить, чтобы получить действительно хорошо определенную, проработанную функцию, которая работает так, как вы хотите, с самого начала и не имеет всех этих странных крайних случаев, которые не учтены. Так что это большое преимущество, потому что оно позволяет нам на этом этапе проработать всю эту неоднозначность и фактически точно настроить план, прежде чем мы перейдем к следующему этапу планирования. Каковы некоторые примеры? Может ли пользователь фактически вернуться к предыдущей версии? Что происходит, когда подсказка удаляется? Удаляете ли вы всю историю версий этого, и она как бы исчезает? Разрешаете ли вы нескольким пользователям одновременно редактировать один и тот же файл? Например, нужна ли функция совместной работы? Каково максимальное количество версий, которые могут быть фактически сохранены в этой штуке? Все эти разные вопросы, на которые нам нужно ответить. А затем, когда мы дойдем до фактических функциональных требований, у нас есть тот же набор уточнений, которые нам нужно предоставить системе. Например, как долго должна фактически храниться история версий? Это все вещи, о которых мы хотим подумать, чтобы система построила именно то, что мы хотим. Итак, я прошел и примирил все неоднозначности. И это здорово, потому что теперь у нас есть этот очень конкретный список требований, которые необходимо выполнить, чтобы мы могли считать эту штуку фактически завершенной. И снова, это заставляет нас действительно думать о том, что мы строим, и не тратить время позже. Принуждая себя думать о требованиях заранее, вы фактически становитесь менеджером продукта для своих собственных проектов. Таким образом, эта пятиминутная инвестиция экономит вам пять часов рефакторинга в дальнейшем. И что более важно, это предотвращает бесконечный цикл "мда, это не совсем то, что я пытался построить". Потому что это чувство действительно убивает ваш импульс и разрушает вашу мечту о создании чего-то крутого. Но как только у нас это есть, мы сразу переходим к задачам и кодированию? Нет. Нам нужно превратить эти спецификации теперь в реальный план. У нас есть этот список требований, но теперь нам нужно перейти к тому, как мы намерены их реализовать. Потому что для кажущейся простой функции есть много способов ее реализовать, и есть много исследований, которые вы должны провести, чтобы убедиться, что вы выполняете ее правильно. Так что, если вы пропустите этот этап планирования, вы будете кодировать себя в угол, который потребует полного переписывания. Такой процесс — это то, как реальные команды разработчиков предотвращают эти архитектурные катастрофы. И подсказка: именно поэтому многие настоящие разработчики программного обеспечения устремились к Kira, когда она только появилась. в то время как кодеры, основанные на вибрациях, просто сидели сложа руки. Итак, теперь мы запустим команду plan, и здесь мы можем дать ей любые конкретные детали, такие как текстовые стеки или другие архитектурные решения, которые у вас уже есть на уме. Для этого проекта я уже использую superbase и nex.js, а также множество других библиотек, и поэтому это уже есть. Поэтому я просто буду ссылаться на эти вещи. Но если вы строите что-то, что потребует использования новой технологии или ее привлечения, вы можете указать это здесь. И теперь вы заметите, что после завершения этого шага мы получаем много от этого. Итак, у нас есть не только полный файл плана с множеством деталей о том, как фактически реализовать эту штуку, и технологический стек, и где все интегрируется, но мы получаем много других вещей. Итак, мы получаем этот исследовательский документ, который говорит о ключевых архитектурных компромиссах или принятых решениях, почему это решение было принято и какие альтернативы рассматривались. Так что это очень полезно, чтобы пройтись и увидеть контекст того, что было решено. Мы также получаем нашу модель данных, что означает, что у нас будет довольно четкое понимание того, как должны выглядеть наши данные, чтобы фактически реализовать этот тип функции для этой истории версий и все связанные с ней определения. Еще одна очень потрясающая вещь, которую мы получаем из этого, называется API-контракт. Это означает, что он подробно перечислит все различные конечные точки API для этой функции и конкретные параметры, которые он принимает, а также то, что он будет отвечать на фронтенде. Причина, по которой это действительно важно, заключается в том, что это станет источником истины для всего, что мы строим на фронтенде для этой функции, потому что мы уже знаем, к чему будет иметь доступ бэкенд, что он ожидает получить и что он должен отправлять обратно. Итак, теперь последний этап — это генерация задач для этого плана. Опять же, многие люди пропускают этот шаг и удивляются, почему их код кажется фрагментированным или дрянным. Между тем, мы только что получили архитектурные консультации на 5000 долларов за несколько минут от GitHub spec kit. Но, правильно проводя это исследование и внося конкретные детали в вашу архитектуру, вы готовите себя к успеху в будущем. И вот в чем разница между созданием чего-то, что вроде бы работает, но часто ломается, и чего-то, что на самом деле масштабируется. Итак, у нас есть все эти замечательные вещи: наш план, наши исследования, наша модель данных, наши контракты, краткое руководство по началу работы, все такое. Последнее, что нам нужно сделать, это сгенерировать задачи. И настоящим препятствием здесь, и именно поэтому мне нравится этот инструмент, потому что он помогает его преодолеть, является то, что мы не хотим, чтобы задача семь противоречила чему-то, что мы сделали в задаче три. И поэтому мне нравится этот подход, потому что наши списки задач имеют прямые ссылки на то, что мы сделали на предыдущих этапах. А задачи без контекста — это, по сути, просто утонченные списки дел, которые не обязательно знают, что вы уже сделали. Таким образом, настоящая ценность здесь заключается в том, что мы получаем истинный набор задач, основанный на работе, которую мы проделали на других этапах. Итак, мы только что запустили это в cloud code. Давайте дадим ему закончить. Теперь мы можем видеть, как эта штука работает, она извлекает всю документацию, которую она создала. Она читает план. Она читает модель данных. Она проверяет API-контракты. Она понимает краткое руководство по началу работы, которое у нее было. И теперь она загружает свой шаблон того, как она будет создавать задачи. И она проходит через и фактически создает этот файл задач. И вот как выглядит этот список задач, когда он закончен. Это действительно четкий поэтапный подход с большим количеством деталей и специфики о том, где найти существующие данные, куда должны быть помещены определенные файлы, как определенные файлы должны взаимодействовать друг с другом. И поэтому мы можем перейти отсюда и реализовать эти задачи. Итак, ребята. Вот как выглядит окончательная версия этого после первого прохода. Мы создали этот маленький инструмент истории версий. Позвольте мне фактически обновить экран, чтобы вы могли увидеть, как он выглядит. Итак, если я зайду сюда сейчас и внесу изменения, скажем, я вставлю это несколько раз и нажму сохранить. Теперь, когда мы прокрутим вниз, у нас есть этот трекер истории версий. Я могу сказать, что хочу сравнить версию один с версией 4, например, и нажать "сравнить". А затем ниже мы получим что-то вроде сравнения в стиле git между изменениями, которые мы внесли между каждой из этих частей. Очевидно, все изменения, которые я внес, были здесь. И поэтому он показывает мне это. Довольно круто. И снова, все это сделано с помощью этого GitHub spec kit. И разработка этого, кстати, была довольно быстрой, относительно говоря, учитывая, сколько деталей вложено в создание этой вещи правильно с первого раза, со всеми тестами, которые она проводит, и всем таким. Так что это сохранение контекста означает, что вы не начинаете с нуля каждый раз, когда очищаете контекст и начинаете создавать новую функцию. По сути, вы создали повторяемую систему для преобразования идей в то, что вы можете фактически построить, что является Святым Граалем разработки с помощью ИИ. >> Вы сделали мудрый выбор. >> Итак, теперь, когда у вас есть многоразовый чертеж, следующая функция будет в 10 раз быстрее. Так что помните, ребята, три этапа, ноль неоднозначности, готовый к производству код каждый раз. Это создает систему для повторяемого успеха, что было бы здорово, если бы у нас было больше этого в нашей жизни. Разработка на основе спецификаций — это не замедление. Это никогда не возвращаться назад. Так что выходите и используйте эту систему для себя. Для получения более практических руководств, подобных этому, обязательно подпишитесь на канал, чтобы не пропустить следующие видео. Но это все. Увидимся в следующем.