Skip to main content

​
نصائح للإنشاء

​
1. حدّد البيانات أولًا

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

​
2. خطط قبل الإنشاء

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

​
3. ابدأ بنطاق صغير

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

​
4. كن محددًا لا مجردًا

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

​
5. شخّص المشكلة قبل إصلاحها

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

اطلب من الذكاء الاصطناعي التحليل أولًا

صِف الأعراض واطلب من الذكاء الاصطناعي سرد الأسباب المحتملة والأساليب الممكنة، من دون لمس الشيفرة بعد.
2

اختر اتجاهًا ثم نفّذه

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

​
6. استفد من التراجع عن الإصدارات

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

​
الأسئلة الشائعة

​
لا يدعم منشئ التطبيقات سوى Next.js

تعتمد بيئة تشغيل منشئ التطبيقات (البيئة المعزولة والمعاينة والبناء) على Next.js، وهي لا تدعم حاليًا أطر الواجهة الأمامية الأخرى، ومنها Astro وVite وCreate React App وVue وSvelte وغيرها. إذا طلبت من الذكاء الاصطناعي استخدام إطار غير Next.js، فقد لا يرفض الطلب دائمًا، بل قد يحاول إنشاء الشيفرة المقابلة. ولكن نظرًا إلى عدم توافق البيئة الأساسية، ستفشل المعاينة في البدء، وستظل عالقًا عند «جارٍ بدء المعاينة…» إلى أجل غير مسمى، وستواصل المحادثات استهلاك الأرصدة خلال ذلك الوقت.
إذا كنت تحتاج إلى استخدام إطار غير Next.js، فنوصي بالتطوير في بيئتك المحلية وربط بياناتك عبر Teable API.

​
معالجة أخطاء 429

يقتصر Teable API حاليًا على 10 QPS (10 طلبات في الثانية). قد تواجه التطبيقات التي ينشئها منشئ التطبيقات أخطاء 429 أثناء الاستخدام العادي إذا لم تُحسّن معالجة الطلبات. يعمل فريقنا الهندسي بفعالية على تحسين أداء API، وقد نعدّل هذا الحد مستقبلًا.
توجد أربع استراتيجيات عامة لمعالجة ذلك:

التخزين المؤقت

تقليل الطلبات المكررة

التقسيم إلى صفحات والمعالجة المجمعة

تقليص حمولة كل طلب

تأخير الإدخال وتقييد المعدل

خفض تكرار الطلبات

توافق العرض

تقليل أخطاء المعاينة
يسرد كل قسم أدناه السيناريوهات الشائعة والإصلاح ومطالبة مرجعية يمكنك إعادة استخدامها. التخزين المؤقت — تقليل الطلبات المكررة
السيناريو: تحتوي صفحة لوحة معلومات على عدة مخططات وبطاقات إحصاءات وقوائم، يستعلم كل منها عن جدول مختلف. أو تكون الصفحة مخصصة أساسًا للعرض، لكن كل زيارة تظل تستدعي API مباشرةً. في الحالتين، قد يرتفع عدد الطلبات المتزامنة عند تحميل الصفحة، وتزداد احتمالية تسبب ارتفاع حركة الزيارات في أخطاء 429.الإصلاح: فضّل أنماط عرض ملائمة للتخزين المؤقت. خزّن البيانات مؤقتًا في ذاكرة التطبيق بعد تحميلها (تُعد مدة TTL من دقيقة إلى 3 دقائق نقطة بداية مناسبة) وأعد استخدامها في الزيارات اللاحقة. حمّل المكوّنات الواقعة أسفل الجزء المرئي تحميلًا كسولًا لتوزيع الطلبات زمنيًا. وإذا ظلت الصفحة تعيد الجلب في كل زيارة، فاطلب صراحةً من الذكاء الاصطناعي تعزيز استراتيجية التخزين المؤقت.
مطالبة مرجعية: «هذه صفحة كثيفة العرض. استخدم أسلوب عرض ملائمًا للتخزين المؤقت. خزّن البيانات محليًا بعد تحميل الصفحة مع مدة TTL قدرها دقيقة واحدة، ولا تعاود طلب API خلال مدة TTL، وأخّر المكوّنات الواقعة أسفل الجزء المرئي بمقدار 500 ms».
السيناريو: تحتاج ثلاثة مكوّنات في الصفحة نفسها إلى بيانات من الجدول نفسه، ويرسل كل منها طلبًا مستقلًا، مع أن طلبًا واحدًا كان سيكفي.الإصلاح: اجعل جلب البيانات مركزيًا، بحيث تُحمّل مجموعة البيانات نفسها مرة واحدة وتُشارك بين المكوّنات.
مطالبة مرجعية: «إذا احتاجت عدة مكوّنات إلى بيانات من الجدول نفسه، فاجلبها مرة واحدة وشاركها بينها جميعًا. لا ترسل طلبات مكررة».
السيناريو: يتنقل المستخدمون ذهابًا وإيابًا بين الصفحات، وتؤدي كل عودة إلى عملية جلب جديدة حتى إذا لم يتغير شيء.الإصلاح: أعد استخدام البيانات المحمّلة سابقًا خلال مدة TTL للتخزين المؤقت بدلاً من طلبها مجددًا.
مطالبة مرجعية: «عندما يعود المستخدم إلى صفحة، استخدم البيانات المخزنة مؤقتًا إذا مر أقل من دقيقة واحدة منذ آخر تحميل. لا تعاود طلب API».
السيناريو: تعرض قائمة منسدلة كل سجل في جدول كخيار. ومع كثرة السجلات، يصبح هذا الطلب الواحد ثقيلًا.الإصلاح: حوّلها إلى أداة اختيار بالبحث، بحيث لا تُجلب إلا السجلات المطابقة بعد أن يكتب المستخدم. ويمكنك بدلاً من ذلك تخزين قائمة الخيارات مؤقتًا.
مطالبة مرجعية: «ينبغي ألا تحمّل القوائم المنسدلة كل الخيارات مسبقًا. استخدم بحثًا بالكلمات المفتاحية يجلب السجلات المطابقة عند الإدخال، مع تطبيق تأخير ارتدادي».
السيناريو: يؤدي اختيار حقل إلى تحميل خيارات المستوى التالي. وتؤدي السلاسل متعددة المستويات إلى تراكم عدة طلبات لكل تفاعل.الإصلاح: حمّل البيانات ذات الصلة مسبقًا مرة واحدة وصفّها محليًا، أو خزّن بيانات التسلسل مؤقتًا بعد التحميل الأول.
مطالبة مرجعية: «خزّن بيانات خيارات أدوات التحديد المتتالية محليًا بعد تحميلها. عندما يغيّر المستخدم خيارًا رئيسيًا، صفِّ البيانات من الذاكرة المؤقتة بدلاً من طلبها مجددًا».
السيناريو: تتسبب إدارة الحالة السيئة في إعادة جلب المكوّنات للبيانات عند كل عملية عرض.الإصلاح: شغّل جلب البيانات عند أحداث محددة (التحميل الأولي أو إجراء صريح من المستخدم)، لا عند كل عملية عرض. واستخدم التخزين المؤقت كشبكة أمان.
مطالبة مرجعية: «لا تجلب البيانات إلا عند أول تحميل للصفحة أو عند إجراءات صريحة من المستخدم. لا تعاود الجلب عند إعادة العرض، واستخدم البيانات المخزنة مؤقتًا بدلاً من ذلك».
التقسيم إلى صفحات والمعالجة المجمعة — تقليص حمولة كل طلب
السيناريو: يؤدي تحميل جميع السجلات دفعة واحدة إلى سيل من استدعاءات API عندما تكبر مجموعة البيانات.الإصلاح: قسّم البيانات إلى صفحات، ولا تجلب إلا بيانات الصفحة الحالية.
مطالبة مرجعية: «اعرض 20 صفًا في كل صفحة. لا تحمّل الصفحة التالية إلا عند انتقال المستخدم إليها. لا تحمّل كل شيء دفعة واحدة».
السيناريو: بعد تحميل قائمة، تجلب تفاصيل الجدول المرتبط لكل سجل على حدة. فتحميل 50 مشروعًا ثم إجراء 50 عملية بحث عن المسؤولين يعني 50 طلبًا إضافيًا في لحظة واحدة.الإصلاح: اجلب جميع البيانات المرتبطة في دفعة واحدة، لا صفًا بصف.
مطالبة مرجعية: «عند تحميل قائمة، اجلب جميع البيانات المرتبطة في طلب مجمع واحد. لا تمر على السجلات لجلب معلوماتها المرتبطة كلًا على حدة».
السيناريو: تحديث عدة سجلات دفعة واحدة بإرسال طلب تحديث لكل سجل بدلاً من طلب مجمع واحد.الإصلاح: استخدم API للتحديث المجمع لإرسال جميع التغييرات في استدعاء واحد.
مطالبة مرجعية: «ادمج تغييرات عدة سجلات في طلب مجمع واحد عند تنفيذ عمليات مجمعة. لا ترسل طلب تحديث مستقلًا لكل سجل».
السيناريو: تعالج حلقة for السجلات واحدًا تلو الآخر وتستدعي API في كل تكرار.الإصلاح: اجمع جميع المعرّفات أولًا، ثم أرسل طلبًا مجمعًا واحدًا.
مطالبة مرجعية: «لا تستدعِ API داخل حلقة. اجمع جميع المعرّفات المطلوبة أولًا، ثم أرسل طلبًا مجمعًا واحدًا».
تأخير الإدخال وتقييد المعدل — خفض تكرار الطلبات
السيناريو: ترسل كل ضغطة مفتاح في مربع البحث طلبًا. تؤدي كتابة استعلام من 4 أحرف إلى إرسال 4 طلبات.الإصلاح: طبّق تأخيرًا ارتداديًا على الإدخال؛ انتظر من 300 إلى 500 ms بعد توقف المستخدم عن الكتابة قبل إرسال الطلب.
مطالبة مرجعية: «طبّق تأخيرًا ارتداديًا على إدخال البحث. لا ترسل الطلب إلا بعد 300 ms من توقف المستخدم عن الكتابة. لا ترسل طلبات أثناء الكتابة».
السيناريو: نقرات إرسال متلاحقة، أو تبديل سريع لعوامل التصفية، أو تنقل سريع بين الصفحات؛ يرسل كل إجراء طلبًا فورًا.الإصلاح: طبّق التأخير الارتدادي أو تقييد المعدل. عطّل أزرار الإرسال إلى أن يكتمل الطلب لمنع الإرسال المزدوج.
مطالبة مرجعية: «عطّل زر الإرسال بعد النقر، وأعد تمكينه عند اكتمال الطلب. طبّق تأخيرًا ارتداديًا على تغييرات عوامل التصفية حتى لا ترسل التغييرات السريعة خلال 300 ms سوى طلب واحد».
السيناريو: يُحفظ كل تغيير في حقل فورًا. قد يؤدي ملء نموذج إلى عشرات عمليات الكتابة.الإصلاح: استخدم الحفظ الصريح عند النقر على زر، أو طبّق تأخيرًا ارتداديًا على الحفظ التلقائي حتى يعمل مرة واحدة بعد توقف التحرير مؤقتًا.
مطالبة مرجعية: «لا تحفظ عند كل تغيير في حقل. احفظ عند النقر صراحةً على الزر، أو نفّذ الحفظ التلقائي مرة واحدة بعد توقف المستخدم عن التحرير لمدة ثانيتين».
السيناريو: تُحدّث البيانات كل بضع ثوان، ما ينتج حركة مرور مستمرة وعالية التكرار.الإصلاح: زد فاصل الاستقصاء إلى مدة معقولة (30 ثانية أو أكثر)، أو انتقل إلى التحديث اليدوي.
مطالبة مرجعية: «اضبط فاصل التحديث التلقائي على 60 ثانية. أضف زر تحديث يدويًا حتى يتمكن المستخدمون من جلب أحدث البيانات عند الطلب».
السيناريو: يضبط كل مكوّن من عدة مكوّنات في الصفحة مؤقت الاستقصاء الخاص به. ويتجاوز الحمل المجمع الحد بسهولة.الإصلاح: اجعل الاستقصاء مركزيًا. نفّذ عملية جلب دورية واحدة، ثم وزّع النتيجة على كل مكوّن يحتاج إليها.
مطالبة مرجعية: «لا تسمح لكل مكوّن بضبط مؤقت استقصاء خاص به. استخدم آلية تحديث واحدة تجلب كل شيء وفق جدول زمني وتوزع البيانات على المكوّنات».
توافق العرض — تقليل أخطاء المعاينة
السيناريو: تستخدم الصفحة مخططات أو خرائط أو مكتبات تعتمد على window أو قياسات DOM أو واجهات API أخرى لا تتوفر إلا في المتصفح، وتعرض المعاينة أخطاء أو شاشة فارغة أو حالات عدم تطابق في الإماهة.الإصلاح: غالبًا ما يكون تحميل هذه المكوّنات في المتصفح أكثر أمانًا من عرضها مباشرةً على الخادم. وإذا استمرت مشكلات المعاينة، فاطلب صراحةً من الذكاء الاصطناعي تحويلها إلى نمط تحميل خاص بالمتصفح.
مطالبة مرجعية: «يعتمد هذا المكوّن على بيئة المتصفح. حمّله على جانب العميل فقط لتجنب أخطاء عرض المعاينة أو عدم تطابق الإماهة».
قد يخطئ الذكاء الاصطناعي. يُرجى التحقق من الردود.
آخر تعديل في ٤ سبتمبر ٢٠٢٦