MCP для работы с Figma

Теперь я знаю как делать дизайн в Figma с помощью AI.

Ссылка на GitHub

#ai #нейронныесети #figma #mcp

Framelink MCP для работы с Figma

Анализирует макеты Figma и тем самым можно делать верстку.

Ссылка на GitHub

#ai #нейронныесети #figma #mcp

Маленькое видео о том как подключить MCP к Cursor и Trae.

Чтобы MCP заработал, читайте инструкции которую предоставляют разработчики. Для Windows и Mac, JSON может отличаться. Так же могут потребоваться API ключи.

#ai #cursor #trae #mcp

Qodo (ex-Codium) — пишет тесты, ревьюит пулреквесты и генерит код. Подтягивает правила именно вашего проекта, а не абстрактные best practices.

Модели которые доступны: GPT-4.1, 4.o, o4-mini, o3, Claude 4 Sonnet, Deepseek-R1 (хостится на Qodo), Gemini 2.0 Flash.

Плагины
Qodo Gen — расширение для VS Code и JetBrains: автогенерация тестов, чат с контекстом всего репозитория, быстрые подсказки. Возможность расширения с помощью встроенных и настраиваемых MCP.

Qodo Merge — Git-агент в PR: ищет баги, собирает описание, дописывает доки.

Сколько стоит
Developer — бесплатно, 250 запросов в месяц.
Teams — $30/мес., 5 000 запросов.


Сайт Qodo

#ai #qodo #нейросети

Промпт который помогает сделать: бизнес-план, бизнес-модель, финансовую модель.
Проверил на ChatGPT o3.

Краткий промпт для диалогового режима

Выступи в роли бизнес-консультант / стратег.
Мне нужна помощь в составлении бизнес плана. Сфера бизнеса [тут напишите свою идею].
Задавай вопросы, до тех пор пока не соберёшь всю нужную информацию от меня. 

Универсальный шаблон промпта
Этот шаблон превращает LLM в настойчивого консультанта. Она не приступит к расчётам, пока не соберёт все критичные данные, и выдаст конечные документы в удобном формате.

Роль и ключевая задача
----------------------
Ты — Бизнес-консультант / стратег. 
Твоё задание — вывести из пользователя всю необходимую информацию и на основе ответов подготовить:

1. Бизнес-план (Executive Summary → Market → Product / Service → Go-to-Market → Ops & Team → Finance → Risk).  
2. Бизнес-модель (канва Business Model Canvas или аналог).  
3. Финансовую модель (таблица допущений + P&L + Cash-flow, 3 года).

Общие правила общения
---------------------
* Работай интерактивно: задавай вопросы до тех пор, пока данных недостаточно.  
* После каждого «блока вопросов» жди ответ пользователя и кратко резюмируй, что уже собрано.  
* Никогда не переходи к расчётам, если остаются важные «пустые поля».  
* Все термины объясняй просто, без жаргона и англицизмов (кроме общепринятых).  
* Источник цифр всегда уточняй: «оценка», «реальные данные», «ещё не знаю».  

Контрольный чек-лист информации
-------------------------------
1. Видение и цели: долгосрочная цель, ключевой KPI.  
2. Продукт / услуга: что именно продаём, уникальное преимущество.  
3. Целевая аудитория: сегменты, география, размер рынка.  
4. Конкуренты и позиционирование.  
5. Ценообразование и источники выручки (единоразово, подписка, B2B и т.д.).  
6. Маркетинг и продажи: каналы, конверсии, партнёры.  
7. Команда и ресурсы: роли, зарплаты, технологии, подрядчики.  
8. Операционные затраты: произв., логистика, лицензии, аренда.  
9. Финансы: стартовый капитал, планируемые инвестиции, точка безубыточности.  
10. Риски и регуляторные требования.  
11. Тайм-лайн: даты MVP, запусков, контрольных точек.

Алгоритм работы
----------------
Этап 0. Приветствие
– Представься и поясни процесс (сбор данных → резюме → документ).

Этап 1. Блок «Стратегия»  
– Спроси цели, рынок, продукт, УТП.  
– Резюмируй полученное; отметь пробелы.

Этап 2. Блок «Маркетинг и продажи»  
– Спроси сегменты, каналы, воронку, ценник, конверсии.  
– Резюмируй, снова покажи недостающие поля.

Этап 3. Блок «Ресурсы и финансы»
– Спроси команду, расходы, план инвестиций, ожидания по выручке.  
– Проверь, что есть все числа для P&L (объёмы, цены, косты).

Этап 4. Финальная проверка  
– Выведи таблицу «Что известно / Что не известно».  
– Запроси оставшиеся точки.

Этап 5. Формирование документов  
– Когда всё собрано, сформируй:  
  • Business Model Canvas (9 блоков);  
  • Бизнес-план (разделы 1-7);  
  • Финансовую модель: таблицу допущений и свод P&L + Cash-flow (в Markdown или ссылкой на Excel-файл).  

Формат вывода
-------------
1. Каждый блок вопросов — маркированный список.  
2. Резюме — короткий параграф + таблица «поле / заполнено ли».  
3. Финальные документы — Markdown-структура (можно скачать как .md) или прикреплённый Excel.

#ai #нейросеть #chatgpt #промпты #бизнес

Я провел небольшое исследование.
На каком языке программирования нейросети проще всего писать код.

Давайте просто пофантазируем.
Отбросим все рассуждения по поводу вайб кодинга и т.п.

Представим себе следующую ситуацию. Что нейросеть выступает в роли того кто пишет код, но этот код не для человека, а для самой LLM должен быть понятен. Т.е. нейросеть выступает в роли компилятора (транслятора, интерпретатора) с человеческого языка в понятный ей код.

На подобии того как мы сейчас пишем код. У нас есть высокоуровневый язык, который потом мы компилируем в машинный код. Нас мало интересует какой код там получился. Тут та же история, нас мало интересует какой код получился. Для примера можно взять TypeScript, мало кому интересно какой JavaScript на выходе.

И так. Больше всего нейросети склонны к пониманию функциональных языков со строгой и статической типизацией. С минимальным синтаксисом.
Чтобы была только одна интерпретация выражения. Однозначная линейная сериализация абстрактного синтаксического дерева (AST).

Высказывание ChatGPT

Если полностью забыть о том, что код когда-нибудь будет читать человек, и смотреть только с позиции LLM-модели, то «удобство» — это:

Минимальная энтропия токенов (как можно меньше вариантов написания одной и той же конструкции).

Однозначное древовидное представление без необходимости восстанавливать его из смешивания пробелов, скобок, ключевых слов и т.д.

Явные типы и связи (чтобы не нужно было делать вывод типов во время анализа).

Отсутствие «шумового» синтаксиса, который не несёт семантики, но расходует окно контекста.

Поэтому в идеале я бы выбрал не «язык» в привычном смысле, а чистое сериализованное AST-дерево.

Самый практичный вариант — S-выражения (Lisp-стиль) с обязательными аннотациями типов.

Пример такого когда

(fn add
  ((a : Int) (b : Int))
  : Int
  (+ a b))

Каждая скобка это граница узла. Порядок токенов всегда одинаков. Типы видны сразу, значит поиск/замена по типовой сигнатуре тривиален.

Важно чтобы в одном файле была одна сущность, тогда не будет путаницы. Из-за минималистичного синтаксиса идёт экономия токенов. Контекст становится больше.


Пойдя дальше, я выяснил что и задачи ставить можно в виде диаграмм процессов. Четкая последовательность действий и что делать при негативном сценарии (аналитики карты вам в руки).

Когда-то программисты придумали компиляторы и высокоуровневые яп, чтобы упростить работу и сделать код читаемым. А не писать все на перфокартах и ассемблере.

Мне кажется что не за горами то время, когда LLM станет ещё одной абстракцией. И мы не будем смотреть в ее код. И придумаем ещё более высокоуровневые языки. Которые будут описывать бизнес процессы.


Примеры возможных реализаций описание задачи для LLM.
Псевдокод с контекстными якорями

Когда пользователь {нажимает} на [кнопку ID=buy_btn]:
  ЕСЛИ корзина НЕ пуста:
    ПОКАЗАТЬ модалку "Оплата" (#шаблон=stripe_form_v2)
    ОЖИДАТЬ ответ от Stripe
    ЕСЛИ успех: 
      СОХРАНИТЬ заказ в #база_данных[Заказы]
      ОТПРАВИТЬ email через #сервис[SendGrid]
    ИНАЧЕ: 
      ПОВТОРИТЬ 2 раза
      СООБЩИТЬ "Ошибка платежа"

Визуальный конструктор как Miro

[Кнопка "Купить"] --клик--> {Проверить корзину} --> [Форма оплаты] 
  --> (API Stripe) --> [Успех!] :show_confetti
  --> (Ошибка?) :red --> [Повторить?]

Онтология

# Типы данных:
Данные_карты ::= номер:строка[16-19], срок:дата, cvv:число[3]
Email ::= строка@домен:валидный_формат

# Действия:
ПОКАЗАТЬ(элемент, анимация?="плавно")
СОХРАНИТЬ(куда: "таблица", данные: json)

Как LLM это обрабатывает
1) Декомпозиция, разбивает визуальный граф на атомарные задачи.
2) Контекстный поиск по тегам (#база_данных, #шаблон) подтягивает релевантные фрагменты из базы знаний.
3) Генерирует код, используя:
Онтологию → типизацию
Примеры → UI-библиотеки
Речевые паттерны → бизнес-логику
4) Проверяет код на соответствие онтологии через статический анализ.

#ai #мысли

Преимущества перед классическим вайб кодингом
Нет простыней текста. Визуал + речевые паттерны сокращают описание в 5 раз. Обход контекстного окна. Теги (#пример[...]) работают как гиперссылки в RAG. Автодокументирование. Онтология становится спецификацией API.
LLM может спрашивать: "Укажи тип для cvv: число[3] или строка?" прямо на схеме.


Я не говорю что исчезнут программисты. Но согласитесь, многие кто сейчас является разработчиком, не является инженером. У нас сейчас довольно много абстракций, которые позволяют не задумываться о технической части. Есть сферы, где важны более глубокие познания технологий и железа, но это малая часть от всей разработки.

Пишем веб, а как работает браузер не знаем. Пишем игры, но не знаем как работает видеокарта, да и не нужно. Пишем бэкэнд, но не знаем как работает процессор.

Есть области разработки, где возможна такая абстракция как LLM.

А вы как считаете? Давайте по халиварим.

#ai #мысли