Transcription
Если вы видели сравнение GSD против OpenSpec, которое я недавно проводил, это видео покажется вам знакомым по форме. Легкий инструмент против более тяжелого инструмента. Более тяжелый инструмент дает немного более строгий результат, а более легкий достигает его быстрее. Я не буду делать вид, что это совершенно новое открытие. Что я хочу выяснить в этом видео, так это где Spec Kit на самом деле находится в этом спектре, потому что Spec Kit — это не GSD, и различия имеют значение. Я дал одно и то же задание OpenSpec и Spec Kit в два последовательных дня. Задание — это PRD dogfood, который я создал для такого рода тестирования. Самосовершенствующийся Python-агент для кодирования с девятью функциями и девятью тестами приемки. Оба запуска прошли через Claude Opus 4.7 на уровне 1 миллиона контекстов в Claude Code. Я установил низкий уровень усилий по рассуждению, чтобы тест уложился в однодневное окно для съемок. Без этого Spec Kit сам по себе занял бы гораздо больше времени. OpenSpec выпустил рабочий агент примерно за 2,5 часа реального времени, включая накладные расходы на запись видео, а не только фреймворк, за 30,26 доллара на Claude. Spec Kit занял примерно пять часов и 54,83 доллара. Оба прошли девять из девяти тестов приемки. Замечание об внимании аудитории. На сегодняшний день, 11 мая 2026 года, OpenSpec имеет 47 000 звезд на GitHub. Spec Kit имеет почти 96 000. Spec Kit имеет примерно двойную долю общественного внимания. Это тщательное продолжение сравнения, которое я проводил около полугода назад. Я измерял реальное время, парсил токены через ccusage, применял формальную оценку Cat Score и публиковал оба репозитория. Не выбирая победителя. Размещая Spec Kit в спектре между OpenSpec на легкой стороне и GSD с автоматическим режимом на тяжелой стороне. Прежде чем перейти к запускам. Вот краткое напоминание о том, как эти фреймворки ожидают от вас работы, и что каждый из них выпустил с момента моего последнего обзора. Если вы не видели предыдущее сравнение, я кратко расскажу и об OpenSpec здесь, чтобы вам не пришлось переключаться туда-сюда. OpenSpec меньше двух по объему. Основной цикл: предложить, применить, архивировать. Команды: /opsx:propose, /opsx:apply и /opsx:archive после переписывания v1. Propose создает папку изменений с предложением, документом дизайна, списком задач и дельта-спецификациями. Apply работает по списку задач. Archive объединяет дельта-спецификации обратно в каноническую спецификацию. Он предлагает вам запустить sync во время архивирования. Хотя sync является отдельным шагом, и в стандартном основном профиле вам, возможно, придется установить его сначала. Существует шаг validate вне основного профиля, который выполняет проверку предложения на здравый смысл. Стоит оставить его включенным для спокойствия, даже если он в основном ничего не находит при здоровом запуске. С момента моего последнего обзора новая работа в OpenSpec — это в основном полировка и исправления стабильности. Версия 1.3.1 была выпущена около трех недель назад. Это список мелких исправлений, улучшенная обработка путей, обнаружение скрытых требований внутри блоков кода, более чистый вывод JSON и бесшумная телеметрия в сетях с брандмауэром. После этого патча Kimi CLI был добавлен как поддерживаемый инструмент. Пока только навыки. Более важным является работа с рабочими областями. Большинство недавних коммитов — это работа по созданию основы для рабочих областей. Он еще не открыт для публики, и со стороны не совсем ясно, как будет выглядеть рабочий процесс. Сигнал в том, что это следующая большая цель выпуска. Spec Kit выполняет более тяжелый цикл. Вы начинаете с /speckit.constitution, который записывает набор именованных принципов, которые фреймворк считает обязательными правилами для всего проекта. Каждый эпик затем проходит пятиступенчатый цикл. Specify, plan, tasks, analyze, implement. Spec Kit также автоматически создает ветку функции для каждого эпика. Что нового в Spec Kit, это обратная история. 13 релизов за четыре недели. Около 160 коммитов. Конституция теперь загружается во время implement, а не только во время plan, поэтому принципы управления активны во время шага кодирования, а не только во время планирования. Существует пара команд specify self check и self upgrade. Так что больше никаких ритуалов обновления pipx. Самое интересное изменение Spec Kit — это система плагинов и расширений. Каталог содержит более 80 расширений сообщества плюс растущий набор пресетов, и теперь есть CLI discovery для их просмотра, не покидая терминал. Пресеты могут объединяться, добавляться в начало, конец или оборачиваться шаблонами и командами, поэтому несколько пресетов накладываются чисто. Единственное расширение, которое стоит упомянуть для этого видео, — это TinySpec, легкий рабочий процесс из одного файла, который позволяет пропустить тяжелый многошаговый цикл для небольших задач. Это легкий путь, которого нет в основном Spec Kit, и это сторонний плагин, а не встроенная команда. Я сам не запускал TinySpec, поэтому не буду делать вид, что рецензирую его. Суть в том, что идентичность Spec Kit — это расширяемость, в то время как идентичность OpenSpec — нет. Контраст реален. OpenSpec находится в режиме медленного глубокого построения, вкладывая большую часть своей энергии в одну большую функцию, которая еще не выпущена. Spec Kit находится в режиме блиц-функций, еженедельно выпуская значимые изменения через новую архитектуру плагинов. Два разных подхода к тому, как должен развиваться фреймворк SDD, и история релизов делает эти подходы видимыми. Прежде чем перейти к фактическим запускам. Если вам нравится такой измеряемый сравнение с реальным реальным временем, парсированными токенами и обоими репозиториями, опубликованными публично, подпишитесь на канал. Я пытаюсь сделать это полезным, а не перефразировать то, что уже написано на веб-сайте каждого инструмента. И если вы хотите поговорить со мной или с другими людьми, которым это интересно, присоединяйтесь к Discord. Он еще маленький, а маленький означает, что вы можете вести реальный разговор. Ссылка находится в описании ниже. Перед вызовом OpenSpec я разделил PRD на пять фаз с помощью простого запроса Claude и сохранил их в файле phases.md. OpenSpec не имеет команды высокого уровня, которая разделяет PRD за вас. Так что это небольшая предварительная работа, которую вы делаете вне фреймворка. Фаза один была работой по созданию основы, настройке проекта, зависимостям. Интерфейс клиента LLM, структура .env и smoke-тест против реальной конечной точки Moonshot. Применение заняло около 2,5 минут. Один тест не прошел, когда присутствовал реальный токен API, и шаг verify исправил его на месте, прежде чем двигаться дальше. Фаза два была циклом решения, песочницей и автоматическим выключателем. Применение заняло около пяти минут. 27 задач вернулись зелеными, 35 тестов прошли, и verify обнаружил только небольшую проблему с именованием путей. Фаза три добавила персистентность и структурированный запрос на рефлексию. Применение заняло около пяти минут и 40 секунд. Выводы там были незначительными. Избыточная локальная переменная была худшим, что verify смог найти. Интересной частью фазы три было попытка реально продемонстрировать историю самосовершенствования. Kimi K2.6 оказался слишком умным для тестовых сценариев, которые я подготовил. Начиная с фазы два, каждая задача, которую я ему давал, успешно выполнялась с первой итерации. К фазе три мне пришлось написать отдельный файл first_failure_demo.py с намеренно жесткими ограничениями песочницы, которые вызвали тайм-аут песочницы, активировали шаг рефлексии и позволили мне увидеть. Итерация два в реальном времени. Это реальная особенность тестируемости, а не проблема фреймворка. Это то, что вы узнаете, только когда реально запустите его. Фаза четыре была межзапускным слоем памяти. Применение заняло около 5,5 минут. Это дизайнерское решение, которое я хочу, чтобы вы заметили позже. OpenSpec выбрал TF-IDF сходство вместо хранилищ JSONL в директории памяти в папке home. В цикле нет векторной базы данных, и поиск не вызывает провайдера. Он работает офлайн против токенизированного текста. Это позволяет избежать целого класса проблем, с которыми, как вы увидите, Spec Kit сталкивается напрямую. Фаза пять была CLI инспектором памяти. Применение заняло около 2,5 минут. 18 из 18 задач были выполнены. Семь из семи требований выполнены. Реальное время. Весь запуск занял около 2,5 часов. Значительная часть этого была накладными расходами на запись видео, а не самим OpenSpec. Пиковая загрузка контекста на уровне 1 миллиона составляла около 9% и никогда не была напряженной. В конце я попросил Claude проверить все приложение против PRD с максимальными усилиями. Кодовая база закончилась 96 модульными тестами. Финальный внешний проход проверки выполнил 81 из них и вернулся чистым. Все девять критериев приемки PRD также были пройдены. Единственные недостатки были косметическими. Перестановка меток между T4 и T5 относительно PRD и небольшая проблема с формулировкой в README. Фреймворк не мешал, а циклы оставались достаточно короткими, чтобы я никогда не чувствовал себя запертым в рабочем процессе. Запуск Spec Kit начался с немного более тяжелой настройки. Я установил specify через инструмент uv и получил версию 0.8.7.dev0, последний пререлиз на PyPI на тот момент. Последняя стабильная версия была 0.8.6. Spec Kit установился как набор нативных навыков под папкой .claude, что ощущалось более гладко, чем я ожидал. Как и с OpenSpec, я сначала разделил PRD на шесть эпиков с помощью простого запроса Claude и сохранил их вне фреймворка. Ни один из инструментов пока не имеет команды высокого уровня для разделения PRD. Первое, что вы запускаете в Spec Kit, — это /speckit.constitution. Я написал пять принципов. Дисциплина единого провайдера, безопасность песочницы, доставка на основе тестов приемки, инспектируемая память и нейтральная для фреймворка точность PRD. Это не украшение. Начиная с версии 0.8.6, конституция загружается во время /speckit.implement, а также во время /speckit.plan, поэтому принципы активны во время шага кодирования, а не только во время планирования. Затем для каждого из шести эпиков я запустил цикл. Specify занял около двух минут. Plan занял от 3 до 6. Tasks занял от 2 до 3. Implement занял от 6 до 9. А analyze запускался перед каждым implement, но я не отслеживал его время отдельно. Spec Kit также автоматически создает ветку функции для каждого эпика. 001 foundation llm client, затем 002 и так далее. Это действительно полезно и отличается от OpenSpec, который остается на main на протяжении всего процесса. Шаг analyze заслужил свое место. В отличие от validate в OpenSpec, который на этот раз в основном ничего не находил, /speckit.analyze последовательно выявлял реальные проблемы перед запуском implement. Это лучший вспомогательный инструмент для полировки, который я использовал в любом из фреймворков. Трудный момент наступил в эпике пять, эпике персистентной памяти. Дизайн Spec Kit требовал эмбеддинги Moonshot. Moonshot не предоставляет конечную точку эмбеддингов. Код деградирует плавно. Записи сохраняются с полем embedding_status=missing, и ничего не выходит из строя. Но фактический семантический поиск не может работать без перехода на другого провайдера. Это дизайнерское разделение, которое я отметил в разделе OpenSpec. OpenSpec выбрал TF-IDF и избежал всего класса проблем. Выбор Spec Kit более амбициозен и дает лучший поиск, когда провайдер его поддерживает. На этом провайдере, в этом запуске, функция памяти получила реальный практический оговорок. Был также небольшой момент с работой по ценообразованию, который я хочу упомянуть отдельно. Claude выдумывал цены Moonshot. При заполнении модуля отслеживания затрат я заметил, что цифры выглядели подозрительно круглыми и много оспаривал их с Claude. Затем Claude посмотрел фактическую документацию и обновил значения. Суть не в том, что Claude плох в этом. Суть в том, что даже сильная модель будет выдумывать количественные ответы, если вы ей позволите, особенно в отношении денег, математики и данных. Проверяйте цифры. Реальное время работы Spec Kit было примерно вдвое больше, чем у OpenSpec. Фреймворк занял необходимое время и в обмен произвел больше письменных артефактов. Тон был намеренным, не медленным в раздражающем смысле, просто намеренным. Тем не менее, к третьему или четвертому эпику я поймал себя на том, что скучаю по автоматическому режиму GSD. Spec Kit заставляет вас вручную вводить каждую команду в цикле по эпикам, и нет встроенного способа их объединить. Это разница, которую я хочу, чтобы вы имели в виду. Spec Kit ощущается как GSD без автономного объединения. Осталась только глубина планирования. Сначала основные цифры. OpenSpec завершился примерно за 2,5 часа реального времени. Spec Kit занял примерно пять, примерно вдвое больше. На Claude Opus OpenSpec стоил 30,26 доллара. Spec Kit стоил 54,83 доллара. Это на 81% больше для Spec Kit за тот же доставленный PRD. Общее количество токенов через ccusage составило 35,4 миллиона для OpenSpec и 59,8 миллиона для Spec Kit, примерно на 69% больше. Объем кода идет в том же направлении. OpenSpec достиг около 1848 строк с 96 модульными тестами. Spec Kit — около 2751 строки и 169 модульных тестов. Когда я оценивал оба фреймворка по шкале Cat Score, составные числа составили около 7,5 из 10 для OpenSpec и 8,0 для Spec Kit. Средний необработанный показатель OpenSpec фактически составил 7,75, находясь прямо на границе округления, и я округлил половину вниз. Интересная часть — профиль под ним. Spec Kit получил более высокие оценки по качеству спецификаций, качеству плана, качеству реализации и дисциплине проверки. OpenSpec получил более высокие оценки по первому результату, полировке, стоимости и опыту разработчика. Spec Kit выигрывает по строгости. OpenSpec выигрывает по повседневной эргономике. Тот же разрыв в пол-кошки, что и в сравнении GSD, но роли поменялись. OpenSpec выиграл тогда. По инженерной сути, две реализации вложили свою заботу в разные места. Песочницу Spec Kit действительно труднее обойти. Она делает снимки mtimes вокруг директории итерации и явно разрешает символические ссылки для обнаружения попыток побега, а не следует за ними. Она очищает среду, чтобы сгенерированный код не мог достичь домашней папки родителя или ключа API. Она ограничивает stdout до 262 килобайт, так что вышедший из-под контроля тест не может раздуть память. Песочница OpenSpec проверяет пути с помощью Path.relative_to и доверяет остальному. OpenSpec выигрывает по уровню данных. Атомарные записи tmp плюс fsync плюс rename, и поле schema_version, проставленное на каждой записи, означает, что в тот день, когда вам понадобится мигрировать формат файла JSONL, у вас будет путь. Spec Kit добавляет в JSONL без поля версии. Оба проходят те же девять тестов приемки, и ни один из них не имеет автоматических повторных попыток при временных ошибках LLM. Это самая большая общая слабость. Сюрпризом для меня, оглядываясь на оба запуска, является то, насколько похожими ощущаются эти фреймворки сейчас. Шесть месяцев назад я бы сказал вам, что Spec Kit заметно тяжелее, а OpenSpec — легкая альтернатива. Сегодня разрыв сузился в обоих направлениях. OpenSpec остался легким и стал более способным. Spec Kit использовал дополнительные часы, чтобы произвести немного более строгий кодовую базу. Дополнительные минуты планирования окупаются, но разрыв в качестве доставки меньше, чем разрыв во времени выполнения. Реализатор, Claude Opus 4.7, несет большой вес в любом случае, и вы можете почувствовать это по тому, насколько близки конечные продукты. Так где же вы окажетесь, если будете выбирать между ними сегодня? OpenSpec остается фреймворком, к которому я бы обратился первым. На большинстве проектов цикл достаточно короткий, чтобы я оставался вовлеченным в работу, а инженерия уровня данных тихо окупается позже. Атомарные записи и поле версии схемы на каждой записи — это то, что вы не замечаете, пока не понадобится мигрировать формат. Для одиночного разработчика или небольшой команды над новым проектом это очевидный выбор. Spec Kit — это то, к чему я бы обратился, когда мне действительно нужен более глубокий план и слой конституции. Четыре этапа планирования: specify, plan, tasks, analyze, produce более крупную спецификацию и более тщательно реализованную кодовую базу. И analyze выполняет более полезную работу по полировке, чем verify в OpenSpec в этом запуске. Стоимость этой глубины реальна. Примерно вдвое больше реального времени для того же доставленного PRD, примерно на 81% больше в счете Claude. Если проект нетривиален и история изменений имеет значение, эта стоимость является справедливой сделкой. Спектр, с которым я хочу вас оставить, выглядит так. На легком конце — OpenSpec, где циклы быстрые, а артефакты остаются легкими. На тяжелом конце — GSD с автоматическим режимом, который добавляет автономное объединение поверх глубокого планирования, так что фреймворк управляет рабочим процессом от начала до конца. Spec Kit находится между ними. Та же глубина планирования, что и у GSD. Нет автономного объединения. Это самый полезный способ описать это, который я нашел. Spec Kit — это то, как выглядел бы GSD без автоматического режима. Заметка из списка пожеланий, пока я здесь. Оба были бы намного сильнее с автоматическим режимом, особенно Spec Kit. Ручной ввод каждой команды в цикле по эпикам был самой утомительной частью запуска. К третьему или четвертому эпику я поймал себя на том, что скучаю по автономному объединению GSD. OpenSpec также выиграл бы. Цикл propose-apply-archive уже достаточно быстр, но автономное объединение нескольких из них сделало бы его выбором по умолчанию почти для всего, над чем я работаю. Бонусные очки, если бы любой фреймворк мог запускать под-агента для каждой фазы вместо выполнения всего в основном контексте. OpenSpec фактически предоставляет собственный ярлык, который немного помогает. /opsx:propose объединяет церемонию планирования в одну команду. Таким образом, вы переходите от "я хочу внести изменения" до всех артефактов планирования за один запрос. Spec Kit имеет TinySpec, делающий то же самое со своей стороны, но TinySpec — это стороннее расширение сообщества. Ни один из ярлыков не объединяет полный цикл от начала до конца. Это пробел, который я хочу заполнить следующим. Оба фреймворка эволюционировали с момента моего последнего обзора. Выбирайте по тому, что вы оптимизируете, а не по тому, кто победил. Чистого победителя сегодня нет. Некоторые из вас продолжают оставлять комментарии, что я должен больше моргать. Я вас слышу. Дело в том, что я на самом деле не записывал себя на камеру до начала этого канала, и поверьте мне, произнести 20-минутный сценарий — непростая задача. Над частью с камерой я работаю, и выступления будут становиться все более естественными. Большое спасибо за просмотр, и увидимся в следующем видео.