Transcription
Привет, друзья, как и неизбежная тепловая смерть Вселенной, вы почти гарантированно получите от меня еще одно видео, говорящее о specit. И сегодня я собираюсь поговорить о некоторых обновлениях, которые мы внесли в инструменты, пока вас не было или пока я отсутствовал на стриме другого видео. Итак, давайте начнем. Прежде всего, я хочу поговорить о том, как наш CLI стал немного более разумным и ведет себя как надлежащий CLI, когда вы говорите о создании продуктов в той же папке, например. Теперь все это, кстати, происходит на фоне того, что мы добавили поддержку большего количества агентов. Конечно, мы это сделали, потому что это то, на что есть наибольший спрос. Но давайте посмотрим сюда. Итак, я собираюсь использовать, я собираюсь создать новую папку. Итак, я сделаю mk dur, а затем test two. Перейдем в test two. И здесь, если вы помните, если вы использовали specify раньше, вам приходилось использовать тире здесь, верно? Итак, вы бы использовали что-то вроде um specify init, а затем здесь. И это, по сути, создало бы проект в этой папке. Ну, вы, возможно, видели пик только что, но я могу просто использовать точку, что именно так поступает любой другой CLI в типичном сценарии, подобном этому. Итак, выбор точки по сути создаст проект в папке, в которой я сейчас нахожусь. И тогда у меня есть куча агентов на выбор. Итак, у нас есть Copilot, Claude, Gemini, Cursor agent, многие, многие другие. Мы только что добавили CodeBuddy сегодня. Есть Amazon Q, RU и так далее. Итак, вещи, которые вы уже видели, но я собираюсь использовать Copilot здесь, и я собираюсь использовать PowerShell. Ничего не изменилось, но мы также добавили ряд других улучшений, о которых я хочу поговорить. И первое из них — это команды. И команды теперь гораздо лучше структурированы. Давайте посмотрим, почему. Итак, лучше структурированные команды на самом деле очень полезны, потому что если вы посмотрите на существующий интерфейс /commands в VS Code или любом другом инструменте, у вас могут быть пересекающиеся команды. Например, clarify может существовать или implement может существовать уже. Как вы различаете их? Ну, давайте посмотрим сюда. Я собираюсь перейти прямо в мой VS Code для моего проекта. Итак, мы сделаем code, а затем вы увидите, что если я сделаю /commands, например, specify. Обратите внимание, что теперь у меня есть этот префикс. Это specit. Итак, все команды, специфичные для specit, вы сможете просто набрать specit.sp specify или вы можете просто набрать specify, и это все равно приведет вас к нужной команде. Верно? Так что это очень удобно, очень просто. Теперь, в дополнение ко всему этому, мы также хотели упростить вам создание ваших проектов. Итак, если вы используете, например, Visual Studio Code, и это специально для VS Code и Copilot, вы также получите некоторые улучшения в том, как эти команды отображаются с самого начала. Итак, здесь у меня есть моя конституция, specify, plan, test и implement прямо под рукой. Очень просто. Итак, если я наведу курсор, я получу описание, что тоже довольно здорово. Так что, если я новичок в этом проекте, я только что его создал, я могу просто нажать на constitution static site. Бум. Вот и все. Вот сколько работы мне нужно сделать здесь. И мне на самом деле не нужно запускать команду индивидуально или вводить ее вручную. Просто нажмите кнопку, а затем вы можете начать новую сессию чата и перейти к следующей команде. Верно? Так что, если я просто остановлюсь здесь, и я покажу вам это, и нажму на этот плюс. Обратите внимание, что теперь у меня есть команда specify. Так что я могу просто сделать это после того, как конституция закончится. И она фактически помещена в мою папку. Так что это довольно здорово. Теперь давайте перейдем к следующему улучшению. Еще одно улучшение, которое мы добавили, касается выполнения скриптов. Если вы помните, у нас есть вспомогательные скрипты в наших папках, которые позволяют нам сделать выполнение команд или выполнение spec немного более предсказуемым, потому что вспомогательные скрипты предоставляют контекст, верно? Так что, если я хочу запустить вспомогательный скрипт, чтобы получить пути к моему spec, моей модели данных, для этого есть скрипт оболочки или скрипт PowerShell. Если я хочу создать новую ветку, для этого у меня есть скрипт оболочки или скрипт PowerShell. Теперь, с этими вещами, если вы использовали их в VS Code, например, с Copilot, вас, возможно, постоянно просили разрешить выполнение скрипта, что является хорошей мерой безопасности. Это должно быть так. Но это не совсем эффективно, потому что вам постоянно приходится нажимать эту кнопку. Так что это раздражение на самом деле теперь решено тем фактом, что мы объединяем для co-pilot, специально для co-pilot, пакеты, эти опции для автоматического утверждения команд. Итак, у нас есть указанные скрипты bash и powershell. И я, вероятно, мог бы просто упростить это до простого использования скриптов, но они автоматически утверждаются. Итак, всякий раз, когда вы запускаете эти команды в вашем фактическом редакторе, то есть в VS Code. Итак, мы вернемся сюда, к моему другому проекту. Вы заметите, что команды будут автоматически утверждаться. Вы получите это автоматическое утверждение по правилу specify scripts PowerShell. И поэтому вас никогда не попросят разрешить его выполнение. Он просто выполняется и уходит с дороги. Так что опять же, довольно здорово. Это общее улучшение производительности. А затем давайте перейдем к следующему. Еще одна новая возможность, которую мы добавили, — это, по сути, модульные тесты для английского языка. Когда Джон Лам и я говорили о некоторых улучшениях, которые мы могли бы внести, одной из проблем, с которой мы пытались разобраться, была идея недостаточной спецификации. И мы говорили о недостаточной спецификации в моих видео раньше. Это, по сути, проблема того, что вы не знаете, что вы чего-то не знаете для spec, верно? Неизвестные неизвестные — довольно большая проблема. Так как же их смягчить? Как избежать недостаточной спецификации вещей, когда вы на самом деле не знаете их с нуля? Ну, для этого вы можете создать специальные контрольные списки, специфичные для предметной области. У вас может быть контрольный список для UX, контрольный список для безопасности, контрольный список, возможно, для доступности. И эти контрольные списки намеренно отделены от технологий. Так же, как мы говорили о том, что сам spec отделен от технологии или реализации, сами контрольные списки не обязательно смотрят на такие вещи, как наличие надлежащих модульных тестов или реализация компонента страницы подкаста. Это больше о фактических деталях spec. Для этого мы используем команду /checklist, и она также имеет префикс specit. Итак, я собираюсь использовать /checklist. Готово. И я собираюсь использовать домен. В данном случае это будет UX, потому что я хочу создать контрольный список для моего пользовательского опыта. Теперь, что это сделает, обратите внимание, что это запустит скрипт, и, как я уже упоминал ранее, он автоматически утверждается правилами, которые у меня есть здесь. Так что мне на самом деле не нужно ничего утверждать, и он просто продолжает работать. И поскольку он будет смотреть на домен, который я попросил, он также будет просматривать шаблон контрольного списка, потому что у нас теперь есть шаблон, который дает вам маркированные списки, которые нужно пройти. И он заполнит его на основе домена, который я попросил охватить. Так что в данном случае UX. Опять же, это может быть безопасность, это может быть что угодно еще. И это также сгенерирует список вещей, о которых мне нужно подумать в spec, если есть какие-либо области, которые могут быть недостаточно специфицированы или какие-либо области, которые требуют дополнительной информации, которая не была охвачена в первоначальной итерации. Так что вы, возможно, не видели первых шагов, когда я просто создал этот spec для моей целевой страницы подкаста, но, по сути, это простой проект, верно? Там не так много вещей, которые я на самом деле добавил в первоначальный запрос. Но это также означает, что по мере того, как я перехожу к дальнейшим шагам, большая часть этой информации становится очень подразумеваемой, а подразумеваемая информация плоха, потому что подразумеваемая информация означает, что LLM начинает угадывать вещи вместо того, чтобы вы явно указывали это. Так что это проблема. Давайте посмотрим сюда сейчас на контрольный список UX. Итак, я сохраню файл, я перейду сюда и закрою это и закрою наш терминал. И давайте посмотрим сюда. Итак, наши требования к визуальной иерархии определены для всех трех типов страниц, верно? Например, это не техническая реализация, которая говорит мне, как они должны быть построены. Это на самом деле спрашивает, определены ли требования к состоянию загрузки для переходов страниц и асинхронного контента. Опять же, это отличная возможность, которая позволяет мне подумать об этих вещах, которые не указаны в spec, но они должны быть отделены от реализации. И когда мы пройдемся по этому, вы заметите, что есть разделы, верно? Например, для таких вещей, как ясность требований, последовательность требований, критерии приемки, верно, и также мне очень нравится эта часть для вещей, которые являются метриками, для вещей, которые измеримы. Он фактически проверяет, являются ли они тестируемыми с определенными условиями измерения. Хорошо, это то, на что я смотрел раньше, и я думал, ну, он может создать кучу метрик, и эти метрики приятно смотреть, но действительно ли они тестируемы? Так что эти контрольные списки позволяют вам пройти процесс: охватываю ли я все, что мне нужно охватить в моем spec, или есть какие-то слепые зоны? Так что очень, очень полезно. И если вы когда-нибудь захотите реализовать этот контрольный список, вы можете просто попросить LLM перекрестно проверить контрольный список UX с spec. Вот и все. И когда вы это сделаете, LLM на самом деле начнет отмечать вещи на основе контрольного списка и изменять spec, если есть какие-либо области, которые недостаточно специфицированы. Опять же, я нахожу это очень полезным для себя, потому что это улучшает мой мыслительный процесс. Теперь давайте посмотрим на следующее обновление. Другое, что мы фактически значительно улучшили, — это то, как мы управляем задачами. Теперь, если вы помните в предыдущих версиях SpecKit, разбивка задач включала много тестов. Так что, если вы создавали простую функцию или большой проект, у вас было бы множество тестов, потому что вы знаете, TDD или разработка на основе тестов — это лучшая практика. Но есть проблема: это не всегда применимо. Так что мы это почистили. Так что теперь тесты полностью исключены, если вы явно не попросите их. Это верно. Так что, если вы не просили тесты, вы не получите тесты здесь в задачах. Другая часть здесь, которая немного интереснее, заключается в том, что мы фактически обновили структуру разбивки задач. Так что теперь вы знаете, что у вас есть возможность смотреть на это с точки зрения менеджера продукта. Это верно. Если вы когда-либо пропускали пользовательские истории и пользовательские сценарии, именно по ним они сгруппированы. Так что теперь у вас есть фаза 1: настройка общей инфраструктуры. Теперь у вас есть фаза 2: фундаментальные или блокирующие предварительные условия. Все разбито на, по сути, как вы достигаете MVP, минимально жизнеспособного продукта, как можно быстрее, упорядоченное таким образом, чтобы вы могли фактически построить его независимо. Так что, если вы пройдете фазу 1 и фазу 2, у вас будут фундаментальные блоки. Если вы сделаете фазу 3, у вас будет MVP. Это, по сути, часть. А затем вы начинаете проходить улучшения в итерациях, таких как фаза 4: у вас есть пользовательская история 2: просмотр эпизодов, как это позволяет вам лучше итерировать проект, потому что мне на самом деле не нужно ждать, пока все закончится, чтобы сшить вместе, чтобы увидеть конечный продукт, я могу фактически итерировать по фазам, и когда я это делаю, я получаю возможность фактически собирать их независимо, чтобы я мог остановиться после фазы 2 и сказать: хорошо, давайте посмотрим, как это выглядит. Я могу остановиться после фазы 3 и задать тот же самый вопрос. Это дает больше гибкости как разработчику, и вы получаете лучшие результаты, потому что тогда вы можете направить LLM в правильном направлении, прежде чем он зайдет слишком далеко в реализацию. Так что мы очень рады всем этим изменениям. Будет больше. Следите за другими обновлениями, связанными с specit. Мы активно развиваем его, и если есть какие-либо отзывы, перейдите на github.com/githubspec-kit. Откройте проблему, отправьте запрос на вытягивание. Мы всегда открыты для вкладов, и я увижу вас в следующем.