Transcription
Подумайте о последнем разе, когда вы просили ИИ-инструмент написать код. Вероятно, он выдал вам что-то, что выглядело правильно, но не совсем работало. Именно здесь "вайб-кодинг" (vibe coding) терпит неудачу. Но это может быть не проблема конкретной модели, которую вы используете. Скорее всего, это связано с недостаточной ясностью спецификаций. Вот где разработка, управляемая спецификациями (spec-driven development), приходит на помощь.
GitHub только что выпустил новый набор инструментов с открытым исходным кодом под названием SpecKit, который полностью меняет правила игры. Сегодня мы рассмотрим SpecKit, посмотрим, как он работает, и я покажу вам небольшой демо-пример его использования, и мы выясним, действительно ли это будущее программирования.
В традиционной разработке вы пишете код, а затем документируете, что он делает. В разработке, управляемой спецификациями, вы делаете наоборот. Вы пишете спецификацию, живой исполняемый артефакт, и эта спецификация определяет, что вы намерены создать. Отсюда все заинтересованные стороны и ИИ-инструменты выравниваются вокруг одного источника истины. Этот подход устраняет разрывы между намерением и реализацией и приводит к более чистому, безопасному и надежному коду.
Основная идея заключается в том, что языковые модели отлично справляются с шаблонами, но не так хорошо читают ваши мысли. Широкие запросы, такие как "Добавь функцию обмена фотографиями в мое приложение", заставляют ИИ угадывать тысячи деталей, большинство из которых никогда не соответствуют вашему реальному намерению. Разработка, управляемая спецификациями, устраняет это угадывание. Она дает ИИ четкие структурированные указания, чтобы он создавал именно то, что вы хотите.
Несколько месяцев назад Amazon запустила Kira, которая стала первой платформой, действительно сосредоточенной на разработке, управляемой спецификациями. А Джеймс сделал отличный глубокий обзор этого в отдельном видео, если вы хотите посмотреть его здесь. Но теперь на сцене новый игрок, SpecKit. Это набор инструментов с открытым исходным кодом от GitHub для разработки, управляемой спецификациями, с ИИ-агентами для кодирования. Он включает в себя инструмент командной строки (CLI), шаблоны и направляющие запросы, разработанные для работы с такими инструментами, как GitHub Code Pilot, Claude Code и Gemini CLI. Он призван трансформировать ваши произвольные запросы в структурированный, проверяемый рабочий процесс разработки.
Вот как это работает. Specit организует вашу разработку в четыре этапа с контрольными точками проверки перед переходом к следующему. Первый этап — "Specify" (Указать). Здесь вы описываете, что хотите создать и почему, фокусируясь на пользовательских сценариях и результатах. ИИ-агент использует это для генерации подробной спецификации, которая также развивается по мере роста вашего понимания.
Второй этап — "Plan" (Планировать). Этот этап определяет стек технологий и архитектурные ограничения. Вы сообщаете агенту свои спецификации, и он составляет технический план, который соответствует этим ограничениям.
Третий этап — "Tasks" (Задачи). Здесь спецификация и план разбиваются на небольшие выполнимые задачи. Это дает вам управляемые, тестируемые единицы, которые ИИ может реализовывать по одной.
И четвертый этап — "Implement" (Реализовать). Здесь ИИ поэтапно решает задачи. Вы можете просматривать каждое изменение перед реализацией вместо того, чтобы запускать громоздкие пакеты кода. Таким образом, модель знает, что создавать, как создавать и на чем сосредоточиться. Вы можете проверять и уточнять это на каждом шаге. Это дает вам полный гранулярный контроль над выполнением.
Этот набор инструментов родился из разочарования тем, что модели кодирования вели себя как поисковая система, а не как буквальный парный программист. По сути, это сдвиг в сторону намерения как источника истины. Вместо кода спецификация становится авторитетным артефактом, и модели постоянно возвращаются к документу спецификации для получения указаний о том, как действовать дальше.
Итак, теперь я покажу вам на небольшом проекте, как мы можем использовать specit в наших собственных проектах. Для начала вам нужно просто выполнить эту команду в вашем терминале, указав имя проекта, а затем выбрать, какой агентный фреймворк использовать. В этой демонстрации я буду использовать GitHub Copilot. Набор инструментов инициализирует все необходимые файлы для вашего проекта, а затем вы можете открыть рабочую область в вашем редакторе кода.
Первое, что вы увидите, когда откроете редактор кода, это то, что specit создал папку "script" и папку "templates". И это просто стандартные шаблоны спецификаций, которые используются для генерации ваших фактических файлов спецификаций. А скрипты — это те, которые выполняются и подготавливают эти документы. Нам не нужно ничего здесь менять. Мы можем просто приступить к подготовке нашего проекта, набрав "specify" (указать) с последующим запросом. Этот начальный запрос должен быть общим описанием вашего проекта, какова цель, каковы основные функции, и, возможно, даже описать, как выглядит простой пользовательский сценарий. В этом примере я буду создавать простой конструктор команд Pokedex, где я смогу искать покемонов и добавлять их в свою команду. Я также буду использовать Grok Code Fast 1 в качестве базовой модели для этого проекта. Итак, давайте выполним команду.
И как только это будет сделано, вы увидите, что specit создал новую ветку для этой разработки и также создал файл спецификации в формате markdown. В этом файле мы видим, что модель успешно поняла задание и создала основную пользовательскую историю вместе с сценариями приемки. Мне также нравится, что она думает об крайних случаях и других потенциальных препятствиях. И всякий раз, когда модель сталкивается с ситуацией, когда она не может решить, как действовать дальше, она добавляет этот блок под названием "needs clarification" (требуется уточнение). Таким образом, вы можете сами указать требования. И мы также можем увидеть здесь, что она составила некоторые функциональные требования и ключевые сущности. Честно говоря, это очень круто, потому что мне было бы слишком лень писать все эти детали, чтобы модель могла им следовать. Так что хорошо, что SpecKit способен направлять модель для создания всего этого для нас. И помните, если вы когда-либо захотите что-то здесь изменить или решить полностью другое направление, это тот файл, где вы можете внести эти правки. Но если мы довольны файлом спецификации, дальше мы можем перейти к этапу "plan" (планировать).
И здесь мы должны более конкретно описать стек технологий нашего приложения вместе с другими деталями, которые мы считаем необходимыми. Здесь я просто вставил некоторые основные технические требования для проекта вместе с другими полезными командами, такими как использование "debounce" (задержка) на конечной точке поиска покемонов, чтобы мы не перегружали API. И как только вы будете довольны всем этим, давайте выполним команду "plan" (планировать). И вы можете увидеть здесь, что specit становится более детальным. Он добавляет модель данных и исследовательский документ, а также контракты для типов объектов, что очень круто. И в файле модели данных он даже составил объект схемы Zod. Но мне очень нравится исследовательский документ, потому что здесь мы можем увидеть обоснование выбора моделью конкретных фреймворков, и он также дает нам объяснения о своих рассуждениях, а также другие соображения относительно альтернативных решений, и он также уважает выбранный вами стек технологий, плюс он пытается подумать о других необходимых вещах, которые вы, возможно, не учли. Так что это действительно мощно.
Затем мы переходим к файлу "plan" (план), который изложил все этапы разработки в конкретных шагах и также отметил те, которые уже завершены. Все это выглядит очень хорошо для меня. Так что теперь мы можем перейти к следующему этапу, этапу выполнения задач. Теперь у нас уже есть спецификация и план. Поэтому для команды "tasks" (задачи) мы можем просто начать с просьбы к модели создать MVP-версию нашего проекта. И вот где происходит магия. SpecKit теперь создаст очень подробный список задач, который пошагово описывает, что нам нужно сделать, чтобы достичь нашей цели разработки. Давайте откроем список задач. И мы можем увидеть здесь, что каждой задаче присвоен уникальный номер. И это поддерживает все в порядке и организованно. Так что вы можете выполнять задачи по порядку и просматривать их по мере выполнения. Я вижу здесь, что задачи с первой по четвертую посвящены настройке среды. Так что давайте попросим модель выполнить их. Для этого этапа нет команды с косой чертой, но, насколько я понимаю, рекомендуемый способ действий — это написать "implement" (реализовать) с последующими номерами задач, чтобы сообщить модели, какие задачи выполнять в конкретной команде. Итак, сначала давайте выполним задачи по настройке, чтобы вы также могли отслеживать прогресс. Так что с этого момента это очень свободный подход, просто спрашивая модель, какие задачи реализовать, а затем просто следуя за процессом, наблюдая за прогрессом и итерируя процесс. И как только они будут выполнены, мы увидим, что модель также отметила их как завершенные. Я заметил, что в этом конкретном шаблоне, который у них есть, он очень любит подход разработки, управляемой тестами (test-driven development), где он сначала пишет тесты, а затем реализует функции. Вы, вероятно, можете изменить это в спецификации или плане, если хотите выбрать другой подход к разработке.
Итак, после нескольких команд и итераций моя модель закончила реализацию всех задач. И вот результат. Как вы можете видеть, у нас есть небольшой функционирующий Pokedex, где я могу искать любого покемона и добавлять его в свою команду. API, кажется, работает идеально. И проект также выглядит очень чисто. Он использует чаты и элементы пользовательского интерфейса, как я просил. И судя по всему, он очень хорошо функционирует. Итак, вот он. Мы только что "вайб-кодили" небольшой веб-проект с помощью SpecKit. Я надеюсь, что теперь вы видите, как этот тщательный подход к разработке, управляемой спецификациями, может помочь улучшить способность ИИ создавать более чистый, более отточенный код. Он также дает вам больше точности, чтобы направлять модель в нужном вам направлении. И я должен упомянуть, что хотя SpecKit разработан для работы с большинством моделей кодирования, выбор модели кодирования по-прежнему имеет значение. Во время тестирования этого инструмента я также пытался создать проект с помощью GPT4.1, и он не дал мне такого хорошего результата, как когда я использовал модель Grok. Так что выбор правильной модели кодирования по-прежнему необходим для достижения наилучших результатов.
Ясно, что разработка, управляемая спецификациями, — это парадигма, которую мы будем видеть гораздо чаще в будущем программирования. Но каковы ваши мысли о Specit? Используете ли вы разработку, управляемую спецификациями, в своей практике кодирования? Дайте нам знать в комментариях ниже. И, друзья, если вам нравятся такие технические разборы, дайте нам знать, нажав кнопку "лайк" под видео. И также не забудьте подписаться на наш канал для получения большего количества видео, подобных этому. Это был Андресс из Better Stack, и я увижу вас в следующих видео. [Музыка]