كيف يحول الذكاء الاصطناعي المطالب الغامضة إلى تصاميم هندسية جاهزة للإنتاج

ماذا يعني فعلاً "من الموجه إلى الهندسة"

الموجه الغامض هو نقطة البداية الشائعة لأن معظم الأفكار تبدأ كنوايا، ليست كمواصفات: "ابنِ بوابة عملاء"، "أضف بحثًا بالذكاء الاصطناعي"، أو "بث الأحداث في الوقت الحقيقي". الناس يعرفون النتيجة التي يريدونها، لكنهم لا يعرفون بعد الحدود، المخاطر، أو الخيارات الهندسية التي تجعلها قابلة للتنفيذ.

"من الموجه إلى الهندسة" هو سير العمل الذي يحوّل تلك النية إلى خطة متماسكة: ماذا نبني، كيف تتصل الأجزاء، أين يمرُّ البيانات، وما اللازم ليعمل ذلك في بيئة الإنتاج.

ماذا يعني "تصميم جاهز للإنتاج"

جاهزية الإنتاج ليست "وجود مخططات" فقط. تعني أن التصميم يعالج صراحةً:\n\n- القدرة على التحمل: ما الذي يتعطل، كيف يتعافى، وماذا يحدث تحت الحمل\n- الأمن: كيف يُتحكم بالوصول، أين تُخزن الأسرار، وكيف تُخفف التهديدات\n- التكلفة: ما الذي يُحفز الإنفاق وكيف يُراقب ويُضبط\n- التشغيلية: المراقبة، النسخ الاحتياطي، النشر، وكيف تُصَحّح الأعطال عند الساعة 2 صباحًا\n

أين يساعد الذكاء الاصطناعي — وأين قد يُضلل

الذكاء الاصطناعي قوي في تسريع التفكير المبكر: توليد هندسات مرشحة، اقتراح أنماط شائعة (قوائم انتظار، كاش، حدود خدمات)، إظهار متطلبات غير وظيفية مفقودة، وصياغة عقود واجهات أو قوائم تحقق.

يمكن أن يضلّل عندما يبدو واثقًا بشأن تفاصيل لا يمكنه التحقق منها: اختيار تقنيات بلا سياق، التقليل من تعقيد التشغيل، أو تجاهل قيود يعرفها مؤسستك فقط (الالتزام، المنصات الحالية، مهارات الفريق). عامل مخرجاته كمقترحات للتحدّي، لا كإجابات مُسلّمًا بها.

ما ستغطيه هذه المقالة وما لن تغطيه

تغطي هذه المقالة سير عمل عملي وقابل للتكرار للانتقال من موجه → متطلبات → افتراضات → خيارات → قرارات، مع تتبّع للمقايضات.

لن تحل محل الخبرة الميدانية، الحسابات التفصيلية للأحجام، أو مراجعة أمنية — ولن تدّعي وجود "هندسة صحيحة" واحدة لكل موجه.

الخطوة 1: حوّل الموجه إلى بيان مشكلة واضح

الموجه الغامض يميل إلى خلط الأهداف ("بناء لوحة تحكم"), الحلول ("استخدام مايكروسيرفس"), والآراء ("اجعله سريعًا"). قبل رسم المكونات، تحتاج إلى بيان مشكلة محدد بما يكفي للاختبار والنقاش.

بيان المشكلة (من يحتاج ماذا، ولماذا الآن)

اكتب جملة أو جملتين تسمي المستخدم الأساسي، الوظيفة التي يحاول إنجازها، وملاءمة التوقيت.

مثال: "مديرو دعم العملاء يحتاجون إلى عرض واحد للتذاكر المفتوحة ومخاطر اتفاقيات مستوى الخدمة ليتمكنوا من تحديد الأولويات يوميًا وتقليل حالات فشل الشروط هذا الربع."

إذا لم يحدِّد الموجه مستخدمًا حقيقيًا، اطلب واحدًا. إذا لم يذكر لماذا يهم الآن، فلن تستطيع ترتيب المقايضات لاحقًا.

مقاييس النجاح (كيف ستعرف أنه نجح)

حوّل "جيد" إلى نتائج قابلة للقياس. فضّل مزيجًا من إشارات المنتج والتشغيل.

• منتج: زمن إكمال المهمة الرئيسية، معدل الاعتماد، معدل الأخطاء، التحويل، NPS\n- تشغيلي: زمن الكمون p95، هدف التوافر، التكلفة لكل طلب، عدد التنبيهات الأسبوعية للفريق

اختر مجموعة صغيرة (3–5). الكثير من المقاييس يخلق ارتباكًا؛ القليل جدًا يخفي المخاطر.

رحلات المستخدم والتدفقات الأساسية

صِف "المسار السعيد" بلغة بسيطة، ثم اذكر حالات الحافة التي ستشكل الهندسة.

مثال المسار السعيد: المستخدم يسجل الدخول → يبحث عن عميل → يرى الحالة الحالية → يحدّث حقلًا → يُسجَّل سجل تدقيق.

حالات الحافة المبكرة: الاتصال غير متوفر/ضعيف، أذونات جزئية، سجلات مكررة، استيرادات ذات حجم كبير، مهلات، محاولات إعادة، وماذا يحدث عندما يعتمد النظام على تبعية متوقفة.

ما خارج النطاق (لمنع زحف التصميم)

اذكر ما لن تبنيه في هذه النسخة: التكاملات غير المدعومة بعد، تحليلات متقدمة، تعدد المناطق، إجراءات مخصصة، أو أدوات إدارة كاملة. الحدود الواضحة تحمي الجداول الزمنية وتجعل محادثات "المرحلة 2" أسهل لاحقًا.

بمجرد كتابة هذه القطع الأربعة، يصبح الموجه عقدًا مشتركًا. يمكن للذكاء الاصطناعي أن يساعد في تحسينه، لكنه لا ينبغي أن يخترعه بمفرده.

الخطوة 2: استخرج المتطلبات والقيود

الموجه الغامض غالبًا ما يمزج الأهداف ("اجعله سهلًا"), الميزات ("أرسل إشعارات"), والتفضيلات ("استخدم سيرفرلس") في جملة واحدة. تفصل هذه الخطوة بينها إلى قائمة متطلبات يمكنك التصميم بناءً عليها.

المتطلبات الوظيفية (ما يجب أن يفعله)

ابدأ بسحب السلوكيات الملموسة والأجزاء التي تؤثر عليها:

• الميزات: تسجيل/تسجيل دخول المستخدم، بحث، إتمام الدفع، لوحة إدارة، سجلات تدقيق\n- البيانات: ما يُخزن (المستخدمون، الطلبات، الأحداث)، مدة الاحتفاظ، ومن يمكنه الوصول\n- التكاملات: مزوّد المدفوعات، البريد/SMS، CRM، التحليلات، واجهات برمجة التطبيقات الداخلية القائمة

اختبار جيد: هل يمكنك الإشارة إلى شاشة، أو endpoint API، أو مهمة خلفية لكل متطلب؟

المتطلبات غير الوظيفية (كيف يجب أن يؤدي العمل)

تشكل هذه المتطلبات الهندسة أكثر مما يتوقع معظم الناس. ترجم الكلمات الغامضة إلى أهداف قابلة للقياس:

• الكمون: "الصفحات سريعة" → "95% من الطلبات تحت 300ms."\n- التوافر: "متاح دائمًا" → "99.9% توافر شهري."\n- الخصوصية/الامتثال: "نتعامل مع عملاء الاتحاد الأوروبي" → "أساسيات GDPR: طلبات الحذف، تصدير البيانات، الاحتفاظ الأدنى."

القيود (ما لا يمكنك تغييره)

سجّل الحدود مبكرًا حتى لا تصمِّم نظامًا مثاليًا لا يمكن شحنه:

• الميزانية والجدول الزمني: تاريخ إطلاق ثابت، حدود إنفاق السحابة\n- مهارات الفريق: خبرة قوية في Python، خبرة محدودة في Kubernetes\n- الأنظمة القائمة: يجب استخدام قاعدة البيانات الحالية، SSO، أو حافلة الرسائل الحالية

معايير القبول بلغة بسيطة

اكتب بضعة عبارات "اكتمال يعني…" يمكن لأي شخص التحقق منها، مثل:

• "يمكن للمستخدم الجديد التسجيل، تأكيد البريد الإلكتروني، وتسجيل الدخول خلال دقيقتين."\n- "يمكن للدعم رد مبلغ لطلب ويتلقى العميل تأكيدًا خلال دقيقة واحدة."\n- "يمكن حذف البيانات الشخصية عند الطلب، بما في ذلك النسخ الاحتياطية خلال 30 يومًا."\n تصبح هذه المتطلبات والقيود مدخلاً للهندسات المرشحة التي ستقارنها لاحقًا.

الخطوة 3: أظهر الافتراضات والمجهولات مبكرًا

نادراً ما يفشل الموجه الغامض لأن التكنولوجيا صعبة — يفشل لأن كل شخص يملأ التفاصيل الناقصة في رأسه بشكل مختلف. قبل اقتراح أي هندسة، استخدم الذكاء الاصطناعي لـ إخراج تلك الافتراضات الصامتة إلى العلن وفصل ما هو مؤكد عمّا هو تخمين.

الافتراضات الشائعة التي يجب سردها

ابدأ بكتابة "الافتراضات الافتراضية" التي يلمح الناس إليها عادةً:

• الحركة والنمو: هل نبني لـ 50 مستخدم/يوم أم 50k متزامن؟ هل الاستخدام متقلب أم ثابت؟\n- جودة البيانات: هل البيانات الواردة نظيفة ومهيكلة أم فوضوية مع تكرارات وحقول مفقودة؟\n- سلوك المستخدم: هل المستخدمون يتسامحون مع التأخير؟ هل سيعيدون المحاولة بكثافة؟ هل يتوقعون تحديثات في الوقت الحقيقي؟\n- التشغيل: من يدعم النظام؟ هل هناك تغطية on-call؟ هل تقبل انقطاعات في عطلة نهاية الأسبوع؟

تشكل هذه الافتراضات اختيارات مثل الكاش، القوائم، التخزين، المراقبة، والتكلفة.

قسّم "المؤكّدات" مقابل "المجهولات" مقابل "بحاجة بحث"

اطلب من الذكاء الاصطناعي إنشاء جدول بسيط (أو ثلاث قوائم قصيرة):

• المؤكّدات: المتطلبات المؤكدة من الموجه أو أصحاب المصلحة\n- المجهولات: التفاصيل المفقودة التي تمنع اتخاذ قرار واثق\n- بحاجة بحث: أسئلة تتطلب تجارب صغيرة، فحوصات بائعين، مقاييس أداء، مراجعة قانونية، أو اختبارات مع المستخدمين

هذا يمنع النموذج (والفريق) من التعامل مع التخمينات كحقائق.

أسئلة يجب أن يسألها الذكاء الاصطناعي قبل الالتزام بالتصميم

أسئلة مفيدة تتضمن:

• ما هي أهم 3 رحلات مستخدم، وماذا يعني "سريع بما فيه الكفاية" لكلٍ منها؟\n- ما البيانات التي يجب تخزينها، وكم من الوقت، ومن يحق له الوصول؟\n- ما أوضاع الفشل المقبولة (تعطل جزئي، معالجة مؤجلة، وضع قراءة فقط)؟\n- ما التكاملات الموجودة وما حدود المعدل والموثوقية لكلٍ منها؟\n- ما القيود الثابتة: الميزانية، الموعد النهائي، السحابة/المزوّد، الامتثال؟

وثّق الافتراضات ليتم تحديها لاحقًا

اكتب الافتراضات صراحة ("افترض ذروة 2,000 طلب/دقيقة"، "افترض وجود بيانات شخصية") وعاملها كمدخلات مسودة للمراجعة — من الأفضل ربط كل افتراض بمن أكده ومتى. يسهل ذلك شرح وتبرير تغييرات الهندسة لاحقًا.

الخطوة 4: اقترح هندسات مرشحة، لا إجابة واحدة

نادراً ما يوحي موجه غامض بتصميم "صحيح" واحد. أسرع طريق إلى خطة جاهزة للإنتاج هو رسم عدد قليل من الخيارات القابلة للحياة، ثم اختيار افتراضي وشرح واضح لما سيجعلُك تغيّر القرار.

الخيار A (الافتراضي أولًا): مونوليث بسيط + خدمات مُدارة

لمعظم المنتجات في المراحل المبكرة، ابدأ بخلفية قابلة للنشر واحدة (API + منطق العمل)، قاعدة بيانات واحدة، ومجموعة صغيرة من الخدمات المُدارة (مصادقة، بريد، تخزين كائنات). هذا يبقي النشر، التصحيح، والتغييرات بسيطة.

اختر هذا عندما: الفريق صغير، المتطلبات متغيرة، والحركة غير مؤكدة.

الخيار B: مونوليث معياري + مهام غير متزامنة

نفس القابلية للنشر، لكن مع وحدات داخلية صريحة (الفوترة، المستخدمون، التقارير) وعامل خلفي للمهام البطيئة (الاستيرادات، الإشعارات، مكالمات AI). أضف قائمة انتظار وسياسات إعادة المحاولة.

اختر هذا عندما: لديك مهام طويلة، أو ذروة دورية، أو حاجة لحدود ملكية أوضح — دون تقسيم إلى خدمات منفصلة.

الخيار C: خدمات قابلة للتوسع (فقط إذا كانت المتطلبات تفرض ذلك)

قسّم بعض المكونات إلى خدمات منفصلة عندما يوجد دافع قوي: عزل صارم (امتثال)، تحجيم مستقل لبقعة ساخنة (مثل معالجة الوسائط)، أو دورات إصدار منفصلة.

اختر هذا عندما: يمكنك الإشارة إلى أنماط تحميل محددة، حدود تنظيمية، أو قيود مخاطرة تبرر العبء التشغيلي الإضافي.

ماذا يتغير بين الخيارات

اشر إلى الفروقات بوضوح:\n\n- المكونات: API واحد مقابل API + عامل مقابل عدة وحدات قابلة للنشر\n- التكلفة: أجزاء أقل متحركة مقابل قوائم انتظار ومراقبة وحركة بيانات بين خدمات\n- التعقيد: تطوير محلي أبسط مقابل المزيد من النشرين، إصدار النسخ، وأوضاع الفشل

ناتج جيد بمساعدة AI هنا هو جدول قرار صغير: "الافتراضي = A، انتقل إلى B إذا كانت لدينا مهام خلفية، انتقل إلى C إذا تحقق المعيار X/القياس/القيود". يمنع هذا تحولًا مبكرًا إلى مايكروسيرفس ويحافظ على الهندسة مرتبطة بمتطلبات حقيقية.

الخطوة 5: نمذجة البيانات والحدود

كمية مفاجئة من "الهندسة" هي فعليًا مجرد الاتفاق على ما هي بيانات النظام، أين تعيش، ومن المسموح له تغييرها. إذا قمت بنمذجة ذلك مبكرًا، تصير الخطوات اللاحقة (المكونات، الواجهات، التحجيم، الأمن) أقل تخمينًا.

عرّف كائنات النطاق الأساسية (ومن يملكها)

ابدأ بتسمية عدد قليل من الكائنات التي يدور النظام حولها — عادة أسماء من الموجه: User, Organization, Subscription, Order, Ticket, Document, Event. لكل كائن، سجّل الملكية:

• مصدر الحقيقة: أي نظام/خدمة مسموح له بكتابة التحديثات؟\n- القراء: من يستهلكه (خدمات أخرى، تحليلات، دعم العملاء)\n- دورة الحياة: إنشاء/تحديث/حذف، بالإضافة إلى أي قواعد "حذف ناعم"

هنا يفيد AI: يمكنه اقتراح نموذج نطاق أولي من الموجه، ثم تؤكد ما هو حقيقي مقابل ما هو متضمن.

اختر أنماط التخزين المطابقة لاحتياجات الوصول

قرر هل كل كائن هو في الأساس معاملاتية (OLTP) — قراءات/كتابات صغيرة متكررة وتتطلب اتساقًا — أم تحليلي (تجميعات، اتجاهات، تقارير). خلط كلا الحاجتين في قاعدة بيانات واحدة غالبًا ما يخلق توترًا.

نمط شائع: قاعدة OLTP للتطبيق، ومخزن تحليلي منفصل يُغذّى بالأحداث أو التصديرات. المفتاح هو مواءمة التخزين مع كيفية استخدام البيانات، لا مع شعورك المفاهيمي عنها.

خطّ تدفق البيانات من الطرف إلى الطرف

ارسم مسار البيانات خلال النظام:\n\n- الاستيعاب: APIs، تحميلات، webhooks، استيرادات دفعات\n- التحويل: التحقق، الإثراء، إلغاء التكرار\n- الاحتفاظ والحذف: مدة الاحتفاظ وكيفية الإزالة

ابرز مخاطر البيانات مبكرًا

اذكر المخاطر صراحة: البيانات الشخصية، سجلات مكررة، مصادر متعارضة (نظامان يَدّعيان أنهما الحقيقة)، وغموض قواعد الحذف. هذه المخاطر تحدد الحدود: ما يجب أن يبقى داخليًا، ما يمكن مشاركته، وما يحتاج آثار تدقيق أو ضوابط وصول.

الخطوة 6: ارسم المكونات والواجهات

بمجرد وجود الحدود والبيانات، حوّلها إلى خريطة مكونات ملموسة: ما الموجود، ماذا يملك، وكيف يتحدث إلى الباقي. هنا يكون AI مفيدًا جدًا كـ "مولّد مخططات بالكلمات" — يمكنه اقتراح فواصل نظيفة والإشارة إلى واجهات مفقودة.

عرّف الوحدات والمسؤوليات

اهدِف إلى مجموعة صغيرة من المكونات مع ملكية واضحة. فحص جيد: "إذا تعطّل هذا، من يصلحه، وما الذي يتغير؟" على سبيل المثال:

• API Gateway / BFF: توجيه الطلبات، فرض المصادقة، حدود المعدل\n- الخدمة/الخدمات الأساسية: قواعد العمل وسير العمل\n- مخزن/مخازن البيانات: الاستمرار والاستعلام (ليس فقط "قاعدة بيانات")\n- عوامل غير متزامنة: مهام طويلة، إعادة المحاولة، الوظائف المجدولة\n- الملاحِظة: التسجيل، المقاييس، التتبع (كعناصر أولية)

اختر كيف تتواصل المكونات (ولماذا)

اختر نمط تواصل افتراضي وعلّل الاستثناءات:

• REST/HTTP للطلبات/الاستجابة البسيطة ومسارات يمكن تصحيحها يدويًا\n- Events / pub-sub عندما يتفاعل مستهلكون متعددون مع نفس التغيير\n- Queues للعمل الخلفي، امتصاص الذروات، وإعادة المحاولة الموثوقة

يمكن للذكاء الاصطناعي المساعدة بمطابقة كل حالة استخدام إلى أبسط واجهة تلبي احتياجات الكمون والموثوقية.

التبعيات الخارجية وسلوك الفشل

سجل خدمات الطرف الثالث وقرر ماذا يحدث عند فشلها:\n\n- مهلات، إعادة محاولات مع backoff، وقواطع الدائرة\n- وضع تدهور (عرض بيانات مخزنة؟ وضع قراءة فقط؟)\n- عقود خطأ واضحة (ماذا يتوقع العملاء)

خريطة التكامل (الأنظمة، API، المصادقة)

اكتب "جدول تكامل" مضغوطًا:\n\n- المدفوعات → واجهة مزود (REST)، OAuth2 client credentials، مفاتيح عدم التكرار\n- البريد/SMS → واجهة مزود الرسائل (REST)، مفتاح API، قائمة انتظار إعادة المحاولة على 5xx\n- التحليلات → تيار أحداث، رمز خدمة، سياسة إسقاط عند التحميل الزائد

تصبح هذه الخريطة العمود الفقري لتذاكر التنفيذ ونقاشات المراجعة.

الخطوة 7: صمّم لمتطلبات الإنتاج (قبل الكود)

يمكن أن يبدو التصميم مثاليًا على اللوح ويخفق في اليوم الأول في الإنتاج. قبل كتابة الكود، اجعل "عقد الإنتاج" صريحًا: ماذا يحدث تحت الحمل، أثناء الفشل، وتحت الهجوم — وكيف ستعرف ذلك.

الاعتمادية: خطّط لمسارات الفشل

ابدأ بتحديد كيف يتصرف النظام عندما تتباطأ أو تتوقف التبعيات. أضف مهلات، إعادة محاولات مع jitter، وقواعد قواطع الدائرة واضحة. اجعل العمليات قابلة لإعادة التشغيل بأمان عن طريق استخدام معرفات الطلب أو مفاتيح idempotency.

إذا استدعيت APIs طرف ثالث، افترض حدود معدل وابنِ ضغطًا رجعيًا: قوائم انتظار، تزامن محدود، وتدهور مرحلي (مثل "حاول لاحقًا" بدلاً من تراكم الطلبات).

الأمن: قرّر من يفعل ماذا

حدّد المصادقة (كيف يثبت المستخدم هويته) والتفويض (ما الذي يمكنه الوصول إليه). اكتب السيناريوهات الأعلى تهديدًا للنظام: سرقة رموز، إساءة استعمال نقاط النهاية العامة، حقن عبر المدخلات، أو تصعيد امتيازات.

وحدّد أيضًا كيفية التعامل مع الأسرار: أين تُخزن، من يقرأها، وتواتر التدوير ومسارات التدقيق.

الأداء: أهداف، لا انطباعات

حدد أهداف السعة والكمون (حتى لو كانت تقريبية). ثم اختر التكتيكات: الكاش (ماذا، أين، وTTL)، التجميع للمكالمات المتكررة، العمل غير المتزامن عبر قوائم الانتظار للمهام الطويلة، وحدود لحماية الموارد المشتركة.

الملاحِظة: لا يمكنك إصلاح ما لا ترى

قرّر السجلات المهيكلة، المقاييس الأساسية (الكمون، معدل الخطأ، عمق الطابور)، حدود تتبع موزع، وتنبيهات أساسية. اربط كل تنبيه بإجراء: من يتجاوب، ما الذي يُفحص، وماذا يبدو "الوضع الآمن".

عامل هذه الخيارات كعناصر هندسية من الدرجة الأولى — فهي تشكل النظام بقدرEndpoints وقواعد البيانات.

الخطوة 8: اجعل المقايضات صريحة وقابلة للتتبع

الهندسة ليست إجابة "أفضل" واحدة — إنها مجموعة اختيارات ضمن قيود. الذكاء الاصطناعي مفيد هنا لأنه يسرد الخيارات بسرعة، لكنك تحتاج إلى سجل واضح لِـ سبب اختيارك مسارًا معينًا، وما الذي تخلّيت عنه، وما الذي سيؤدي لتغيير لاحقًا.

استخدم جدول مقايضة بسيط

قرّر أين تقبل المخاطرة مقابل أين تستثمر في الضمانات

اكتب "إخفاقات مقبولة" (مثل رسائل البريد المتأخرة أحيانًا) مقابل مناطق "يجب ألا تفشل" (مثل المدفوعات، فقدان البيانات). ضع الضمانات حيث تكون العواقب مكلفة: النسخ الاحتياطية، idempotency، حدود المعدل، ومسارات التراجع الواضحة.

المقايضات التشغيلية التي تؤثر على فريقك

بعض التصاميم تزيد عبء النوبة وصعوبة التصحيح (المزيد من الأجزاء المتحركة، المزيد من إعادة المحاولات، سجلات موزعة). فضّل اختيارات تتماشى مع واقع الدعم: خدمات أقل، ملاحظة أوضح، وأوضاع فشل متوقعة.

مقايضات التكنولوجيا: مُدارة مقابل مستضافة ذاتيًا

اجعل معايير القرار صريحة: احتياجات الامتثال، التخصيص، الكمون، والطاقم. إذا اخترت الاستضافة الذاتية من أجل التكلفة، سجّل السعر الخفي: الترقيع، الترقية، تخطيط السعة، واستجابة الحوادث.

الخطوة 9: سجّل القرارات، البدائل، وقابلية الرجوع

الهندسات الجيدة لا "تحدث" — هي نتيجة اختيارات متعددة. إذا عاشت هذه الاختيارات فقط في سجلات دردشة أو بذاكرة أحدهم، يعيد الفريق النقاشات، يشحن بتباينات، ويكافح عند تغير المتطلبات.

استخدم ADRs لجعل القرارات قابلة للبحث

انشئ سجل قرار معماري (ADR) لكل خيار رئيسي (قاعدة البيانات، نمط الرسائل، نموذج المصادقة، نهج النشر). اجعله قصيرًا ومتسقًا:\n\n- السياق: المشكلة والقيود\n- القرار: ما اخترت\n- البدائل المدروسة: 2–3 خيارات قابلة للحياة\n- السبب: المنطق والمقايضات\n- العواقب: ما يتيح وما يقيّد

الذكاء الاصطناعي مفيد هنا: يمكنه تلخيص الخيارات، استخراج المقايضات من المناقشات، وصياغة ADRs لتعدّلها لاحقًا.

أنشئ "مخارج" للتغيّر في التصميم

تتغير الافتراضات: قد ينمو الحمل أسرع، أو يصبح الامتثال أشد، أو يتدهور API خارجي. لكل افتراض رئيسي، أضف مخرجًا:\n\n- "إذا تجاوزنا X طلب/ث، ننتقل من قاعدة بيانات واحدة إلى نسخ قراءة."\n- "إذا انخفضت SLA لمزوّد الخدمة أدنى Y، أدرج قائمة انتظار + عامل إعادة المحاولة."\n هذا يحوّل التغيير المستقبلي إلى خطوة مخططة، لا إلى حالة طوارئ.

أضف نقاط إثبات وإصدارات للقرارات

أرفق معالم قابلة للاختبار للاختيارات الخطرة: تجارب حمل، مقارنات أداء، نماذج أولية صغيرة، أو اختبارات تحميل. سجّل النتائج المتوقعة ومعايير النجاح.

أخيرًا، رقّم ADRs مع تطور المتطلبات. لا تمحُ التاريخ — أضف تحديثات حتى يمكنك تتبع ما تغيّر ومتى ولماذا. إذا أردت هيكلًا خفيفًا، اربط إلى قالب داخلي نسبي مثل /blog/adr-template.

الخطوة 10: حقّق في الهندسة بمراجعات وأدلة

الهندسة المسودة ليست "مكتملة" عندما تبدو نظيفة على مخطط. تُعد مكتملة عندما يتفق من سيبنيها، يؤمّنها، يشغّلها، ويموّلها أنها تعمل — وعندما تملك أدلة تدعم الأجزاء الحساسة.

أجرِ مراجعة معمارية مركزة

استخدم قائمة تحقق قصيرة لإجبار الأسئلة المهمة على الظهور مبكرًا:\n\n- الأمن: نموذج المصادقة/التفويض، إدارة الأسرار، أقل امتياز، سجلات التدقيق\n- الخصوصية: تصنيف البيانات، الاحتفاظ، ضوابط الوصول، خريطة سريان PII، طلبات الحذف\n- أوضاع الفشل: سلوك التدهور، إعادة المحاولة وbackoff، idempotency، قوائم رسائل الميتا، حدود المعدل\n- الجاهزية التشغيلية: المراقبة، التنبيهات، كتيبات التشغيل، ملكية on-call، النسخ والعودة

اجعل النواتج ملموسة: "ماذا سنفعل؟" و"من يملكها؟" بدلاً من نوايا عامة.

حقّق بالأرقام (نطاقات، لا أماني)

بدلًا من تقدير وحيد للقدرة، قدّم نطاقات تحميل وتكلفة تعكس عدم اليقين:\n\n- الحركة: P50 / P95 طلب/ث (مثال: 50–200 RPS عادي، 500–1,000 RPS ذروة)\n- نمو التخزين: نطاق شهري مع افتراضات الاحتفاظ\n- محركات التكلفة: استدعاء API/استخدام نموذج، autoscaling للحوسبة، خروج بيانات

اطلب من AI إظهار حساباته وافتراضاته، ثم صحّحها بمقاييسك الحالية أو أنظمة مماثلة.

قيّم خطر التبعيات والبائعين

سجل التبعيات الحرجة (مزود LLM، قواعد بيانات متجهات، قوائم انتظار، خدمة مصادقة). لكلٍ منها سجّل:\n\n- ما الذي يتعطل إذا أصبح غير متوفر؟\n- ما مدى صعوبة تبديل المزود؟\n- هل هناك قيود تعاقدية، إقليمية، أو امتثالية؟

حدّد نقاط الموافقة البشرية

اجعل المراجعات صريحة، لا مفهومة ضمنيًا:\n\n- المنتج: رحلات المستخدم، اتفاقيات مستوى الخدمة، حدود النطاق\n- الأمن/الخصوصية: نتائج نموذج التهديد، موافقات التعامل مع البيانات\n- العمليات/SRE: خطة الملاحِظة، استجابة الحوادث، افتراضات السعة\n- الهندسة: الواجهات، المعالم، خطة الهجرة

إذا ظلت الخلافات قائمة، سجّلها كـ قرارات يجب اتخاذها مع مالكين ومواعيد — ثم تقدم للأمام بوضوح.

كيفية التعاون مع الذكاء الاصطناعي بفعالية أثناء التصميم

يمكن أن يكون الذكاء الاصطناعي شريك تصميم قوي إذا عاملته كمهندس مبتدئ: قادر على توليد خيارات بسرعة، لكنه يحتاج سياقًا واضحًا، تحققًا، وتوجيهًا.

اكتب موجهات تجبر على إظهار الافتراضات والقيود

ابدأ بمنح AI "صندوق" للعمل داخله: هدف العمل، المستخدمون، الحجم، الميزانية، المهل، وأي ثوابت (ستاك، امتثال، استضافة). ثم اطلب منه سرد الافتراضات والأسئلة المفتوحة أولًا قبل اقتراح الحلول.

قاعدة بسيطة: إذا كانت قيدًا مهمًا، فصرّح به صراحة — لا تتوقع أن يستنتجه النموذج.

أين يمكن أن يساعدك منصة تحويل إلى كود

إذا كان هدفك الانتقال من "خطة معمارية" إلى "نظام عامل" دون فقدان القرارات في التسليمات، فإن أداة سير عمل تهم. منصات مثل Koder.ai قد تكون مفيدة هنا لأن نفس الدردشة التي تساعدك في توضيح المتطلبات يمكن أن تنقل تلك القيود إلى التنفيذ: وضع التخطيط، تكرارات قابلة للتكرار، وإمكانية تصدير الكود عندما تكون جاهزًا لامتلاك خط التجميع.

هذا لا يُلغي حاجتك لمراجعات معمارية — بل يرفع المعيار لتوثيق الافتراضات والمتطلبات غير الوظيفية — لأنك قادر على الانتقال من اقتراح إلى تطبيق عامل بسرعة.

قوالب موجهات يمكنك إعادة استخدامها

You are helping design a system.
Context: <1–3 paragraphs>
Constraints: <bullets>
Non-functional requirements: <latency, availability, security, cost>
Deliverables:
1) Assumptions + open questions
2) 2–3 candidate architectures with pros/cons
3) Key tradeoffs (what we gain/lose)
4) Draft ADRs (decision, alternatives, rationale, risks)

ملاحظة: لا تُترجم المحتوى داخل الكتلة أعلاه — احتفظ به كما هو.

تكرار مع حلقات "نقد وتحسين"

اطلب تمريرة أولى، ثم اطلب فورًا نقدًا:\n\n- "ما الهش أو الخطر في هذا التصميم؟"\n- "أي متطلبات لم تُلبَّ بعد؟"\n- "ماذا تبسّط لو كان الوقت نصفًا؟"

هذا يمنع النموذج من التمسّك بمسار واحد مبكرًا.

راقب أوضاع الفشل الشائعة

يمكن لأن يبدو الذكاء الاصطناعي واثقًا وهو مخطئ. مشكلات شائعة تشمل:\n\n- خدمات/ميزات مُختلقة — اطلب روابط أو بيان عدم اليقين\n- تجاهل القيود (التكلفة، موقع البيانات، مهارات الفريق) — اطلب تتبع كل اختيار إلى متطلب\n- الإفراط في التصميم — أجبِر على خيار "أصغر هندسة قابلة للحياة"

إذا رغبت، يمكنك تحويل المخرجات إلى ADRs خفيفة وإبقاءها بجانب الريبو (انظر /blog/architecture-decision-records).

جولة مصغرة: من موجه غامض إلى خطة جاهزة للبناء

موجه غامض: "ابنِ نظامًا ينبه العملاء عندما يتأخر التسليم."

1) حوّله إلى متطلبات

يساعد AI في ترجمة ذلك إلى احتياجات ملموسة:\n\n- المستخدمون: فريق العمليات، العملاء النهائيون\n- التدفق الأساسي: استيعاب حالة الشحنة → اكتشاف مخاطر التأخير → الإخطار → تتبّع النتائج\n- غير وظيفي: إشعارات خلال دقيقتين من تغيير الحالة، توافر 99.9%، سجل تدقيق للنزاعات

2) افتراضات تغيّر الهندسة

سؤالان مبكّران يغيّران التصميم:\n\n- افتراض A: تحديثات الحالة تصل في الوقت الحقيقي من الناقلين (webhooks). إن صحّ، يناسب المعالجة المدفوعة بالأحداث.

• افتراض B: التحديثات تُستعلم كل 15 دقيقة. إن صحّ، تحتاج جداول زمنية، معالجة حدود المعدل، وقد تكون SLA "دقيقتين" مستحيلة بدون إعادة تفاوض على المدخلات.

بكتابة هذه الافتراضات تمنع بناء شيء خاطئ بسرعة.

3) الخيارات → قرار المقايضة

يقترح AI هندسات مرشحة:

• الخيار 1: متزامن: webhook الناقل → خدمة تسجيل التأخير → خدمة الإشعارات\n - الإيجابيات: بسيط، أجزاء أقل\n - السلبيات: مهلات الويب هوك قد تُفقد التحديثات؛ الذروات قد تُحمّل الخدمة\n
• الخيار 2: قائم على قوائم الانتظار: webhook → إدخال حدث في قائمة انتظار → عمال يقيمون التأخير → إشعارات\n - الإيجابيات: يمتصّ الذروات، إعادة محاولات آمنة، ملاحِظة أفضل\n - السلبيات: مكونات أكثر، اتساق eventual

قرار المقايضة: اختر قائم على القوائم إذا كانت موثوقية الناقل والحِمل القفزي مخاطر؛ اختر متزامن إذا كان الحجم منخفضًا وSLA للناقل قويًا.

4) الخطة النهائية والتسليمات

التسليمات لجعلها قابلة للبناء:\n\n- مخططات السياق والتسلسل\n- نموذج البيانات + مخطط حدث\n- ADRs توضح اختيار قائمة الانتظار مقابل المتزامن\n- كتيبات التشغيل (أوضاع الفشل، إعادة المحاولة، فحوصات on-call)\n- إبسترات للباك لوج (تكامل الناقل، قواعد تسجيل التأخير، قوالب الإشعارات، المراقبة)