Вы уже пробовали применять ИИ в разработке? Если да, то заметили, что чем дольше вы общаетесь с моделью, тем выше шанс, что она забудет ваши исходные требования. Спецификация, которую вы указали вначале, теряется где-то в контексте, и ИИ начинает генерировать код, который немного, но не совсем то, что нужно.
Поэтому некоторые разработчики уже перешли на Spec-Driven Development — подход, в котором требования четко описаны отдельно и всегда под рукой. Звучит логично? Но попробуйте внедрить его на реальном проекте… и вы быстро поймете, почему большинство разработчиков его не используют. Одна из основных причин — спецификации хранятся отдельно от кода, и ИИ их регулярно теряет. А еще они быстро устаревают, когда вы вносите изменения.
Но что, если спецификацию встроить прямо в код? Именно это и предложил японский разработчик в своей оригинальной статье. Он обнаружил, что Vue SFC позволяет использовать пользовательские блоки — и создал <spec> блок для коллокации спецификации с кодом, который поможет решить устоявшиеся проблемы.
Добро пожаловать под кат: разберем, как коллокация спецификаций меняет правила игры в AI-driven разработке.
Трудности внедрения Spec-Driven Development в проекты
В последние месяцы подход Spec-Driven Development (разработка, основанная на четких спецификациях) вызывает живой интерес как эффективный способ повысить точность работы AI-инструментов. Если сравнивать с вайб-кодингом, где качество генерации зависит в основном от удачного промпта, спецификации позволяют максимально повысить предсказуемость и улучшить результаты.
Однако на практике интеграция такого подхода сталкивается с двумя серьезными барьерами.
Формулировать спецификации — непростая задача. В привычной bottom-up разработке требования и спецификации проясняются прямо по ходу написания кода. Такой принцип значительно отличается от Spec-Driven Development-подхода, где всё сначала проговаривается на естественном языке, а потом превращается в программу. Многие разработчики просто не могут перестроиться на новый способ мышления.
Даже инструменты вроде Spec Kit и Kiro, призванные помочь разработчику, не решают самую главную проблему: они создают удобную структуру для описания спецификаций, но не отвечают на вопрос, что именно нужно описывать и насколько подробно.
Спецификации часто расслаиваются с кодом. При использовании Spec Kit или Kiro вы описываете требования в отдельных файлах вроде *.spec.md или tasks.md, которые AI потом использует при генерации. Некоторые агенты, как Coding Agent, вообще предлагают писать спецификации в задачах GitHub.
Однако у ИИ очень ограниченный и часто непрозрачный контекст, и спецификации, лежащие в отдельных файлах, довольно быстро из него выпадают. Если вы меняете задание или продолжаете работать над проектом после перерыва, приходится несколько раз повторять одно и то же, чтобы AI снова понял их суть.
Подход «опиши спецификацию — сгенерируй весь код одним махом» действительно хорош на этапе запуска нового проекта или при разработке отдельной фичи. Но когда начинается рефакторинг или постоянные доработки, этот способ становится неудобным: небольшое изменение спецификации заставляет пересоздавать весь код, а если править код вручную — спецификация моментально устаревает.
Таким образом, даже понимая мощные преимущества Spec-Driven Development, многие сталкиваются с тем, что у этого метода слишком высокий порог входа, результаты не всегда оправдывают ожидания, а с уже существующими проектами он часто плохо интегрируется.
Использование блока в Vue
Чтобы решить обе эти проблемы Spec-Driven Development, предлагается следующий подход — добавить в Vue пользовательский блок <spec> и записывать в нём спецификацию.
Это одновременно решает вопросы хранения и формирования требований для генерации кода AI-инструментами. Custom-блоки описываются так же, как и любые другие секции (template, script, style), при этом их содержимое можно указать в любом формате — для читабельности часто используется Markdown.
Например, нужно создать компонент наподобие «спотлайта», который будет ярко подсвечивать определённый элемент, затемняя остальную часть экрана. Для этого пишем следующий блок <spec>.
Пример оформления SFC с <spec>:
<template> <!— Здесь будет компонент, например, backdrop —> </template> <script> // Здесь может быть пусто на этапе спецификации </script> <spec lang=»md»> ## Только центральную область оставить яркой, остальное затемнить — Используется как фон для модальных окон. — Цвет фона: rgba(0,0,0,0.3). — Затемнение через SVG path, вложение через <teleport> под <body>. </spec>
Затем достаточно отправить подсказку для AI вида: «Имплементируй app/components/SpotlightOverlay.vue на основе <spec>», чтобы получить реализацию по данной спецификации.
Проблемы, которые решает блок
Итак, каким образом подход с описанием спецификации в блоке <spec> помогает конкретно решить упомянутые ранее проблемы?
Запись спецификации в блок облегчает разработчику составление спецификаций с правильной степенью детализации
Точно сформулировать спецификацию до начала написания кода — задача не из лёгких. Но процесс работы с блоком <spec> разбивается на два шага: сначала разработчик решает, какой компонент создать, а затем — в чём его ответственность. Благодаря этому структура описания спецификации становится более упорядоченной, а проектирование разбиения на компоненты не приходится доверять ИИ.
Компонент как единица описания — идеальный уровень детализации. Такие детали интерфейса, как props, emit, defineModel, или, например, решение «реализовать с помощью SVG», излишне мелки для документа рабочего уровня вроде спецификации функции Kiro, но вполне естественно вписываются в локальную спецификацию внутри <spec> блока.
Поскольку описание ограничено одним компонентом, даже при подробной записи оно не становится слишком объёмным для одного файла, что делает объём информации комфортным для восприятия.
Наоборот, если вы чувствуете, что блок <spec> стал слишком длинным — это сигнал, что на компонент возложено слишком много обязанностей (следует разделить компонент).
Записывание спецификации прямо в файл снижает нестабильность контекста в процессе разработки с участием ИИ
Большинство инструментов, использующих искусственный интеллект, в первую очередь анализируют контекст активного файла. Если спецификация и код находятся в одном файле, содержимое блока <spec> гарантированно будет включено в контекст работы ИИ.
Это помогает избежать ситуации, когда при длительном взаимодействии часть спецификации выпадает из контекста, и значительно повышает точность ответов и предложений ИИ.
Кроме того, хранение спецификации и кода вместе под управлением Git удобно и для разработчиков. При редактировании файла спецификация всегда перед глазами — её проще обновить, а ревью становится компактным — достаточно посмотреть один diff‑файл. Это уменьшает риск, что спецификация и реализация со временем начнут расходиться.
Не менее важен факт, что блок <spec> по умолчанию поддерживает синтаксис Markdown. Благодаря этому текст легко читать, писать и сравнивать при ревью, чего трудно добиться с комментариями в коде или JSDoc‑описаниями.
Для ИИ‑инструментов тоже всё просто: при внесении правок в ходе общения достаточно сказать «пожалуйста, обнови и тег <spec>» — и новая версия спецификации автоматически попадёт в файл.
Используя спецификацию не как разовый документ, а как постоянно поддерживаемый источник информации, можно добиться гармоничного сочетания «Spec-Driven Development» и agile-разработки.
Почему SFC — оптимальное решение в эпоху ИИ?
Попробовав подход с использованием блока <spec>, я всё больше прихожу к мысли, что SFC (Single-File Component) в Vue — это, возможно, наилучший формат для эпохи ИИ.
Изначально концепция Vue SFC предполагает объединение значимых частей — <template>, <script>, <style> — в единый компонент, где каждая часть логически связана с другими. Такой подход позволяет собирать интерфейс из изолированных, инкапсулированных компонентов.
Возможность определить спецификацию для каждого компонента отдельно и жёсткая связь между компонентом и его спецификацией делают такой способ очень логичным.
Ранее считалось, что JSX в React более гибок, ведь он позволяет определять несколько компонентов в одном файле, тогда как у Vue SFC на один файл приходится только один компонент. Однако для разработки с ИИ такая «жёсткость» становится скорее преимуществом.
Именно из-за структуры SFC объединяет спецификацию и код в одном файле — это помогает максимально раскрыть потенциал ИИ. Даже если начать внедрять этот подход лишь для части компонентов, вы сразу почувствуете, что качество и стабильность вывода ИИ возрастают, — обязательно попробуйте!
НЛО прилетело и оставило здесь промокод для читателей нашего блога:
-15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.
Источник: habr.com
