23 مارس 2025·8 دقيقة
كيف تبني تطبيق موبايل لتتبع الأصول الشخصية
تعلّم كيف تخطط، تصمم، وتبني تطبيق موبايل لتتبع الأصول الشخصية — من نطاق MVP ونموذج البيانات إلى الأمان، المزامنة أوفلاين، الاختبار والإطلاق.
تعلّم كيف تخطط، تصمم، وتبني تطبيق موبايل لتتبع الأصول الشخصية — من نطاق MVP ونموذج البيانات إلى الأمان، المزامنة أوفلاين، الاختبار والإطلاق.
قبل بناء تطبيق موبايل، قرّر أي مشكلة تحلّها. "تطبيق تتبع الأصول الشخصية" يمكن أن يعني أشياء مختلفة جدًا: متتبع صافي ثروة للأرصدة، جرد أصول للعناصر والمستندات، أو مزيج بين الاثنين. كلّما كان الهدف أوضح، كان تصميم الشاشات وحقول البيانات وMVP القابل للإطلاق أسهل.
اختر الوظيفة الأساسية التي يجب أن يقوم بها التطبيق في اليوم الأول:
إذا حاولت فعل الثلاثة بكلّ كمال، سيتأخر MVP.
المستخدمون المستهدفون يشكّلون كل شيء من التشغيل الأولي إلى المشاركة:
بالنسبة لـMVP، اختر واحدًا. يمكنك التوسّع لاحقًا بعد أن تتعلّم كيف يستخدم الناس التطبيق فعلاً.
اكتب أنواع الأصول الأولية: نقد, حسابات مصرفية, استثمارات, كريبتو, عقارات, مركبات, وأشياء ثمينة.
ثم عرّف "التتبع" لكل نوع. هل هو:
MVP جيد هو وعد مركز. مثال: "تتبع 5–7 أنواع أصول، إضافة أصول في أقل من 60 ثانية، ورؤية قيمة إجمالية بسيطة." احفظ الاستيرادات المتقدّمة، التكاملات، والتقارير المعقّدة للإصدار التالي.
قبل تصميم الشاشات أو اختيار التقنية، اكتب ما يحاول الناس فعله بالفعل. ينجح تطبيق تتبع الأصول الشخصية عندما تكون الأفعال اليومية سريعة وموثوقة.
إليك 10 قصص عملية يمكنك استخدامها كأساس:
ركز على خمسة تدفقات ستصمّمها أولًا:
اختر مجموعة صغيرة من المقاييس حتى لا تخمّن لاحقًا: الأصول المضافة في الأسبوع الأول, المستخدمون النشطون أسبوعيًا, الاحتفاظ لأربعة أسابيع, و**٪ المستخدمين الذين يصدرون**.
ثم حوّل القصص إلى قائمة ميزات:
هذا يبقي MVP مركّزًا مع ترك مجال للترقيات بعد الإطلاق.
تجربة المستخدم الرائعة لتطبيق تتبع الأصول الشخصية تتعلق في الغالب بتقليل الجهد. يفتح الناس التطبيق بسرعة للتحقق السريع "أين أنا؟" أو لإضافة شيء اشتروه للتو—لذا يجب أن تبدو كل شاشة واضحة وسريعة.
يمكن أن تغطي خمس شاشات معظم الاحتياجات في MVP:
إذا عملت بعدد قليل من الوجهات الرئيسية (الرئيسية، الأصول، الإعدادات)، فالعناصر السفلية غالبًا أكثر قابلية للاكتشاف. استخدم درجًا فقط عند وجود مناطق ثانوية كثيرة (تقارير، تكاملات، ملفات تعريف متعددة) التي ستُشغّل علامات التبويب.
تدفّق الإضافة يجب أن يطلب فقط الأساسيات:
يمكن أن تكون الباقي اختياريًا مع افتراضات ذكية: ضبط العملة من الإعدادات تلقائيًا، فئة افتراضية بناءً على الأخير المستخدم، وملفات اختيار سريعة للأصول الشائعة (سيارة، لابتوب، مجوهرات). فكّر في زر "حفظ + أضف آخر" لإدخال الدُفعات.
صمّم للاستخدام الواقعي: أحجام خطوط قابلة للقراءة، تباين قوي، وأهداف نقر كبيرة (خاصة لشرائح الفئة وأزرار الإجراءات). دعم تغيير حجم النص وتجنّب الاعتماد على اللون فقط لنقل الحالة.
حالات الفراغ مهمة: عندما تكون قائمة الأصول فارغة، أظهر مطالبة ودودة مع إجراء واضح واحد ("أضف أصلك الأول") ونصيحتين للإعداد (مثلاً: "ابدأ بالفئات الكبيرة: المنزل، المركبات، المدخرات").
نموذج بيانات واضح يبقي MVP بسيطًا الآن ويمنع إعادة كتابة مؤلمة لاحقًا عندما يطلب المستخدمون التاريخ أو الرسوم البيانية أو الاستيراد. بالنسبة لتطبيق تتبع الأصول الشخصية، فكّر بمثلين: الأشياء التي يملكها الناس (الأصول) وكيف تتغير قيمتها عبر الزمن (التقييمات).
على الأقل، عرّف هذه الكيانات:
لكل أصل، اجعل الحقول الإلزامية قليلة ومتناسقة:
أضف حقولًا مرنة لتقليل حالات الطرف لاحقًا:
تجنّب تخزين "قيمة حالية" فقط. نمذِج التقييم كسلسلة زمنية:
يمكن لواجهة المستخدم أن تعرض رقمًا واحدًا بأخذ أحدث تقييم، لكنك ستفتح إمكانيات للاتجاهات والتاريخ و"صافي الثروة عبر الزمن" دون إعادة تصميم قاعدة البيانات.
معظم المستخدمين يريدون إجماليًا واحدًا. دعم ذلك بتخزين:
احتفظ بالقيم الأصلية في عملة الأصل، ثم حوّل للمجاميع والرسوم البيانية. هذا يبقي الاستيرادات دقيقة ويتجنّب أخطاء التقريب عبر الزمن.
البنية هي حيث تقرر على ماذا تبني ومكان حفظ البيانات. هذه الاختيارات تؤثر على الأداء والتكلفة وصعوبة التحديث بعد سنة.
النيتف (Swift لـ iOS, Kotlin لـ Android) عادة يعطي أفضل سلاسة للواجهة، وكفاءة البطارية، وأسهل وصول لميزات النظام (Face ID/البايومتري، عناصر واجهة، مهام الخلفية). المقايضة: تطبيقان للصيانة.
عبر‑المنصات (React Native, Flutter) يمكن أن يكون أسرع وأرخص لـMVP لأنك تشارك معظم الشيفرة بين iOS وAndroid. المقايضة: متاعب منصة أحيانًا وإدارة تبعيات أكثر. لتطبيق تتبع الأصول، غالبًا ما يكون عبر‑المنصات خيارًا منطقيًا إلا إذا خطّطت لميزات نظامية مكثفة.
عادة لديك ثلاث خيارات:
حتى تطبيق بسيط يستفيد من قاعدة بيانات محلية (خيارات تعتمد على SQLite مثل Room على Android، Core Data على iOS، أو أغلفة عبر‑المنصات). خطّط للـmigrations مبكرًا لتضيف حقولًا لاحقًا دون كسر المستخدمين الحاليين.
أضف باك‑إند خفيفًا إذا احتجت المزامنة، المشاركة (أصول عائلية)، التكاملات، أو تذكيرات على الخادم. وثّق المقايضات—السرعة، التكلفة، التعقيد، الصيانة—وحافظ على بنية MVP متعمدة وبسيطة.
إذا أردت التحرك بسرعة دون الالتزام بخط أنابيب بناء مخصص طويل من البداية، منصة توليد‑الشيفرة مثل Koder.ai يمكن أن تساعدك في بناء نموذج أولي كامل (واجهة + API + قاعدة بيانات) من وصف دردشي. مفيدة خصوصًا لتخطيط MVP، تكرار المخططات (الأصول/التقييمات/المرفقات)، والرجوع للتصويرات إذا اكتشفت أن قرار نموذج البيانات كان خاطئًا.
إذا شعرت عملية تسجيل الأصول وكأنها عمل ضرائب، سيتوقف الناس عن الاستخدام. يجب أن يفترض MVP أن المستخدمين سيضيفون عددًا قليلاً من العناصر في كل مرة—واجعل ذلك سريعًا.
لـMVP، الإدخال اليدوي كافٍ. هدفك نموذج واحد مدمج يحتوي فقط ما يحتاجه للتعرّف على الأصل وتقدير القيمة:
يمكن للباقي أن يكون "متقدم". إذا لم يعرف المستخدم رقمًا، اسمح له بتركه فارغًا والمتابعة.
ميزات المسح مفيدة، لكن اجعلها ترقيات اختيارية—ليست متطلبات:
حتى دون OCR، يضيف إرفاق صورة قيمة ويقلّل الاحتكاك.
الكثير من المستخدمين لديهم جدول بيانات بالفعل. قدّم قالب CSV بسيط يمكنهم ملؤه، بالإضافة إلى تدفق "لصق جدول" سريع للنسخ/اللصق من Notes أو Sheets. للاستيراد اليدوي الكمي، ادعم "أضف آخر" مع افتراضات (نفس الفئة/العملة) لتسريع الإدخالات المتكررة.
خلاصات الأسعار التلقائية منطقية أساسًا للأوراق المالية والكريبتو. عاملها كتكامل اختياري، وحافظ على الإدخال اليدوي كأساس لكل شيء آخر (الممتلكات المنزلية، المركبات، الفن).
كن صريحًا حول المجهول. استخدم حالات مثل "القيمة غير معروفة" أو "آخر تحديث منذ 6 أشهر" واسمح بالإدخالات الجزئية. عندما تكون القيم قديمة، اعرض تذكيرات لطيفة للتحديث بدلًا من حجب الرؤى.
قد لا يكون تطبيق تتبع الأصول الشخصية تطبيقًا مصرفيًا، لكن المستخدمين سيتعاملون معه كما لو كان كذلك. إذا أدخلوا قيم منازل أو أرصدة حسابات أو أرقام تسلسلية، يتوقعون نفس مستوى العناية: جمع أدنى حد، ضوابط واضحة، وحماية قوية على الجهاز.
لا تُجبِر المستخدم على إنشاء حساب لفتح التطبيق. بالنسبة للكثيرين، "الاستخدام محليًا على هاتفي" ميزة بحد ذاتها.
نهج جيد لـMVP:
إذا قدّمت تسجيلًا، كن واضحًا أنه لأجل المزامنة لا لأجل "استخدام التطبيق".
ابدأ بطبقتين:
إذا خزّنت أي شيء في الباك‑إند للمزامنة، شفره هناك أيضًا وفصّل بيانات هوية المستخدم عن سجلات الأصول قدر الإمكان.
اطلب الأذونات في لحظة الحاجة وبأقل نطاق ممكن.
أمثلة:
إذا كانت ميزة تعمل بدون إذن، لا تطلبه.
الناس يتتبعون غالبًا معلومات مشتركة أو حساسة، لذا أضف ضوابط بسيطة تتوافق مع الحالات الواقعية:
اكتب شروحات داخل التطبيق بلغة بسيطة مثل:
يمكن أن تكون شاشة "الخصوصية" قصيرة في الإعدادات مع رابط لسياسة الخصوصية (مثلاً /privacy). التوقعات الواضحة تقلل مشكلات الدعم وتبني الثقة مبكرًا.
التذكيرات والرؤى الخفيفة هي حيث يبدأ التطبيق بالشعور "بالحياة"—دون التحوّل إلى لوحة بيانات مالية مزعجة. الهدف هو مساعدة المستخدمين على البقاء محدّثين ورصد التغيّرات بسرعة وبإعداد بسيط.
ابدأ بمجموعة صغيرة من التنبيهات التي تتطابق مع لحظات الحياة الحقيقية:
احتفظ بضوابط الإشعارات مفصّلة: اسمح بتبديل التذكيرات حسب النوع، ضبط التكرار، واختيار نافذة هادئة. قاعدة بسيطة: إذا لم تستطع شرح تذكير في جملة واحدة، فغالبًا ليس MVP.
تجنّب جدار الرسوم البيانية. ابدأ بـ 2–3 عروض تجيب عن أسئلة شائعة:
هذه سهلة الفحص والتحقق ومفيدة حتى مع قائمة أصول صغيرة.
الثقة تأتي من الوضوح. عندما تعرض "صافي الثروة"، أضف رابط "ما الذي يتضمن؟" أو ملاحظة داخلية، مثل:
أعرض أيضًا طريقة التقييم (يدوي، مستورد، مُقدّر) بجانب كل أصل حتى يفهم المستخدم سبب تغيّر الأرقام.
دعم عدم الاتصال ميزة يشعر بها المستخدم فورًا: يمكنهم إضافة عنصر في القبو، تحديث قيمة على متن طائرة، أو استعراض إيصال في موقف السيارات. لتطبيق تتبع الأصول الشخصية، هدفك أن يكون "أوفلاين أولًا"—يعامل التطبيق قاعدة بيانات الجهاز كمصدر الحقيقة ويزامن بشكل انتهازي.
تأكد أن كل الإجراءات الرئيسية تعمل بدون إنترنت:
هذا يتطلّب قاعدة بيانات محلية (مثل SQLite) وطابور "التغييرات المعلقة" للمزامنة لاحقًا.
إذا قدمت مزامنة سحابية، حدّد التعارضات مقدمًا. نهجان شائعان:
هجين عملي: "آخر تعديل يفوز" للحقول منخفضة المخاطر (الملاحظات)، واطلب تأكيدًا عندما تُغير كلا النسختين حقلًا رئيسيًا (القيمة، العملة، الفئة).
المرفقات غالبًا تهيمن على التخزين والنطاق. قرّر مبكرًا:
حدد حدودًا واضحة (مثل حجم صورة أقصى، عدد المرفقات لكل أصل) واضغظ الصور قبل التحميل.
المزامنة يجب أن تكون مدفوعة بالأحداث ومحافظة: جمّع التغييرات، استخدم تراجعًا أسّيًا عند الفشل، وتجنّب الاستطلاع المستمر في الخلفية.زامن عند فتح التطبيق، عند إجراء المستخدم لطلب صريح، وعند منح النظام وقتًا في الخلفية.
أنشئ قائمة فحص اختبار: وضع الطائرة، التبديل من Wi‑Fi إلى LTE أثناء المزامنة، شبكات بطيئة، وإعادة تشغيل التطبيق مرارًا. أضف حالة مزامنة مرئية ("محدّث", "جارٍ المزامنة…", "يحتاج انتباها") ليثق المستخدم فيما يراه.
يكسب تطبيق تتبع الأصول الشخصية ثقة المستخدمين بأن الأساسيات تعمل دائمًا: مجاميع دقيقة، سلوك متوقّع في الأوفلاين، وعدم وجود "فقدان بيانات غامض". خطة اختبار قابلة للتكرار وخفيفة أكثر قيمة من قائمة ميزات طويلة.
ابدأ باختبارات آلية للمنطق الذي يؤثر على صافي الثروة والتقارير:
هذه الاختبارات سريعة وتلتقط الانكسارات عند تعديل نموذج البيانات أو قواعد الاستيراد.
اختبر يدويًا (أو بأتمتة واجهة بسيطة) رحلات المستخدم الحرجة على أحجام شاشات متعددة:
انتبه بشكل خاص للشاشات الصغيرة، إعدادات النص الكبير، وقابلية الاستخدام بيد واحدة.
لست بحاجة إلى مختبر معقّد—فقط حالات ضغط واقعية:
تتبّع الشاشات البطيئة وصحّح الأسوأ أولًا.
اجمع مجموعة بيتا صغيرة لتمييز الخطوات المربكة ("أين أعدّل العملة؟" "هل استيرادي نجح؟"). ثم نفّذ قائمة تحقق قبل الإصدار تركز على:
إطلاق التطبيق ليس خط النهاية—هو النقطة التي يلتقي فيها المستخدمون الحقيقيون بالأجهزة الحقيقية، حالات الطرف الغريبة، وتوقعات عالية حول الثقة. إطلاق سلس وخطة دعم واضحة يمكن أن يمنعا مشكلات صغيرة (مثل ملف استيراد معطّل) من التحوّل إلى أضرار في تقييم المتجر.
متاجر التطبيقات تُكافئ الوضوح. حضّر مواد قائمتك مبكرًا حتى لا يتحول الإطلاق إلى فوضى.
إذا أضفت تسجيل دخول أو مزامنة، تحقّق من تلبية متطلبات المنصات لحذف الحساب والتعامل مع البيانات.
أعد يوم واحد: ضع نظامين من اليوم الأول:
أضف قسم "مساعدة" صغير يجيب عن أسئلة شائعة: الاستيراد، الفئات، تعديل القيم التاريخية، ومعنى المجاميع.
الناس لن يلتزموا بجرد أو متتبع صافي ثروة إذا شعروا بأنهم محبوسون. خطّط للتصدير مبكرًا:
حتى إن لم تقدم مزامنة سحابية، يقلّل التصدير الموثوق من التسرب وشكاوى الدعم.
انشر خارطة طريق بسيطة للحفاظ على توقعات واقعية. مثال: MVP يركّز على التتبع اليدوي والاستيراد؛ المراحل التالية تضيف تكاملات, خلاصات بنكية, وباحثات أسعار. اربط /roadmap من الإعدادات.
خصّص وقتًا شهريًا (أو ربع سنويًا) لـ:
إذا بنيت بمنصة تدعم اللقطات والعودة للخلف (مثل Koder.ai)، اعتبرها جزءًا من استراتيجيتك: يمكنك الشحن بسرعة، ثم التراجع عن تغييرات خطرة أثناء إصلاح المشكلة—دون إيقاف المستخدمين لأيام.
الثبات الطويل الأمد هو ما يحوّل تحميلًا لمرة واحدة إلى تطبيق يُستخدم يوميًا.
إطلاق تطبيق تتبع الأصول هو بداية حلقة التغذية الراجعة، ليس النهاية. الهدف هو تعلّم ما يساعد الناس على تحديث جردهم—وما يدفعهم للتخلي عنه.
احتفظ بالتحليلات مركّزة: استخدام الميزات (إضافة أصل، تعديل، استيراد), الاحتفاظ (يوم 1/7/30), وأين يترك المستخدمون التدفق. تجنّب جمع محتوى حساس مثل أسماء الأصول، الملاحظات، أو القيم الدقيقة.
أضف ملاحظة "ما الذي نجمعه" في الإعداد الأولي أو الإعدادات، واربط /privacy. إذا قدمت خيار إلغاء الاشتراك، اجعله سهل الوصول.
بدلًا من مقاطعة المستخدمين عشوائيًا، اطلب الملاحظات بعد محطات مهمة:
استخدم مطالبة قصيرة ومحددة مثل: "هل كان هناك شيء محيّر أثناء إضافة أصل؟" مع تقييم سريع وصندوق تعليق اختياري. إذا كان لديك صفحة مساعدة، اربطها مباشرة (مثلاً /help) ليتمكّن المستخدم من الخدمة الذاتية.
أنشئ سجلًا واحدًا لكن علّم البنود كالتالي:
هذا يمنع الميزات اللامعة من سرقة وقت إصلاح الأساسيات التي تحافظ على الثقة.
معظم القيمة تأتي من التحسينات المستمرة. راجع تحليلاتك وملاحظاتك بتركيز على إضافة/تعديل:
التحسينات الصغيرة—افتراضات أفضل، حقول إلزامية أقل، بحث أذكى—تحرّك الاحتفاظ أكثر من الرسوم البيانية الجديدة.
ضع إيقاعًا خفيفًا: فرز أسبوعي، إصدارات تصحيحية كل أسبوعين، وتحسينات UX شهرية. عندما تكتب ما تغيّر (أو تحدّث ملاحظات الإطلاق)، أدرج أمثلة ولقطات لتوضيح التغييرات—دون تحويل كل إصدار إلى إعادة تصميم كبيرة.
إذا شاركت ما تعلّمته علنًا، فكّر في برامج تكافئ محتوى البناة: على سبيل المثال، Koder.ai يقدم نهجًا لكسب رصيد مقابل إنشاء محتوى عن المنصة أو إحالة مستخدمين جدد—مفيد إذا كنت تموّل MVP وتريد أن يموّل عملك جزءًا من أدوات التطوير.
ابدأ بتحديد وظيفة رئيسية لليوم الأول:
ثم حدّد الجمهور المستهدف (استخدام شخصي، عائلات، أو فرق صغيرة) وضع حدود MVP صارمة مثل "إضافة أصل في أقل من 60 ثانية" و"دعم 5–7 أنواع أصول".
اعتبر الإيصالات/المرفقات، تاريخ التقييم، وتعدد العملات كميزات "يجب أن تكون" إذا أمكن تنفيذها دون إبطاء التدفقات الأساسية.
صمّم الإصدار الأول حول خمسة تدفقات أساسية:
إذا كانت هذه سريعة وموثوقة في وضع عدم الاتصال، فسيشعر معظم المستخدمين أن التطبيق "مكتمل" حتى بدون تكاملات متقدّمة.
هذه الحالات الطرفية أسهل لدعمها مُبكّرًا من تعديلها لاحقًا بعد تراكم البيانات.
اجعل شاشة "إضافة أصل" تتطلّب فقط الاسم، الفئة، والقيمة (أو السماح بـ"غير معروف") مع جعل الباقي اختياريًا.
استخدم نموذج سلسلة زمنية:
حتى لو عرضت الواجهة قيمة واحدة فقط، فإن تخزين التقييمات كلقطات يمنع إعادة كتابة مؤلمة لاحقًا عند إضافة الرسوم البيانية أو التصدير التاريخي.
نهج MVP الجيد:
احسب المجاميع بتحويل القيم إلى العملة الأساسية باستخدام سعر/تاريخ محدد وسجّل أي سعر استخدمته. هذا يتجنب الانحرافات الحسابية ويحافظ على دقة الاستيراد.
اختَر بناءً على فريقك وخريطة الطريق:
بالنسبة لتخزين البيانات، قاعدة بيانات محلية بنهج "أوفلاين أولًا" غالبًا ما تكون الأفضل. أضِف باك‑إند فقط إذا احتجت إلى المزامنة/المشاركة/التذكيرات على الخادم.
ابدأ بالإدخال اليدوي وركّز على السرعة:
أضف الاستيراد كتطوير عملي: قالب CSV وتدفق "لصق جدول" للمستخدمين الذين لديهم جداول بالفعل.
عامل التطبيق كبيانات مصرفية حتى لو كانت "مجرد جرد":
اشرح بوضوح ما يُخزّن على‑الجهاز مقابل ما يُخزّن في السحابة واربط /privacy.
ابدأ بمجموعة صغيرة من التنبيهات المفيدة:
تجنّب جدار من الرسوم البيانية؛ ابدأ بـ 2–3 عروض مفيدة: اتجاه صافي الثروة، توزيع حسب الفئة، والتواريخ القادمة. اجعل الحسابات شفافة ووضح ما هو مُدرج/مستبعد.
اجعل التطبيق "أوفلاين أولًا":
للمزامنة السحابية، حدّد سياسة التعارض: "آخر تعديل يفوز" للحقل المنخفض المخاطر، واطلب تأكيدًا عند تغييرات على حقول حسّاسة. قرّر ما إذا كانت المرفقات جهازية فقط أم تُحمّل للسحابة (مع تشفير وحدود حجم).
ضع اختبارات تركّز على الموثوقية:
قضاء الوقت هنا يبني ثقة المستخدم.
إذا أضفت تسجيل دخول أو مزامنة، تأكد من الالتزام بمتطلبات المنصات لحذف الحساب ومعالجة البيانات.
قدّم أمرين من اليوم الأول:
أضف قسم "مساعدة" صغيرًا يغطي الأسئلة الشائعة: الاستيراد، الفئات، تعديل القيم التاريخية، ومعنى المجاميع.
حتى إن لم تكن تقدم مزامنة سحابية كاملة بعد، فإن التصدير الموثوق يبني ثقة ويقلل شكاوى الدعم.
حافظ على خارطة طريق بسيطة ومعلنة: MVP يركّز على التتبع اليدوي والاستيراد؛ المراحل التالية قد تضيف التكاملات، خلاصات الأسعار، ورؤى أذكى. اربط /roadmap من الإعدادات.
قسم الصيانة كميزة: خصص وقتًا شهريًا أو ربع سنوي لـ:
إذا استخدمت منصة تدعم اللقطات والعودة للخلف (مثل Koder.ai)، اعتبرها جزءًا من استراتيجية الصيانة لتسريع النشر والقدرة على التراجع السريع.
تتبع فقط ما تحتاجه وفسّر للمستخدمين:
اطلب التعليقات عند لحظات ذات مغزى (بعد إضافة 5 أصول، بعد استيراد، بعد أول تحديث للقيم) واستخدم مطالبة قصيرة مع تقييم وخانة تعليق اختيارية. اربط /help للمساعدة الذاتية.