Figma представи Specs на 15 октомври 2026 г. като общо място за писмения контекст на продукта, дизайните и работата с AI агенти. Идеята е техническото намерение да остане близо до визуалните материали, вместо да се губи между отделни документи. Функцията се разгръща в отворена бета; наличието на съобщение не означава, че всеки акаунт вече я вижда.

Документът участва в работния процес

Specs използва Markdown като четим за агенти формат и позволява контекст от дизайни, диаграми и code layers. Чрез Figma MCP server агент може да получава този контекст. Това е опит да се намали разстоянието между решението и реализацията. Не е доказателство, че всеки получен код автоматично съответства на намерението на екипа.

Помощната документация посочва достъп за Professional, Education, Organization и Enterprise при нужните права за редакция. Разгръщането е постепенно. Ръчното писане и редактиране на Spec не използва агента и не струва AI кредити; работата с агента използва такива, като количеството зависи от задачата и контекста. Следователно общият документ и автоматизираната работа в него имат различно отражение върху употребата.

Защо това има значение за екипите

Нашият прочит е, че основният проблем не е липсата на още текст. Често е неясно кой текст описва прието решение и кой е предложение от разговор. Ако агент получи и двете без разграничение, той може да произведе последователна реализация на грешната версия. Новото място за контекст е полезно само ако екипът поддържа това разграничение.

Пример е формуляр с нормално, празно и грешно състояние. Красивият основен екран не описва какво става при невалидни данни или прекъсната заявка. В собствен Spec бихме включили тези състояния, очакваното поведение и начина за проверка. Това е наш предложен пример, а не твърдение, че Figma автоматично попълва всички липсващи изисквания.

Важна е и връзката към конкретен дизайн. Ако диаграмата се промени, трябва да е ясно дали писменото решение все още е валидно. Иначе по-богатият контекст може да направи старо допускане по-убедително, вместо да го поправи. Поради това препоръчваме съществените промени да имат видим собственик и преглед.

Как да се оцени ползата без подвеждащ резултат

За пилот е по-полезна малка реална задача с ясни критерии за приемане, отколкото общо измерване колко бързо се е появил прототип. Трябва да се отчетат времето за подготовка на контекста, корекциите и прегледът на резултата. Ако тези стъпки останат извън измерването, автоматизацията може да изглежда по-бърза само защото част от човешката работа е изключена.

Нашето предложение е да се пазят заедно приетият Spec, използваните материали и проверката на получения код. При промяна в изискванията се обновява и критерият за приемане. Така екипът може да установи дали агентът е следвал текущото решение, вместо да разчита на общото впечатление, че екранът изглежда близък.

Specs добавя конкретен интерфейс към тази организация на работата. Стойността му ще зависи от това дали документът остава актуален и дали участниците знаят какво е одобрено. Отворената бета е подходящ момент за ограничена проверка на такъв процес. Тя не отменя нуждата от тестове, продуктови решения и отговорен преглед преди внедряване.

Редакционна проверка: 2026-10-19T06:33:53.177083+00:00 (UTC). Корица: концептуална AI илюстрация, не документална снимка.