اقتصاديات التطوير المدعوم بالذكاء الاصطناعي لفريق إضافة WordPress

سؤال لم نستطع الإجابة عنه بصدق في الشهر الأول

كم تكلفة إطلاق إضافة WordPress مع Claude Code كمتعاون يومي؟

خلال شهرنا الأول في بناء Statnive، لم نستطع الإجابة عن ذلك. كنّا نعلم قيمة الفاتورة، لكنّنا لم نعرف ما الذي يحرّكها فعليًا. كانت بعض الأيام بـ 3$، وأخرى بـ 11$، ولم يكن للتباين ارتباط واضح بكمّ الكود الذي تمّ إطلاقه.

بعد أربعة أشهر، أصبحت لدينا صورة أوضح بكثير. هذه التدوينة هي محاسبة التكاليف: إلى أين تذهب الأموال، والروافع الأربع التي تتراكم لتصل إلى ما يقارب 2–3× من إنفاقنا، والرقم الواحد الذي كان أهم من أي تحسين فردي.

العنوان الرئيسي: انخفض الإنفاق اليومي من ~6$ في اليوم إلى ~2–3$ في اليوم بنفس الإنتاجية الهندسية. الوفورات ليست تراكمية بالجمع، بل بالضرب.

إلى أين يذهب إنفاق الذكاء الاصطناعي فعليًا

تسعير Anthropic للنماذج ذات الصلة بـ Claude Code، الحالي اعتبارًا من بداية 2026:

النموذج	الإدخال / MTok	الإخراج / MTok	الأفضل لـ
Haiku 4.5	1$	5$	الاستكشاف للقراءة فقط، التحقق، الإصلاحات الروتينية
Sonnet 4.6	3$	15$	عمل التطوير القياسي
Opus 4.7	5$	25$	البنية المعقّدة، التفكير العميق

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

للمرجعية، إليك ميزانيات tokens النموذجية لكل عملية:

نوع العملية	tokens النموذجية	الوقت الواقعي
إصلاح بسيط (Haiku)	2K–5K	1–2 دقيقة
ميزة قياسية (Sonnet)	10K–20K	5–10 دقائق
إعادة هيكلة معقّدة (Sonnet + extended thinking)	30K–50K	15–25 دقيقة
مراجعة معمارية (Opus)	50K–100K	20–40 دقيقة

عند الضرب في يوم عمل كامل، هنا يأتي الرقم ~6$ في اليوم لمهندس واحد. اضربه في السنة، ويصبح حديث التحسين جدّيًا.

الرافعة 1 — prompt caching (~90% على البادئة المستقرّة)

يقوم Claude Code تلقائيًا بتخزين البادئة المستقرّة لكل محادثة: prompt النظام، تعريفات الأدوات المدمجة، البيانات الوصفية للـ skills، وملف CLAUDE.md الجذري. تكلفة قراءات الـ cache 0.1× من السعر الأساسي — أي انخفاض بنسبة 90% على الجزء المخزّن.

البادئة المستقرّة تتجاوز 50K من الـ tokens في معظم الإعدادات. بدون caching، يُعاد احتساب هذه الـ 50K tokens في كل دورة. مع الـ caching، تُقرأ في كل دورة بعد الأولى بتكلفة 10% فقط.

قاعدتان عمليّتان:

1. رتّب المحتوى من الثابت أولًا إلى الديناميكي أخيرًا. يتطلّب نجاح الـ cache تطابقًا تامًّا للبادئة. أي شيء ديناميكي في بداية محادثة يكسر الـ cache ويفرض إعادة قراءة كاملة. نحتفظ بـ CLAUDE.md الجذري والبيانات الوصفية للـ skills أولًا، والسياق الديناميكي (الملفات المتغيّرة، حالة الفرع الحالية) أخيرًا.
2. لا تلوّث البادئة بأي شيء يتغيّر في كل جلسة. هذه هي الحجّة الحقيقية للحفاظ على CLAUDE.md خفيفًا — كل بايت تحذفه هو بايت لا يحتاج إلى إعادة caching عند تغيّر الملف، والبادئات المخزّنة الأقصر أرخص في التحديث عند انتهاء صلاحيتها.

الـ caching هو أكبر رافعة تكلفة منفردة، وهو في معظمه تلقائي. العمل ينحصر في عدم كسره.

الرافعة 2 — توجيه النموذج (3× على الجزء الموجَّه)

تكلفة Haiku 4.5 أقل بـ 3× من Sonnet لكل token. الفارق في القدرة بالنسبة لمهام القراءة فقط والتحقق ضئيل. توصي Anthropic بالاعتماد افتراضيًا على Haiku في ~80% من المهام الروتينية.

من الناحية العملية، نوجّه على النحو التالي:

المهمة	النموذج	السبب
استكشاف الكود («ابحث عن جميع مواضع استدعاء X»)	Haiku (subagent)	قراءة فقط، حتمية
فرز فشل الاختبارات	Haiku (subagent)	مطابقة أنماط، حكم منخفض
تنفيذ الميزات القياسية	Sonnet (main)	الافتراضي للعمل المنتج
قرارات البنية، تصميم الـ schema	Opus (main، أحيانًا)	يستحق العلاوة لأجل التفكير الصعب
تمريرة مراجعة الكود	Haiku (fork subagent)	قراءة كثيفة، إرجاع ملخّص

التوجيه يصبح أقوى ما يكون عندما يقترن بـ subagents، لأن للـ subagents إعدادًا خاصًّا للنموذج مستقلًّا عن الجلسة الرئيسية. يمكننا تشغيل المحادثة الرئيسية على Sonnet بينما يقوم fork subagent بالعمل ذي القراءة الكثيفة على Haiku. يحدث توجيه النموذج عند حدود الـ skill، لا عند حدود المحادثة.

الرافعة 3 — عزل الـ subagent (~37% من تخفيض السياق الرئيسي)

تحصل الـ subagents (وتُعرف أيضًا بـ fork agents) على نافذة سياق خاصّة بها بحجم 200K token. العمل المنجَز داخل subagent لا يلوّث المحادثة الرئيسية. فقط الملخّص يعود.

توثّق Anthropic أن الـ subagents تُرجع ~500–1,000 tokens من 10,000+ من العمل الداخلي — أي تخفيضًا قدره ~37% للسياق الرئيسي في المهام المعقّدة.

أثران على التكلفة:

1. توفير مباشر للـ tokens. مراجعة كود تقرأ 30 ملفًّا وتُرجع حكمًا تستهلك tokens الخاصة بها في عزلة. بدون عزل، تبقى قراءات الـ 30 ملفًّا في السياق الرئيسي، ويُعاد احتسابها في كل دورة لاحقة (مع مراعاة الـ caching).
2. توفير tokens مدفوع بالجودة. السياقات الطويلة تُضعف جودة الاسترجاع — تُوثّق الأبحاث انخفاضًا في الأداء بنسبة 15–47% عند امتلاء السياق، وهي مشكلة «الضياع في المنتصف». الجودة الأقل تعني محاولات أكثر، وقراءات معادة أكثر، وtokens أكثر. الحفاظ على نظافة السياق الرئيسي يمنع فئة الإهدار هذه بأكملها.

المقايضة حقيقية: تستهلك فرق العملاء (agent teams) حوالي 7× من إجمالي الـ tokens أكثر من الجلسات القياسية، لأن كل عميل يُولِد نسخة جديدة بحمل إعداد خاص بها. نقبل بذلك لأنّنا لا نُحسّن من أجل إجمالي الـ tokens — بل نُحسّن من أجل نظافة السياق الرئيسي والإنتاجية الإجمالية. وعلى أي حال، الـ subagents على Haiku رخيصة.

الرافعة 4 — تأجيل أدوات MCP (~85%)

غطّينا هذا بتفصيل في تدوينة MCP Tool Search. النسخة القصيرة:

استهلكت أربعة وعشرون موصِّل MCP بدون تأجيل ما يقارب 135,000 token كحمل أساسي لكل جلسة. خفّض Tool Search ذلك إلى ~3,000 token للفهرس فقط، مع تحميل الـ schemas الكاملة عند الطلب. انخفاض بنسبة 85%، والدقّة ارتفعت، وتوقّفت الجلسات عن الشعور بالضيق.

أثر التكلفة: كل token من الحمل الأساسي هو token يندرج ضمن البادئة المخزّنة في كل جلسة. توفير 130K token من الحمل يعني توفير حوالي 130K × 0.1× المعدّل لكل token × عدد قراءات الـ cache في كل الجلسات. حتى بتكلفة 10%، يساوي ذلك مئات الدولارات شهريًّا لمهندس واحد منتج.

مضاعِف التراكم

هنا الجزء الذي لا تلتقطه الأرقام العنوانية. الروافع الأربع ضربية لا جمعية.

تخيّل جلسة أساسية تستهلك مثلًا 0.30$ على مهمة مدّتها 5 دقائق. طبّق كل رافعة بالترتيب:

الرافعة	الأثر	التكلفة الجارية
الأساس	—	0.30$
prompt caching (90% على البادئة المستقرّة)	البادئة المستقرّة هي ~70% من tokens الجلسة	~0.12$
توجيه النموذج (3× على العمل المؤهَّل لـ Haiku)	~50% من العمل مؤهَّل لـ Haiku	~0.07$
عزل الـ subagent (تخفيض 37% للسياق الرئيسي)	يتقلّص السياق الرئيسي ← إعادة احتساب أقل	~0.05$
تأجيل أدوات MCP (85% على حمل الـ tool-schema)	الـ schemas لم تعد ضمن الأساس	~0.04$

كل خطوة متواضعة. والتركيب درامي. النسب الدقيقة ليست هي المهمّ — البصيرة الهيكلية هي أن تحسينات تكلفة الـ tokens تتراكم ضربيًّا لأنها تنطبق على أجزاء متداخلة من الفاتورة. أصلح أربعًا منها وستكون قد غيّرت رتبة الحجم (order of magnitude).

لهذا انخفض إنفاقنا اليومي من ~6$ إلى ~2–3$ دون تغيير ما نُطلقه. نفس الكود، نفس الاختبارات، نفس وتيرة الإصدار. إعدادات افتراضية مختلفة.

على ماذا نُنفق المال الآن

يوم هندسي نموذجي في Statnive، بعد التحسين:

النشاط	التكلفة التقريبية
مراجعة كود صباحية على PR مفتوح (forked، Haiku)	~0.20$
ميزتان قياسيتان في لوحة React (Sonnet، مع caching)	~0.80$
تشغيلة بوّابة إصدار واحدة (statnive-release skill)	~0.30$
مسودّات توثيق / تدوينات	~0.40$
استكشاف متفرّق وأسئلة وأجوبة	~0.50$
الإجمالي	~2.20$

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

extended thinking: طابق الكلمة المفتاحية للمهمة

تجعّد تسعير يستحق المعرفة: أوضاع extended thinking لدى Claude لها ميزانيات تُفعَّل بكلمات مفتاحية:

الكلمة المفتاحية	ميزانية التفكير
think	5K–10K tokens
think hard	20K–50K tokens
think harder	50K–100K tokens
ultrathink	100K–128K tokens (الحد الأقصى)

تُحسب هذه الـ tokens كإدخال. استخدم الأرخص الذي يناسب المهمة. نعتمد افتراضيًّا على عدم استخدام معدِّل تفكير للعمل الروتيني، وthink hard لقرارات التصميم غير التافهة، وultrathink فقط للأسئلة المعمارية الفعلية حيث يستحق التفكير العميق ثمنه. اللجوء إلى ultrathink لإصلاح خطأ مطبعي يعادل في تطوير الذكاء الاصطناعي تشغيل نافذة Chrome من 50 لسانًا لقراءة صفحة ويب واحدة.

نظافة الجلسة وفّرت لنا بقدر ما وفّرته الروافع

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

الجلسات الطويلة المستقلّة دون إعادة ضبط للسياق تتدهور جودتها تدريجيًّا. يترجم تأثير «الضياع في المنتصف» — انخفاض الأداء بنسبة 15–47% عند امتلاء السياق — مباشرة إلى محاولات أكثر، وقراءات معادة أكثر، وtokens مهدورة أكثر. الجلسات التي تجاوزت 80% من السياق كانت تكلّف بانتظام 2–3× ما تكلّفه الجلسات الأقصر لنفس العمل.

قاعدتا نظافة باتتا الآن جزءًا من طريقة عملنا:

1. /clear بين المهام غير المرتبطة. الانتقال من خطأ في الواجهة الأمامية إلى تغيير في بوّابة الإصدار محادثتان مختلفتان. مسح السياق لا يكلّف شيئًا ويمنع التلوّث.
2. /compact بشكل استباقي عند 60–70% من السياق، لا عند عتبة الـ 95% للـ auto-compact. الـ auto-compact عند الحد الأقصى عملية ذعر تفقد معلومات. الـ compact الاستباقي يحفظ الحالة المهمّة ويُعيد ضبط الضوضاء.

حفظ الحالة في ملفات بدل تاريخ المحادثة يجعل القاعدتين آمنتين — أي شيء مهم يكون على القرص، فلا يفقده الـ clear.

ما لم نُحسّنه

• لا نقيس التكلفة لكل skill بعد. يمكننا رؤية الإجماليات اليومية عبر فوترة Anthropic ونستخدم الأمرين المحليين /cost و/stats للفحوصات الموضعية، لكن ليس لدينا إسناد لكل skill. أدوات مثل ccusage (تقرأ ملفات جلسة JSONL المحلية الخاصة بـ Claude) وClaude-Code-Usage-Monitor موجودة؛ لم ندمجها.
• نسبة الـ subagent لدينا على الأرجح منخفضة جدًّا. نستخدم وضع fork بقوّة للمراجعات والتدقيقات، لكن نسبة معتبرة من عملنا القياسي يمكن أن تُنفَّذ ضمن fork للحفاظ على نظافة السياق الرئيسي. لم نقِس ذلك بصرامة.
• لا نُجري مقارنات A/B رسمية. الرقم 6$ ← 2–3$ يأتي من مقارنة إنفاقنا قبل وبعد استقرار التحسينات. لا توجد تجربة محكومة وراءه. تجربتك ستكون مختلفة.

ما يلزم لتقليله إلى النصف مرّة أخرى

الإجابة الصادقة: على الأرجح لا شيء يستحق العناء.

يمكننا الضغط أكثر على Haiku. يمكننا تجميع عمل أكثر في subagents. يمكننا كتابة عقود أصرم لميزانية الإخراج داخل skills الخاصة بنا. كل ذلك قد يقتطع 10–20% إضافية ربّما.

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

جرّب Statnive

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