وقتی از Claude یا Codex می‌خوایم «یک صفحه مدرن و تمیز» بسازه، معمولاً خروجی قابل‌قبولی می‌گیریم. اما چرا خیلی از این خروجی‌ها شبیه هم هستن؟ همون Cardهای گرد، Gradientهای تکراری و فاصله‌گذاری‌هایی که انگار برای هر محصولی استفاده می‌شن.مسئله اینه که Agent نمی‌دونه طراحی خوب برای پروژه ما دقیقاً چه معنایی داره.در مقاله‌ای با عنوان Design Trends | October 2026 که در وبلاگ Mean CEO منتشر شده، نویسنده به تغییر جالبی در فرایند طراحی استارتاپ‌ها اشاره می‌کنه: با ابزارهایی مثل Claude Code و Codex، ساخت نسخه‌های اولیه محصول سریع‌تر شده، اما چیزی که کیفیت خروجی رو تعیین می‌کنه، فقط توانایی Agent نیست؛ بلکه وضوح تصمیم‌ها و محدودیت‌هاییه که در اختیارش قرار می‌گیره.یکی از پیشنهادهای مقاله، استفاده از یک فایل کوتاه به نام design.md است.
فایل design.md دقیقاً چیه؟
یک فایل Markdown در پروژه که مهم‌ترین قواعد طراحی رو برای Agent مشخص می‌کنه؛ از Typography و Spacing گرفته تا نحوه استفاده از Componentها، قواعد Responsive و الگوهایی که نباید در خروجی ظاهر بشن.نویسنده پیشنهاد می‌کنه حتی یک فایل حدوداً ۳۰ خطی هم می‌تونه نقطه شروع مناسبی باشه.البته قرار نیست ۳۰ خط جای یک Design System کامل رو بگیره. ارزش این فایل در اینه که تصمیم‌های طراحی رو از توضیحات مبهم به دستورالعمل‌های مشخص تبدیل می‌کنه
چه چیزهایی باید داخلش باشه؟
۱. Tokenهای مشخص: به‌جای «از رنگ آبی مناسب استفاده کن»، مشخص کنیم Agent باید از کدوم Semantic Token استفاده کنه.۲. قواعد Componentها: مثلاً قبل از ساخت Button جدید، Component موجود در Library رو بررسی کنه.۳. محدودیت‌ها: مثل استفاده نکردن از رنگ‌های Hardcoded، Radiusهای دلخواه یا Componentهای تکراری.۴. معیارهای بررسی: از Accessibility و Focus State گرفته تا بررسی خروجی در اندازه‌های مختلف صفحه
یک مثال ساده
فرض کنیم بخشی از فایل این‌طور نوشته شده:
حالا تفاوت رو ببینیم.وقتی می‌گیم «یک UI تمیز بساز»، نمی‌تونیم دقیقاً مشخص کنیم Agent چقدر به خواسته ما پایبند بوده.اما وقتی می‌گیم «از Componentهای موجود استفاده کن و رنگ جدید خارج از Tokenها تعریف نکن»، می‌تونیم کد خروجی رو بررسی کنیم و ببینیم این قواعد رعایت شدن یا نه.
اما یک نکته مهم وجود داره
اگر پروژه از قبل Design System داره، بهتره design.md به منبع جدیدی برای کپی کردن تمام Tokenها و Componentها تبدیل نشه.چون با هر تغییر در Design System، این فایل هم ممکنه قدیمی بشه و خودش باعث ایجاد ناهماهنگی بشه.راه بهتر اینه که فایل، قواعد اصلی و مسیر دسترسی به منابع معتبر رو مشخص کنه. مثلاً Agent رو به مستندات Design System، Component Library یا MCP متصل به سیستم ارجاع بده.از طرف دیگه، ساخت فایل design.md به‌تنهایی باعث نمی‌شه همه Agentها اون رو خودکار بخونن. باید از طریق دستورالعمل‌های پروژه، مثل CLAUDE.md یا AGENTS.md، مطمئن بشیم فایل وارد Context ابزار می‌شه.
جمع‌بندی
یکی از پیام‌های اصلی گزارش اکتبر ۲۰۲۶ اینه که با سریع‌تر شدن تولید رابط کاربری، اهمیت تعریف مسئله، مشخص کردن محدودیت‌ها و ارزیابی خروجی بیشتر می‌شه.فایل‌هایی مثل design.md می‌تونن بخشی از این کار رو ساده‌تر کنن؛ به شرطی که با منابع واقعی پروژه هماهنگ باشن و استفاده Agent از اون‌ها بررسی بشه.هر خط design.md می‌تونه تصمیمی باشه که دیگه لازم نیست در هر Prompt از اول توضیحش بدیم.شما برای انتقال قواعد طراحی به Agentها از چه روشی استفاده می‌کنین؟ فایل‌های راهنما، مستندات یا MCP؟
کامنت‌ها
…