اقتصاديات التطوير المدعوم بالذكاء الاصطناعي لفريق إضافة WordPress
محاسبة تكاليف صادقة من فريق صغير يُطلق إضافة تحليلات WordPress. كيف كانت فاتورة Anthropic قبل التحسين، وكيف أصبحت الآن، ومن أين تأتي الوفورات المتراكمة فعليًا.
وسم
منشورات بوسم “engineering”
7 منشورًا. مسح المرشّح
تدريج الـ Skill: نموذج الدلاء الأربعة الذي يُبقي 80+ skill خارج السياق
الكشف التدريجي يعني أن 80 skill يمكن أن تكلّف 3,200 رمز metadata، أو صفرًا. إليك كيف نصنّف كل skill في مستودع Statnive ضمن دائم التشغيل أو قابل للاستدعاء التلقائي أو يدوي فقط أو fork — واختبار السؤال الواحد الذي نستخدمه لاتّخاذ القرار.
MCP Tool Search: كيف أجّلنا 120 ألف رمز من schemas الأدوات
كان أربعة وعشرون connector من MCP يستهلكان نحو 60% من نافذة سياقنا قبل أي عمل. تشغيل Tool Search خفّض ذلك إلى ~3000 رمز. إليك مخرج /context قبل وبعد، إضافة إلى أنماط الدمج التي ساعدت.
CLAUDE.md لدينا 162 سطرًا. هذا ما فيه — وما حذفناه.
اختصرنا CLAUDE.md في جذر المشروع من 820 إلى 162 سطرًا دون فقدان أي guardrails. الحيلة كانت استبدال البروتوكولات inline بجدول محفّزات للمهارات ونقل قواعد المجال إلى ملفات متداخلة وقواعد path-scoped.
كيف نُصدر Statnive باستخدام Claude Code دون حرق الرموز
ميزانية رموز فعلية لفريق plugin WordPress — أكثر من 80 skill و24 connector MCP ونافذة سياق 200K. ما قِسناه، وما قطعناه، والأرقام الأربعة التي تَحْكُم الآن كل إصدار.
248 اختبارًا، 22 بوابة إصدار، بدون اختصارات: كيف نُصدر Statnive
تشغّل معظم plugins WordPress أداة linter واحدة وتعتبر ذلك كافيًا. يمرّ Statnive عبر 5 طبقات من التحقّق الآلي — من hooks ما قبل الـ commit إلى بوابات الامتثال لـ WordPress.org — قبل أن يُشحن أي إصدار. إليك بالضبط ما نفحصه ولماذا. (الأرقام اعتبارًا من v0.4.9.)
كيف هندسنا Statnive لحمل أداء منخفض
ثلاثة تغييرات معمارية — التحميل async، tracker النواة inline، وidle callbacks — قطعت تأثير LCP في معيار Statnive إلى النصف. إليك القصّة الهندسية والتحفّظات الصادقة.