Вы уже пробовали применять ИИ в разработке? Если да, то заметили, что чем дольше вы общаетесь с моделью, тем выше шанс, что она забудет ваши исходные требования. Спецификация, которую вы указали вначале, теряется где-то в контексте, и ИИ начинает генерировать код, который немного, но не совсем то, что нужно.

Поэтому некоторые разработчики уже перешли на Spec-Driven Development — подход, в котором требования четко описаны отдельно и всегда под рукой. Звучит логично? Но попробуйте внедрить его на реальном проекте... и вы быстро поймете, почему большинство разработчиков его не используют. Одна из основных причин — спецификации хранятся отдельно от кода, и ИИ их регулярно теряет. А еще они быстро устаревают, когда вы вносите изменения. 

Но что, если спецификацию встроить прямо в код? Именно это и предложил японский разработчик в своей оригинальной статье. Он обнаружил, что Vue SFC позволяет использовать пользовательские блоки — и создал <spec> блок для коллокации спецификации с кодом, который поможет решить устоявшиеся проблемы.

Добро пожаловать под кат: разберем, как коллокация спецификаций меняет правила игры в AI-driven разработке.

Трудности внедрения Spec-Driven Development в проекты

В последние месяцы подход Spec-Driven Development (разработка, основанная на четких спецификациях) вызывает живой интерес как эффективный способ повысить точность работы AI-инструментов. Если сравнивать с вайб-кодингом, где качество генерации зависит в основном от удачного промпта, спецификации позволяют максимально повысить предсказуемость и улучшить результаты.

Однако на практике интеграция такого подхода сталкивается с двумя серьезными барьерами.

1. Формулировать спецификации — непростая задача. В привычной bottom-up разработке требования и спецификации проясняются прямо по ходу написания кода. Такой принцип значительно отличается от Spec-Driven Development-подхода, где всё сначала проговаривается на естественном языке, а потом превращается в программу. Многие разработчики просто не могут перестроиться на новый способ мышления.
   
   Даже инструменты вроде Spec Kit и Kiro, призванные помочь разработчику, не решают самую главную проблему: они создают удобную структуру для описания спецификаций, но не отвечают на вопрос, что именно нужно описывать и насколько подробно.

2. Спецификации часто расслаиваются с кодом. При использовании 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.