DeepSeek يصلح 3 أخطاء في 1C خلال 104 دقائق ويكرر تصحيحين حرفيًا

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

جاءت النتيجة أكثر فائدة من نقاش آخر حول ما إذا كان الذكاء الاصطناعي «سيحل محل المبرمج». فقد أصلح الوكيل ثلاثة عيوب محددة خلال 25–47 دقيقة وبتكلفة تتراوح بين 155 و427 روبلًا. وفي حالتين تطابق كوده حرفيًا مع تصحيحات 1C الرسمية. أما في التعديل الأكبر فقد أنجز النموذج الوظيفة فقط: عمل الحل، لكن البنية القياسية في 1C كانت أنظف.

كيف وجد الوكيل الأخطاء

في الحالة الأولى كانت طباعة مستند النقل الشامل تتعطل بقسمة على صفر عندما تقل كمية البضاعة عن 0,005. لم يكن السبب قيمة أولية صفرية. فقد كان الكود يقرّب الكمية إلى منزلتين عشريتين قبل القسمة مباشرة، فتتحول القيم 0,001–0,004 إلى صفر. وجد DeepSeek الاستعلام المطلوب في وحدة تضم نحو 12 ألف سطر، وأضاف حماية وبنى الإضافة. أما التصحيح الرسمي فعالج المشكلة بطريقة مختلفة قليلًا: حافظ على ثلاث منازل بعد الفاصلة. ولاحظ الوكيل أيضًا أن الوصف الأصلي لحدود الخطأ كان غير دقيق.

في الحالة الثانية لم يكن الدفع الإلكتروني لفاتورة المبيعات يُحمَّل إلى القاعدة بصمت. كان المعالج العام ينتظر الخاصية «АдресСайта» (عنوان الموقع)، وهي غير موجودة في بعض المستندات. أضاف النموذج فحصًا لوجود الخاصية قبل الوصول إليها. وتطابق هذا الحل تمامًا مع تصحيح 1C. كما اكتشف الوكيل العيب نفسه في نوعين آخرين من المستندات، مع أن المهمة الأصلية لم تذكرهما.

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

أين تراجع النموذج أمام مطوري 1C

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

ومع ذلك كان النموذج أقل معرفة بآليات مكتبة الأنظمة الفرعية القياسية. فلإنشاء المستند كان يحفظ مسودة أولًا، ويبني نموذج الطباعة يدويًا. أما مطورو 1C فاستخدموا الإدخال القياسي على أساس مستند والطباعة القياسية مع التصدير إلى PDF وExcel. نُفذت الوظيفة، لكن صيانة الحل القياسي أسهل.

ما الذي يمكن اعتماده

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

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