أنور بآي
قد يكتب وكيل البرمجة خطة صحيحة، ومع ذلك يصعب فهمها. الملفات موزعة على مراحل، والتغييرات مترابطة، والقرارات المهمة مدفونة بين فقرات طويلة. قبل أن توافق على التنفيذ، تحتاج أن ترى ما الذي سيتغير، وما الذي يعتمد على ماذا، وأين يمكن أن تفشل الخطة.
مشروع Answer me with HTML يحاول تحسين هذه اللحظة: يكتب الوكيل مسودة قصيرة، ثم تحولها أداة محلية إلى صفحة HTML فيها أقسام ومخططات ومقارنات. تبقى المحادثة مختصرة، وتحصل على ملف يمكن فتحه ومراجعته خارج نافذة الدردشة.
جرّبت الأداة مع Hermes. لاحظت أن الرد يصل أسرع، وأن شرح الأمور يصبح أوضح بالنسبة لي. وأكثر مكان وجدتها مفيدة فيه هو مرحلة التخطيط: مع Hermes، أو عند العمل مع Oh My Pi، تساعدني الصفحة على فهم ما ينوي الوكيل فعله أفضل من متابعة نص طويل داخل نافذة المحادثة أو فتح ملف Markdown بالطريقة المعتادة.
هذه ملاحظة من استخدامي، وليست قياسًا منشورًا لسرعة Hermes أو مقارنة مضبوطة بين الوكلاء. أما شرح آلية المشروع والأوامر في هذا المقال فمبني على مراجعة مستودعه وتوثيقه، دون إعادة تنفيذ تجربتي أو اختبارات أداء جديدة أثناء إعداد المقال.
الفكرة المرتبطة بكارباثي: فهم مخرجات النموذج
يربط صاحب المشروع الفكرة بمنشور Andrej Karpathy عن فهم مخرجات النماذج. في المنشور الأصلي، يقترح كارباثي تحسين الكتابة، ثم استخدام الرسوم والصور، وصفحات HTML التفاعلية، وحتى فيديوهات الشرح. حجته أن النماذج ستنجز قدرًا أكبر من العمل، بينما سنقضي نحن وقتًا أكبر في مراجعته وفهمه.
وهنا يلزم التفريق بين فكرتين. المنشور يقدم ملاحظات ونصائح عملية، وليس دراسة تثبت أن الذكاء الاصطناعي «يفضل HTML» على النص العادي. كما أنه لا يثبت أن طلب HTML يجعل النموذج أذكى أو أدق في جميع المهام.
ما يهمني في هذه الفكرة هو جانب المستخدم: صيغة العرض قد تجعل العلاقات والقرارات أسهل في الفهم. وعندما أراجع خطة وكيل، فإن هذا الفرق يستحق التجربة، حتى إن لم يتغير النموذج نفسه.
ماذا يضيف المشروع فوق طلب «أجبني بصيغة HTML»؟
يمكنك طلب صفحة HTML من أي نموذج قادر على كتابة الكود. لكن النموذج عندها قد يكتب المحتوى، وCSS، وعناصر الصفحة، وتفاصيل SVG وإحداثيات الأسهم. جزء من الانتظار يذهب إلى إنشاء الشكل بدل شرح الموضوع.
Answer me with HTML يفصل العمل:
يحدد الوكيل أقسام الإجابة والعلاقات التي يحتاج القارئ إلى رؤيتها.
يكتب مسودة بصيغة Markdown موسعة، مع أنواع مكونات مثل flow وsequence وtree.
تتولى أداة CLI المرفقة بناء HTML وتنسيقه وحساب تخطيط المخططات.
يحفظ الوكيل الصفحة ويشير إلى مكانها، بدل نسخ محتواها كاملًا إلى المحادثة.
القيمة هنا ليست في جعل النموذج يكتب مزيدًا من HTML. على العكس، يكتب النموذج محتوى أقل، وتنجز أداة ثابتة جزءًا من العمل المتكرر.
هذا تفسير هندسي معقول لشعوري بسرعة الرد، لكنه لا يحول تجربتي إلى إثبات سببي. زمن استدعاء الأدوات، والنموذج، وحجم السياق، وتفاصيل السؤال يمكن أن تؤثر أيضًا.
لماذا أفضله عند مراجعة الخطة؟
في ملف نصي، قد تقرأ: «سنضيف الخدمة، ثم نغير المسار، ونحدّث التحقق، وبعد ذلك الاختبارات». تستطيع فهم الخطوات، لكن العلاقة بين المكونات قد تحتاج إلى إعادة قراءة عدة فقرات.
في صفحة منظمة، يمكن عرض المسار الحالي، والمكون الجديد، والتغييرات المقترحة، والقرار الذي لم يُحسم في أماكن واضحة. وتدعم تعليمات المهارة الحالية علامات للإضافة والحذف والتعديل داخل بعض المخططات، مع عرض التغييرات والمقارنة بين قبل وبعد.
ما أريده من هذه الصفحة ليس تزيين الخطة. أريد أن أعرف قبل التنفيذ:
هل فهم الوكيل حدود المهمة؟
ما الملفات والمكونات التي سيعدلها؟
لماذا اختار هذا المسار بدل البديل؟
ما الذي يحتاج موافقتي؟
كيف سنعرف أن التنفيذ نجح، وكيف نرجع عنه إذا فشل؟
الصفحة تساعدني على مراجعة هذه الأسئلة. لكن شكل المخطط لا يثبت صحة العلاقات التي رسمها الوكيل. إذا أساء فهم المستودع، فقد ينتج مخططًا أنيقًا لخطة خاطئة.
ما أنواع الصفحات التي يمكن إنتاجها؟
المشروع يوفر مكونات يختارها الوكيل بحسب المعلومات:
flow لمسار طلب، أو بنية النظام، أو تفرعات قرار.
sequence لتبادل الرسائل بين أطراف بترتيب زمني.
tree لهيكل الملفات أو الوحدات.
timeline للمراحل أو تطور الموضوع.
er للكيانات وعلاقات البيانات، بحسب تعليمات المهارة الحالية.
جداول للمقارنة، وcallout لخلاصة أو تحذير، وask لقرارات تحتاج رد المستخدم.
يمكن أن تكون النتيجة لوحة أقسام، أو مستندًا خطيًا. ويذكر التوثيق أن الصفحة ملف HTML واحد يمكن فتحه دون اتصال، وتحتفظ بمسودة المصدر داخلها. ذلك مفيد لإعادة المراجعة والتعديل، لكنه مهم أيضًا للخصوصية: ما يُضمَّن في الصفحة لا يختفي لمجرد أن العرض يبدو مختصرًا.
ولا يلزم إنتاج صفحة لكل سؤال. أمر صغير أو جواب من سطر واحد غالبًا أفضل كنص عادي. استخدم الصفحة عندما توجد علاقات أو بدائل أو خطوات يصعب رؤيتها داخل تسلسل المحادثة.
البداية والتثبيت
المشروع مهارة Agent Skill مع CLI مرفقة، وليس نموذجًا جديدًا أو خادم MCP مطلوبًا لتوليد الصفحة. وفق التوثيق، تحتاج Node.js 20 أو أحدث، والأداة المجمعة موجودة داخل مجلد المهارة، فلا تحتاج خطوة npm install لتشغيلها بالطريقة المعتادة بعد الحصول عليها.
يوثق المستودع هذا الأمر للتثبيت عبر مدير مهارات Vercel:
npx skills add QingYunA/answer-me-with-html
اختر الوكيل الذي تستخدمه إذا ظهر ضمن خيارات المثبّت. لا تفترض أن مسار مهارات Claude Code هو نفسه مسار Hermes أو Oh My Pi، ولا تنسخ إعدادات وكيل إلى آخر بلا مراجعة.
في Hermes، راجع توثيق نظام المهارات واستخدم طريقة تثبيت مناسبة للـProfile النشط. بعد تثبيت المهارة والتحقق من ظهورها، يمكن استدعاؤها باسمها كما يدعم Hermes استدعاء المهارات المثبتة:
/answer-me-with-html اشرح خطة التغيير في صفحة بصرية، ولا تنفذ أي تعديل قبل موافقتي.
هذا مثال طلب، وليس أمرًا نفذناه في تجربة جديدة. وفي الوكلاء الأخرى، تحقق من تحميل المهارة ومن قدرة الوكيل على تشغيل Node وحفظ الملف.
ومن تفاصيل التوافق المهمة أن متغير ${CLAUDE_SKILL_DIR} الوارد في تعليمات المشروع مرتبط ببيئة Claude Code. إذا لم تستبدله بيئة وكيلك تلقائيًا، يحتاج الوكيل إلى استخدام المسار الفعلي لمجلد المهارة بدل تمرير المتغير كما هو.
اطلب خطة تساعدك على اتخاذ قرار
هذا طلب مقترح لمرحلة التخطيط، يمكن تعديله بحسب مشروعك:
استخدم Answer me with HTML لعرض خطة التنفيذ قبل كتابة الكود.
ابدأ بهدف المهمة وما لن نغيره.
ارسم مسار العمل الحالي والتغييرات المقترحة.
اذكر الملفات التي تحتاج تعديلًا، وميز المؤكد عما يحتاج فحصًا.
ضع البدائل وأسباب اختيارك في مقارنة قصيرة.
أظهر المخاطر، والاختبارات، وخطوات التراجع.
ضع القرارات المفتوحة في أقسام واضحة تحتاج ردي.
استخدم العربية في الشرح، واحتفظ بأسماء الملفات والكود كما هي.
احفظ الصفحة دون فتح المتصفح تلقائيًا.
لا تنفذ الخطة حتى أوافق عليها صراحة.
إذا كنت تراجع مستودعًا حقيقيًا، اطلب من الوكيل ربط الخطة بالملفات التي قرأها، وألا يخترع بنية أو أسماء ملفات. دعم عرض الكود داخل الصفحة لا يغني عن مراجعة مصدره أو حماية الأجزاء الخاصة.
وبعد فتح الصفحة، يمكنك إرسال رد مثل «وافق على المسار المقترح، لكن استبعد تعديل قاعدة البيانات» أو «القرار في القسم C لم يُحسم». تعليمات المشروع توثق آلية لجمع قرارات وتعليقات القارئ وإعادتها إلى الوكيل.
لا تعتبر الضغط على واجهة أو ترك خيار بلا إجابة موافقة تلقائية. الصفحة وسيلة لعرض القرار؛ سلطة التنفيذ تبقى في تعليمات المستخدم وضوابط الوكيل.
استخدام CLI مباشرة
يوثق المشروع مسار الأداة داخل المستودع وأمرًا لتحويل مسودة موجودة إلى صفحة:
AM=skills/answer-me-with-html/scripts/am.mjs
node "$AM" render notes.md -o out.html --no-open
المثال يفترض تشغيله من جذر نسخة المستودع، ووجود notes.md. أما بعد تثبيت المهارة داخل وكيل، فاستخدم المسار الفعلي للملف am.mjs في مجلدها. خيار --no-open يمنع فتح المتصفح لهذه العملية.
مسودة مبسطة قد تبدو هكذا؛ هي مثال تعليمي وليست خطة تنفيذ لمشروع فعلي:
---
title: خطة مراجعة التغيير
lang: ar
---
## الهدف
فهم التغيير والموافقة عليه قبل التنفيذ.
## مراحل العمل
```flow LR
Review -> Plan: inspect the project
Plan -> Approval: discuss the changes
Approval -> Implement: explicit permission
Implement -> Verify: run the agreed tests
```
## ما يحتاج موافقة
لا نغير الصلاحيات أو البيانات دون موافقة منفصلة.
الصفحة العربية تحتاج مراجعة بصرية، خصوصًا اتجاه RTL، والنص المختلط بالكود، وطول العناوين داخل الرسوم. تعليمات المهارة تدعم تحديد lang:، لكن هذا لا يثبت وحده أن كل مكون سيعرض العربية بصورة مناسبة. كما أن قواعد التدقيق اللغوي الخاصة بالإنجليزية والصينية ليست تدقيقًا عربيًا كاملًا.
ماذا تقول أرقام المشروع عن السرعة؟
ينشر صاحب المشروع Benchmark يقارن بين طلب HTML مباشرة واستخدام المهارة، على ثلاثة موضوعات، بثلاث تشغيلات لكل حالة، ويصف النموذج المستخدم بأنه Claude Sonnet 5.5.
في الإعداد الخفيف المنشور، يعرض التقرير متوسط القيم الوسيطة عبر الموضوعات:
مخرجات النموذج: 4,932 token عند طلب HTML مباشرة، مقابل 1,007 باستخدام المهارة.
الزمن: نحو 31 ثانية، مقابل 12 ثانية.
هذه نتائج صاحب المشروع في بيئته، وليست أرقام تجربتي على Hermes أو Oh My Pi. والأهم أن المقارنة مع توليد HTML مباشرة، لا مع إجابة نصية عادية أو ملف Markdown بسيط.
ويذكر التقرير أن الصفحات نفسها تختلف: التوليد المباشر أعطى نصًا أطول، بينما أعطت المهارة صفحة أكثر اختصارًا. لذلك لا تقرأ فرق الزمن باعتباره إثباتًا لتساوي المحتوى أو جودة الفهم.
هناك أيضًا اختلاف بين الأرقام البارزة في README والتقرير التفصيلي في المراجعة التي راجعناها؛ استخدمنا التقرير التفصيلي عند ذكر النتائج. ويتناول التقرير أثر حجم السياق والتخزين المؤقت على التكلفة. تقليل مخرجات النموذج لا يعني أن الفاتورة تنخفض بالنسبة نفسها، ولا يثبت توفيرًا ثابتًا لكل إعداد.
الحدود التي يجب ألا تختفي خلف التصميم
هناك فرق بين تحسين عرض الخطة وتحسين التفكير الذي أنتجها. قد تساعدك الصفحة على اكتشاف خطأ، لكنها لا تضمن أن الوكيل فحص جميع الملفات أو اختار البديل الصحيح.
كما أن نقل الخطة إلى HTML لا يوسع نافذة سياق النموذج. تحتاج أن يعرف الوكيل النسخة الحالية من الخطة وأن يحدّثها عندما تتغير المهمة؛ الصفحة القديمة قد تصبح مرجعًا مضللًا إذا استمر التنفيذ على خطة مختلفة.
راجع هذه النقاط قبل الاعتماد على المخرجات:
لا تسمح للاختصار بحذف افتراضات أو مخاطر تؤثر في القرار.
افصل المقترح عن التغيير المنفذ، والنتيجة المتوقعة عن اختبار نجح فعلًا.
احذف الأسرار والبيانات الخاصة قبل مشاركة HTML، بما فيها مسودة المصدر أو الكود المضمّن.
افتح الملفات المولدة بحذر، وراجع أي محتوى خام من HTML أو JavaScript، ولا تمنحها أسرارًا أو صلاحيات غير لازمة.
تحقق من كيفية إيصال الملف في بيئتك؛ رابط file:// على جهاز الوكيل البعيد لن يفتح الملف الموجود هناك على جهازك تلقائيًا.
ويذكر README أن إضافة always-on الخاصة بـClaude Code لا تنتج صفحات في plan mode. لذلك لا تعمم تجربتي في عرض التخطيط مع Hermes على كل وضع تخطيط في كل وكيل. القدرة على كتابة ملف وتشغيل renderer تختلف بحسب القيود المفروضة.
خلاصة تجربتي
وجدت Answer me with HTML مفيدًا عندما أحتاج إلى فهم خطة الوكيل قبل الموافقة عليها. شعرت بسرعة أكبر، وكان العرض أوضح لي من الفقرات الطويلة أو ملفات Markdown التي يشاركها الوكيل عادة.
لا أحتاجه لكل رد. أبدأ به عند وجود مسار عمل أو تغييرات مترابطة أو بدائل أحتاج المقارنة بينها. ثم أراجع المحتوى كما أراجع أي خطة: ما الدليل؟ ما المخاطر؟ وما الذي سأسمح للوكيل بتنفيذه؟
هذه هي الفكرة التي آخذها من تجربة الأداة ومن ملاحظات كارباثي: كلما زاد العمل الذي ينجزه الوكيل، احتجنا طريقة أفضل لفهمه ومراجعته، لا مجرد طريقة أسرع للموافقة عليه.
المصادر
الغلاف يستخدم شعار المشروع من المستودع المرخص بـMIT، مع تصميم تحريري؛ ليس لقطة لتجربة تشغيل. حقوق العلامة لأصحابها. إشعار المصدر: Copyright (c) 2026 Answer me with HTML contributors؛ يُرفق نص الترخيص مع حزمة المراجعة.
لا تعليقات بعد. شارك سؤالك أو تجربتك مع هذا الدليل.