Are you a Canadian company wondering about your tariff impact? Click here to find out →

دمج الذكاء الاصطناعي في FlutterFlow: دليل 2026 الشامل بعد إيقاف Assistants API

Illustration for the InfiniteUp article “APIs Over Building Models: Why InfiniteUp’s Approach to Generative AI is the Future”

إذا كنت تبحث عن طريقة عملية لـ دمج الذكاء الاصطناعي في FlutterFlow في 2026، فأمامك اليوم ثلاث طرق جيدة، والاختيار الصحيح بينها يعتمد على مقدار التحكم الذي تحتاجه. لكن قبل التفاصيل، تنبيه مهم لكل من بنى على الجيل السابق: OpenAI ستوقف Assistants API نهائيًا في 26 أغسطس 2026، وهذا الدليل — المُعاد كتابته بالكامل في يوليو 2026 — يشرح البدائل وكيفية الانتقال إليها. نحن في InfiniteUp نبني ميزات ذكاء اصطناعي داخل تطبيقات FlutterFlow لعملائنا كل شهر — مساعدين للمحادثة، ومحركات تغذية، وتحليل مستندات — فما يلي قرار نتخذه بأنفسنا مرارًا، لا تلخيصًا لدرس كتبه غيرنا.

ولمن يصل إلى هذا المقال من زاوية أخرى: نعم، هذا هو أقرب ما يكون إلى تطوير تطبيق ذكاء اصطناعي بدون كود. الخياران الأولان أدناه لا يتطلبان كتابة برمجيات تُذكر، والثالث موجود لمن يحتاج آخر 10% من التحكم.

أولًا، الموعد النهائي: Assistants API في طريقها إلى الإيقاف

إن كان تطبيقك ما يزال يستدعي Assistants API — بمفاهيمها: Threads وRuns وRun Steps — فسيتوقف عن العمل في 26 أغسطس 2026. أعلنت OpenAI أنه لا تمديد للمهلة، ولا أداة آلية لترحيل المحادثات المخزنة. البديل مكوّنان أبسط: Responses API (ترسل مدخلًا وتستلم مخرجًا) وConversations API (تخزّن سجل الحوار). وخريطة الانتقال، لحسن الحظ، نظيفة:

  • Assistants ← Prompts. إعدادات مساعدك (النموذج، الأدوات، التعليمات) تصبح Prompt يُدار من لوحة تحكم OpenAI بدلًا من إنشائه عبر الـ API.
  • Threads ← Conversations. كائن المحادثة (Conversation) يحفظ السجل الجاري كاملًا، بما فيه استدعاءات الأدوات — لا الرسائل فقط.
  • Runs ← Responses. طلب واحد، ورد واحد. حلقة الاستطلاع (Polling) التي علّمها دليلنا القديم عام 2023 — أنشئ Run ثم افحص حالته حتى يكتمل — اختفت كليًا، وبلا رجعة نتمناها.
  • Run Steps ← Items. الرسائل واستدعاءات الأدوات ومخرجاتها كلها مجرد عناصر (Items) داخل المحادثة.

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

الخيار 1: وكلاء الذكاء الاصطناعي المدمجون في FlutterFlow (ابدأ من هنا)

يقدم FlutterFlow اليوم وكلاء ذكاء اصطناعي (AI Agents) كميزة أصيلة في المنصة، وهي نقطة البداية الصحيحة لمعظم التطبيقات. تُعرّف الوكيل داخل FlutterFlow نفسه — المزود (OpenAI أو Google أو Anthropic أو ElevenLabs)، ورسالة النظام، وأمثلة المحادثات، ودرجة الحرارة (Temperature)، وصيغة الرد — وتتكفل المنصة بكل الأسلاك خلف الكواليس. هذا هو دمج الذكاء الاصطناعي في FlutterFlow بأقل قدر ممكن من الكود.

وأهم ما في الأمر: طريقة تعاملها مع مفتاح API الخاص بك. عند استخدام وكيل OpenAI، ينشر FlutterFlow دالة سحابية (Cloud Function) في مشروع Firebase الخاص بك تمرر الطلبات إلى الـ API، فيبقى المفتاح على الخادم ولا يُشحن داخل تطبيقك أبدًا. يتطلب هذا أن يكون مشروع Firebase لديك على خطة Blaze المدفوعة — وهي عقبة شائعة، فقم بالترقية قبل أن تحتار لماذا يفشل النشر.

داخل صفحاتك تستخدم بعد ذلك إجراءات الوكيل: Send Message (مع معرّف محادثة، لينتقل السياق بين الردود)، وClear Chat History، إضافة إلى النطق والتفريغ الصوتي وتوليد الصور إن هيأت هذه الأنواع من الوكلاء. وكلاء الدردشة يقبلون نصوصًا وصورًا ومستندات بحسب المزود، ويستطيعون الرد بنص عادي أو Markdown أو JSON.

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

الخيار 2: واجهة API Calls موجّهة إلى Responses API

واجهة استدعاءات الـ API في FlutterFlow — ذاتها التي استخدمها دليلنا الأصلي — تعمل جيدًا مع نقاط النهاية الجديدة. أنشئ مجموعة API لـ OpenAI، وأضف استدعاء POST إلى /v1/responses مع النموذج والمدخل، ثم فسّر عناصر المخرجات من الـ JSON. وللمحادثات متعددة الأدوار، إما أن تمرر previous_response_id أو تنشئ كائن Conversation وتشير إليه في كل طلب؛ مسار الـ Conversation هو ما توصي به OpenAI الآن، وهو يوفر عليك إعادة بناء السجل في جهة العميل.

وهنا قاعدة نعتبرها غير قابلة للتفاوض، وهي سبب توجيهنا معظم الفرق نحو الخيار الأول أو نحو وسيط خلفي: لا تضع مفتاح OpenAI API في استدعاء يُنفَّذ من جهة العميل أبدًا. المفتاح المخزن في حالة التطبيق أو في ترويسة API يُشحن داخل ملف تطبيقك، واستخراجه منه أمر تافه السهولة. كل مشروع حقيقي نسلمه يمرر نداءات الذكاء الاصطناعي عبر خلفية يقيم فيها المفتاح — دالة Firebase Cloud Function، أو Supabase Edge Function، أو واجهة الـ API القائمة لدى العميل. جهة FlutterFlow تستدعي عندئذٍ نقطة النهاية الخاصة بك، وهي التي تستدعي OpenAI. هذه ربع ساعة إضافية من الإعداد، وهي أيضًا المكان الذي تضيف فيه ما تحتاجه تطبيقات الإنتاج على أي حال: تحديد معدل الطلبات، والتسجيل، وسقوف التكلفة لكل مستخدم، وضوابط على ما يجوز أن يُطلب من النموذج.

الخيار 3: كود مخصص، لآخر 10%

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

أي خيار تختار لدمج الذكاء الاصطناعي في تطبيقك؟

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

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

أسئلة شائعة

هل يمكن فعلًا تطوير تطبيق ذكاء اصطناعي بدون كود؟

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

تطبيقي مبني على Assistants API — ماذا أفعل قبل 26 أغسطس 2026؟

انقل الاستدعاءات إلى Responses API (وConversations API إن كنت تحتاج سجلًا محفوظًا)، وحوّل إعدادات المساعد إلى Prompt في لوحة تحكم OpenAI. وإن كان سجل محادثات مستخدميك مهمًا، فرحّله يدويًا قبل الموعد: اجلب رسائل كل Thread واكتبها في Conversation جديدة — لا توجد أداة ترحيل آلية، وخصص لذلك يومًا كاملًا.

أين أضع مفتاح OpenAI API في FlutterFlow؟

على خادم، وليس في التطبيق أبدًا. الخيار الأول يتكفل بذلك تلقائيًا عبر دالة سحابية في Firebase (على خطة Blaze). ومع استدعاءات API المباشرة، مرر الطلبات عبر خلفية بسيطة — Firebase أو Supabase أو واجهتك القائمة — يقيم فيها المفتاح وتضيف فيها ضوابط التكلفة والاستخدام.

كم تكلفة تشغيل ميزة ذكاء اصطناعي في تطبيقي؟

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

تريد إنجازها صحيحة من المرة الأولى؟

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