ما هي وثيقة DESIGN.md؟ وما المشكلات التي تعالجها فعلياً؟
أنظمة التصميم والذكاء الاصطناعي
ملف DESIGN.md، ملفات design.md، سياق التصميم للذكاء الاصطناعي، نظام التصميم للوكلاء الأذكياء، ملف Google Stitch DESIGN.md، رموز التصميم بصيغة markdown، تصميم وكلاء البرمجة بالذكاء الاصطناعي
منذ فترة، نشر أحد موظفي عملائنا ملف markdown في قناة Slack عامة. كان قد لخص هذا الملف من معايير الهوية البصرية ليصمم عرضاً تقديمياً بشكل متناسق واحترافي.
هذا الملف البسيط تحول لاحقاً إلى واحدة من أنجح قصص أنظمة التصميم لدينا هذا العام.
في غضون أسبوع واحد، نسخت ثلاثة فرق أخرى هذا الملف. واستخدمه أحدهم في أداة ذكاء اصطناعي لإنشاء صفحة هبوط، وكانت النتيجة تصميماً يعكس الهوية البصرية الحقيقية للشركة بدقة. كما أضافه مهندس برمجيات إلى مستودع الكود (repo) لمنع المساعد البرمجي من ابتكار أنماط أزرار عشوائية. لم يخطط أحد لكل هذا، بل استمر الملف في إثبات فائدته ببساطة لأنه وفّر لأول مرة قرارات التصميم الخاصة بالهوية في صيغة مرنة ومفهومة للبشر والآلات معاً دون الحاجة لاستشارة أحد.
ذاك الملف العفوي كان، في جوهره، بمثابة DESIGN.md. إليك ما أصبح عليه هذا التنسيق اليوم، والميزات الحقيقية التي يقدمها.
ما هو ملف DESIGN.md تحديداً؟
ملف DESIGN.md هو منهجية عمل وليس منتجاً؛ وهو ملف markdown يوضع في المجلد الرئيسي للمشروع لوصف واجهة المستخدم، بحيث يستوعب أي مساعد ذكاء اصطناعي يتعامل مع المشروع نظام التصميم بالكامل بدلاً من التخمين. نشرت مختبرات Google Labs مواصفات هذا الملف في أبريل 2026 بناءً على أداتهم Stitch، وحصد المستودع الرسمي آلاف الإعجابات في أيام معدودة، حيث كان الإقبال هائلاً لأن المشكلة التي يعالجها عامة وتؤرق الجميع.
يجمع الملف بين نوعين من المحتوى:
رموز برمجية قابلة للقراءة آلياً (Tokens): مثل ترويسات YAML أو جداول تحتوي على القيم الدقيقة: كرموز الألوان الست عشرية (hexes) وأدوارها، وتدرج الخطوط، ووحدات المسافات الهامشية، وزوايا الانحناء، والظلال.
توجيهات منطقية واضحة للبشر: نصوص تشرح الغرض من التصميم؛ مثل الحالات التي يُسمح فيها باستخدام اللون الأساسي، وأي خط مخصص لعناوين الصفحات فقط، بالإضافة إلى قائمة المسموحات والمحظورات التي غالباً ما تظل حبيسة ذهن المصمم الخبير.
تغطي الأقسام الأساسية للملف كلاً من: النظرة العامة، الألوان، الخطوط، التخطيط، الارتفاع والظلال، الأشكال، المكونات، والمسموحات والمحظورات. وينضم هذا الملف إلى عائلة متنامية من ملفات markdown الأساسية مثل AGENTS.md و CLAUDE.md و llms.txt، والتي تشكل معاً ما يمكن تسميته بطبقة بروتوكول .md: وهي ملفات نصية بسيطة ترشد مساعدي الذكاء الاصطناعي إلى كيفية التعامل مع مشروعك.
ما هي المشاكل الحقيقية التي يحلها؟
يحل هذا الملف ثلاث مشاكل رئيسية، أولاها هي الأكثر تكلفة وهدراً للوقت.
1. مخرجات الذكاء الاصطناعي النمطية والمكررة. بدون سياق واضح للتصميم، تنتج أدوات الذكاء الاصطناعي المتوسط الإحصائي لبيانات تدريبها: مثل خطوط Inter أو خطوط النظام الافتراضية، واللون الأزرق كلون أساسي، وزوايا انحناء بمقدار 8 بكسل، ومسافات متطابقة. مخرجات مقبولة تقنياً لكنها بلا روح، وبالتأكيد لا تمثل هويتك الفريدة. كل فريق استخدم الذكاء الاصطناعي لإنشاء واجهات مستخدم واجه هذه المشكلة واضطر لتعديلها يدوياً، وكانت دورة التصحيح المستمرة هذه هي التكلفة الخفية لـ "سرعة الذكاء الاصطناعي". إن وجود ملف DESIGN.md في مستودع الكود يختصر هذه الحلقة في خطوة واحدة، حيث تفيد الفرق التي اعتمدته بانخفاض معدل المخرجات غير المناسبة إلى النصف أو أكثر خلال الأسبوع الأول فقط.
2. تكرار الأوامر (Prompting). قبل اعتماد هذا الملف، كان البديل هو نسخ تعليمات الهوية البصرية ولصقها في كل أمر، ومع كل أداة، ومن قِبل كل فرد؛ وهو أمر مرهق وغير دقيق ويصعب تحديثه باستمرار. يختصر الملف مئات التوجيهات المشتتة في مرجع واحد منظم ومُدار، يخضع لإصدارات محددة (Version-controlled)، ويمكن مراجعته عبر طلبات السحب (pull requests)، ومتواجد في نفس مكان الكود الذي يحكمه.
3. فجوة التفسير والغاية. كانت رموز التصميم بصيغة JSON قابلة للقراءة آلياً بالفعل، لكنها تقدم أرقاماً وقيمًا مجردة دون معايير واضحة للاستخدام؛ فهي تخبر الذكاء الاصطناعي بوجود لون معين، لكنها لا توضح أنه مخصص لإجراء رئيسي واحد فقط في الصفحة ولا يصح استخدامه لأغراض التزيين. وهنا يأتي دور الجزء النصي في DESIGN.md ليقدم هذا المنطق التوجيهي تحديداً. وفي الواقع، يشير المصممون إلى أن قسم "المحظورات" — مثل "لا تستخدم الحروف الكبيرة بالكامل في العناوين" أو "لا تضع أكثر من زرين لاتخاذ إجراء (CTA) فوق بعضهما" أو "لا تستخدم الظلال في البطاقات بل استبدلها بالحدود" — يساهم في تحسين جودة المخرجات أكثر مما تقدمه الرموز البرمجية مجتمعة.
ما هي الأمور التي لا يحلها؟
هنا يجب أن نكون واقعيين ونوضح الحقائق التي قد يتجاهلها حماس البدايات.
الملف لا يعرف الكود الخاص بك. يصف DESIGN.md كيفية إعادة بناء مكوناتك، وليس كيفية استخدام المكونات الموجودة بالفعل في برمجياتك. أظهرت اختبارات شركة Atlassian في يونيو 2026 هذا الأمر بوضوح؛ حيث مالت مساعدات الذكاء الاصطناعي التي زودت بملف DESIGN.md فقط إلى إعادة إنشاء المكونات من الصفر بدلاً من استيراد المكونات الحالية — وهو أمر يضر بصيانة الكود — واستهلكت طاقة معالجة (tokens) تزيد بنحو 92% مقارنة بأسلوبهم المعتمد على بروتوكول MCP لإنجاز المهمة نفسها.
لا يتحدث تلقائياً. إنه مجرد ملف في النهاية. يتطور نظام التصميم باستمرار، ويجب على شخص ما تحديث الملف يدوياً وإلا سيفقد قيمته. وجود ملف DESIGN.md قديم وغير محدث أسوأ من عدم وجوده، لأن المساعد البرمجي سيتبعه بثقة تامة ويقدم مخرجات خاطئة.
لا يستوعب التفاصيل المعقدة للمشاريع الضخمة. تلخص Atlassian نظامها في حوالي 2.5 ميجابايت من التوجيهات البرمجية للمساعدات الذكية والتي تُقدم عند الطلب عبر بروتوكول MCP. في المقابل، يجب أن يكون حجم ملف DESIGN.md صغيراً ليتم تحميله بالكامل — وقد استقر حجم ملفهم عند 80 كيلوبايت تقريباً بعد اختصاره بشكل كبير، مما أدى إلى فقدان بعض السياق الهام في عملية الضغط. مرونة النقل تأتي دائماً على حساب التفاصيل المعقدة.
الخيار الأمثل الذي يتجه إليه قطاع التقنية الآن هو: استخدام DESIGN.md كملخص سريع ومرن، واستخدام بروتوكول MCP كربط مباشر وحي لعمليات الإنتاج الفعلي. الملف للتوجه العام، والخادم للبنية التحتية.
متى تحتاج إليه فعلاً؟
تحتاج إلى ملف DESIGN.md إذا كانت أدوات الذكاء الاصطناعي تنتج واجهات مستخدم في أي جزء من مشروعك — سواء كانت نماذج أولية، أو أدوات داخلية، أو صفحات هبوط، أو ميزات مطورة بواسطة الذكاء الاصطناعي — وتجد نفسك تعيد تصحيح المخرجات باستمرار. هذا هو واقع معظم فرق تطوير المنتجات في عام 2027.
يمكنك الانتظار إذا كان نظام التصميم الخاص بك صغيراً جداً ومستقراً تماماً، أو إذا كان فريقك لا يستخدم الذكاء الاصطناعي لإنشاء الواجهات بعد (وهو أمر نادر ويقل يوماً بعد يوم).
الخبر السار هو أن إعداد النسخة الأولى المفيدة من هذا الملف يتطلب بضع ساعات فقط وليس ربع عام كامل. اجمع القيم والأرقام الفعلية من منتجك الحالي — وليس من خطط إعادة التصميم المستقبلية — واكتب المحظورات بناءً على الأخطاء الحقيقية التي رأيتها في مخرجات الذكاء الاصطناعي السابقة، ثم ضع الملف في مستودع الكود واختبره مع الأدوات التي يستخدمها فريقك فعلياً. بعد ذلك، عدل الملف بناءً على الأخطاء التي لا يزال يقع فيها المساعد البرمجي. دورة التطوير السريعة هذه هي السر الحقيقي لنجاح هذا الأسلوب وتبنيه.
لماذا نجح ملف Slack البسيط ذاك؟
بالعودة إلى قصتنا؛ السبب في أن ملف markdown العادي الخاص بالهوية البصرية، والذي أُعد خصيصاً لعرض تقديمي، قد تحول إلى بنية تحتية أساسية هو نفس السبب وراء الانتشار الواسع لـ DESIGN.md: وهو أن قرارات التصميم كانت حبيسة صيغ لا يمكن للآلات استخدامها — مثل ملفات PDF، وملفات Figma، وعقول المصممين — وكان أول ملف ينجح في جعل هذه القرارات قابلة للنقل والترجمة هو الملف الذي تبنته كل الأدوات القادرة على قراءة النصوص.
الدرس المستفاد هنا ليس مجرد "كتابة ملف"، بل إنه في عصر الذكاء الاصطناعي، فإن أقوى سلاح يملكه فريق التصميم هو صياغة قراراته بأسلوب مرن وقابل للنقل والاستخدام. لطالما كان نظام التصميم هو الأصل الحقيقي، ويمثل DESIGN.md الصيغة الأولى التي تسمح لمنظومة التطوير بأكملها باستغلال هذا الأصل والاستفادة منه.
إذا كان فريقك ينشئ واجهات مستخدم باستخدام الذكاء الاصطناعي ويقضي الوقت في تعديلها يدوياً، فإن الحل يكمن في مرحلة ما قبل الأداة نفسها — وتأسيس البنية التحتية لنظام التصميم (من رموز وقواعد، وبالطبع ملف DESIGN.md) هو صميم ما يقدمه فريق تصميم المنتجات لدينا.
