تخطٍ إلى المحتوى
9 أغسطس 2026 · الهندسة

كيف تتحقق عمليات البناء من نفسها

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

كيف تتحقق عمليات البناء من نفسها

0:00 — ينتهي بناء ما. الوكيل يقول إنه انتهى، وهذا ادّعاء عن كتابة الكود، لا عن كون الكود يعمل فعلًا. كل مستخدم لباني مدعوم بالذكاء الاصطناعي شعر بالفجوة بين هذين الادّعاءين مرة واحدة على الأقل: تُفتح المعاينة، يُنقر الزر الثالث، لا يحدث شيء. رأيت غرفة عرض تصمت في تلك اللحظة بالضبط. لذا قبل أن يرى أي إنسان بناءً ما، يمر بسلسلة من نحو ست دقائق تقريبًا تجادل نفسها. وهذا ما يبدو عليه الأمر فعليًا، متتبَعًا عبر بناء واحد شاهدناه ينحرف ثم يُصلَح.

0:02 — تبدأ مراجعة الكود. ليس الوكيل الذي كتب الكود يعيد قراءة واجبه المنزلي الخاص — بل وكيل منفصل، بموجّه مختلف، لا مصلحة له في نجاح البناء. هذا الفصل يهم أكثر مما يبدو. الوكيل الذي قرر الساعة 2:14 ظهرًا أن استدعاء fetch بلا معالجة أخطاء أمر مقبول سيظل يعتقد ذلك الساعة 2:15 إن طلبت منه مراجعة عمله الخاص. مراجع جديد يُطلب منه "ابحث عمّا هو معطوب، واذكر الملف" يتصرف كالمهندس الأول العابس الذي تريده فعلًا لهذه المهمة. في بناء سابق، رصد إجمالي سلة تسوّق لا يتحدث أبدًا بصمت — كانت `updateTotal` معرَّفة في `Cart.jsx` لكن لم تُربط أبدًا بمعالج تغيير الكمية، فالدالة كانت موجودة ولم تُنفَّذ ببساطة أبدًا. هذه هي الفئة التي وُجدت مراجعة الكود من أجلها: أشياء يتجاهلها المترجم بلا مبالاة.

0:04 — تدقيق الأمان. أضيق مما يبدو، وعن قصد — هذا ليس اختبار اختراق، بل بحث نمطي عن الأخطاء القليلة التي تظهر فعليًا في الكود المُولَّد بالذكاء الاصطناعي. استعلامات SQL المُركَّبة بدمج النصوص. التحقق من جانب العميل فقط والوثوق به وكأنه القصة الكاملة بأكملها. والخاصية المميزة: مفتاح API مُدرَج مباشرة في الكود، لأن الوكيل الذي كتب الميزة لم يكن أمامه اتفاقية متغيرات بيئة جاهزة فلجأ إلى ما نجح فعليًا. نراه بما يكفي من التكرار حتى لم يعد يُحسب مفاجأة.

0:07 — الروابط وتحسين محركات البحث (SEO). غير برّاق، ويلتقط ما لا يلاحظه أحد حتى يلاحظه عميل: رابط تنقل يشير إلى /pricing بينما الصفحة تولّدت فعليًا عند /price، أو إدخال في sitemap لصفحة تُظهر خطأ 404، أو وصف تعريفي (meta description) لا يزال يحمل نص العنصر النائب في القالب. لا شيء من ذلك يعطّل البناء. لكن كل ذلك يقوّض بهدوء الشيء الذي بنى معظم مستخدمينا الموقع من أجله — أن يُعثر عليهم، وأن يُنقر عليهم.

0:09 — إمكانية الوصول. هذا فحص آلي عبر axe-core، وليس تدقيقًا يدويًا شاملًا، ومن المهم توضيح ما تحصل عليه مقابل هذه المقايضة. يلتقط axe-core نسب التباين، النصوص البديلة المفقودة، حقول النماذج غير المُسمّاة، فخاخ ترتيب التنقل بالتبويب — الطبقة الآلية، أي ما يقارب 30-40% مما قد يرصده تدقيق WCAG كامل. لكنه لن يلتقط تجربة قارئ شاشة متوافقة تقنيًا لكنها مربكة فعليًا للاستخدام. اخترنا الاعتماد على الفحص الآلي وحده لأنه يعمل في ثوانٍ ولأن معظم ما يُبنى عبر هذه المنصة مواقع تسويقية وأدوات صغيرة، وليست نوع التطبيقات التي يشكل فيها التدقيق الجزئي خطرًا حقيقيًا على أحد.

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

0:13 — الفحص داخل المتصفح، وهنا تحديدًا تعطل البناء الخاص بنا فعليًا. هذه الطبقة هي الأصعب في خداعها لأنها لا تقرأ الكود، بل تُشغّل متصفحًا حقيقيًا — تنقر، تكتب، تنتظر، وتتحقق من أن شجرة DOM تغيّرت كما ينبغي. البناء المعني كان لعبة "idle game"، والألعاب تحصل على فحص إضافي هنا لأن اللعبة يمكن أن تُعرض بشكل مثالي وتبقى غير قابلة للعب — يمكن لعرض النقاط أن يبدو خاليًا من العيوب بينما هو منفصل تمامًا عن منطق تسجيل النقاط. المدقّق لعبها. النقاط تحدّثت بشكل صحيح. الصوت لم يُصدر أي شيء.

ثلاث جولات، ثم تصعيد

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

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

الطلبالطبقةالأخطاء المُلتقطة
1مراجعة الكودمنطق معطّل، معالجات أحداث ميتة، أخطاء في الحالة
2تدقيق الأمانمساحات الحقن، الأسرار المُسرَّبة، الأنماط غير الآمنة
3الروابط وتحسين محركات البحثروابط معطّلة، بيانات وصفية مفقودة، صحة ملف sitemap/robots.txt
4إمكانية الوصولفحص axe-core آلي: التباين، التسميات، التنقل عبر لوحة المفاتيح
5المطابقةهل يحتوي البناء على ما وعدت به الخطة
6الفحص داخل المتصفحيُشغّل البناء فعليًا — ينقر، يكتب، ويراقب استجابته

ما كنت سأتجنبه في المرة القادمة

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

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

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

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

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

وإذا تسلل شيء رغم ذلك؟ أخبر محادثة البناء. يصبح الإصلاح نسخة جديدة إلى جانب القديمة، تمرّ بنفس سلسلة التحقق، ويمكنك التراجع في أي وقت. الحلقة لا تفترض أنها معصومة من الخطأ؛ بل تفترض أنه يمكنها دائمًا أن تُشغَّل مجددًا.
الهندسة
مشاركةXLinkedInFacebookRedditQuoraواتسابتيليجرامالبريد الإلكتروني
← جميع المقالات