العودة إلى المدونة
29 سبتمبر 2026Sergei Solod10 دقائق قراءة

بدأت مدونة تقنية من دون خطة للربح، ثم وجدها موقع هندسي ياباني

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

التدوين التقنيالتطوير بمساعدة الذكاء الاصطناعيهندسة البرمجياتChatGPTتجربة المطور

لفترة طويلة، لم أكن متأكدًا أصلًا من أن هذا الموقع يحتاج إلى مدونة.

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

بعد ذلك، قد يبدو من غير الضروري كتابة بضعة آلاف كلمة أخرى.

من سيقرأها؟

ماذا سأحصل من ذلك؟

لماذا لا أحل المشكلة وأنتقل إلى غيرها؟

في النهاية وجدت إجابة كانت كافية بالنسبة لي: بعض هذا العمل مكلف أكثر من أن أسمح له بالضياع.

قد تحتوي المشكلة الصعبة على مقالة كاملة قبل أن أدرك ذلك

مقالاتي لا تبدأ عادة بفكرة: «أحتاج إلى تدوينة هذا الأسبوع».

إنها تبدأ بمشكلة.

أحيانًا تأتي المشكلة من عملي، وأحيانًا من أحد مشاريعي الخاصة، وأحيانًا يثير اهتمامي شيء لا أفهمه فأواصل البحث فيه حتى يصبح فهمي له أعمق بكثير.

وقد قادتني معالجة الصور إلى كثير من هذه الحفر العميقة.

في البداية قد تبدو المهمة بسيطة إلى حد السذاجة:

خذ هذه الصور واجعلها أصغر حجمًا.

يمكنك أن تطلب من نموذج ذكاء اصطناعي سكربتًا وتحصل عليه تقريبًا فورًا.

لكن هذا لا يعني أن لديك خط معالجة صور جيدًا.

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

كون السكربت يعمل بنجاح لا يعني أنه أصبح نظامًا أثق به.

ومن هذا الفرق تأتي كثير من مقالاتي.

سير عملي مع الذكاء الاصطناعي أبطأ بكثير من مجرد «اسأل ChatGPT عن الإجابة»

أستخدم حساب ChatGPT مدفوعًا بكثافة أثناء العمل على مشكلات كهذه.

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

في بعض التحقيقات العميقة جدًا تراكم لدي أكثر من 100 ساعة عمل حول المشكلة العامة نفسها.

هذا لا يعني أنني أقضي 100 ساعة في انتظار نموذج ذكاء اصطناعي ليكتشف الإجابة بالسحر.

العملية تكرارية.

وغالبًا ما تبدو بهذا الشكل:

  1. أصف المشكلة.
  2. يقترح النموذج حلًا أوليًا.
  3. أشغله على بيانات حقيقية.
  4. أجد أن شيئًا ما ضعيف أو غير كفء أو خاطئ ببساطة.
  5. أعيد الأدلة إلى المحادثة.
  6. نغير النهج.
  7. أختبره مرة أخرى.
  8. تظهر حالة طرفية جديدة.
  9. ثم نكرر.

وقد تتكرر هذه الدورة مرات كثيرة.

النتيجة المفيدة غالبًا ليست السكربت الأول، بل مجموعة الإخفاقات والقياسات والتصحيحات والقرارات التي تراكمت حوله.

الذكاء الاصطناعي جعل نقطة البداية رخيصة، لكنه لم يجعل التحقق رخيصًا

وهذا أحد أسباب اعتباري النقاش المعتاد حول المحتوى التقني المكتوب بالذكاء الاصطناعي مبسطًا أكثر من اللازم.

نعم، يمكن للنموذج أن ينتج شرحًا يبدو معقولًا بسرعة شديدة.

ويمكنه أيضًا إنتاج كود يبدو منطقيًا تمامًا لكنه يخطئ تحديدًا في الحالات التي تهم.

في المشكلات التقنية الضيقة، نادرًا ما أريد أول إجابة تبدو معقولة. أريد أن أعرف ماذا يحدث عندما أشغلها فعليًا.

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

وإذا كان السكربت سيعمل في النهاية على مجموعة ضخمة، يصبح هذا العمل أكثر أهمية.

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

تكلفة توليد الكود انهارت.

أما تكلفة تحديد ما إذا كان هذا الكود يستحق التشغيل على نطاق واسع فلم تنهَر.

المحادثة مادة بحثية وليست المقالة النهائية

بعد تحقيق طويل من هذا النوع، قد يحتوي سجل المحادثة على كمية هائلة من المعلومات.

قد تجد فيه:

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

ترك كل ذلك داخل محادثة خاصة واحدة يبدو تبذيرًا.

لذلك أستخرج الأجزاء المفيدة وأحولها إلى مقالة.

المقالة ليست نسخة من المحادثة، ومعظم المحادثة لا ينبغي أن تتحول إلى مقالة أصلًا.

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

هذه الخطوة التحريرية مهمة.

يمكن للذكاء الاصطناعي المشاركة فيها، لكن الأدلة ما زالت تأتي من العمل نفسه.

معالجة الصور علمتني إلى أي مدى يمكن أن تصبح المشكلة «البسيطة» عميقة

تحسين الصور هو على الأرجح أوضح مثال من عملي.

قضيت فيه وقتًا كافيًا حتى تحول ما بدا أولًا مجموعة إعدادات لمُرمّز إلى مشكلة أنظمة أكبر بكثير.

تتغير الأسئلة بسرعة.

ما صيغة المصدر التي أتعامل معها؟

هل المحتوى متحرك؟

هل ينبغي تغيير الأبعاد؟

كيف أختار الجودة؟

أي مقياس يجب أن يقرر ما إذا كان فقدان الجودة مقبولًا؟

هل تعمل عتبة جودة واحدة على صور مختلفة تمامًا؟

كيف أتجنب التكبير؟

أي بيانات وصفية يجب أن تبقى؟

ماذا يحدث للشفافية؟

كيف يجب التحقق من المخرجات؟

هل يبرر الملف الأصغر تكلفة الترميز الإضافية فعلًا؟

ماذا يحدث عندما تتغير مجموعة المدخلات؟

لهذا أشك في سكربتات «تحسين الصور النهائي» ذات الأسطر الخمسة.

هي بالتأكيد تستطيع معالجة صورة.

لكن هذا مختلف عن بناء خط معالجة تفهم تنازلاته.

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

المثير للاهتمام ليس إعلان فوز صيغة واحدة.

بل فهم عبء العمل بما يكفي لاتخاذ القرار بوعي.

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

ثم وجد موقع ياباني المدونة

لم أكن أتوقع عائدًا معينًا من نشر هذه المقالات.

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

ثم حدث شيء لم أتوقعه فعلًا.

في 17 سبتمبر 2026، نشر الموقع الياباني Levtech Freelance مجموعة بعنوان يقارب «مدونات موصى بها للمهندسين الذين يريدون تطوير مهاراتهم».

وأدرج مقال Levtech Freelance مدونة JSVar إلى جانب عدة مدونات هندسية أخرى.

Levtech جزء من منظومة يابانية كبيرة مرتبطة بمهن تقنية المعلومات، ويركز Levtech Freelance على دعم مهندسي تقنية المعلومات المستقلين ومطابقتهم مع الفرص. بالنسبة لي، لم يكن الجزء المثير مجرد الحصول على رابط خلفي، بل رؤية الأجزاء من عملي التي اعتبر فريق تحرير خارجي أنها تستحق الوصف.

وقد أبرز قسمهم عن JSVar ثلاث مقالات بصورة خاصة.

إحداها عن سبب اعتقادي أن Codex وTypeScript يعملان جيدًا معًا في التطوير الإنتاجي، خصوصًا لأن أنواع TypeScript وملاحظات المترجم يمكن أن تكشف مشكلات في الكود المولد.

والثانية عن ترجمة المدونة إلى 20 لغة باستخدام ChatGPT، ورؤية زوار من البحث يصلون مباشرة إلى صفحات مترجمة من دول مختلفة.

أما الثالثة فكانت تجربتي في نشر 10,000 صفحة SEO مولدة بالذكاء الاصطناعي، والتي تحولت في النهاية إلى قصة عن الفشل بدل النمو السهل.

أضحكني هذا الاختيار لأن المقالات الثلاث مختلفة جدًا، لكنها تشترك في نمط واحد.

كلها مبنية على شيء فعلته بالفعل.

لا أعرف بالضبط كيف وجدني Levtech

هناك قصة مغرية يمكن سردها هنا.

أنا لا أتحدث اليابانية.

موقعي له نسخة يابانية.

منشور هندسي ياباني وجد الموقع.

إذن ترجمة المدونة إلى اليابانية هي التي جعلت Levtech يكتشفها.

لا أستطيع إثبات ذلك.

ربما ساعدت الصفحات اليابانية.

وربما قادهم البحث إلى مقالة إنجليزية.

وربما شارك شخص ما رابطًا.

وربما وصلوا إلى الموقع بطريقة مختلفة تمامًا.

لا أملك بيانات الإسناد اللازمة، ولذلك لن أصنع من ذلك دراسة SEO نظيفة لا تدعمها الأدلة.

ما أستطيع تأكيده أبسط بكثير: نشرت المدونة بعدة لغات، ثم وجدها منشور ياباني مثيرة للاهتمام بما يكفي لإدراجها في مجموعة تحريرية.

وهذه نتيجة جيدة بالفعل.

وهي مرضية بصورة خاصة لأن التوطين كان بدوره تجربة بدت في البداية كثيرة الجهد مقابل عائد غير مؤكد.

كان الظهور مهمًا لأنه جاء كتأكيد مستقل

لا أقصد بكلمة «تأكيد» أن Levtech أثبت أن كل ما أكتبه صحيح.

هم لم يدققوا قاعدة الكود لدي، ولم يعيدوا تنفيذ كل تجربة.

المهم كان أمرًا أكثر تواضعًا.

شخص على الجانب الآخر من العالم، يكتب لجمهور لا أستطيع مخاطبته بلغته بنفسي، وجد قيمة كافية في العمل كي يلخصه لقرائه.

لم أعرض عليهم الفكرة.

ولم أكتب المقالات الأصلية من أجل Levtech.

ولم أتوقع الظهور في مجموعة يابانية.

لهذا تبدو النتيجة ذات معنى بالنسبة لي.

وهي توحي بأن المقالة التقنية شديدة التخصص لا تحتاج بالضرورة إلى جمهور ضخم كي تستحق النشر.

يكفي أن تكون مفيدة للقارئ المناسب.

هل ينبغي للمطور أن يبدأ مدونة في 2026؟

بالنسبة لي، نعم — لكن بشرط مهم.

يجب أن تكون راغبًا فعلًا في كتابة شيء.

لن أوصي ببدء مدونة تقنية لأن شخصًا أخبرك أن كل مطور يحتاج إلى «علامة شخصية».

ولن أبدأها لأنني أتوقع دخلًا سلبيًا.

ولن أنشئها فقط لأملأها بتفسيرات عامة لتقنيات لديها أصلًا وثائق أفضل.

لكن إذا كان عملك ينتج باستمرار أشياء كنت تتمنى أن تجدها عندما بدأت، فهذا مختلف.

اكتبها.

اكتب عن عطل الإنتاج الغريب.

اكتب عن التحسين الذي استغرق ثلاثة أيام أكثر مما توقعت.

اكتب عن الاختبار الذي ناقض افتراضك.

اكتب عن النهج الذي بدا أنيقًا ثم فشل.

اكتب عن التنفيذ النهائي، لكن اشرح أيضًا لماذا لم يكن التنفيذ الواضح كافيًا.

هذه هي الأجزاء التي يصعب تصنيعها من المعرفة العامة وحدها.

الذكاء الاصطناعي يعطيني مادة أكثر للكتابة، لا أقل

لم يجعلني الذكاء الاصطناعي أعتقد أن المدونات التقنية أصبحت قديمة.

بالنسبة لي حدث العكس تقريبًا.

أستطيع استكشاف أفكار أكثر لأن الحصول على تنفيذ أولي أو تفسير أصبح أسرع من السابق.

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

هذه المادة الخام لا تصبح ذات قيمة إلا بعد أن يقوم شخص بالعمل اللازم لتحديد ما هو صحيح وما هو مهم.

محادثة ذكاء اصطناعي تحتوي 500 رسالة ليست معرفة تلقائيًا.

أما سكربت ينجو في النهاية من الاختبار الحقيقي، مع شرح للنسخ العشرين التي لم تنجح، فقد يكون معرفة فعلًا.

هذا الفرق هو ما أريد للمدونة أن تحفظه.

النشر هو طريقتي لمنع العمل المفيد من الاختفاء

معظم العمل التقني مؤقت بصورة مدهشة.

يُصلح الخطأ الصعب.

تُغلق الطرفية.

ينجح النشر.

وتهبط المحادثة إلى أسفل سجل الدردشات.

بعد ستة أشهر، قد لا أتذكر حتى أنا لماذا يبدو التنفيذ النهائي بهذه الطريقة.

الكتابة تغير ذلك.

تجبرني على إعادة بناء التفكير بينما ما زالت الأدلة موجودة.

وتنشئ شيئًا قابلًا للبحث.

وتمنحني مرجعًا لعملي المستقبلي.

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

ما زال ليس لدي سبب معقد للحفاظ على هذه المدونة.

أنا أحب التعلم.

وأحب بناء الأشياء.

وأحب التعمق أكثر من اللازم في مشكلات بدت بسيطة في البداية.

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

هذا سبب كاف بالنسبة لي للنشر.

وإذا كان عملك ينتج النوع نفسه من المعرفة التي تُكتسب بصعوبة، فأعتقد أنه قد يكون سببًا كافيًا لك أيضًا.