التعليمات الآتية هي أمثلة أعيدت صياغتها للتعليم، وليست محادثات التطوير الأصلية. لا تتضمن الشفرة المصدرية للتطبيق أو المفاتيح أو ملفات الإعداد أو تفاصيل النشر. في التعلم الذاتي استخدم أدوات مسموحًا لك باستخدامها، أو اعمل على الورق. إن لم يتوافر الذكاء الاصطناعي، فارسم التدفق واكتب معايير القبول أولًا، من دون انتظار وجود المعلم على الإنترنت. ويمكن مناقشة أمثلة مصطنعة في الاجتماعات عن بُعد أيضًا.
مسار تطوير قابل لإعادة الاستخدام
تحديد الشخص والسياق → رسم أصغر مسار → إعداد نسخة بمواد مصطنعة → تنفيذ مهمة على الجهاز → تسجيل العوائق → تعديل واحد وإعادة الاختبار → دعوة شخص متطوع للتجربة → تحديد الخطوة التالية بناءً على الأدلة.
يمكن البدء بنموذج أولي بمساعدة الذكاء الاصطناعي والأدوات المتاحة قبل إتمام دراسة برمجة Android أو iOS دراسة منهجية. لكن تظل هناك معرفة تُكتسب حسب المهمة: الأذونات والحالات، وAPI والتكاليف، والتخزين والاستعادة، والتفويض والتحقق. كما يجب اختبار إنشاء الحزمة وتوقيعها وتثبيتها وتوافر الخدمة عمليًا. اعتمدت هذه الحالة على خبرة متراكمة؛ ولم تُنجز لحظيًا من دون معرفة سابقة.
التفويض الأول | مساعدة الشخص على البدء بالكلام
«ساعدني في تصميم نموذج أولي بسيط للتسجيل الصوتي. يريد المستخدم الحديث على مهل، لا كتابة مقالة أولًا. استخدم سؤالًا يوميًا خياليًا للعرض، واقتصر على السؤال والإجابة والإيقاف المؤقت والحفظ. ابدأ بتحديد الحالات وطريقة قبول النتيجة، ثم اقترح تنفيذًا. لا تربطه بحسابات حقيقية، ولا تستخدم تسجيلات خاصة، ولا تشغل الكاميرا تلقائيًا. وضح الأذونات والتكاليف وحالات الفشل التي يجب أن أراجعها».
ما نتحقق منه: هل يُسمع السؤال بعد البدء؟ هل يتوقف فعلًا عند الإيقاف المؤقت؟ هل يمكن استرجاع المحفوظ؟ وعند الفشل، هل يشرح ما حدث من دون مسح المحتوى المؤكد؟
التفويض الثاني | بعد أن يقول الذكاء الاصطناعي إن التعديل اكتمل
«المتوقع: النقر على إعادة التشغيل يقرأ السؤال الحالي وحده. الفعلي: لا يصدر الهاتف صوتًا. افصل أولًا بين المعروف والمجهول وثلاث فرضيات قابلة للاختبار. اقترح أبسط طريقة لإعادة المشكلة وأول فحص واحد، ثم انتظر النتيجة قبل التعديل. لا تغير وحدات عدة معًا. بعد التغيير وضح كيفية إعادة التحقق والمخاطر التي لم تُحل».
لا تنسخ سجلات حقيقية؛ فقد تتضمن معرفات أو بيانات اعتماد. التدريب هنا على إعادة المشكلة والفرضيات وتعديل متغير واحد وإعادة الاختبار، وليس على أسماء الأطر أو قواعد البرمجة.
التفويض الثالث | تنظيم الملاحظات من دون اتخاذ القرار عني
«هذه ملخصات تجارب خيالية: الأول يريد التجربة ولم يثبت التطبيق؛ الثاني تعثر في التثبيت؛ الثالث يريد تعديل النص ولا يعرف موضع الوظيفة؛ والرابع يريد موضوعات يومية جديدة ثم وجد الخيارات الموجودة. صنفها إلى مواقف وسلوك وعوائق وحاجات محتملة، وحدد نقص الأدلة. اقترح مهمة تالية قابلة للملاحظة لكل حالة، ولا تستنتج المبيعات أو الفاعلية العلاجية أو احتياجات جميع المستخدمين».
ما ينبغي للطالب ملاحظته: قد تعني عبارة «أضف ميزة» أن ميزة موجودة يصعب العثور عليها. المديح ليس شراءً، والاقتراح ليس إثباتًا للحاجة.
مسؤولية المنتج عن البيانات وAPI
| المشكلة | ما ينبغي للطالب أن يستطيع شرحه | الحالة والخطوة التالية |
|---|---|---|
| ما الذي يغادر الهاتف؟ | أين تذهب التسجيلات والنصوص والإعدادات، كل على حدة؟ ومن يستطيع الوصول إليها؟ | نرسم في الدرس تدفقًا مبسطًا للبيانات فقط، ولا نعرض إعدادات خدمة حقيقية |
| ما فائدة مفتاح مستقل لكل شخص؟ | يسهل التفويض وإدارة الحصص ونسبة التكلفة؛ أما الفوترة المستقلة فتعتمد على مزود الخدمة وإعداد الحساب | لا يضمن تلقائيًا عزل السجلات الشخصية؛ ويجب أن يتعامل التخصيص عند التسجيل مع الطلبات المتزامنة ونفاد المفاتيح وإلغاء الوصول |
| لماذا لا تُعامل بيانات اعتماد الإدارة كإعداد عادي؟ | قد يخضع التطبيق على جهاز المستخدم للتحليل؛ وإخفاء الشفرة لا يساوي حفظ السر | سهولة الاختبار الداخلي تترك مخاطر قائمة، ولا يجوز نسخها باعتبارها حلًا أمنيًا ناضجًا |
| كيف نجعل التجربة المحدودة أكثر اطمئنانًا؟ | أقل قدر من البيانات، وصلاحيات محدودة، وتفويض قابل للإلغاء، واختبار الاستعادة، ومعالجة الاستثناءات | يتطلب العزل الفعلي خدمات خاضعة للضبط والتحكم في الوصول والتدقيق وغيرها من التدابير الهندسية؛ ولا يدعي الدرس أن كل ذلك حُل بالفعل |
| كيف نضبط التكلفة؟ | من يتحمل عدد الاستدعاءات ومدتها وفشل الخدمة والميزانية؟ | يستخدم طلاب الجامعة ميزانية افتراضية تعليمية من دون اختلاق أسعار مزود؛ يحددون السقف أولًا ثم يتحققون |
يشرح الدرس المسؤولية والمنهج فقط. لا يقدم جداول إدارة حقيقية أو إعدادات خدمة أو بيانات اعتماد Bot أو طرق استخراجها. عدم فتح الشفرة خيار في نشر المنتج؛ ولا يمكن للأمن أن يعتمد على إغلاقها وحده.
كيف نتعامل مع أدوات تحليل وإعادة بناء أقوى؟
حتى 2026-10-23، اقتصرت المراجعة على قراءة وصف المستودعين وعلامات الترخيص، من دون تثبيت أو تشغيل أو اختبار عملي.
مستودع REA الرسمي ↗: يصف مساعدة في تحليل سلوك التطبيقات والملفات الثنائية وسير التشغيل. وصف القدرة لا يضمن نجاح التحليل لكل تطبيق بعينه.
مستودع replica-skill الرسمي ↗: ينظم الملاحظة وإعادة البناء والاختبار في صورة مهارة. ويؤكد README إعادة بناء الوظائف والتدفقات بأصولك الخاصة، من دون نسخ شفرة التطبيق المستهدف أو علامته أو نصوصه أو محتواه.
يعرض المستودعان حاليًا ترخيص MIT؛ ويجب مراجعة الإصدار والاعتماديات والترخيص قبل الاستخدام الفعلي.ترخيص الأداة أمر، وحقوق التطبيق المستهدف والإذن بالوصول إليه أمر آخر. عبارات المستودع الترويجية ليست إذنًا قانونيًا أو ضمانًا أمنيًا. يناقش الدرس أمثلة نملكها أو نملك إذنًا واضحًا بشأنها فقط، ولا يقدم حكمًا قانونيًا أو تدريبًا على الهندسة العكسية.
أربعة أسئلة قبل القرار
هل يحق لي الوصول إلى هذا الشيء وتحليله؟ هل أستخدم طريقة أو مكونًا مرخصًا، أم محتوى لا أملكه؟ كيف أنسب المصادر وأتحقق من النتائج؟ وحتى لو تشابه الشكل، فمن أخدم، وما قيمي ومفاضلاتي ومسؤوليتي؟
«جوهر منتجي» ليس عذرًا للتنصل من المسؤولية، ولا يشترط كتابة كل سطر من الصفر. بل يعني تحمل مسؤولية الاتجاه والمصادر والتحقق وما نرفض فعله والتسليم النهائي.