كيفية تحويل مستند Word إلى نص بشري داخل Claude Code

توفّر HumanPen خادم MCP محليًا من نوع stdio. يشغّل كل عميل الأمر نفسه، `npx -y humanpen-mcp`، مع متغير بيئة واحد يحمل مفتاح API. يمرّر الوكيل مسارًا مطلقًا إلى ملف `.docx` بدلًا من نصه، حتى لا يدخل المستند إلى نافذة السياق أبدًا، ويُعاد الملف المُعالَج إلى القرص.

لا توجد نقطة وصول بعيدة، ولا طبقة بوابة أمامه. إن كنت قد استخدمت `mcp-remote` أو `supergateway` مع خوادم أخرى، فلن تحتاج إلى أيٍّ منهما هنا.

التصميم البديهي هو قبول سلسلة نصية وإعادة سلسلة نصية. وهو كذلك التصميم الذي ينهار تحديدًا على المستندات التي يريد القراء إعادة كتابتها فعلًا.

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

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

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

يدويًا، الأمر في Claude Code سطر واحد:

claude mcp add humanpen -s user -e HUMANPEN_API_KEY=hp_your_key -- npx -y humanpen-mcp

للخيار `-s user` أهمية أكبر مما يبدو. النطاق الافتراضي هو `local`، وهو لا يسجّل الخادم إلا للمجلد الذي نفّذت الأمر فيه. في اليوم التالي تفتح Claude Code في مكان آخر، فلا تجد أي أداة من أدوات HumanPen، وتستنتج عن حق أن التثبيت قد فشل.

يقرأ Codex الملف `~/.codex/config.toml`، حيث يظهر الخادم نفسه على هيئة جدول `[mcp_servers.humanpen]` مع `command = "npx"` و`args = ["-y", "humanpen-mcp"]` و`env = { HUMANPEN_API_KEY = "hp_your_key" }`. وفي دليل التثبيت تجد الكتلة الجاهزة للنسخ.

تتخذ Cursor وWindsurf وCline وClaude Desktop الشكل نفسه في ملفات الإعداد الخاصة بكل منها. ثمة فخ في تطبيقات سطح المكتب: ضع المسار المطلق إلى `npx` في `command`. نفّذ `which npx` واستخدم النتيجة. يشغّل نظام التشغيل هذه التطبيقات بمتغير `PATH` ضئيل، فلا يُعثر على الاسم المجرد في كثير من الأحيان، والعرض الوحيد هو أن الأدوات لا تظهر إطلاقًا.

بعد إعادة التشغيل تظهر ثماني أدوات. الأداة التي يتناولها هذا المقال هي `humanize_document`؛ أما `read_detection_report` و`check_job` فهما الأداتان اللتان تدعمانها.

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

أعطِ المهمة الاثنين معًا. عندما يكون التقرير مرفقًا ولا تُعطى قائمة مقاطع صريحة، تصبح المقاطع المُعلَّمة في ذلك التقرير هي نطاق إعادة الكتابة، ويُترك كل ما عداه في المستند على حاله. وإن أعطيت قائمة صريحة، فتلك القائمة نهائية، ولا يبقى التقرير إلا بوصفه مرفقًا على المهمة. عبر واجهة REST يبدو الأمر نفسه على هذا النحو، مقابل جذر API الذي توضّحه لك صفحة المطورين:

curl -X POST "$HP_API_ROOT/jobs/humanize" -H "Authorization: Bearer $HP_API_KEY" -F "file=@paper.docx" -F "turnitin_file=@turnitin-report.pdf" -F "strategy=balanced" -F "additional_instructions=Keep terminology and citations unchanged."

تُحسب الاعتمادات على الكلمات التي أُعيدت كتابتها فعلًا، فالمهمة التي يحدّدها تقرير فيه أربع فقرات مُعلَّمة تُحاسَب كأربع فقرات. ومسارات Skill وMCP وAPI تستنفد الرصيد نفسه، والمهمة التي لا تكتمل لا تُحاسَب.

النموذج لا يرى الناتج أبدًا.

ما يعيده استدعاء مكتمل هو إيصال للمهمة: أين كُتب الملف، وكم كلّف، وكيف تحرّك عدد الكلمات. لا محتوى، ولا فرق. وكل ما أردت توجيهه يجب أن يُكتب في سلسلة التعليمات قبل بدء المهمة، وبلا رؤية.

الرد المعتاد هو أن العميل لديه أداة لقراءة الملفات، فيمكن للوكيل أن يقرأ النتيجة ببساطة. الكلمات يستطيع قراءتها: خمسة أسطر من `python-docx` تكفي لاستخراج نص الفقرات ومقارنته بالأصل. أما ما لا يستطيع قراءته فهو ما إذا كان التنسيق قد نجا، والتنسيق هو سبب إرسالك ملفًا بدلًا من سلسلة نصية. لذا يستطيع الوكيل أن يخبرك أن المهمة نجحت، وكم كلّفت، وماذا يقول النص الآن. ولا يستطيع أن يخبرك ما إذا كان الجدول في الصفحة 7 قد وصل سليمًا.

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

إعادة كتابة مستند حقيقي تستغرق دقائق، وهو أمر غير مريح داخل بروتوكول بُني حول استدعاءات أدوات سريعة. ينتظر الاستدعاء نحو 55 ثانية ثم يعيد معرّف مهمة بدلًا من ملف. ويستمر العمل على الخادم، ويتولّاه `check_job`.

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

والاستدعاء الذي يعيد ملفًا والاستدعاء الذي يعيد معرّفًا هما الاستدعاء نفسه، لذا فإن أي أتمتة حوله يجب أن تتعامل مع النتيجتين معًا، بدل افتراض أن مستندًا سيعود.

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

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

مع أي العملاء يعمل هذا؟ مع أي عميل MCP قادر على تشغيل أمر محلي. تغطي الإعدادات الموثّقة Claude Code وCodex وCursor وWindsurf وCline وClaude Desktop وVS Code وOpenCode وغيرها، والعقد مع أي شيء آخر هو تشغيل `npx -y humanpen-mcp` مع وجود `HUMANPEN_API_KEY` في بيئته.

هل أحتاج إلى اشتراك منفصل لخادم MCP؟ لا. Skill وMCP وREST تستنفد الرصيد نفسه من الاعتمادات، وتُحسب الاعتمادات على الكلمات التي أُعيدت كتابتها فعلًا.

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

لماذا أعاد استدعاء الأداة معرّف مهمة بدلًا من ملف؟ لأن المهمة تجاوزت نافذة الانتظار، وهي نحو 55 ثانية. تستمر المهمة على الخادم؛ و`check_job` بذلك المعرّف يعيد النتيجة عندما تصبح جاهزة.