Transcription
Сегодня мы рассмотрим один из лучших фреймворков для кодирования с использованием ИИ на планете Земля. Это инструмент, управляемый спецификациями, под названием Open Spec, и он решает некоторые из самых больших проблем, с которыми я сталкивался с другими фреймворками, плагинами и инструментами для кодирования. Так что, если вы никогда раньше им не пользовались и устали кричать в пустоту, потому что Claude Code не делает того, что вы ему сказали, в миллионный раз, то вы попали на правильное видео. И если вы уже пользовались им, то недавно они добавили новый расширенный рабочий процесс, который мы рассмотрим позже. Итак, очень быстро, где этот инструмент находится в экосистеме всех этих различных инструментов, которые у нас есть, таких как OBRA и GitHub spec kit и BMAD, и всех этих других вещей? Я думаю, что эти инструменты как бы разделяются примерно на три разные категории. Первая категория, к которой относится этот инструмент, я бы назвал инструментами, управляемыми спецификациями. Так что это будут такие вещи, как GitHub spec kit и, очевидно, OpenSpec, который мы сейчас рассматриваем, где спецификация, которую вы создаете, является основным артефактом, который управляет всем. И поэтому много времени обычно тратится на то, чтобы убедиться, что вы точно определились с тем, что собираетесь построить, а затем все обычно плавно следует отсюда. Таким образом, ментальная модель заключается в том, что в основном человек оркестрирует процесс, а агент помогает. Лично я считаю, что это лучший подход, если вы занимаетесь кодированием или если вы новичок в кодировании с помощью ИИ в целом, потому что он заставляет вас действительно четко понять, что именно вы строите и что оно должно делать.
Вторая категория, которую я бы назвал соблюдением жизненного цикла разработки программного обеспечения. Так что это такие вещи, как агентские навыки, суперспособности Ora и составное проектирование, где да, у них есть определенные рабочие процессы, через которые они вас проводят, но реальная ценность этих инструментов, с моей точки зрения, заключается в том, что они обеспечивают соблюдение лучших практик и дисциплины в фактическом процессе кодирования. Так, например, с Obra, что-то вроде разработки, управляемой тестами, их красный-зеленый рефакторинг — это очень важная вещь, которую нужно делать всякий раз, когда вы собираетесь что-то построить. И это не то, что, например, будет встроено обязательно в эти другие инструменты.
Итак, третья группа, которую я бы назвал более автономным конвейером. И это то, где мы обычно видим такие инструменты, как BMAD, например, или get done, где есть много инструментов, позволяющих вам определить что-то, а затем буквально отойти и вернуться, и вот, теперь что-то построено для вас без необходимости большого вмешательства. Итак, очевидно, существует пересечение между многими из этих категорий, но сегодня мы будем рассматривать OpenSpec и то, как он работает. Итак, в этом видео мы собираемся решить проблему, о которой я слышу от многих людей, особенно в моей бесплатной и платной группах, а также в комментариях к моим видео, которая заключается в том, что вы получаете эту первую версию чего-то вроде этого, и в итоге думаете, что это как-то уродливо и не совсем похоже на то, что я хочу, чтобы это выглядело, но вы потратили много работы, вы знаете, на создание вещей, и вы действительно хотите, чтобы это выглядело эффектно. И поэтому в этом случае я перешел в Claw Design и потратил некоторое время, пытаясь построить вещи так, чтобы они выглядели более профессионально и были чем-то, что я действительно хотел бы использовать. Например, вот как сейчас выглядит страница рецепта. И вот как она в идеале должна выглядеть. И поэтому мы попытаемся использовать инструмент разработки, управляемый спецификациями, чтобы преодолеть этот разрыв и построить все эти экраны шаг за шагом. И поэтому я очень ценю то, что вы можете связывать навыки вместе. Просто потому, что вы используете один из них, не означает, что вы не можете использовать другие. Поэтому я все еще буду использовать навык Ora по работе с рабочими деревьями Git, чтобы запустить это рабочее дерево, выполнить все мои тесты и убедиться, что у нас есть чистая базовая линия, прежде чем мы начнем.
Чтобы это заработало, все довольно просто. Все, что вам нужно сделать, это установить пакет с помощью этой команды, а затем перейти в свой проект и просто ввести `open-spec init`, выбрать свою среду, и с этого момента вы готовы к работе. Итак, одна из вещей, которая действительно крутая и которая мне нравится в этой библиотеке, это то, что у них есть этот навык онбординга. Так что, если вы новичок в этом, и это будет ваш первый раз, когда вы им пользуетесь, и вы хотите, чтобы он провел вас через процесс, если вы используете эту команду `onboard`, она фактически проведет вас через создание вашей первой функции с помощью этой системы. Но для того, чтобы показать вам все шаги и как мы будем их использовать, я собираюсь запустить это вручную. Что я собираюсь сделать, это я собираюсь вернуться в Claw Design и просто скопировать команду, которую они дают, чтобы позволить Claw Code получать эти дизайны. А затем я собираюсь пройти и запустить первую команду, которая называется `explore`. Так что я собираюсь запустить это, а затем мы сможем поговорить об этом. Итак, как и большинство хороших библиотек, у нее есть эта необязательная фаза исследования, где вы можете фактически обдумать идеи, прежде чем вы решите, как именно вы хотите двигаться и делать это. И поэтому мне действительно нравится, что вы не привязаны к какому-то очень специфическому способу делать вещи. И с многими другими инструментами именно это и происходит. У них есть свой предвзятый подход к тому, как вы должны проводить исследование, и это очень специфически связано с остальной частью процесса, и поэтому иногда нет большой гибкости в использовании этих вещей. Но вы можете вызвать эту команду практически в любой момент процесса, когда вы хотите углубиться в то, что вы собираетесь изменить. И это приятное преимущество по сравнению с чем-то вроде spec kit, который как бы предполагает, что вы сразу перейдете к спецификации и будете знать, что вы хотите построить. У него есть возможность действительно проработать это заранее. Так что, если вы использовали другие библиотеки, такие как compound engineering, у них есть эта функция `ideate`. Это как бы похоже, но опять же, немного более гибко.
Итак, после того, как он прочитает весь этот контекст, он начнет как бы рассуждать о том, что мы просили. И в этом случае есть несколько разных неоднозначностей, которые нам нужно пройти и ответить, потому что мы полностью меняем установленную систему дизайна, которую мы задокументировали в `design.md` и которая ссылается на использование в `agents.md`. Так что все эти вещи нужно обновить, очевидно, а затем нам придется также изменить структуру репозитория, потому что, исходя из информационной архитектуры, которая есть в новых дизайнах, она не будет очень чисто соответствовать тому, что у нас есть. Так что предстоит проделать немалый объем работы. Я вставил немного дополнительного контекста, который ему был нужен, и теперь он работает над уточнением частей плана. И одна вещь, которая мне действительно нравится в этом, это то, что он отмечает вещи, о которых нам нужно знать, прежде чем мы двинемся вперед. И поэтому этот процесс действительно ценен, потому что слишком многие люди склонны сразу же приступать к попытке построить вещь. И это означает, что любые предположения, которые всплывают по мере нашего разговора, языковая модель просто решит, что делать во время создания вещи. И тогда вы можете быть недовольны результатом. Так что эта функция `explore` — это действительно хороший способ обойти эти проблемы без большого количества церемоний и процессов, которые мы обычно имеем в других инструментах, таких как spec kit или BMAD, или некоторых из этих других систем. Но что мы делаем дальше? Как только это будет полностью исследовано, следующим шагом будет создание предложения. И поэтому то, что вы получите в итоге, это файл `proposal.md`, файл `system-design.md` и затем ваш список задач. Итак, в этом файле системы дизайна мы получим несколько разных вещей. Во-первых, это будут основные архитектурные решения. Например, в этом случае для этого проекта, как мы будем переносить все токены для системы дизайна? Как мы фактически построим эти компоненты внутри нашей системы, потому что они очевидно отличаются от того, что было внутри Claw Design? Как изменится наше маршрутизация приложений и фактическая архитектура самого приложения? Так что мы получаем кучу классных деталей, таких как это. Затем предложение больше о том, что фактически изменится в этом проекте. Например, миграция системы дизайна, создание новых экранов, создание новой библиотеки компонентов, обеспечение того, чтобы мы отслеживали, как наши модели данных и наши API должны будут измениться на основе нового пользовательского интерфейса, который мы строим, потому что я сказал ему, что не хочу делать все изменения на стороне сервера прямо сейчас. Верно? Верно? Так что это очень четкий журнал изменений того, что именно мы намереваемся изменить с помощью этой спецификации, а затем мы получаем поэтапный набор фактических задач, которые необходимо выполнить для реализации этой вещи. Таким образом, мы получаем "что" и "почему" того, что мы делаем, из предложения, "как" это будет сделано на высоком уровне из файла `design.md`, а затем мы получаем шаги реализации из файла задач. Так что это соглашение потрясающее, потому что все предположения и все решения очень четко документированы, и у нас есть действительно конкретные задачи на каждом этапе. И поэтому последняя часть этого, мы получаем этот новый каталог `specs`, где для каждого основного блока того, что нам нужно сделать. Например, миграция закладок, страница обнаружения, люди, за которыми вы следите, фактическая миграция системы дизайна, каждая из этих частей получает индивидуальную спецификацию с очень четкими сценариями о том, что именно должно быть там. Теперь, прежде чем мы перейдем к фактическому применению этих изменений и покажем, как выглядит рабочий процесс, одна вещь, которая мне действительно нравится в этом инструменте, это то, что у них есть функция `validate`. И поэтому, в этом случае, я хотел убедиться, что у него есть дополнительный проход, где он фактически проверит свою работу, используя расширение браузера Chrome MCP. И это не то, что встроено в процесс. Многие из этих инструментов, они склонны функционально описывать, как что-то должно работать, но они не часто описывают визуально, как вещь действительно должна выглядеть. И это становится проблемой, если вы пытаетесь мигрировать систему дизайна из другого инструмента. И поэтому все, что мы попросили его сделать, это добавить шаг, где он должен это проверить. И теперь, когда он создал эту новую спецификацию, он пройдет и проверит ее, чтобы убедиться, что мы не потеряли никаких критических деталей в нашей спецификации, которые мы будем использовать для фактического создания этих вещей.
Итак, теперь мы запустим финальную команду, которая называется `apply`. И затем мы просто передадим каталог, который он дал нам для этого проекта, или идентификатор этого проекта. И мы позволим ему работать. Теперь, небольшое примечание, я действительно запустил Claude с флагом Chrome, чтобы он мог фактически взаимодействовать с браузером, пока он проверяет свою работу. Теперь этот процесс наличия визуальной проверки на стороне фронтенда на самом деле является одной из вещей, которая входит в стек советов Claude Code Creators, которая может оказать самое большое улучшение на то, что вы получите в итоге этих типов задач кодирования. Хорошо, ребята. Итак, эта штука работала около 2 часов подряд без какого-либо вмешательства с моей стороны. Единственное, что я сделал, это в определенный момент я включил автоматический режим, чтобы он перестал останавливаться, чтобы задавать мне вопросы. Так что на самом деле с этими остановками это заняло, возможно, 3 или 4 часа. Но если бы он был в автоматическом режиме, фактическое время обработки заняло бы 2 часа и 8 минут. И снова, это включает в себя фактическое выполнение всей работы, а также выполнение проверки, которую мы внедрили, где он использовал Chrome для фактического просмотра экранов. И поэтому мы еще не видели, как это будет выглядеть, но это должно быть по крайней мере близко к нашим дизайнам. Так что давайте быстро посмотрим, а затем вернемся и сделаем последний шаг. Итак, есть несколько вещей, на которые я особенно хочу обратить внимание, потому что были некоторые аспекты приложения, которые меня больше всего беспокоили. Первое — это страница обнаружения, которая у нас есть. Итак, мы видим, что это очень четкий дизайн. У нас есть эта боковая панель. Очевидно, боковую панель нужно немного доработать, потому что она не соответствовала спецификации. Но затем у нас есть этот раздел героя, что готовится сейчас. У нас есть эти маленькие опции поиска фильтра. Затем у нас есть этот раздел героя, который представляет собой обновленные более свежие вещи. А затем он как бы продолжается в некотором роде в редакционном стиле. Итак, если мы перейдем к экрану, он выглядит довольно близко к этому. Итак, я на очень большом экране, и поэтому некоторые из пробелов, насколько близка боковая панель к этой средней колонке, этот пробел немного испорчен. Так что мы можем решить такие вещи. Но в целом, этот верхний раздел, как он стилизован, маленькие детали, такие как имя человека и что это был за рецепт, трендовые форки, редакционный выбор, все эти [хмыкает] вещи довольно точны. Так что я очень доволен этим. Другая вещь, которая меня очень беспокоила, это страница профиля пользователя. Так что, если бы мы, например, нажали на REN, раньше это было очень просто, как будто ничего не было. И теперь, если мы зайдем и посмотрим, каким должен был быть дизайн. Итак, мы видим здесь, что есть несколько вещей, которые не так. Это должен быть акцентный цвет. Выравнивание на некоторых из этих кнопок, они должны быть примерно одного размера. Одна должна быть акцентированной. Так что есть несколько вещей, которые нам нужно будет доработать. Но в целом, для такого масштабного рефакторинга системы дизайна, это очень близко к тому, что мы просили. Даже эта страница рецепта — это огромное обновление по сравнению с тем, что было раньше. Я очень доволен тем, как он прошел через эту первую версию того, что мы просили. И снова, конкретный аспект того, что мы делали, объясняет, почему он смог сделать это так эффективно. Итак, у него были четкие функциональные требования и четкие шаги проверки, а затем у него также были эти эталонные дизайны, которые он знал, что нужно проверить. Так что это отличные работающие вещи. Но одна из удивительно полезных вещей — это то, как они завершают ветку функций. И это одна из вещей, которая делает этот инструмент отличным в использовании. Так что, если мы пройдем здесь сейчас и запустим команду `archive`, по сути, это синхронизирует все различные спецификации и контекст, который был построен и собран вокруг них, с корневым источником истины о вашем приложении. И это одна из вещей, которая мне действительно нравится в этой библиотеке. Многие люди жалуются на то, как сложно управлять документацией своего приложения с течением времени. И вот как OpenSpec помогает вам управлять этим. Так что, если мы зайдем в эту папку `openspec`, где все это находится, вы заметите, что вся работа, которую мы делали, была внутри этой папки `changes`. И поэтому, как это работает, это то, что каждая новая функция, которую вы создали, в данном случае мы создали несколько из них. Итак, у нас был этот новый вид закладок, у нас была страница обнаружения, у нас была страница подписки, у нас было обновление системы дизайна. Все эти разные вещи получат свой собственный файл спецификации. И причина, по которой это ценно, заключается в том, что когда в будущем будет внесено изменение, у нас будет постоянный источник истины, описывающий, как эта вещь должна работать. Например, если мы спустимся сейчас и посмотрим на спецификацию закладок, у нас есть очень четкий набор требований, а затем сценарии пользовательских историй, которые объясняют функционально, что должно происходить в этой области. Теперь причина, по которой это ценно, заключается в том, что в дальнейшем, если мы внесем изменение в нашу функциональность закладок в приложении, когда мы затем архивируем это изменение, как мы только что сделали, если мы сделали что-то, что теперь нарушает критическую часть этой спецификации, это вызовет эту проблему и заставит нас примирить ее там, чтобы у нас не было таких "черных лебедей" или вещей, которые просто скрыты в нашем проекте, и мы не осознаем, что сломали. Так что снова, это заставляет вас иметь этот живой набор спецификаций для всех основных функций вашего приложения. И поэтому после всего этого мы получаем эту папку `archive`. И если мы зайдем сюда, все, над чем мы работали, например, эта миграция системы дизайна, вся эта информация фактически сохраняется, чтобы мы могли всегда вернуться и обратиться к ней, если нам это понадобится. Так что все задачи, над которыми мы работали, предложение, как мы собирались обеспечить визуальную точность, все это теперь сохранено для нас, чтобы мы могли всегда вернуться и посмотреть это позже.
Итак, это базовый рабочий процесс, но есть три других рабочих процесса, которые вы можете использовать и которые решают множество проблем, возникающих с другими инструментами. Итак, первый — это фактически два разных рабочих процесса, которые вы используете вместе, и они называются `new` и `continue`. Одна из парадигм этого инструмента, которая, на мой взгляд, действительно выделяет его по сравнению с другими, заключается в том, что он принимает итеративный подход к планированию. Например, у вас может быть какая-то идея, вы начинаете ее планировать, но затем появляется информация, и вы хотите интегрировать эту информацию в свой дальнейший план. Итак, один из способов, которым они решают эту проблему, — это эти две новые команды: `new` и `continue`. Итак, мы запустим команду `new`, и, по сути, мы скажем, что теперь, когда это изменение на стороне фронтенда сделано, нам нужно создать функциональность на стороне бэкенда, чтобы маршруты API были там, модели данных были на месте, и все было хорошо, чтобы мы могли фактически, вы знаете, сделать это. И поэтому мы начнем с команды `new`, чтобы начать двигаться в этом направлении. И поэтому, что это делает, это создает оболочку для нас, чтобы пройти через аналогичный процесс, который мы прошли раньше. Итак, что мы сделаем, чтобы продолжить этот процесс сейчас, это ввести `opsx continue`, и затем, если есть какие-либо вопросы, на которые нам нужно ответить на основе этого, мы можем ввести наши ответы здесь. Итак, в этом случае у меня есть два варианта. Один — я могу сделать одно огромное изменение со всем, что в нем есть. А второй — я могу разделить эти изменения на более сфокусированные изменения, а затем брать их по частям, где каждое отдельное изменение получает свое собственное предложение, спецификации и задачи. Теперь, поскольку это затрагивает логику бэкенда, я действительно хочу убедиться, что мы ничего важного не упустим. Поэтому я решил пройти и разделить его таким образом, что займет больше времени, но, вероятно, будет сделано лучше. Итак, теперь в этом случае, поскольку у нас есть все эти разные части, через которые мы будем двигаться, мы можем снова запустить команду `new`. Но в этом случае мы говорим, ну, что мы хотим запустить? Ну, в данном конкретном случае мы работаем по частям. И поэтому мы пройдем весь этот процесс создания предложения, применения изменений и их архивирования для каждой из этих отдельных частей. Итак, мы можем видеть, аналогично тому, как у нас была эта структура для этого более широкого плана, у нас теперь есть та же структура для этого очень конкретного изменения. Итак, теперь, если мы спустимся и запустим команду `continue`, что она сделает, это она составит предложение. Итак, аналогично тому, как раньше мы запускали команду `propose`, теперь мы делаем это поэтапно. И вместо того, чтобы нам приходилось вызывать конкретную команду, мы просто проходим процесс, используя эту команду `continue`. Итак, разница, которую мы можем увидеть сейчас, заключается в том, что когда мы переходим к этому конкретному экземпляру изменения для подключения чтений публичного профиля, вместо того, чтобы генерировать все эти вещи одновременно, как мы делали в прошлый раз, теперь у нас есть только часть предложения. И поэтому мы можем пройти, мы можем прочитать это, мы можем убедиться, что мы на одной волне. И затем отсюда, если мы пройдем и запустим команду `continue`, она перейдет к генерации спецификаций. Теперь причина, по которой это действительно ценно, заключается в том, что раньше мы смотрели на команду `explore`. Так что, если в любой момент мы находимся в середине этого процесса, и что-то возникает, с чем мы как бы не знаем, как лучше всего справиться, мы можем запустить команду `explore`. Мы можем обсудить проблему, а затем интегрировать это изменение в тот этап, на котором мы находимся сейчас. Так что эта библиотека очень хорошо генерирует контекст, сохраняет его в очень разумном виде, а затем позволяет вам легко перейти к следующему этапу. Итак, одна из вещей, которая действительно приятна, это то, что если в любой момент мы считаем, что план уже достаточно хорош, и мы просто хотим, чтобы он прошел через остальные этапы, мы можем запустить команду `fast-forward`. И поэтому это позволит нам двигаться намного быстрее, но при этом оставаться на рельсах. Как будто он все еще следует системе, которая обеспечивает лучший способ делать вещи и иметь вашу спецификацию на месте, а затем разрабатывать на основе этой спецификации и делать все, что вы там определили. И поэтому это очень похоже на то, что мы делали в парадигме `new` и `continue`, за исключением того, что он просто будет автоматически продолжать двигаться дальше. Итак, это теперь завершено, и это подводит нас к последней функции, которая, я думаю, является одной из самых ценных вещей в том, как работает эта библиотека, и это команда `sync`. Итак, по сути, это помогает вам вести постоянный учет фактического состояния всех различных функций вашего приложения, чтобы вам не нужно было беспокоиться о том, что документация выйдет из-под контроля и быстро устареет. Так что, если мы вернемся в эту папку `master-specs` и прокрутим вниз до `public-profile`, мы увидим, что она была обновлена на основе этой работы. Итак, вся эта дополнительная информация здесь о требованиях и о том, как должна выглядеть база данных, и обо всем этом, все это основано на работе, которую мы только что проделали в этом изменении. Итак, у нас уже была спецификация публичного профиля, которая существовала, но теперь она была обновлена работой, которая только что произошла. Так что всякий раз, когда мы вносим какие-либо изменения, которые затрагивают что-то, что уже существует, у нас есть этот встроенный шаг, который вернется и фактически обновит документацию, чтобы вещи никогда не терялись и никогда не выходили из контакта с реальностью того, что там есть. И это огромное добавление ценности, которое вы не получаете с многими другими инструментами нативно.
Итак, эта библиотека довольно велика, и я думаю, что для повседневного рабочего процесса, особенно того, который вызывает другие плагины, такие как OB или аналогичные библиотеки, когда они вам нужны, например, с выполнением под-агента или разработкой, управляемой тестами. Это, безусловно, новый ежедневный драйвер, особенно если вы работаете над существующим проектом. Итак, если вам понравилось это видео, я оставлю ссылку на плейлист с другими разборами подобных инструментов, которые я сделал. Но на этом все для этого видео.