تصور کنید یک رابط کاربری را تحویل می‌گیرید که در نگاه اول بی‌نقص است، اما وقتی برای کدنویسی بازش می‌کنید، متوجه می‌شوید هیچ‌کدام از رنگ‌ها و فاصله‌ها به سیستم طراحی (Design System) متصل نیستند. این دقیقاً همان جایی است که هوش مصنوعی زاینده (Generative AI) — مثل نقاشی که ظاهر اثر را می‌سازد اما از ساختار بوم بی‌خبر است — در طراحی‌های حرفه‌ای شکست می‌خورد. در واقع، یک صفحه در فیگما ممکن است از نظر بصری بی‌عیب به نظر برسد، اما از نظر ساختاری کاملاً شکسته باشد.
به گزارش تیاگو شیکوتا، طراح محصول AI برزیلی، ابزار figma-maxxing برای حل این مشکل خاص ساخته شده است. این ابزار به تمایل عامل‌های هوش مصنوعی برای ایجاد طرح‌هایی پاسخ می‌دهد که با هدف بصری مطابقت دارند اما سیستم طراحی زیربنایی را نقض می‌کنند. اکثر ابزارهای طراحی فعلی فقط روی خروجی نهایی تصویر تمرکز می‌کنند، اما در محیط‌های تولیدی حرفه‌ای، یک طرح تنها زمانی مفید است که از متغیرها و کامپوننت‌های درست استفاده کند. اگر یک عامل (Agent) — شبیه به دستیاری که دستورات را اجرا می‌کند اما منطق پشت آن‌ها را نمی‌فهمد — به جای توکن‌های طراحی از کدهای رنگی خام (Hex Code) استفاده کند، یا یک کامپوننت را برای اینکه «بهتر جا بیفتد» جدا (Detach) کند، بدهی فنی عظیمی برای برنامه‌نویسان انسانی ایجاد می‌کند که باید آن را پیاده‌سازی کنند.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی استانداردهای کدنویسی AI اشاره کردیم، شکاف بین «ظاهر درست» و «ساختار درست» بزرگ‌ترین مانع پذیرش کامل ابزارهای خودکار است. این چالش شباهت زیادی به مشکلات اعتبارسنجی پرامپت‌های بصری دارد که در آن توهمات بصری منجر به خروجی‌های غیرقابل پیاده‌سازی می‌شوند. شیکوتا برای مقابله با این وضعیت، مجموعه‌ای از هشت مهارت عاملی با مجوز MIT توسعه داده است. این دستورالعمل‌ها به AI اجازه می‌دهد مانند یک بازرس سخت‌گیر، «شُل‌وپلوتی» (Slop) یا همان فاصله بین ظاهر فایل و نحوه ساخت واقعی آن را بررسی کند. این سیستم بر دو مسیر اتصال اصلی متکی است: سرور رسمی MCP فیگما و پل figma-console-mcp که توسط Southleft توسعه یافته است. شیکوتا در کارهای تولیدی خود از این پل دسکتاپ محلی استفاده می‌کند، هرچند همان‌طور که در جدول سازگاری مخزن (Repository) ذکر شده، پشتیبانی و پوشش تست‌ها بسته به مهارت و سرور متفاوت است.
مکانیزم بازرسی
این چارچوب از سه دروازه اصلی برای کنترل کیفیت و مدیریت جریان کاری استفاده می‌کند:
- figma-preflight: یک دروازه فقط-خواندنی با ۸ بررسی که پیش از هر عملیات نوشتاری اجرا می‌شود تا از خطاهای اولیه جلوگیری کند.
- figma-slop-check: بازرسی پس از اجرا که طراحی‌های «مصنوعی» (Generated-looking) و انحراف از توکن‌ها و مقیاس‌های پروژه را شناسایی می‌کند. در نسخه ۱.۲.۰، این بخش شامل ۸ بررسی شُل‌وپلوتی و ۱۱ بررسی سخت‌گیرانه است که در ۵ گروه سازماندهی شده‌اند.
- figma-handoff-gate: بررسی نهایی با ۱۷ الزام برای اطمینان از اینکه هر اکشن، یک مقصد و یک مسیر بازگشت مشخص دارد.
پشتیبان این سیستم، figma-canon است؛ مخزنی از ۹۰ مورد «دام» (Gotcha) که شامل ۴۵ ناهنجاری API پلاگین و ۴۵ یادداشت میدانی است که بر اساس علائم (Symptom) ایندکس شده‌اند. این یادداشت‌ها شکست‌های بحرانی را مستند می‌کنند؛ برای مثال، مواردی که در آن یک لایه جدّ (Ancestor) قفل‌شده مانع از اتصال متغیر می‌شود، در حالی که خود لایه گزارش می‌دهد که قفل نیست (locked: false). در چنین مواردی، فراخوانی‌ها بدون خطا باز می‌گردند و اگر فقط رنگ خوانده شود، مشکل نادیده گرفته می‌شود زیرا رنگ خام و متغیر مقدار یکسانی دارند.
نتایج تست کور
در ۵ اکتبر ۲۰۲۶، شیکوتا یک تست کور با استفاده از سه عامل مجزا اجرا کرد. عامل اول یک صفحه «اعضای تیم» (Team members) را ساخت که شامل یک عنوان، یک کارت خلاصه، لیستی از پنج نفر و یک دکمه «افزودن عضو» بود و ۱۰ نقص خاص را به طور عمدی در آن جایگذاری کرد. عامل دوم، در نقش بازرس و بدون داشتن کلید پاسخ‌ها، بررسی‌های slop و handoff را اجرا کرد. عامل سوم نتایج بازرسی را با کلید پاسخ‌ها مقایسه کرد.
نتایج مطلق بود: بازرس تمام ۱۰ نقص عمدی را بدون هیچ خطایی (Zero misses) و بدون هیچ تطابق جزئی پیدا کرد. لیست نهایی (Punch list) شامل ۲۷ مورد بود: ۱۶ مورد از بررسی slop و ۱۱ مورد از دروازه handoff. از این میان، ۱۳ مورد با نقص‌های عمدی مطابقت داشت (برخی نقص‌ها منجر به ایجاد چندین مورد در لیست شدند).
جالب‌تر اینکه بازرسی ۱۴ مشکل اضافی را هم پیدا کرد که عامل اول از آن‌ها غافل شده بود. این موارد ۱۳ مشکل متمایز را توصیف می‌کردند (یک تغییر نام توسط هر دو بررسی شناسایی شده بود). این یافته‌ها شامل یک خطای کنتراست رنگی (۴.۳۲:۱) روی متنی با اندازه ۱۴ پیکسل بود که حتی کلید پاسخ‌ها هم از آن غافل شده بود. اگرچه داور نتوانست دو مورد را بدون باز کردن فایل مستقیماً تأیید کند، اما هیچ‌کدام با شواهد موجود در تضاد نبودند.
شکست‌های رایج طراحی AI
این تست چندین خطای «نامرئی» را برجسته کرد که معمولاً از چشم انسان در بازرسی بصری دور می‌مانند:
- عدم تطابق متغیرها: یک عنوان ممکن است رنگ درست (#111827) را داشته باشد اما به متغیر
color/text/primaryمتصل نباشد. از نظر بصری یکسان است، اما از نظر ساختاری شکسته است. - کامپوننت‌های جداشده (Detached): یک ردیف در لیست (مانند ردیف Sofia Martins) ممکن است درست به نظر برسد اما در واقع یک Frame ساده باشد که فقط نام کامپوننت را حفظ کرده است. این لایه دیگر نمونه‌ای (Instance) از کامپوننت
ListItemنیست، به این معنی که تغییرات در کامپوننت اصلی روی آن اثر نمی‌گذارد. - خطاهای مقیاس‌بندی: استفاده از
instance.resize()می‌تواند باکس محیطی را کوچک کند در حالی که آیکون داخلی را در اندازه کامل نگه می‌دارد؛ در حالی که برای اصلاح درست، استفاده ازrescale()الزامی است. - شکاف‌های عملیاتی: دروازه handoff اکشن‌های «افزودن عضو» را شناسایی کرد که فاقد مسیر «حذف» متناظر و همچنین فاقد وضعیت‌های تاییدیه (Confirmation) و نتیجه (Result) بودند.
- شکست‌های اتصال (Binding): پر کردن (Fill) یک بخش ممکن است به یک متغیر متصل شود اما همچنان رنگ پایه‌ای را رندر کند که هنگام اتصال ارسال شده است. یادداشت میدانی figma-maxxing برای جلوگیری از این اتفاق، متغیر را پیش از اتصال Resolve می‌کند.
- شکست‌های پروتوتایپ: تغییر دادن تنها فیلد اکشن قدیمی (Legacy action) می‌تواند منجر به این شود که فراخوانی گزارش موفقیت دهد در حالی که مقصد بدون تغییر باقی مانده است. راه حل این است که آرایه اکشن‌ها تغییر کند و سپس مقصد دوباره خوانده شود.
محدودیت‌های اصلاح خودکار
با وجود این ابزارها، اتوماسیون هنوز مرزهایی دارد. در این تست، یک عامل چهارم سعی کرد مشکلات شناسایی شده را حل کند. این فرآیند شامل ۱۳ فراخوانی ابزار برای اصلاح، پس از ۱۲ فراخوانی برای بازرسی اولیه و ۱۳ فراخوانی برای بازرسی دوم بود. عامل‌ها توسط سرور رسمی محدود شده بودند، زیرا ابزار انتخاب (Selection tool) یا ابزار وضعیت پل (Bridge-status tool) نداشتند؛ همچنین get_screenshot رندرهای بالای 1x را انجام نمی‌داد و سقف آن ۲۰ کیلوبایت بود.
در حالی که این اصلاحات ۱۲ مورد از یافته‌های slop را بست، صفحه همچنان در دروازه‌های بازرسی نهایی شکست خورد. یافته‌های figma-slop-check از ۱۶ مورد به ۶ مورد کاهش یافت، اما یک یافته بحرانی باقی ماند: نبود وضعیت فوکوس (Focus state) روی دکمه یا ListItem. تعداد مشکلات figma-handoff-gate در واقع از ۱۱ مورد به ۱۳ مورد افزایش یافت که ۸ مورد آن‌ها مسدودکننده (Blocker) بودند — عمدتاً جریان‌های کاربری پیچیده و وضعیت‌هایی که AI نمی‌توانست بدون تصمیم یک طراح رسم کند. همچنین دو مورد از شش یافته باقی‌مانده در slop، در واقع توسط خودِ فرآیند اصلاح ایجاد شده بودند.
در نسخه ۱.۲.۰، سیستم اصلاحات پیشنهادی را به سه دسته تقسیم می‌کند:
- Swap (تعویض): متصل کردن یا اعمال یک مقدار یکسان، به گونه‌ای که صفحه از نظر بصری بدون تغییر بماند.
- Snap (تراز): انتقال یک مقدار به نزدیک‌ترین گام شناخته شده در پروژه و ثبت فاصله آن.
- Ask (پرسش): واگذاری یک تصمیم طراحی به مالک انسانی پروژه.
این ساختار تضمین می‌کند که عامل‌های AI تصمیمات خلاقانه دلخواه نگیرند. مهارت‌ها به عامل دستور می‌دهند که ابتدا گزارش دهد و منتظر تایید بماند؛ موارد «Ask» هرگز وارد دسته‌ای از اصلاحات خودکار نمی‌شوند. این دروازه‌ها متکی بر پیروی عامل از دستورالعمل‌ها هستند و به تنهایی نمی‌توانند جلوی یک عملیات نوشتاری را بگیرند.
این تغییر در رویکرد، طراحی AI را از حالت «پرامپت بده و دعا کن» به یک فرآیند مهندسی قابل تایید تبدیل می‌کند. با تبدیل فایل فیگما به چیزی شبیه به کد که نیاز به Linter (ابزار بررسی خطاهای نوشتاری) دارد، طراحان می‌توانند در نهایت به لایه‌های تولید شده توسط عامل‌ها در محیط‌های تولیدی اعتماد کنند. این رویکرد دقیقاً مشابه سیستم‌های اعتبارسنجی پاسخ‌ها در APIهاست که برای جلوگیری از شکست‌های خاموش در خروجی‌های تولید شده توسط هوش مصنوعی به کار می‌روند.
امتحان کنید با عامل خود
اگر از Claude Code، Codex، Gemini CLI یا دستور npx استفاده می‌کنید، می‌توانید این مهارت‌ها را از طریق npx skills add thiagoxikota/figma-maxxing نصب کنید. به طور خاص برای Claude Code، مسیر /plugin marketplace add thiagoxikota/figma-maxxing و سپس /plugin install figma-maxxing@figma-maxxing-skills است. در تاریخ ۲۰۲۶-۱۰-۰۵، این نصب‌ها در پوشه‌های پاک در تمامی این ابزارها تایید شدند، هرچند Cursor و اپلیکیشن‌های دسکتاپ/وب Claude تست نشدند.
برای کسانی که عامل کدنویسی ندارند، می‌توانید از این پرامپت در هر ابزار AI استفاده کنید:
"این فایل را به عنوان مرجع بخوان و استفاده کن: https://raw.githubusercontent.com/thiagoxikota/figma-maxxing/main/llms.txt. اگر نمی‌توانی آن را باز کنی، به من بگو و حدس نزن. من یک طراح هستم. من [دارم / ندارم] یک عامل AI متصل به فیگما. زمینه من: [پلن فیگما، اینکه آیا فایل‌هایم سیستم طراحی دارند، تک‌نفره یا تیمی]. حداکثر پنج قانون برای کار من انتخاب کن. برای هر کدام، یک بررسی به من بده که امروز بتوانم در فیگما انجام دهم. سپس به من بگو آیا نصب هر یک از مهارت‌ها برای من ارزشمند است یا خیر."
این پرامپت در ۶ مورد از ۶ تست در ابزارهای Claude، Codex و Gemini terminal با موفقیت عمل کرد. اگر عاملی فایل فیگما شما را به گونه‌ای خراب کرد که در موارد Gotchas پوشش داده نشده است، شیکوتا تشویق می‌کند که یک Issue با ذکر علائم و اصلاحی که اجرا کردید، باز کنید. مخزن: thiagoxikota/figma-maxxing. مجوز MIT. بدون وابستگی به شرکت فیگما.
گام بعدی شما
- اگر از Claude Code یا Gemini CLI استفاده می‌کنید، این مهارت‌ها را با دستور
npx skills add thiagoxikota/figma-maxxingنصب کنید. - برای کسانی که عامل کدنویسی ندارند، از پرامپت ارائه شده در انتهای مقاله برای تحلیل فایل‌های خود در هر مدل زبانی استفاده کنید.
- در پروژه‌های تیمی، یک مرحله «بازرسی ساختاری» را به گردش کار تحویل طرحات (Handoff) اضافه کنید تا از بدهی فنی جلوگیری شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو