استخدام الذكاء الاصطناعي في اكسل: صيغة حقيقية وتنظيف عمود

استخدام الذكاء الاصطناعي في اكسل يعني أنك تصف المهمة بجملة عادية لمساعد محادثة مثل ChatGPT أو Claude، فيكتب لك الصيغة أو خطوات التنظيف جاهزة تنسخها في الخلية.

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

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

جرّبتُ الاثنين على ملف بيانات واحد: صيغة جمع مشروط، وصيغة بحث، وتنظيف عمود حالة دفع فوضوي، وتحقّقتُ من كل رقم بطريقة ثانية مستقلة قبل أن أكتبه هنا.

كيف تطلب من الذكاء الاصطناعي صيغة اكسل صحيحة؟

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

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

الصيغة التي كتبها:

=SUMIF(C2:C11,"القاهرة",G2:G11)

فتحت الملف ووضعتها في خلية فارغة، فظهرت ٢٧٥٠. لم أكتفِ بالرقم الذي أظهرته الصيغة؛ جمعتُ نفس الصفوف الخمسة يدويًا (٥٤٠ + ٤٢٠ + ٤٤٠ + ١٠٥٠ + ٣٠٠)، وجمّعتها مرة ثانية بمكتبة pandas في Python على نفس الملف. الطرق الثلاث اتفقت على ٢٧٥٠.

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

مهمة بحث على نفس الملف

طلبتُ من المساعد مهمة ثانية مختلفة: صيغة ترجع سعر الوحدة لمنتج معين باسمه، لأن «سماعة بلوتوث» ظهرت مرتين في الملف بسعرين قد يكونان مختلفين. كتب:

=XLOOKUP("سماعة بلوتوث",D2:D11,F2:F11)

هذه الصيغة ترجع أول تطابق تجده، وهذا تفصيل يسهل تفويته: لو كان سعر المنتج اختلف بين الصفين لأي سبب، كانت الصيغة ستُظهر سعر الصف الأول فقط دون أن تنبهك أن هناك صفًا ثانيًا بسعر مختلف. تحققتُ من هذا الاحتمال بنفسي قبل أن أثق بالنتيجة: بحثتُ يدويًا عن كل الصفوف التي فيها نفس اسم المنتج في الملف الخمسة أزواجها، وقارنت سعريهما. في بيانات تجربتي كان السعر متطابقًا في كل زوج، فأعطت الصيغة ٣٥٠ وهو صحيح، لكن النتيجة كانت ستبقى ٣٥٠ أيضًا لو كان الصف الثاني بسعر مختلف، وهذا فرق بين صيغة «صحيحة الصياغة» وصيغة «تجيب على سؤالك الحقيقي».

لماذا تُخرج الصيغة الصحيحة رقمًا خاطئًا؟

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

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

كيف تطلب تنظيف عمود فوضوي قبل أي حساب عليه؟

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

تحققتُ من النتيجة بقراءة كل صف بعيني ومقارنته بما قرره التنظيف؛ توافقت القراءتان على ستة طلبات مدفوعة وأربعة غير مدفوعة. هذه الخطوة ليست شكلية. أي صيغة شرطية تبني عليها لاحقًا، سواء SUMIF لجمع المدفوع فقط أو COUNTIF لعدّ غير المدفوع، سترث نفس الخطأ إن بنيتها على العمود الخام مباشرة.

متى تحتاج تنظيفًا ومتى لا

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

كيف تتحقق أن النتيجة صحيحة قبل أن تثق بها؟

القاعدة التي اتبعتها في التجربتين واحدة: لا تثق برقم خرج من صيغة واحدة فقط، احسبه بطريقة مستقلة تمامًا. في صيغة SUMIF جمعتُ الصفوف يدويًا وأعدت حسابها ببرنامج منفصل. لعمود منظّف، قارنتُ النتيجة بقراءة كل صف بعيني. في ملف حقيقي أكبر من عشرة صفوف، الطريقة المكافئة هي جدول محوري (Pivot Table) يجمع نفس العمود بطريقة مختلفة تمامًا عن الصيغة، أو عيّنة عشوائية من عشرين صفًا تتحقق منها يدويًا وتقارنها بما تقوله الصيغة على نفس العيّنة.

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

ما الفرق بين أن يكتب الذكاء الاصطناعي الصيغة وأن يرى هو ملفك؟

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

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

هل يصلح الذكاء الاصطناعي لكل صيغ اكسل؟

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

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

ما لا يغطّيه هذا الدليل

• لا يغطي Power Query أو Power Pivot، وهما أدوات مختلفة داخل اكسل لها منطق تنظيف وتجميع خاص بها يستحق دليلًا منفصلًا.
• لا يغطي المساعدات المدمجة داخل اكسل نفسها بالتفصيل، لأنها تحتاج اشتراكًا وتجربة منفصلة على نفس الملف لأقارنها بأمانة بمساعد المحادثة العادي.
• لا يغطي كتابة أكواد VBA أو الماكرو الطويلة؛ التجربة هنا اقتصرت على صيغ الخلايا المباشرة.
• لا يغطي ملفات بآلاف الصفوف؛ طريقة التحقق بالعيّنة العشوائية التي ذكرتها تصلح بداية، لكن ملفًا بهذا الحجم يحتاج أدوات تحقق آلية لا يسعها مقال واحد.

أسئلة يطرحها الناس

هل أقدر أرفع ملف اكسل للذكاء الاصطناعي مباشرة؟

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

هل الذكاء الاصطناعي يكتب كود VBA؟

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

هل في فرق بين أن أطلب صيغة بالعربي أو الإنجليزي؟

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

هل أقدر أثق في الصيغة من أول مرة بلا تحقق؟

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