يمكن لـ Claude Opus 5 البرمجة بالساعات بمفرده. ما هي أجزاء نظام POS التي ما زالت تتطلب أكثر من الكود؟

تتمثل أجزاء نظام POS التي لا تزال تتطلب أكثر من مجرد كود في تلك التي تلمس الأموال والعالم الفعلي: اتفاقيات معالجة المدفوعات، والامتثال لمعايير PCI (قواعد الأمان الخاصة بقطاع البطاقات للتعامل مع بيانات البطاقات)، والأجهزة الطرفية المعتمدة للحضور الفعلي للبطاقة، والحفظ الدقيق للسجلات الذي يجب أن يكون صحيحًا في كل مرة. يمكن لـ Claude Opus 5، الذي صَدر في 24 يوليو 2026، تشغيل جلسات برمجة لساعات بأقل قدر من الإشراف¹. لكن لا توجد أية ساعة من تلك الساعات تنتج حساب تاجر.

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

ما الذي غيره Claude Opus 5 بالفعل؟

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

هذا تحول حقيقي، وهو يعزز نمطًا غطيناه عندما تم إطلاق GPT-5.6: كل بضعة أشهر، تنمو كمية البرامج العاملة التي تحصل عليها من إيعاز واحد. إن واجهة الدفع التي كانت تتطلب أسبوعًا من الإيعازات العام الماضي أصبحت تستغرق بعد ظهر يوم واحد الآن، ومع Opus 5، يستمر النموذج في العمل بعد الابتعاد عنه.

لماذا لا تنهي زيادة وقت البرمجة المهمة؟

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

هناك حد ثاني أكثر دقة. المهارة الرئيسية لـ Opus 5 هي التحقق من عمله الخاص، والتحقق يحتاج إلى حقيقة أساسية مثبتة. يمكن للنموذج اختبار أن حسابات عملية الدفع تكتمل بشكل صحيح. لكنه لا يمكنه الاختبار في مواجهة شبكة بطاقات حقيقية، أو جدول تسوية حقيقي (عندما تصل أموال البطاقات بالفعل إلى بنكك)، أو هيئة ضريبية حقيقية، لأنه لا يوجد أي من هؤلاء داخل بيئة البرمجة المعزولة. يمكن للكود أن يكون متسقًا تمامًا مع نفسه ومع ذلك يواجه الواقع لأول مرة على منضدة البيع لديك.

ما هي أجزاء نظام POS التي ما زالت تتطلب أكثر من الكود؟

أربعة أجزاء رئيسية:

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

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

• أجهزة الحضور الفعلي للبطاقة. تعمل مدفوعات التمرير والشريحة على أجهزة طرفية معتمدة مع برامج ثابتة آمنة لا يمكن لأحد كتابتها بشكل عشوائي. إنه نفس الجدار الذي يجعل تطبيقات الدفع المعتمدة على البرمجة بالحس تُرفض من متجر التطبيقات App Store: العوائق هي الاستحقاقات والاعتمادات، وليست جودة الكود.

• السجلات الصحيحة في كل مرة. المخزون الذي يصمد أمام بيعين متزامنين والتقارير التي تتوافق (تتطابق مع الأموال التي وصلت بالفعل) هي كود برمجي من الناحية الفنية، لكنه كود يجب أن يكون صحيحًا للأبد. لقد رسمنا هذا الجدار في البرمجة بالحس لنظام نقاط البيع (POS). يكتب Opus 5 هذا النوع من الأكواد بشكل أفضل من أي نموذج قبله؛ ومع ذلك لا تريد أن يكون اختباره التشغيلي الأول أثناء فترة الذروة لديك يوم السبت.

إذًا ما الذي ينبغي أن تدع Claude Opus 5 يبنيه؟

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

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

يعمل Build من Final بهذه الطريقة: أداة البناء قائمة على الأوامر، تصف المسار الذي تريده أو تربط الذكاء الاصطناعي الخاص بك عبر MCP، وينتشر المسار على البنية التحتية حيث تم التعامل مع Final Pay والأجهزة الطرفية المعتمدة وحفظ السجلات الأساسي بالفعل. كيفية استخدام Claude Fable 5 لبناء نظام POS شغال يستعرض كيف يبدو ذلك مع الشقيق الأكبر لـ Opus 5.

إذًا، ما هي أجزاء نظام POS التي ما زالت تتطلب أكثر من الكود؟

تلك التي تنتهي باتفاقية، أو اعتماد، أو تحويل مالي: معالجة المدفوعات، والامتثال لمعايير PCI، وأجهزة الحضور الفعلي للبطاقات، بالإضافة إلى السجلات التي يجب أن تكون صحيحة في كل مرة. لقد غير Claude Opus 5 حجم نظام POS الذي يمكنك الحصول عليه من جلسة برمجة واحدة. لكنه لم يغير ما يمكن لجلسة البرمجة إنتاجه. قاعدة ذهبية مفيدة: إذا كانت المهمة تنتهي بكود، فسلمها للنموذج؛ وإذا كانت تنتهي باتفاقية، أو اعتماد، أو تحويل أموال، فسلمها للبنية التحتية.

إذا كنت تريد معرفة أين يقع الحد الفاصل في الممارسة العملية، قم بربط الذكاء الاصطناعي الخاص بك بـ Build عبر MCP ودع النموذج يقوم بالجزء الذي أصبح بارعًا جدًا فيه الآن.