ما هو Ponytail وكيف تجعل وكيل البرمجة يكتب كوداً أقل؟

ما هو Ponytail

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

مستودع المشروع هو DietrichGebert/ponytail. أُنشئ المشروع في 12 يونيو 2026 وتجاوز حاجز 90,000 نجمة بحلول 1 أغسطس 2026. أحدث إصدار موسوم في 1 أغسطس 2026 هو v4.8.4، والذي نُشر في 29 يونيو 2026، وتدرج صفحة الإصدارات عشر وسوم بين 14 و29 يونيو وحده. المشروع الذي يتحرك بهذا المعدل سيكون قد تغير بحلول الوقت الذي تقرأ فيه هذا، لذا قم بتثبيت وسم (tag) معين قبل بناء أي شيء بالاعتماد عليه.

الفكرة قبل الأداة: توقف عند أول درجة ثابتة

جوهر Ponytail هو سلم اتخاذ القرار. يصعد الوكيل هذا السلم قبل كتابة أي شيء ويتوقف عند أول درجة ثابتة.

1. هل هناك حاجة لوجود هذا الشيء أصلاً؟ هذا هو مبدأ YAGNI (أنت لن تحتاج إليه). إذا كانت الإجابة لا، فتجاوزه.
2. هل هو موجود بالفعل في قاعدة الأكواد هذه؟ أعد استخدام المساعد أو النمط الموجود مسبقاً.
3. هل توفره المكتبة القياسية؟ استخدمها.
4. هل تغطيه ميزة أصلية في المنصة؟ استخدمها.
5. هل تحله تبعية (dependency) مثبتة بالفعل؟ استخدمها.
6. هل يمكن أن يكون في سطر واحد؟ اجعله في سطر واحد.
7. عندها فقط، اكتب الحد الأدنى من الكود الذي يعمل.

الترتيب هو الذي ينجز العمل، وليس أي درجة بمفردها. الوكيل الذي يُطلب منه إنشاء منتقي تاريخ (date picker) سيقوم بكتابة واحد، لأن كتابته هي ما طُلب منه فعله. السلم يجعله يتحقق من الدرجة 4 أولاً، والدرجة 4 تقول إن المتصفح يحتوي بالفعل على <input type="date">. ملاحظات قياس الأداء الخاصة بالمشروع تشير تحديداً إلى هذه الحالة: منتقي تاريخ كان يتكون من 404 أسطر بدون القاعدة، أصبح 23 سطراً معها، لأن الوكيل لجأ إلى المدخل الأصلي (native input) بدلاً من بناء مكون. منتقي ألوان انخفض من 287 سطراً إلى 23 للسبب نفسه. الدرجة 2 هي التي تفشل بصمت، لأن الوكيل الذي لا يستطيع رؤية المساعد الموجود لديك سيقوم بكل سرور بكتابة مساعد ثانٍ، وهي الفجوة التي تهدف خريطة قابلة للاستعلام لقاعدة أكوادك إلى سدها.

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

محتويات المستودع الفعلية

• AGENTS.md، مجموعة القواعد التي تعمل دائماً، وهي الفكرة الجوهرية في ملف واحد يمكنك قراءته في خمس دقائق.
• skills/ponytail/SKILL.md، تعريف المهارة، مع تلميح وسيط لـ lite أو full أو ultra.
• ملفات القواعد الموجودة ضمن أدلة خاصة بالمحررات مثل .cursor/rules/ و .windsurf/rules/، للمضيفات التي تقرأ القواعد ولكنها لا تحمّل المهارات.
• hooks/ و benchmarks/ و examples/ و scripts/.

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

تحصل المضيفات التي تدعم المهارات أيضاً على أوامر شرطة مائلة (slash commands). يقوم /ponytail بضبط المستوى، ويفحص /ponytail-review فرقاً (diff) بحثاً عن الإفراط في الهندسة، ويفحص /ponytail-audit مستودعاً كاملاً، ويجمع /ponytail-debt الاختصارات التي أجّلتها، ويطبع /ponytail-gain بطاقة أداء المعايير. المضيفات التي تقرأ ملفات القواعد فقط تحصل على مجموعة القواعد دون أي أوامر.

لقراءة المصدر قبل الوثوق به، استنسخ (clone) الوسم (tag) بدلاً من الفرع (branch):

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

في Claude Code، يوثق المشروع تثبيت إضافة (plugin) بدلاً من ذلك، وهذان السطران موثقان كما في 1 أغسطس 2026:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

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

لماذا يُعد الوكيل الكسول أقل تكلفة على خادم VPS

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

تُحاسب على الرموز (tokens) عند الإدخال والإخراج، لذا فإن الفرق الذي يبلغ نصف الحجم يكون أرخص بمرتين؛ مرة عند كتابته، ومرة أخرى في كل دور يعيد قراءته. يعتمد ما إذا كان هذا التوفير سيظهر في فاتورتك على طريقة دفعك، لأن اشتراك Pro أو Max الثابت يمتص الرموز الإضافية، بينما تفرض الفوترة القائمة على عدد الرموز (per-token) رسوماً على كل رمز منها. إذا كنت تراقب التكاليف في إعدادات مستضافة ذاتياً، فإن ملف التعليمات هو أداة تحكم لا تكلف شيئاً عند استخدامها. تبدأ السيطرة على تكاليف وكيل الذكاء الاصطناعي من حجم المخرجات، ويوضح موضوع كيف ينفق وكيل البرمجة رموزه سبب أهمية إعادة القراءة أكثر مما يتوقع الناس.

لا يزال البشر يقرؤون الفرق. إن تغييراً بطول 400 سطر كان يجب أن يكون 20 سطراً فقط يستهلك انتباه المراجع، والانتباه هو المورد الذي ينفد أولاً. لا أحد يراجع الفرق الطويل الرابع في اليوم بنفس الدقة التي منحها للأول، لذا فإن الإفراط في البناء لا يضيع الوقت فحسب، بل يخفض بهدوء جودة المراجعة التي يفترض بها اكتشاف الأخطاء.

على الخادم، تتغير المخاطر، لأن الوكيل غالباً ما يعمل دون مراقبة. الوكيل الذي يعمل داخل جلسة tmux أو وفق مؤقت لديه ساعات للبناء على قرار خاطئ قبل أن تراه. هذه هي المخاطرة العملية في تشغيل وكيل برمجة على خادم VPS، ولهذا السبب يقضي الأشخاص الذين يمارسون هندسة الحلقات (loop engineering) الكثير من العناية في التعليمات الدائمة بدلاً من المطالبات الفردية. القاعدة الموجودة في ملف التعليمات الدائم تُطبق في الدور 200. أما القاعدة التي كتبتها في الدردشة فتُطبق في الدور 3 فقط. كما أنها تُطبق على الجلسة الثانية التي تبدأها على نفس الجهاز، والتي تقرأ الملف المعتمد ولكنها لا ترث أي شيء كتبته في الجلسة الأولى، حتى عندما تستطيع الجلستان مراسلة بعضهما البعض.

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

ما تقوله أرقام قياس أداء Ponytail الخاصة

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

[
  {
    "label": "Lines of code",
    "single_shot_pct": 93,
    "agentic_pct": 54
  },
  {
    "label": "Cost per run",
    "single_shot_pct": 63,
    "agentic_pct": 20
  },
  {
    "label": "Wall clock time",
    "single_shot_pct": 74,
    "agentic_pct": 27
  }
]

يأتي عمود "المحاولة الواحدة" (single shot) من نموذج خام يجيب على مجموعة صغيرة من المطالبات مع وبدون القاعدة، وتؤخذ كقيم وسيطة عبر عمليات تشغيل متكررة بتاريخ 13 و17 يونيو 2026. أما عمود "الوكيل" (agentic) فيأتي من جلسة Claude Code بدون واجهة رسومية تقوم بتعديل مستودع full-stack-fastapi-template الخاص بـ tiangolo، وهو مستودع حقيقي لـ FastAPI وReact، عبر اثني عشر تذكرة ميزات مع أربع عمليات تشغيل لكل منها على Haiku 4.5، ويتم التقييم بناءً على نواتج git diff المتبقية.

اقرأ العمود الثاني. نتيجة الوكيل هي 54 بالمئة أقل في أسطر الكود، و20 بالمئة أقل في التكلفة، و27 بالمئة أقل في الوقت الفعلي المستغرق، مقابل 93 بالمئة و74 بالمئة لنفس المقاييس في إعداد المحاولة الواحدة. ملف README صادق بشأن السبب: خط الأساس للمحاولة الواحدة هو نموذج خام "يجيب بعدة خيارات بالإضافة إلى تعليق"، وهو أمر يسهل التفوق عليه. قارن النتائج بوكيل حقيقي يقوم بعمل حقيقي وستتقلص نسبة الفوز. تظل النتيجة واقعية أيضاً، وهي الحقيقة الأكثر فائدة.

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

النمط الذي يمكنك نسخه اليوم دون تثبيت أي شيء

السلم عبارة عن نص، لذا لا تحتاج إلى إضافة (plugin) لاستخدام هذه الفكرة. انسخ كتلة مثل هذه في ملف التعليمات الذي يقرؤه وكيلك (agent) بالفعل، سواء كان ذلك AGENTS.md أو CLAUDE.md أو ملف قواعد المحرر الخاص بك.

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

تستحق القاعدة الأخيرة أن تؤخذ بمفردها. اصطلاح Ponytail هو تعليق موسوم باسم الأداة:

# ponytail: global lock, per-account locks if throughput matters

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

مكان وضع الكتلة لا يقل أهمية عن محتواها. الملف الذي يحمّله الوكيل في كل تشغيل يوجّه كل عملية تشغيل، بما في ذلك تلك التي لا تراقبها. هذا الفرق هو موضوع كتابة ملف AGENTS.md يتبعه وكيلك فعلياً، وهو السبب في أن هذا النمط ينتمي إلى ملف مُلتزم به (committed file) بدلاً من سجل الصدفة (shell history) الخاص بك. في المستودع الموحد (monorepo)، ينتمي النمط إلى أكثر من ملف مُلتزم به، لأن ملف AGENTS.md لكل حزمة يبقي قواعد كل دليل قصيرة بدلاً من جعل الوكيل يقرأ اصطلاحات الشجرة بأكملها في كل تشغيل. ومع ذلك، فإن الموقع ليس ضماناً، ومن الجدير معرفة لماذا يتجاهل الوكيل قاعدة قام بتحميلها بالفعل قبل أن تستنتج أن السلم يحتاج إلى صياغة أقوى.

متى تفقد القاعدة صلاحيتها

صُمم هذا السلم للعمل على الميزات في قاعدة برمجية موجودة مسبقاً، حيث تتوفر إمكانية إعادة الاستخدام وتكون صحيحة عادةً. لا يتناسب هذا السلم مع المشاريع الجديدة (greenfield) بشكل جيد؛ لأن الدرجة 2 لا تجد شيئاً لإعادة استخدامه، والدرجة 5 لا تجد شيئاً مثبتاً، مما يجعل الوكيل يسقط إلى الدرجة 7 في كل مرة. كما أنه لا يتناسب جيداً في اللحظة التي تحتاج فيها فعلياً إلى التجريد (abstraction). إذا كنت على وشك إضافة المستدعي الرابع لنفس الكتلة المنسوخة، فإن "أقصر فرق" (shortest diff) سيمنحك نسخة خامسة.

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

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

الخلاصة الصادقة هي أن Ponytail عبارة عن مطالبة (prompt) مكتوبة بعناية، وموزعة بشكل جيد، ومرفقة بأرقام. لا يوجد شيء فيها يتطلب إضافة برمجية (plugin). ما يقدمه لك المشروع هو أن شخصاً ما كتب القائمة بشكل صحيح، واختبرها مقابل مستودع حقيقي، ونشر الطريقة بجانب النتيجة.

FAQ

هل يعمل Ponytail مع وكلاء غير Claude Code؟

نعم. يتم شحن الأداة كمهارة للمضيفين الذين يدعمون تحميل المهارات، وهي قائمة تشمل Claude Code وCodex وOpenCode وGemini وعدة أدوات أخرى مذكورة في ملف README. أما المحررات التي تقرأ ملفات القواعد ولكنها لا تحمل المهارات، مثل Cursor وWindsurf وCline وCopilot، فهي تأخذ مجموعة القواعد الدائمة من دليل القواعد المطابق ولا تحصل على أوامر الشرطة المائلة (slash commands). النص هو نفسه في كلتا الحالتين، لذا يكمن الفرق الحقيقي في ما إذا كان مضيفك يحتفظ بهذا النص في السياق في كل دورة أم فقط عند تفعيل المهارة.

هل سيتجاهل الوكيل الكسول الاختبارات أو التحقق أو الأمان؟

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

هل أرقام السرعة والتكلفة المنشورة جديرة بالثقة؟

هذه هي قياسات المشروع الخاصة، وقد نُشرت مع توضيح منهجيتها، ويجب قراءتها على هذا الأساس. تقارن أرقام المحاولة الواحدة (single shot) مقابل نموذج أساسي يرد بخيارات وتعليقات، وهو ما يشير إليه ملف README نفسه كخط أساس ضعيف. تأتي أرقام الوكيل من جلسة Claude Code بدون واجهة رسومية على مستودع واحد لـ FastAPI وReact، عبر اثني عشر تذكرة، وأربع عمليات تشغيل لكل منها، على نموذج Haiku 4.5. هذه أرقام صادقة لهذا الإعداد. إنها ليست توقعاً لقاعدة الأكواد الخاصة بك، لأن المشروع يذكر أيضاً أن التوفير ينخفض إلى ما يقرب من الصفر في الأكواد التي كانت بالفعل في حدها الأدنى.

هل أحتاج إلى تثبيت أي شيء للحصول على الفائدة؟

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

كيف أمنع الوكيل غير المراقب من الإفراط في البناء طوال الليل؟

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