ما هو ملف DESIGN.md؟ وكيف تستفيد منه مع أدوات البرمجة بالذكاء الاصطناعي
أنظمة التصميم والذكاء الاصطناعي
من فترة، شارك موظف لدى أحد عملائنا ملف markdown بسيط في قناة عامة على Slack. جمع فيه عناصر الهوية البصرية للشركة على عجل، فقط لأنه كان يجهّز عرضاً تقديمياً ويريده أن يظهر بالشكل الصحيح.
هذا الملف بالذات تحوّل لاحقاً إلى واحدة من أروع قصص نجاح أنظمة التصميم لدينا هذا العام.
خلال أسبوع واحد فقط، نسخته ثلاثة فرق أخرى. أحدهم وضع محتواه في أداة ذكاء اصطناعي لإنشاء صفحة هبوط، وحصل أخيراً على تصميم يُعبّر فعلاً عن روح العلامة التجارية. وأحد المهندسين أضافه إلى مستودع الكود البرمجي ليمنع وكيل البرمجة بالذكاء الاصطناعي من ابتكار أنماط أزرار عشوائية. لم يخطط أحد لأي من هذا. استمر الملف في إثبات فائدته ببساطة؛ لأنها المرة الأولى التي تتوفر فيها قرارات تصميم العلامة التجارية بصيغة تفهمها الآلات ويستخدمها البشر على حد سواء، دون الحاجة للرجوع لأي شخص.
هذا الملف الذي وُلد بالصدفة جسّد، في جوهره، فكرة ملف DESIGN.md. إليك ما آل إليه هذا التنسيق اليوم — والمواضع التي يُحدث فيها فارقاً حقيقياً.
ما هو ملف DESIGN.md تحديداً؟
DESIGN.md ليس منتجاً، بل عُرف قياسي متبع: إنه ملف markdown يُوضع في المجلد الرئيسي (root) لأي مشروع ليوضّح الشكل الذي ينبغي أن تبدو عليه واجهة المستخدم؛ وبذلك يرث أي وكيل ذكاء اصطناعي يتعامل مع المشروع نظام التصميم مباشرة بدلاً من التخمين. نشرت Google Labs مواصفات هذا الملف في أبريل 2026، مستلهمة الفكرة من أداة Stitch التابعة لها، وحصد المستودع الرسمي آلاف النجوم على GitHub خلال أيام معدودة — فقد كان الإقبال هائلاً لأن المشكلة يعاني منها الجميع.
يجمع الملف بين نوعين من المحتوى:
رموز تصميم تفهمها الآلة (Tokens) — في صيغة YAML في الترويسة أو في جداول تضم قيماً محددة: رموز الألوان السداسية مع وظائفها، وتدرجات الخطوط، ووحدات التباعد، وانحناءات الحواف، والظلال.
توجيهات يفهمها الإنسان — نصوص تشرح الغاية والمنطق: متى يحق لك استخدام اللون الأساسي، وأي الخطوط مخصص لعناوين الصفحات فقط، وقواعد ما يُسمح به وما يُمنع، وهي التفاصيل التي عادةً ما تظل حبيسة ذهن كبار المصممين.
تغطي الأقسام القياسية نظرة عامة، والألوان، والخطوط، والتخطيط العام، والبروز، والأشكال، والمكونات، وقواعد ما يُفعل وما يُتجنب. وبذلك ينضم هذا الملف لعائلة متنامية من ملفات markdown في جذر المشروعات — مثل AGENTS.md وCLAUDE.md وllms.txt — والتي تشكّل معاً ما يمكن تسميته بطبقة بروتوكول .md: وهي ملفات نصية بسيطة تُرشد وكلاء الذكاء الاصطناعي إلى كيفية التصرف داخل مشروعك.
ما المشكلة التي يحلها فعلياً؟
يحل ثلاث مشكلات، أولاها هي الأكثر تكلفة واستنزافاً للوقت.
1. مخرجات الذكاء الاصطناعي النمطية. دون سياق واضح للتصميم، تنتج أدوات الذكاء الاصطناعي المتوسط الإحصائي لبيانات تدريبها: خط Inter أو خطوط النظام الافتراضية، ودرجات أزرق باهتة كلون أساسي، وحواف منحنية بنحو 8px، ومسافات رتيبة. واجهات تبدو مقبولة تقنياً، لكنها بلا هوية وتفتقر تماماً لطابعك الخاص. كل فريق اعتمد على الذكاء الاصطناعي لتوليد الواجهات اصطدم بهذه المشكلة وكان يضطر لإصلاحها يدوياً — وكانت دوامة التعديل المستمر هي التكلفة الخفية وراء وهم "سرعة الذكاء الاصطناعي". وجود DESIGN.md في المستودع ينهي معظم هذه الدوامة بضربة واحدة.
2. تكرار كتابة التوجيهات (Prompting). قبل هذا الملف، كان البديل هو نسخ تعليمات الهوية ولصقها في كل أمر وداخل كل أداة ومن قِبل كل موظف — عملية مرهقة، تفتقر للاتساق، وتستحيل مواكبتها وتحديثها. يحوّل هذا الملف مئات التوجيهات المشتتة إلى مرجع واحد محدد ومُدار بوضوح؛ مرجع يتمتع بمتابعة الإصدارات، ويخضع للمراجعة عبر طلبات الدمج (pull requests)، ويستقر جنباً إلى جنب مع الكود الذي يتحكم فيه.
3. فجوة فهم المقصد (The intent gap). لطالما كانت رموز التصميم بصيغة JSON قابلة للقراءة آلياً، لكنها مجرد أرقام بلا تقدير سياقي: فهي تخبر الوكيل بأن اللون الفلاني موجود، لكنها لا توضح أنه مخصص لإجراء أساسي واحد فقط في الشاشة ولا يُستخدم كعنصر زخرفي أبداً. الجزء النصي في DESIGN.md يتولى بالتحديد سد هذه الفجوة. وتؤكد التجارب العملية أن قسم التنبيهات والممنوعات — مثل: "تجنب كتابة العناوين بأحرف لاتينية كبيرة بالكامل"، "لا تضع أكثر من زرين لاتخاذ إجراء (CTA)"، "لا ظلال للبطاقات بل نعتمد الحدود الفاصلة" — يرفع جودة المخرجات أكثر من جميع رموز التصميم مجتمعة.
ما الذي لا يستطيع هذا الملف حله؟
هنا تحديداً تبرز أهمية النظرة الواقعية، بعيداً عن بريق الدعاية والمبالغات.
لا يفهم تفاصيل الكود لديك. يشرح ملف DESIGN.md كيفية إعادة بناء مكوناتك، وليس كيفية استخدام المكونات الموجودة بالفعل في قاعدة الكود لديك. وقد أثبتت تجارب أجرتها Atlassian في يونيو 2026 ذلك عملياً: فالوكلاء الذين زُوّدوا بملف DESIGN.md فقط مالوا إلى إعادة إنشاء المكونات من البداية بدلاً من استيراد المكونات الجاهزة، وهو أمر يضر بقابلية صيانة الكود.
لا يُحدّث نفسه تلقائياً. في النهاية، هو مجرد ملف. نظام التصميم يتطور باستمرار؛ لذا يجب أن يتولى شخص ما تحديثه بانتظام وإلا سيحدث انفصال عن الواقع — وملف DESIGN.md المهمل والقديم أسوأ بكثير من عدم وجوده، لأن الوكيل سيتبعه بثقة عمياء.
لا يستوعب التفاصيل المعقدة للشركات الكبرى. تختزل Atlassian نظامها في نحو 2.5 ميجابايت من التوجيهات البرمجية التي تُقدَّم لوكلاء الذكاء الاصطناعي عند الطلب عبر MCP. بينما يجب أن يكون حجم DESIGN.md صغيراً وموجزاً لتحميله دفعة واحدة — وقد بلغ حجم نسختهم بعد اختصار مكثف نحو 80 كيلوبايت، مما أفقدهم تفاصيل سياقية جوهرية خلال هذا التقليص. فالمرونة وخفة الحركة هنا تأتي على حساب الدقة والعمق.
النهج العملي المكتمل، والذي يتجه إليه المجال حالياً: استخدام DESIGN.md كملخص سريع ومحمول، والاعتماد على بروتوكول MCP لاتصال مباشر وحي في بيئة الإنتاج الفعلية. الملف لتوضيح المقصد، والخادم لإدارة البنية البرمجية.
متى تحتاج إليه فعلاً؟
تحتاج إلى ملف DESIGN.md إذا كانت أدوات الذكاء الاصطناعي تُسهم في توليد واجهات منتجك بأي شكل — سواء في النماذج الأولية، أو الأدوات الداخلية، أو صفحات الهبوط، أو الميزات التي تبنيها الوكلاء بالكامل — وتجد نفسك تعيد تصحيح النتائج يدوياً باستمرار. وهذا هو حال معظم فرق المنتجات في عام 2027.
يمكنك التمهل وعدم استخدامه إذا كان نظام التصميم لديك بسيطاً للغاية وثابتاً، أو إذا كنتم لا تستخدمون الذكاء الاصطناعي في تصميم وتطوير الواجهات بعد (وهي حالة نادرة، وتزداد ندرة بمرور الوقت).
والخبر السار: تجهيز أول إصدار مفيد وعملي لن يتطلب سوى ظهيرة يوم واحد، لا ربعاً سنوياً كاملاً. استخرج القيم الحقيقية من منتجك الفعلي المعروض للمستخدمين — وليس من خطط إعادة التصميم المستقبلية — واكتب قائمة الممنوعات استناداً إلى الأخطاء التي رأيت الذكاء الاصطناعي يرتكبها بالفعل، ثم ضع الملف في المستودع واختبره عبر الأدوات التي يعتمدها فريقك يومياً. عدّل الملف باستمرار وفق الأخطاء التي يستمر الوكيل في ارتكابها. هذه المراجعة المستمرة والسريعة هي سر نجاح هذا الملف وتبنيه في بيئة العمل.
ما الذي يحتويه ملف DESIGN.md؟ (الأقسام ومثال عملي)
تحدد المعايير طبقتين أساسيتين: رموز تصميم بنسق YAML (كتلة في الترويسة بين فواصل ---، أو كتل YAML مدمجة داخل كل قسم)، وتوجيهات نصية بصيغة markdown توضح طريقة تطبيقها. الرموز توفر القيم الإلزامية المحددة، بينما تعبّر النصوص عن التوجه والمقصد الفني.
تُستخدم الترويسات ## لتقسيم المحتوى. يمكنك الاستغناء عن بعض الأقسام، لكن ما تقرر إدراجه ينبغي أن يلتزم بهذا الترتيب:
نظرة عامة (Overview) (أو الهوية والأسلوب Brand & Style): شخصية المنتج، والجمهور المستهدف، والانطباع العام للواجهة.
الألوان (Colors): لوحة الألوان الأساسية
primaryكحد أدنى، مع توضيح وظيفة كل لون.الخطوط (Typography): التسلسل الهرمي للخطوط والغرض من استخدام كل نمط.
التخطيط (Layout) (أو التخطيط والمسافات Layout & Spacing): الشبكة، وهوامش المحاذاة، ونظام التباعد.
البروز والعمق (Elevation & Depth): كيفية إبراز التسلسل البصري عبر الظلال أو الحدود الفاصلة.
الأشكال (Shapes): نصف قطر انحناء الحواف وقواعد الأشكال المختلفة.
المكونات (Components): الأزرار، وحقول الإدخال، والوسوم وحالاتها المختلفة.
ما يُفعل وما يُتجنب (Do’s and Don’ts): الملاحظات والتنبيهات التي يكررها كبار المصممين عادةً في جلسات المراجعة.
يبدو النموذج المصغر لكتلة الرموز كالتالي: colors: { primary: "#1A1C1E" } وrounded: { sm: 4px }، مع وصف للمكونات مثل button-primary: { backgroundColor: "{colors.primary}", rounded: "{rounded.sm}" }. تعتمد الإشارة إلى الرموز على صيغة {path.to.token}، كما تُخصص مدخلات مستقلة لحالات التفاعل مثل تمرير المؤشر (hover) أو النقر (pressed).
كيف تستخدم DESIGN.md مع Stitch أو Claude Code أو Cursor؟
أداة Stitch: قم بتصدير أو استيراد ملف DESIGN.md ليبدأ أي مشروع جديد مستنداً فوراً إلى قواعد التصميم المعتمدة لديك.
وكلاء البرمجة (مثل Claude Code وCursor وغيرهما): ضع الملف في جذر المستودع البرمجي، وأشر إليه داخل AGENTS.md أو في ملف القواعد الخاص بك، حتى يطالعه الوكيل قبل إنشاء أي واجهة مستخدم.
التحقق البرمجي (Validation): يحتوي المستودع الرسمي على أداة سطر أوامر (CLI) تتضمن فاحصاً يراجع ترتيب الأقسام وهيكلة الرموز بدقة. قُم بتشغيله ضمن خط التكامل المستمر (CI) لتفادي أي خلل بمرور الوقت.
الاختبار: أنشئ نفس الشاشة باستخدام الملف وبدونه وقارن بينهما. وأضف قاعدة تنبيه واضحة في قسم "ما يُتجنب" لكل خطأ متكرر يفلت من الوكيل.
إذا كنت تعمل على دمج ميزات الذكاء الاصطناعي في منتجك، فإن هذه المبادئ ذاتها تنطبق تماماً على تصميم محركات القيود للذكاء الاصطناعي وتطوير واجهات المستخدم التوليدية.
ما سر نجاح ملف Slack البسيط؟
لنعد إلى بداية القصة. السبب وراء تحول ملف markdown بسيط خُصص لعرض تقديمي إلى بنية تحتية أساسية هو ذاته السر وراء الانتشار الواسع لـ DESIGN.md: فقد كانت قرارات التصميم لسنوات حبيسة صيغ لا تفهمها الآلات — من ملفات PDF وتصاميم Figma إلى أفكار غير مدونة في رؤوس أصحابها — ولما ظهرت أول صيغة تنقل تلك القرارات بمرونة، تبنتها على الفور كل أداة قادرة على قراءة النصوص البرمجية.
العبرة هنا ليست "أن تكتب ملفاً فحسب"، بل إدراك أن أثمن ما يملكه فريق التصميم في عصر الذكاء الاصطناعي هو قراراته الفنية الموثقة بصيغة مرنة وقابلة للنقل. نظام التصميم كان دائماً هو رأس المال الحقيقي؛ وملف DESIGN.md ليس إلا الصيغة العملية الأولى التي مكّنت منظومة البرمجة بأكملها من استثماره والاستفادة منه.
الأسئلة الشائعة حول DESIGN.md
من ابتكر صيغة DESIGN.md؟
فريق Google Labs. انبثقت الفكرة من أداة التصميم Stitch، ثم أتاحت Google مواصفات المسودة كمشروع مفتوح المصدر في 21 أبريل 2026. تتوفر المواصفات وأداة سطر الأوامر عبر مستودع google-labs-code/design.md تحت رخصة Apache 2.0.
هل DESIGN.md هو نفسه AGENTS.md أو CLAUDE.md؟
لا. يوجه كل من AGENTS.md وCLAUDE.md الوكيل الذكي لكيفية التعامل مع الكود والمستودع، بينما يحدد DESIGN.md الشكل الخارجي للواجهة. تفضل كثير من الفرق الاحتفاظ بالملفين، مع توجيه الوكيل من خلال AGENTS.md لقراءة ملف DESIGN.md قبل البدء في مهام واجهة المستخدم.
هل موقع designmd.cc هو الموقع الرسمي لمبادرة DESIGN.md؟
المواصفات الرسمية موجودة فقط في مستودع Google Labs على GitHub وداخل وثائق Stitch. أما المواقع الأخرى، بما فيها designmd.cc، فهي مبادرات مستقلة. تأكد دائماً من مطابقة ما تنسخه منها مع المواصفات الرسمية، والتي لا تزال مصنفة كنسخة تجريبية (alpha) قابلة للتغيير والتطوير.
هل يُغني DESIGN.md عن نظام التصميم (Design System)؟
إطلاقاً. هو مجرد ملخص محمول وسريع له. تظل بحاجة لرموز التصميم، والمكونات، والتوثيق المفصل الداعم لها، بالإضافة لمسؤول يضمن تحديث الملف ومزامنته باستمرار مع تطور النظام. تعرّف على الوقت الفعلي الذي تحتاج فيه الشركة الناشئة إلى نظام تصميم.
إذا كان فريقك يولد واجهات المستخدم بالذكاء الاصطناعي ويقضي وقته في تصحيحها يدوياً، فالحل يبدأ قبل تشغيل الأداة — وبناء أساسات أنظمة التصميم (من رموز وقواعد ومعايير DESIGN.md) هو صلب التخصص الذي يقدمه فريق تصميم المنتجات لدينا.
