Writing
FrontendКак я ИИ-шаблон для разработки пилил
Недавно нужно было решить амбициозную задачу: создать шаблон для фронтенд-проектов, чтобы вайбкодить было удобно и небольно, если подробнее то:
- Единый формат оформления всех проектов, то есть использование общего UI-kit
- Возможность быстро набросать дизайн/перенести через MCP Figma его в код
- Типизация и разделение, архитектура должна была быть простой и понятной
- ИИ должна тратить минимальное количество токенов на допустимые проверки - все должно быть прописано в правилах для экономии и исключения возможных галлюцинаций
Начну с самого начала - UI Kit
Поиск UI-Kit
Здесь я выделил следующие дополнительные критерии
- Бесплатный шаблон Figma с компонентами
- Tailwind - для гибкости, ИИ его хорошо понимает
Найти обычный UI-kit на tailwind не проблема, но чтобы с ним в комплекте и Figma шла довольно тяжело
Из вариантов оставался shadcn/obrastudio - они полностью привязали ui-kit к дизайн токенам, внесли переменные в фигме и даже сделали плагин для переноса в CSS. После всего этого поиски продолжать было бессмысленно и я начал переносить shadcn-ui-kit в отдельный ui для возможности обогащения своими компонентами если прийдется. Засунул в story-book, обернул в приватный пакет npm для Gitlab и UI-kit готов
На выходе получили:
- Свой UI-Kit, макеты компонентов в Figma
- Возможность дообогащения
- Легкое использование в формате npm-пакета
UI-Kit готов, следующим вопросом был сам шаблон
Подбор шаблона
Строить архитектуру в формате FSD или атомарного дизайна не хотелось первоначально по-нескольким причинам:
- Сложный вкат для разработчиков
- Возможность галлюцинаций от ИИ
- Ненужные абстракции из-за небольшого размера проектов
Единственное что действительно рассматривалось - FEOD, но решение пришло само собой, когда я смог описать всю нужную мне структуру в одно предложение: “Делим логику по страницам использования, общую кладем в переиспользуемую папку и все”
Большинство компонентов и так в UI-ките, кастомных компонентов будет не так много - тогда зачем усложнять? Проекты повторюсь заточены под средние размеры, поэтому громоздить что-то на ровном месте очень уж не хотелось
Да и любому ассистенту кода будет работать с этим намного проще и меньше времени/токенов уйдет на разбирательства куда класть очередной JSON-чик
Структура выбрана, подходим к концу
Ограничение через типы и навыки
Структура хорошо, но этого мало, нужно ограничить возможность написания плохого кода “подручными” инструментами, берем:
- TypeScript, Zod - для типизации
- Eslint, Prettier - для красоты кода
- .husky - чтобы не напортачить перед тем как залить код
Не буду много рассказывать про эти инструменты, можно почитать про них отдельно, но вместе они дают довольно хорошие ограничения чтобы не скатиться в некрасивый код написанный на коленке.
Из новых инструментов - появляется папочка “skills”, с markdown файлами о том каких правил придерживаться с работой по тем или иным вопросам
Все skills были взяты у жесткого адепта Vue - antfu
Все эти инструменты - круто, но толку от них сейчас почти ноль. Писать промпт все равно прийдется с уточнением что где использовать, хорошо что за нас уже давным давно придумали Agents.md. Суем туда все правила, можно даже через вайбкод и отличная инструкция по разработке нового функционала готова
Примерный итог прикрепляю на скрине работы с Codex:
Краткий итог
Может я уже чуть и запоздал с такими штуками, но как опытом действительно хотелось поделиться
Работая с таким шаблоном действительно чувствуешь себя архитектором кода, а не просто разрабом. Попробуйте сделать что-то такое и для себя, надеюсь, вы получите от этого удовольствие!