چگونه اجبار به تعریف توکن‌ها مانع بازاختراع چیدمان توسط هوش مصنوعی می‌شود؟

تصور کنید یک برنامه‌نویس Front-end است که هر بار از هوش مصنوعی کد می‌گیرد، با یک سیستم رنگ‌بندی و فاصله‌گذاری متفاوت مواجه می‌شود. این عدم ثبات، نتیجه‌ی یک نقص بنیادی در ادراک بصری مدل‌های زبانی است که تنها با تغییر ساختار داده‌های ورودی قابل حل است.

طبق گزارشی که در ۱ جولای ۲۰۲۶ منتشر شد، نتایج یک آزمایش کور نشان می‌دهد که مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — وقتی مجبور باشند ابتدا توکن‌های طراحی را تعریف کنند و سپس به سراغ HTML و CSS بروند، کدهایی با ثبات بسیار بیشتر تولید می‌کنند. این مطالعه ثابت می‌کند که مدل‌های مدرن اگرچه می‌توانند کد تمیزی بنویسند، اما فاقد یک واژگان طراحی داخلی و پایدار هستند و همین موضوع باعث ایجاد نتایج تکه‌تکه‌ شده در جلسات مختلف می‌شود.

شکاف ادراکی

وقتی یک انسان به رابط کاربری (UI) نگاه می‌کند، یک تصویر را می‌بیند: ترکیبی از دکمه‌ها، رنگ‌ها، فاصله‌ها و حس کلی محیط. این فرآیند برای ما طبیعی است، اما برای یک مدل زبانی، چنین کانال بصری‌ای وجود ندارد. یک مدل هرگز صفحه را «نمی‌بیند»، بلکه اعداد را پردازش می‌کند.

بسیاری تصور می‌کنند مدل‌های چندوجهی (Multimodal) — مدلی که هم‌زمان متن، عکس و صدا را می‌فهمد، شبیه ما که با چند حس دنیا را می‌خوانیم — با پذیرش اسکرین‌شات‌ها این مشکل را حل کرده‌اند. اما طبق مستندات فنی، چندوجهی بودن در اینجا موضوع اصلی نیست. ورودی چه متن باشد، چه صدا و چه تصویر، در نهایت به نمایش‌های عددی تبدیل می‌شود. مدل هرگز با یک «عکس» به عنوان عکس برخورد نمی‌کند، بلکه با نمایش عددی آن سروکار دارد.

یک اسکرین‌شات تبدیل به مجموعه‌ای از اعداد می‌شود که پیکسل‌ها، نواحی روشن و تاریک و لبه‌ها را توصیف می‌کنند. از این طریق، مدل تنها می‌تواند «حدس بزند» که یک فاصله تقریباً ۱۶ پیکسل است یا یک رنگ، طیفی از آبی است. این حدس‌زنی است، نه دانش واقعی از قصد طراحی.

کدام اعداد دقیقاً؟

تفاوت این وضعیت، تقریباً شبیه تفاوت بین عکس یک صفحه کتاب با خودِ متن آن کتاب است. برای استفاده از متنِ موجود در عکس، شما ابتدا باید حروف را شناسایی کنید، کلمات را کنار هم بگذارید و شروع یک پاراگراف را از سایه‌ی روی کاغذ تشخیص دهید. اما کار با متن مستقیم، تمام این حدس‌زنی‌ها و مراحل واسط را حذف می‌کند.

طراحی نیز به همین شکل عمل می‌کند. یک اسکرین‌شات، یا حتی کد HTML همراه با استایل‌ها، مدل را مجبور می‌کند تا «قصد طراحی» (Intent) را از روی «فرم» (Form) بازسازی کند. با ارائه مستقیم این قصد از طریق توکن‌های طراحی (Design Tokens)، نیاز مدل به حدس زنی کاملاً حذف می‌شود.

یک توکن طراحی، یک پیکسل یا یک خط CSS نیست؛ بلکه یک مقدار معنادار با یک نام مشخص است: مثلاً «رنگ اقدام اصلی» (Primary Action Color)، «پس‌زمینه سطح» (Surface Background)، «فاصله داخلی کارت» (Padding inside a card) یا «شعاع گوشه پنل» (Corner radius). توکن‌ها طراحی را همان‌طور توصیف می‌کنند که یک تیم طراحی درباره آن صحبت می‌کند: نه اینکه بگویند «این آبیِ دقیقاً اینجا»، بلکه می‌گویند «رنگ اقدام اصلی، که هر کجا یک اقدام اصلی وجود دارد، استفاده می‌شود».

جالب این است که واحد پایه یک مدل زبانی نیز توکن (Token) نامیده می‌شود. اگرچه توکن مدل یک تکه متن (Chunk of text) است و توکن طراحی یک مقدار نام‌گذاری شده از طراحی، اما هر دو در یک نقطه به هم می‌رسند: هر دو معنا را به ساختاری تبدیل می‌کنند که ماشین بتواند با آن کار کند.

بسیاری از توسعه‌دهندگان با AI مانند یک همکار بصری برخورد می‌کنند و به آن اسکرین‌شات یا توصیفات سطح بالا می‌دهند. اما همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چگونه Ollama و Spring Boot زیرساخت‌های AI محلی را ممکن می‌سازند اشاره کردیم، کارایی یک سیستم هوش مصنوعی به شدت به این وابسته است که داده‌ها پیش از رسیدن به مدل، چگونه ساختار یافته باشند.

نویز موجود در HTML و CSS

مدل‌ها می‌توانند HTML و CSS را بخوانند، اما این فرمت‌ها پر از «نویز» هستند: مارک‌آپ‌ها، تودرتو شدن‌ها (Nesting)، پوشاننده‌های چیدمان (Layout Wrappers) و مقادیر رنگی که به صورت دستی کپی شده‌اند. در واقع، طراحی اصلی زیر این حجم از سربار ساختاری دفن شده است.

برای اینکه مدل تشخیص دهد یک رنگ آبی که در سه جای مختلف استفاده شده، در واقع نماینده‌ی یک «رنگ اصلی» واحد است، باید دوباره به بازسازی و حدس‌زنی روی آورد. توکن‌های طراحی این نویز را پاک می‌کنند. آنچه باقی می‌ماند فقط خودِ طراحی و روابط بین اجزای آن است؛ بنابراین مدل دیگر نیازی به بازسازی هیچ چیزی ندارد.

آزمایش: یک تسک، دو مسیر

برای تست این فرضیه، یک آزمایش کور با استفاده از عامل‌های مستقل (Independent Agents) روی یک مدل واحد انجام شد. این عامل‌ها به دو گروه تقسیم شدند. هر دو گروه یک وظیفه داشتند: ساخت یک کارت محصول شامل تصویر، عنوان، قیمت، امتیاز و دکمه خرید. تنها متغیر در این آزمایش، پرامپت بود.

• گروه اول (مستقیم): دستور گرفتند صرفاً کارت را بسازند و HTML و یک فایل CSS جداگانه تحویل دهند. پرامپت دقیق این بود: "یک کارت محصول با تصویر، عنوان، قیمت، امتیاز و دکمه خرید بسازید. HTML و یک فایل CSS جداگانه را برگردانید."
• گروه دوم (ابتدا توکن): دستور گرفتند ابتدا طراحی را در قالب توکن‌ها و با فرمت DTCG در سه لایه (پایه/Primitive، معنایی/Semantic و کامپوننت) توصیف کنند و سپس CSS را بنویسند. پرامپت آن‌ها را ملزم می‌کرد که این لایه‌ها را تعریف کنند و صراحتاً کدنویسی مستقیم مقادیر (Hardcoding) در استایل‌های کامپوننت را ممنوع کرد.

مسیر اول: حرکت مستقیم به سوی کد

در فاز اول آزمایش، رویکرد «مستقیم به کد» سه نقص بحرانی را آشکار کرد. به‌طور غافلگیرکننده‌ای، مدل‌های مدرن همه رنگ‌ها را به صورت سختافزاری (Hardcode) نمی‌نویسند، بلکه اغلب متغیرهای CSS را خودشان می‌سازند، مانند:

:root { --color-surface: #ffffff; --color-accent: #4f46e5; --color-accent-hover: #4338ca; --radius-lg: 18px; --radius-md: 12px; --shadow-card: 0 10px 30px rgba(17, 24, 39, 0.08); }

اما این استفاده «خودکار» از متغیرها کافی نیست زیرا منجر به مشکلات زیر شد:

• ادغام نقش‌ها (Fused Roles): مدل‌ها متغیرهایی مثل --color-accent می‌ساختند که هم‌زمان هم یک رنگ خاص از پالت بود و هم نقش عملکردی «اقدام اصلی» را ایفا می‌کرد. این یعنی «کدام رنگ است» و «برای چه کاربرد است» در یک نام ادغام شدند. اگر رنگ برند تغییر کند، نقش هم تغییر می‌کند؛ اگر بخواهید نقش را تغییر دهید، باید همان نام را ویرایش کنید. علاوه بر این، پیوند بین یک رنگ و نسخه hover آن فقط در ذهن کسی بود که کد را نوشته است.
• نشت مقادیر سخت (Hardcoded Leaks): با وجود متغیرها، باز هم «اعداد جادویی» ظاهر می‌شدند. برای مثال، یک border-radius: 12px ممکن بود دقیقاً کنار یک متغیر شعاع قرار بگیرد، یا یک outline با رنگی که به صورت rgba(...) نوشته شده بود و به هیچ متغیری متصل نبود.
• پراکندگی واژگان (Vocabulary Drift): اجراهای مستقل، قراردادهای نام‌گذاری کاملاً متفاوتی تولید کردند. یک عامل از --color-primary استفاده کرد و دیگری از --color-accent؛ یکی سایه‌ی دکمه را اضافه کرد در حالی که بقیه نکردند. هیچ زبان مشترکی شکل نگرفت و هر عامل واژگان خاص خود را اختراع کرد.

مسیر دوم: اولویت با توکن‌ها

گروه دوم از رویکرد متفاوتی استفاده کردند. استایل‌های کامپوننت آن‌ها هیچ مقدار خامی نداشتند و فقط به توکن‌ها ارجاع می‌دادند:

.card { background: var(--component-card-default-background); border-radius: var(--component-card-default-radius); box-shadow: var(--component-card-default-shadow); } .card__price { color: var(--component-card-price-color); } .card__button { background: var(--component-card-button-background); } .card__button:hover { background: var(--component-card-button-background-hover); }

در پشت این نام‌ها، ساختاری قرار داشت که آن دو پرسش ادغام‌شده در نسخه مستقیم را از هم جدا می‌کرد. پاسخ به «کدام رنگ است» در لایه پایه (Primitives) قرار گرفت و پاسخ به «برای چه کاربرد است» در لایه معنایی (Semantics). یک مقدار خام دقیقاً یک‌بار در لایه‌ی پایه ظاهر می‌شد و بقیه همه ارجاع بودند:

{ "primitive": { "color": { "indigo-600": { "$type": "color", "$value": { "colorSpace": "srgb", "components": [0.31, 0.275, 0.898], "hex": "#4f46e5" } }, "indigo-500": { "$type": "color", "$value": { "colorSpace": "srgb", "components": [0.388, 0.4, 0.945], "hex": "#6366f1" } } } }, "semantic": { "color": { "action-primary": { "$type": "color", "$value": "{primitive.color.indigo-600}" }, "action-primary-hover": { "$type": "color", "$value": "{primitive.color.indigo-500}" } } }, "component": { "button": { "primary": { "background": { "$type": "color", "$value": "{semantic.color.action-primary}" }, "background-hover": { "$type": "color", "$value": "{semantic.color.action-primary-hover}" } } } } }

این فرمت صریح و بدون ابهام است. هر توکن نوع خود را اعلام می‌کند و ارجاعات برای انسان و ابزارها شفاف است. این تفکیک مسئولیت‌ها منجر به تغییری دراماتیک در پایداری خروجی شد. تمام عامل‌های مستقل در این گروه بر روی یک اسکلت تقریباً یکسان هم‌گرا شدند. در حالی که پالت‌های رنگی متفاوتی انتخاب کردند، اما از نقش‌های سازگاری استفاده کردند: surface برای پس‌زمینه، action برای دکمه‌های اصلی و text-primary و text-secondary برای تایپوگرافی. حالت مستقیم هرگز به این سطح از هم‌گرایی نرسید.

نتایج و ابزارها

این آزمایش زیبایی کارت‌ها را اندازه نگرفت (چون همه نسخه‌ها خوب به نظر می‌رسیدند)، بلکه «ثبات» (Consistency) را سنجید. در حالت مستقیم، واژگان در هر اجرا تغییر می‌کردند. در حالت توکنی، اجراهای مستقل به دلیل داشتن یک روش تفکر (مقادیر پایه $\rightarrow$ نقش‌ها $\rightarrow$ کاربرد)، بر روی یک واژگان واحد هم‌گرا شدند.

با این حال، مدل گاهی در جزئیات فرمت DTCG اشتباه می‌کرد. هیچ‌کدام از اجراهای توکنی در تلاش اول کاملاً معتبر نبودند. در برخی موارد، ابعاد به جای جفت‌های «مقدار و واحد»، به صورت رشته (String) نوشته شده بودند؛ در موارد دیگر، گروه‌های پایه بر اساس نوع دسته‌بندی نشده بودند. اینجاست که Design Token Kit ضروری می‌شود. این ابزار اعتبارسنجی و تبدیل توکن‌های تولید شده توسط AI را از طریق دستورات خاص مدیریت می‌کند:

• بررسی توکن‌ها: دستور dtokens check tokens.json برای شناسایی ارجاعات شکسته یا عدم تطابق نوع.
• تبدیل به CSS: دستور dtokens convert --outform css --out tokens.css tokens.json برای تبدیل JSON توکن‌ها به CSS آماده تولید.
• تولید نمایشگر: دستور dtokens showcase --out showcase.html tokens.json برای ساخت یک صفحه تأیید بصری.
• تبدیل بین فرمت‌ها: دستور dtokens convert --inform dtcg --outform hrdt --out tokens.yaml tokens.json برای جابجایی بین نام‌گذاری‌های مختلف.

استانداردهای فرمت توکن

فرمت‌های مختلف برای نیازهای متفاوتی بهینه شده‌اند، اگرچه معنای آن‌ها یکسان است:

• DTCG (Design Tokens Community Group): توسط W3C به عنوان یک استاندارد صنعتی برای تعامل‌پذیری (Interoperability) توسعه یافته است. این استاندارد اجازه می‌دهد توکن‌های یکسان توسط ابزارهای مختلف درک شوند و امکان ساخت تم‌ها را فراهم می‌کند. همان‌طور که در سایت این پروژه ذکر شده، JSONهای DTCG قفل تعامل بین ابزاری و تم‌بندی را می‌شکنند.
• HRDT (Human-Readable Design Tokens): توسط نویسندگان design-token-kit ایجاد شده است. این فرمت از YAML برای روشی فشرده‌تر و خواناتر برای نوشتن توکن‌ها با دست استفاده می‌کند و می‌تواند بدون از دست دادن داده‌ها به DTCG تبدیل شود.
• DESIGN.md: فرمتی از گوگل که از Markdown همراه با YAML frontmatter استفاده می‌کند. این فرمت برای نگهداری یک توصیف کوتاه از سیستم (رنگ‌ها، تایپوگرافی، فاصله‌ها، شعاع گوشه‌ها، کامپوننت‌ها) در کنار مستندات ایده‌آل است، هرچند از انواع پیچیده‌تر مثل سایه‌ها یا گرادینت‌ها پشتیبانی نمی‌کند.

اثر بر چرخه حیات طراحی

پیاده‌سازی این گردش کار اول-توکنی، کل چرخه حیات طراحی را تغییر می‌دهد:

• خلق (Creating): به جای پراکندن مقادیر، مدل ابتدا یک واژگان طراحی می‌سازد. تصمیمات به جای اختراع مجدد، بازاستفاده می‌شوند و ثبات از همان ابتدا تضمین می‌گردد.
• تغییر (Changing): بدون توکن‌ها، «تیره کردن رنگ برند» نیازمند جست‌وجو در کل پروژه است. با توکن‌ها، این کار تنها یک تغییر در لایه پایه است که به تمام ارجاعات جریان می‌یابد.
• تم‌بندی (Theming): تم تاریک دیگر از صفر نوشته نمی‌شود. تم تاریک صرفاً مجموعه‌ای از مقادیر متفاوت است که به همان نقش‌های معنایی قبلی متصل شده‌اند و ساختار را یکسان نگه می‌دارند.
• بررسی (Checking): خطاها شفاف شده و به صورت خودکار قابل بررسی هستند. ابزارها می‌توانند هشدار دهند اگر ارجاعی به جایی نرسد، نوع تطابق نداشته باشد یا اگر یک کامپوننت لایه معنایی را دور بزند و مستقیماً به لایه پایه متصل شود.

این چرخش، تولید UI توسط AI را از یک بازی «حدس زدن ظاهر» به یک فرآیند مهندسی دقیق تبدیل می‌کند. با ارائه یک ساختار صریح به مدل، خروجی پیش‌بینی‌پذیر، قابل حسابرسی و مقیاس‌پذیر می‌شود.

برای پیاده‌سازی این متد امروز، می‌توانید با این کار شروع کنید که از AI بخواهید پیش از نوشتن حتی یک خط CSS، یک نقشه توکن مطابق با استاندارد DTCG — شامل لایه‌های primitive، semantic و component — تعریف کند.

گام بعدی شما

• در پرامپت‌های خود، AI را مجبور کنید پیش از نوشتن CSS، یک نقشه توکن مطابق با استاندارد DTCG (شامل لایه‌های primitive، semantic و component) تعریف کند.
• از ابزار Design Token Kit برای اعتبارسنجی خروجی‌های JSON مدل استفاده کنید تا از شکست کد در مرحله Production جلوگیری شود.
• ساختار توکن‌ها را به عنوان بخشی از «دانش سازمان» در System Prompt مدل‌های خود قرار دهید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.