صيغة توفير التكلفة في Vibe Coding ونقطة التحول

يمكن تصنيف نماذج تسعير أدوات البرمجة بالذكاء الاصطناعي إلى ثلاثة أنواع:

1. الدفع حسب الرمز: يشمل مختلف الواجهات البرمجية للتطبيقات، Claude Code (Claude Pro)، Codex Cli (ChatGPT Plus)، Zhipu Lite/Pro، Cursor الإصدار الجديد وما إلى ذلك. في الأساس كلها تسعير حسب الرمز، وتوفر بعض المنتجات خصومات الحزم.
2. الدفع حسب عدد استدعاءات الواجهة البرمجية للتطبيقات: مثل OpenRouter (الرصيد المجاني)، ModelScope، Gemini Code Assistant (1000 استدعاء مجانًا يوميًا)، Chutes وما إلى ذلك.
3. الدفع حسب عدد الموجهات: مثل Cursor الإصدار القديم (500 استدعاء)، Github Copilot (300 استدعاء) وما إلى ذلك.

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

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

دالة التكلفة الإجمالية الموحدة

لأداة i في دورة فوترة، يمكن كتابة التكلفة الإجمالية كالتالي:

$$ \begin{aligned} \mathrm{Total}_i &= \mathrm{Cash}_i + \mathrm{Time}_i + \mathrm{Risk}_i \ \mathrm{Time}_i &= R \cdot \mathrm{Hours}_i \ \mathrm{Risk}_i &= R \cdot \mathrm{ReworkHours}_i \end{aligned} $$

حيث R هو سعر وقتك (يوان/ساعة). إذا كنت لا تريد احتساب الوقت، يمكنك ضبط R على 0، وستتحول الصيغة إلى مقارنة تكلفة نقدية بحتة.

اتفاقية المتغيرات

لتوحيد نماذج التسعير الثلاثة، يتم تقسيم عبء العمل إلى مستويين: “جلسة (session)” و"تكرار (iteration)". الفحص والفهرسة عند دخول مشروع جديد هو عملية لمرة واحدة، والحوار المستمر والتعديلات البرمجية ضمن نفس السياق هي عمليات قابلة للتكرار.

تعريف المتغيرات:

• $S_i$: الرسوم الثابتة للأداة $i$ (رسوم الاشتراك أو الحد الأدنى الشهري)
• $N_s$: عدد الجلسات الجديدة في هذه الدورة (التبديل بين المشاريع، مسح السياق، بدء جلسات جديدة كلها تُحسب)
• $N_{it}$: عدد مرات التكرار الفعالة في هذه الدورة (توضيح المتطلبات، تعديل الكود، إصلاح الأخطاء وما إلى ذلك)
• $R$: سعر الوقت (يوان/ساعة)
• $h0_i$: الوقت المستغرق لبدء جلسة جديدة (بالساعات)
• $h1_i$: متوسط الوقت المستغرق لكل تكرار (بالساعات)
• $p_{\mathrm{fail},i}$: احتمال فشل كل تكرار واحتياج إلى إعادة العمل (من 0 إلى 1)
• $h_{\mathrm{re},i}$: متوسط الوقت المستغرق لإعادة العمل مرة واحدة (بالساعات)

وبالتالي يمكن كتابة العناصر الزمنية وعنصرا المخاطر كالتالي:

$$ \begin{aligned} \mathrm{Hours}i &= N_s \cdot h0_i + N{it} \cdot h1_i \ \mathrm{ReworkHours}i &= N{it} \cdot p_{\mathrm{fail},i} \cdot h_{\mathrm{re},i} \end{aligned} $$

الآن فقط نحتاج إلى كتابة $Cash_i$ للطرق الثلاث للتسعير.

التكلفة النقدية للتسعير حسب الرمز

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

تعريف المتغيرات:

• $Tin0_i$: إجمالي رموز الإدخال لكل جلسة جديدة
• $r0_i \in [0,1]$: نسبة ضربة التخزين المؤقت للإدخال في الجلسة الجديدة
• $Tin1_i$: إجمالي رموز الإدخال لكل تكرار
• $r1_i \in [0,1]$: نسبة ضربة التخزين المؤقت للإدخال في التكرار
• $Tout0_i, Tout1_i$: كمية الرموز الخارجة
• $Pin_i, Pcache_i, Pout_i$: معلمات السعر (يوان/مليون رمز)

للأدوات التي لا تدعم تسعير التخزين المؤقت، يمكن ضبط $r0_i=r1_i=0$ أو $Pcache_i=Pin_i$.

وبالتالي:

$$ \begin{aligned} \mathrm{Cash}^{(\mathrm{token})}i &= S_i + \frac{1}{10^6}\Bigl[ N_s \cdot \bigl(Pin_i \cdot (1-r0_i)\cdot Tin0_i + Pcache_i \cdot r0_i\cdot Tin0_i + Pout_i \cdot Tout0_i\bigr) \ &\qquad + N{it} \cdot \bigl(Pin_i \cdot (1-r1_i)\cdot Tin1_i + Pcache_i \cdot r1_i\cdot Tin1_i + Pout_i \cdot Tout1_i\bigr) \Bigr] \end{aligned} $$

هذه الصيغة تفسر مباشرةً استنتاجًا تجريبيًا: العمل الغامر المستمر في نفس الجلسة، حيث يزداد $N_{it}$ ولكن $Tin0_i$ تدفع مرة واحدة فقط، يؤدي إلى انخفاض التكلفة المتوسطة لكل تكرار. يؤدي التبديل المتكرر بين المشاريع أو مسح السياق بشكل متكرر إلى دفع $Tin0_i$ بشكل متكرر.

التكلفة النقدية للتسعير حسب عدد استدعاءات الواجهة البرمجية للتطبيقات

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

• $A0_i$: عدد استدعاءات الواجهة البرمجية للتطبيقات لكل جلسة جديدة
• $A1_i$: عدد استدعاءات الواجهة البرمجية للتطبيقات لكل تكرار
• $Ccall_i$: سعر كل استدعاء (يوان/استدعاء)

صيغة التكلفة النقدية:

$$ \mathrm{Cash}^{(\mathrm{call})}i = S_i + Ccall_i \cdot (N_s \cdot A0_i + N{it} \cdot A1_i) $$

إذا قدمت الأداة رصيدًا مجانيًا Q (استدعاءات/دورة) ويتطلب تجاوز الحد الانتظار بدل الدفع، يمكن احتساب وقت الانتظار في تكلفة الوقت، وتحويل الاستدعاءات الزائدة إلى $Hours_i$، واستخدام $Total_i$ للمقارنة.

التكلفة النقدية للتسعير حسب عدد الموجهات

يُساوي التسعير حسب عدد الموجهات “موجهًا واحدًا” بـ “إرسال مهمة واحدة”. من الضروري تقدير:

• $P0_i$: عدد الموجهات لكل جلسة جديدة
• $P1_i$: عدد الموجهات لكل تكرار
• $Cprompt_i$: سعر كل موجه (يوان/موجه)

صيغة التكلفة النقدية:

$$ \mathrm{Cash}^{(\mathrm{prompt})}i = S_i + Cprompt_i \cdot (N_s \cdot P0_i + N{it} \cdot P1_i) $$

للمنتجات “الاشتراك الشهري مع N موجهات”، يمكن استخدام السعر الظل (shadow price) للتقريب: افترض أن رسوم الاشتراك في الدورة هي $S_i$، والحد هو $Q_i$، إذًا $Cprompt_i \approx S_i / Q_i$. على الرغم من أنه ليس تكلفة نقدية هامشية صارمة، إلا أنه يمكن تحويل “ندرة الحصص” إلى تكلفة فرصة قابلة للحساب.

نقطة التحول: صيغة خط الفصل بين أداتين

اكتب الصيغة أعلاه بشكل موحد. للأداة i:

$$ \mathrm{Total}_i = S_i

• N_s \cdot (c0_i + R \cdot h0_i)
• N_{it} \cdot (c1_i + R \cdot h1_i + R \cdot p_{\mathrm{fail},i} \cdot h_{\mathrm{re},i}) $$

حيث $c0_i$, $c1_i$ تمثل التكلفة النقدية للبدء البارد والتكرار الواحد، وتناظر التوسعات المختلفة في نماذج التسعير الثلاثة.

بالنظر إلى أدتين A و B، مع $N_s$ ثابت، اجعل $Total_A$ = $Total_B$، يمكن حل نقطة التحول لعدد التكرارات:

$$ N_{it}^{\ast}

\frac{ (S_B - S_A) + N_s \cdot \bigl((c0_B - c0_A) + R \cdot (h0_B - h0_A)\bigr) }{ (c1_A - c1_B) + R \cdot (h1_A - h1_B)

• R \cdot \bigl(p_{\mathrm{fail},A} \cdot h_{\mathrm{re},A} - p_{\mathrm{fail},B} \cdot h_{\mathrm{re},B}\bigr) } $$

التفسير:

عندما يكون المقام موجبًا، إذا كان $N_{it} > N_{it}^{\ast}$ فإن A أفضل، وإذا كان $N_{it} < N_{it}^{\ast}$ فإن B أفضل. عندما يكون المقام سالبًا، تكون إشارة عدم المساواة عكسية. عندما يكون المقام قريبًا من 0، يعني ذلك أن التكلفة الهامشية الإجمالية لكل تكرار متشابهة جدًا بين الاثنين، ويكون الاختيار يعتمد بشكل أساسي على التكلفة الثابتة وتكلفة البدء البارد.

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

استراتيجيات عملية: أساليب خفض التكلفة

1. التطوير الغامر: استراتيجية تحسين التسعير حسب الرمز

للأدوات المدفوعة حسب الرمز (مثل Codex Cli)، فإن الاستراتيجية الأساسية هي الحفاظ على استقرار سياق العمل.

المبدأ: تجنب دفع $Tin0_i$ بشكل متكرر. يمكن للعمل المستمر ضمن نفس المشروع أن يوزع تكلفة تحميل السياق الأولي، كما أن تحسين معدل ضربة التخزين المؤقت يمكن أن يسرّع بشكل كبير من وقت الاستجابة.

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

2. دمج المتطلبات: استراتيجية تحسين التسعير حسب استدعاءات الواجهة البرمجية للتطبيقات

للأدوات المدفوعة حسب عدد الاستدعاءات (مثل Gemini Code Assistant)، فإن الاستراتيجية الأساسية هي الاستفادة القصوى من عدد الاستدعاءات لـ “إنشاء السياق”.

المبدأ: توزيع تكلفة $A0_i$. يتم احتساب استدعاءات الأدوات، وقراءة الملفات، وغيرها من العمليات ضمن عدد الاستدعاءات.

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

3. معالجة المهام الكبيرة: استراتيجية تحسين التسعير حسب الموجهات

للأدوات المدفوعة حسب عدد الموجهات (مثل Cursor الإصدار القديم)، فهي مناسبة لمعالجة المهام الكبيرة أو الصيانة الباردة.

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

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

تدفق اختيار قابل للحساب

يرسم مخطط التدفق أدناه خريطة للمتغيرات إلى منطق الاختيار. بعد تقدير مستوى $N_s$ و $N_{it}$، استخدم صيغة $N_it*$ للمقارنة لتحديد الحل الأمثل.

flowchart TD
    A[تعريف عبء العمل لهذه الدورة] --> B[تقدير N_s: عدد الجلسات الجديدة]
    B --> C[تقدير N_it: عدد التكرارات لكل جلسة]
    C --> D[تقدير c0, c1 لكل نوع أداة]
    D --> E[إدخال صيغة N_it*]
    E --> F{شكل العبء الرئيسي؟}
    F -->|N_s كبير، N_it صغير| G[الأولوية: الدفع بالمرة أو الدفع حسب عدد الاستدعاءات]
    F -->|N_s صغير، N_it كبير| H[الأولوية: الدفع حسب الرمز]
    F -->|كلاهما كبير| I[تقسيم سير العمل: البدء البارد باستخدام الدفع بالمرة/الاستدعاءات، المرحلة العميقة باستخدام الدفع حسب الرمز]

    classDef in fill:#2c3e50,stroke:#ecf0f1,stroke-width:2px,color:#ecf0f1
    classDef calc fill:#3498db,stroke:#2980b9,stroke-width:2px,color:#fff
    classDef decide fill:#f39c12,stroke:#d35400,stroke-width:2px,color:#fff
    classDef out fill:#27ae60,stroke:#229954,stroke-width:2px,color:#fff

    class A,B,C in
    class D,E calc
    class F decide
    class G,H,I out

• ←السابق
• التالي→