18 سبتمبر 2025·8 دقيقة
كيفية بناء تطبيق ويب للتوظيف يطابق المرشحين
تعلم كيفية بناء تطبيق ويب للتوظيف يطابق المرشحين بالوظائف. يغطي الميزات الأساسية، نموذج البيانات، منطق المطابقة، تجربة المستخدم، التكاملات، وخطة الإطلاق.
تعلم كيفية بناء تطبيق ويب للتوظيف يطابق المرشحين بالوظائف. يغطي الميزات الأساسية، نموذج البيانات، منطق المطابقة، تجربة المستخدم، التكاملات، وخطة الإطلاق.
قبل أن ترسم شاشات أو تختار تقنية، كُن محددًا بشأن المشكلة التي يحلها تطبيق التوظيف ومن هم المستفيدون. «مطابقة المرشحين مع الوظائف» قد تعني أي شيء من فلتر كلمات مفتاحية بسيط إلى سير عمل موجه يساعد المجند على نقل الدور من الاستلام إلى التعيين.
ابدأ بأشخاص سيسجلون الدخول يوميًا. لتطبيق لوكالات التوظيف هؤلاء عادةً:
ممارسة مفيدة: اكتب 2–3 «مهام رئيسية» لكل مستخدم. إذا لم يدعم المطلب مهمة منهم، فغالبًا ليس جزءًا من MVP.
تجنب أهدافًا غامضة مثل «مطابقات أفضل». اختر مقاييس تعكس نتائج الأعمال وتقلل العمل اليدوي:
ستوجه هذه المقاييس لاحقًا تحليلات التوظيف وتساعد على التحقق مما إذا كانت خوارزمية المطابقة تحسّن النتائج.
سير التوظيف أكثر من مجرد مطابقة. وثّق المراحل والبيانات التي تُنشأ في كل خطوة:
Sourcing → Screening → Submitting → Interviewing → Offer → Placement
لكل مرحلة، اذكر «الكائنات» المتورطة (مرشح، وظيفة، تقديم، مقابلة)، الإجراءات الأساسية (تسجيل مكالمة، إرسال بريد، جدولة مقابلة)، ونقاط القرار (رفض، التقدم، الانتظار). هنا تتقاطع ميزات ATS وCRM — فكن متعمدًا فيما تتبعه.
يجب أن يقدم MVP حلقة قابلة للاستخدام: إنشاء طلب وظيفة → إضافة مرشحين (يدوي أو تحليل سيرة أساسي) → مطابقة → مراجعة → تقديم.
المدرجات الشائعة في الإصدار 1:
ميزات تُضاف لاحقًا (جميلة وجودها لكن ليست أساسية في البداية):
بتعريف المستخدمين، المقاييس، سير العمل، والنطاق مقدمًا، تمنع المشروع من أن يصبح "كل شيء ATS" وتحافظ على البناء مركزًا على قوائم مختصرة أسرع وأكثر ثقة.
تطبيق التوظيف ينجح أو يفشل بنموذج بياناته. إن لم تكن المرشحين، الوظائف، وتفاعلاتهم مُنظمة بوضوح، تصبح المطابقات صاخبة، التقارير غير موثوقة، والفريق يناضل مع الأداة بدلًا من استخدامها.
ابدأ بكيان مرشح يدعم تخزين المستندات وحقولًا قابلة للبحث. احتفظ بالسيرة الأصلية/السجل (ملف + نص مستخرج)، وكن منظّمًا في سمات رئيسية ستحتاجها للمطابقة:
نصيحة: افصل البيانات "الخام" (النص المستخرج) عن الحقول "المنقّحة" التي يمكن للمجند تحريرها. هذا يمنع أخطاء التحليل من تشويه الملفات صامتًا.
اصنع كيان وظيفة (طلب) بحقول متسقة: المسمى، المستوى الوظيفي، المهارات المطلوبة مقابل المرغوبة، سياسة الموقع/عن بُعد، نطاق الراتب، الحالة (مسودة/مفتوح/معلق/مغلق)، وتفاصيل مدير التوظيف. اجعل المتطلبات مُنظمة بما يكفي للتقييم، ولكن مرنة بما يكفي لوصف حقيقي للوظائف.
تحدث معظم الأنشطة بين المرشحين والوظائف، لذا نمذج العلاقات صراحة:
عرّف الوصول مبكرًا: مرشحين على مستوى الوكالة مقابل فرق فقط، رؤية خاصة بالعميل، وحقوق التحرير حسب الدور (مجند، مدير، مسؤول). اربط الأذونات بكل مسار قراءة/كتابة حتى لا تتسرب المرشحين الخاصة أو الوظائف السرية عبر البحث أو نتائج المطابقة.
المجندون يتحركون بسرعة: يَقْرَأون بسرعة، يُصفّون، يُقارنون، ويتابعون — غالبًا بين المكالمات. يجب أن تجعل واجهة المستخدم نقرات "الخطوة التالية" واضحة ورخيصة.
ابدأ بأربع صفحات أساسية بالإضافة إلى عرض المطابقة:
يتوقع المجندون أن يتصرف البحث كلوحة أوامر. قدّم بحثًا عامًّا بالإضافة إلى مرشحات للمهارات، الموقع، سنوات الخبرة، الراتب، الحالة، والتوفر. اسمح بتحديد متعدد وحفظ المرشحات (مثلاً: "لندن Java 5+ سنوات تحت £80k"). اجعل المرشحات مرئية، مع شرائط تظهر ما هو مفعّل.
الإجراءات الجماعية توفر ساعات عند التعامل مع قوائم طويلة. من قائمة المرشحين أو عرض المطابقة، ادعم: وسم، تغيير الحالة، إضافة إلى قائمة وظيفة، وتصدير بريد إلكتروني. أضف إشعار تراجع واظهر عدد السجلات التي ستتغير قبل التأكيد.
اجعل الواجهة صديقة للوحة المفاتيح (حالات التركيز، ترتيب تاب منطقي) وقابلة للقراءة (تباين جيد، أهداف نقر كبيرة). على المحمول، أولي أهمية لتدفق القائمة → التفاصيل، احتفظ بالمرشحات في لوحة منزلقة، وتأكد أن الإجراءات الأساسية (إضافة للقائمة، إرسال بريد، تغيير الحالة) قابلة للوصول بإبهام واحد.
المطابقة هي محرك تطبيق التوظيف: يقرر من يظهر أولًا، من يختفي، وما يثق المجندون به. يبدأ MVP الجيد ببساطة — قواعد واضحة أولًا، ثم التقييم — ثم يضيف التعقيد أثناء التعلم من نتائج التوظيف الحقيقية.
ابدأ بغير قابلة للتفاوض يجب أن تكون صحيحة قبل اعتبار المرشح. هذه القواعد تُبقي النتائج ذات صلة وتمنع "مطابقات عالية النقاط لكنها مستحيلة".
البوابات النموذجية تشمل مهارات/شهادات مطلوبة، قيود الموقع أو تصريح العمل، وتقاطع الراتب (مثلاً، يجب أن يتقاطع توقع المرشح مع ميزانية الوظيفة).
بعد تمرير المرشح للبوابات، احسب درجة لفرز النتائج. اجعل النسخة الأولى شفافة وقابلة للتعديل.
خليط تقييم عملي:
يمكنك التعبير عن ذلك كدرجة موزونة (الأوزان تُعدل مع الوقت):
score = 0.45*skill_match + 0.20*recency + 0.20*seniority_fit + 0.15*keyword_similarity
نمذج متطلبات الوظيفة في صندوقين:
هذا يمنع استبعاد مرشحين أقوياء بسبب تفضيلات بينما يكافئ الملاءمة الأفضل.
المجندون بحاجة لمعرفة لماذا تطابق مرشح — ولماذا لم يفعل. اعرض تحليلًا مختصرًا على بطاقة المطابقة:
قابلية الشرح تحول المطابقة من صندوق أسود إلى أداة يمكن للمجندين ضبطها والدفاع عنها أمام مديري التوظيف.
جودة بيانات المرشحين هي الفرق بين "مطابقة" و"تخمين". إن وصلت الملفات بتنسيقات غير متسقة، فحتى أفضل خوارزمية ستنتج نتائج صاخبة. ابدأ بتصميم مسارات إدخال سهلة للمجندين والمرشحين، ثم حسّن التحليل والتطبيع تدريجيًا.
قدّم طرقًا متعددة لإنشاء ملف مرشح حتى لا يتعطل الفريق:
ضع مؤشر «ثقة» واضحًا على الحقول (مثل: "مُحلّل"، "مدخل من المستخدم"، "مؤكّد من المجند") حتى يعرف المجند ماذا يثق.
في MVP، قدم الاعتمادية بدلًا من البنية المثالية:
دائمًا دع المجندين يحررون الحقول المُحلَّلة واحتفظ بمسار تدقيق للتغييرات.
تعمل المطابقة أفضل عندما تُطابق «JS»، «JavaScript»، و"Javascript" إلى نفس المهارة. استخدم قاموسًا مسيطرًا به:
طبق التطبيع عند الحفظ (وأعد تشغيله عند تحديث القاموس) حتى يبقى البحث والمطابقة متسقين.
التكرارات ستسمم مؤشرات خط الأنابيب بهدوء. اكتشف التكرارات المحتملة باستخدام البريد الإلكتروني والهاتف (بالإضافة إلى فحوصات تقريبية على الاسم + الشركة). عند ظهور تعارض، اعرض شاشة دمج موجهة تُظهِر:
هذا يحافظ على قاعدة بيانات نظيفة دون مخاطرة فقدان بيانات غير مقصود.
تطبيق المطابقة جيد بقدر جودة الوظائف داخله. إن كانت الطلبات غير متسقة أو مفقودة، يتوقف المجندون عن الثقة في النتائج. الهدف: جعل إدخال الوظائف سريعًا، مُنظمًا، وقابلًا للتكرار دون إجبار ملء استمارات طويلة.
المجندون عادة يبدأون الوظائف بثلاث طرق:
عالج "تكرار وظيفة" كإجراء من الدرجة الأولى في قائمة الوظائف، وليس خيارًا مخفيًا.
أوصاف الوظائف النصية مفيدة للبشر، لكن المطابقة تحتاج بنية. التقط المتطلبات في حقول متسقة:
اجعلها خفيفة الوزن: يجب أن يستطيع المجند إضافة مهارات في ثوانٍ ثم تحسينها لاحقًا. إن كان لديك خطوة تحليل، استخدمها لاقتراح الحقول — لا للحفظ التلقائي.
اجعل خط التوظيف صريحًا ومخصصًا لكل وظيفة. الافتراضي البسيط يعمل جيدًا:
جديد → مختصر → مقدم → مقابلة → عرض → تم التعيين
يجب أن يخزن كل علاقة مرشح-وظيفة المرحلة الحالية، تاريخ المراحل، المالك، والملاحظات. هذا يوفر مصدر حقيقة مشترك للمجندين ويجعل تحليلاتك ذات معنى.
القوالب تساعد الوكالات على توحيد الإدخال للأدوار الشائعة (مثل "مندوب تطوير مبيعات" أو "عامل مخزن"). يجب أن تملأ القالب المراحل، أسئلة الفرز، والمهارات الضرورية نموذجيًا — مع السماح بتعديلات سريعة لكل عميل.
إن أردت تدفقًا ثابتًا، وجه إنشاء الوظيفة مباشرة إلى المطابقة والقائمة المختصرة، ثم إلى خط الأنابيب بدلًا من تشتت هذه الخطوات عبر شاشات متعددة.
الأمان أسهل عند تصميمه منذ البداية. هدف تطبيق التوظيف بسيط: الأشخاص المناسبون فقط يمكنهم الوصول لبيانات المرشحين، وكل تغيير مهم قابل للتتبع.
ابدأ ببريد إلكتروني + كلمة مرور، مع إعادة تعيين كلمة المرور والتحقق من البريد الإلكتروني. أضف بعض الحمايات العملية حتى في MVP:
للوكالات الكبيرة، خطط لمسار ترقية مستقبلي إلى SSO (SAML/OIDC) للعمل مع Google Workspace أو Microsoft Entra ID. لا تحتاج لبناء SSO من اليوم الأول، لكن تجنب اختيارات تجعل إضافته صعبًا لاحقًا.
على الأقل عرّف دورين:
إذا شملت بوابة للعملاء/مديري التوظيف، عاملها كمجموعة أذونات منفصلة. يحتاج العملاء عادة وصولًا محدودًا (مثلاً، فقط المرشحين المقدمين لوظائفهم، مع حجب بعض التفاصيل الشخصية طبقًا لنموذج الخصوصية).
قاعدة جيدة: الافتراضي أقل صلاحية، وأضف الأذونات عن قصد (مثل "يمكنه تصدير المرشحين"، "يمكنه رؤية حقول التعويض").
التوظيف يتضمن كثيرًا من التناقلات، لذلك يسجل تتبع النشاط الخفيف يمنع الالتباس ويبني ثقة داخلية. سجّل إجراءات رئيسية مثل:
اجعل هذه السجلات قابلة للبحث داخل التطبيق، واحمها من التعديل.
السير الذاتية حساسة. خزّنها في تخزين كائنات خاص (ليس روابط عامة)، وامنح روابط تنزيل موقعة/منتهية الصلاحية، وامسح المرفقات بحثًا عن برامج خبيثة. قيد الوصول بحسب الدور، وتجنب إرسال المرفقات عبر البريد عندما يكون رابط آمن داخل التطبيق كافيًا.
أخيرًا، شفر البيانات في النقل (HTTPS) وعند الإمكان في الراحة، واجعل الإعدادات الأمنية الافتراضية غير اختيارية لمساحات العمل الجديدة.
تتعامل تطبيقات التوظيف مع بيانات حساسة — سير ذاتية، معلومات اتصال، تعويض، ملاحظات مقابلة. إن لم يثق المرشح بكيفية التخزين والمشاركة، فلن يتفاعل، وتتعرض الوكالات لمخاطر قانونية. اعتبر الخصوصية والامتثال ميزات أساسية، وليس إضافات.
تعتمد الوكالات والمناطق على أسس قانونية مختلفة (موافقة، مصلحة مشروعة، عقد). ابنِ متتبعًا قابلًا للتكوين على كل سجل مرشح يلتقط:
اجعل مراجعة وتحديث الموافقة سهلًا، وتأكد أن إجراءات المشاركة (إرسال ملفات للعملاء، التصدير، الإضافة إلى حملات) تتحقق من هذه الإعدادات.
أضف إعدادات احتفاظ على مستوى الوكالة: كم من الوقت تُحتفظ بالمرشحين غير النشطين، المتقدمين المرفوضين، وملاحظات المقابلة. ثم نفّذ تدفقات واضحة:
اجعل هذه الأفعال قابلة للتدقيق وقابلة للاسترجاع فقط عند المناسب.
ادعم تصدير سجل مرشح لطلبات الوصول. اجعلها بسيطة: تصدير JSON منظم بالإضافة إلى ملخص قابل للقراءة (PDF/HTML) يغطي معظم الاحتياجات.
استخدم تشفير في النقل وفي الراحة، بيئات منفصلة، وإدارة جلسات قوية. افترض الحقوق الأدنى: لا ينبغي أن يرى المجندون التعويض، الملاحظات الخاصة، أو كل التقديمات تلقائيًا. أضف سجل تدقيق لعمليات العرض/التصدير/المشاركة، واربط تفاصيل السياسة من /privacy حتى تشرح الوكالات ضماناتك للمرشحين.
التكاملات تقرر ما إذا كان تطبيقك يتناسب مع يوم المجند — أو يصبح "تبويبًا آخر". اهدف لمجموعة صغيرة من الاتصالات ذات التأثير الكبير أولًا، واحتفظ بكل شيء خلف طبقة API نظيفة لتضيف المزيد دون إعادة كتابة سير العمل.
ابدأ بالبريد لأنه يدعم التواصل مباشرة ويخلق سجل نشاط ثمين.
اتصل بـ Gmail وMicrosoft 365 لتتمكن من:
اجعل التسجيل صريحًا حتى يختار المجند أي سلاسل تُسجل في نظامك. خزّن بيانات وصفية للرسائل (الموضوع، الطابع، المشاركون) ونسخة آمنة من الجسم للبحث.
يمكن أن ينتظر التكامل مع التقويم إذا كان يهدد جدولك، لكنه ترقية قوية. مع Google Calendar / Outlook Calendar يمكنك إنشاء مواعيد مقابلات، اقتراح أوقات، وكتابة نتائج المقابلة في مرحلة خط الأنابيب.
للإصدارات الأولى، ركز على: إنشاء أحداث + إضافة الحضور + كتابة تفاصيل المقابلة مرة أخرى إلى مرحلة المرشح.
العديد من الوكالات تستخدم بالفعل ATS/CRM. قدم webhooks للأحداث الرئيسية (تم إنشاء/تحديث مرشح، تغيير مرحلة، جدولة مقابلة) ووثق نقاط نهاية REST بوضوح ليتمكّن الشركاء من الربط بسرعة. فكّر في صفحة مخصصة مثل /docs/api وشاشة إعدادات "التكامل" بسيطة.
النشر على لوحات الوظائف والطلبات الواردة قوية، لكنها تزيد التعقيد (سياسات الإعلانات، طلبات مكررة، تتبع المصدر). عاملهم كمرحلة 2:
صمم نموذج البيانات الآن بحيث تكون "المصدر" و"قناة التقديم" حقولًا متمركزة لاحقًا.
يجب أن توازن كومة التكنولوجيا بين سرعة إطلاق MVP وترك مجال لتحسين البحث والتكاملات لاحقًا. لتطبيقات التوظيف حاجتان مميزتان: سير عمل معاملات (الخطوط الأنابيب، الأذونات، سجلات التدقيق) وبحث/ترتيب سريع (مطابقة المرشحين بالوظائف).
لمكدسة JavaScript حديثة، React + Node.js (NestJS/Express) خيار شائع: لغة واحدة للواجهة والخلفية، مكتبات سوق التوظيف كثيرة، وتكاملات سهلة.
إن رغبت بتطوير CRUD بسرعة وبمفاهيم ثابتة، Rails أو Django ممتازتان لبناء سير عمل ATS/CRM بقليل من القرارات. اقترن بأيٍ منهما بواجهة خفيفة (Views/التيمبليتس) أو React عند الحاجة لواجهة غنية.
إن كان عنق الزجاجة سرعة النماذج الأولية (خصوصًا للأدوات الداخلية أو التحقق المبكر)، منصات بناء سريعة يمكن أن تساعد في بناء MVP من مواصفات دردشة منظمة: الشاشات الأساسية، سير العمل، ونموذج بيانات أساسي. تستخدم الفرق هذه المنصات للتكرار السريع ثم تصدير الشيفرة عندما تكون جاهزة لأخذ المشروع داخليًا.
استخدم قاعدة بيانات علاقية (غالبًا PostgreSQL) كمصدر حقيقة. بيانات التوظيف تحتوي على الكثير من العمل على سير العمل: مرشحين، وظائف، مراحل، ملاحظات، مهام، رسائل، وأذونات تستفيد من المعاملات والقيود.
نمذج "المستندات" (السير الذاتية، المرفقات) كملفات مخزنة (تخزين متوافق مع S3) مع بيانات وصفية في Postgres.
ابدأ بـ بحث نص كامل في Postgres لعمليات الكلمات المفتاحية والمرشحات. كثيرًا ما يكفي MVP ويتفادى تشغيل نظام آخر.
عندما تصبح المطابقة والبحث عنق زجاجة (ترتيب معقد، مرادفات، استعلامات تقريبية، حجم عالٍ)، أضف Elasticsearch/OpenSearch كمؤشر مخصص — يُغذى بشكل غير متزامن من Postgres.
حافظ على بيئتين منفصلتين staging وproduction لاختبار التحليل، المطابقة، والتكاملات بأمان.
أعد نسخ احتياطية آلية، مراقبة أساسية (أخطاء، زمن استجابة، عمق قوائم الانتظار)، وضوابط تكلفة (مدة الاحتفاظ بالسجلات، قياس حجم الخوادم). هذا يبقي النظام متوقعًا مع زيادة عدد المجندين والبيانات.
تتحسن المطابقة عندما تقيس النتائج وتلتقط "لماذا" وراء قرارات المجند. الهدف ليس مقاييس تجميلية — بل حلقة ضيقة حيث كل قائمة مختصرة، مقابلة، وتعيين تحسّن توصياتك.
ابدأ بمجموعة صغيرة من المؤشرات المرتبطة بأداء الوكالة:
اجعل المؤشرات قابلة للتصفية حسب العميل، نوع الدور، الدرجة، والمجند لجعل الأرقام قابلة للتنفيذ بدلًا من عامة.
أضف ملاحظات خفيفة حيث تحدث القرارات (في قائمة المطابقة وصفحة المرشح): إعجاب/عدم إعجاب، مع أسباب اختيارية (مثل "عدم توافق الراتب"، "مفقود شهادة"، "تصريح/فيزا"، "خبرة صناعية"، "استجابة ضعيفة").
اربط الملاحظات بالنتائج:
يمكنك مقارنة التقييم مع الواقع وضبط الأوزان أو القواعد بناءً على أدلة.
اصنع بعض التقارير الافتراضية:
يجب أن تجيب اللوحة على "ما الذي تغيّر هذا الأسبوع؟" في شاشة واحدة، ثم تسمح بالتفصيل. اجعل كل جدول قابل للتصدير إلى CSV/PDF لتحديثات العملاء ومراجعات داخلية، واظهر تعريفات المقاييس (باستخدام تلميح أو /help) حتى يقرأ الجميع المقاييس بنفس الطريقة.
ينجح تطبيق التوظيف عندما يعمل بثبات على أدوار حقيقية ومرشحين وأطر زمنية حقيقية. اعتبر الإطلاق بداية للتعلم—لا خط النهاية.
قبل دعوة المستخدمين الأوائل، تأكد أن الأساسيات ليست مبنية فقط، بل قابلة للاستخدام بشكل كامل:
لا تحتاج إلى مجموعة اختبار هائلة، لكن تحتاج للاختبارات الصحيحة:
اختبر مع 1–3 وكالات (أو فرق داخلية) تعطِك ملاحظات أسبوعية. عرّف مقاييس النجاح مقدمًا: الوقت إلى القائمة المختصرة، تقليل الرسائل ذهابًا وإيابًا، وثقة المجندين في شرح المطابقة.
اتبع دورة أسبوعين: جمع القضايا، إصلاح أهم العقبات، وإصدار تحسينات. انشر تغييرات في سجل تغييرات خفيف (/blog).
عندما يستقر سير العمل الأساسي، أولوياتك:
مع إضافة مستويات (بوابة العميل، التكاملات، تحليلات متقدمة)، احفظ تغليف المزايا واضحًا على /pricing.
ابدأ بحلقة مغلقة يمكن للمجند إتمامها يوميًا:
إذا كان ميزة لا تدعم مباشرة هذه الحلقة (مثل نشر الوظائف على لوحات الوظائف، أو أتمتة معقدة، أو بوابة لمديري التوظيف)، أرجئها للمرحلة الثانية.
اختر 2–3 «المهام الأساسية» لكل مستخدم رئيسي واصمم حولها.
إذا أضفت مديري التوظيف في الإصدار الأول، خطط لنموذج الأذونات وقواعد الإشعارات مبكرًا.
استخدم مقاييس قابلة للقياس مرتبطة بسير العمل بدلًا من «مطابقات أفضل». بداية جيدة:
تساعد هذه المقاييس أيضًا في التحقق مما إذا كانت تغييرات التقييم تحسن النتائج.
اجعل الكيانات الأساسية بسيطة ونمذج سير العمل كعلاقات:
يحافظ هذا على اتساق المطابقة، والتقارير، وسجلات التدقيق مع نمو المزايا.
افصل ما تخزنه عما تبحث عنه:
هذا يمنع أخطاء التحليل من استبدال بيانات وافق عليها المجند ويُحسّن جودة المطابقة مع الوقت.
ابدأ بقواعد شفافة أولًا ثم أضف التقييم:
اجعل الأوزان قابلة للتعديل واظهر "لماذا تطابق المرشح" على كل نتيجة. الشرحية هي ما يجعل المجندين يثقون بالنظام.
نمذج المتطلبات في دلوين:
بهذه الطريقة لا تُستبعد المرشحين الأقوياء بسبب تفضيلات، بينما يحصل المطابق الأفضل على نقاط أعلى.
ابنِ الأذونات في كل مسار قراءة/كتابة (بما في ذلك البحث والمطابقة):
افترض الأقل صلاحية كإعداد افتراضي وأضف القدرات عن قصد (مثل «يمكنه تصدير المرشحين»).
عامل الامتثال كميزة منتجية:
اربط سياساتك بصفحة مثل /privacy واحفظ كل الإجراءات الحساسة قابلة للتدقيق.
أطلق المنتج مع موثوقية وقدرة على التعلم:
أصدر تغييرات صغيرة تكراريًا واحتفظ بسجل تغييرات خفيف (/blog).