المشروع الختامي — نقل أمر واحد عبر 8 نماذج
تأطير التوصية
الـcapture بيانات. الـscoreboard تحليل. التوصية قرار. القرارات بتنزل ولا ما بتنزلش بناءً على الـframing. أهو الـpattern بتاع الـframing اللي بشكل ثابت بيـsurvive مراجعة القيادة.
الـ4 جمل اللي بتفرق
كل توصية في التقرير بتاعك المفروض تكون قابلة للتعبير عنها في 4 جمل بالظبط. لو ما تقدرش، إنت لسه ما خلّصتش تفكير.
- اللي بنغيّره. "حوّل الـcustomer-reply prompt من Claude Sonnet 4.5 لـGPT-4o-mini."
- اللي متوقّعين نكسبه. "التخفيض المقدّر في الـmonthly API spend: $4,200، بناءً على الـvolume الحالي 1.2M request في الشهر."
- اللي متوقّعين نخسره. "الـquality scores على rubric الـ20-input بتاعنا بتنزل من 2.85 لـ2.74 average — في نطاق noise بتاع human reviewer disagreement."
- إزاي بنعرف لو غلطنا. "لو complaint rate للـAI-generated replies طلع أكتر من 0.3 نقطة مئوية في أول 14 يوم، بنرجع."
كل جملة فيها رقم. كل جملة قابلة للدحض. كل جملة تقدر تتفق ولا تختلف عليها لوحدها.
ليه الـformat ده شغّال
reviewers القيادة بيفشّلوا التوصيات لأسباب متوقعة. ما بيقدروش يعرفوا اللي بيتقرر ("بنحوّل كل النماذج ولا واحد بس؟"). ما بيقدروش يعرفوا حجم الـupside ("ده $50 في الشهر ولا $50,000؟"). ما بيقدروش يعرفوا الـrisk ("لو ده فشل، إيه هيحصل للمستخدمين؟"). ما بيقدروش يعرفوا إمتى نراجع ("إزاي بنعرف ده شغّال؟").
format الـ4 جمل بيتعامل مع كل failure مباشرة. مش الـformat الوحيد اللي شغّال، بس الأبسط اللي شغّال.
3 حاجات بتقتل التوصيات
1. "اختبرنا كذا نموذج و Claude كان الأفضل." ده مش توصية؛ ده ملاحظة. مفيش action متعلّق بيها. ضيف الـaction: "...فبنحوّل X لـClaude" أو "...فبنخلّي X على Claude". الـ"فـ" دي بتفرق.
2. توصيات من غير downside. لو التقرير بتاعك بيقول "التغيير ده ما لوش downside، المفروض نشحنه"، القيادة مش هتصدّقك. كل تغيير له downside. لو ما تقدرش تسمّي واحد، ما بصّيتش. downsides شائعة: vendor lock-in أكتر، سلوك أقل قابل للتنبؤ، جودة أقل شوية على edge cases، زيادة في الـlatency.
3. توصيات معتمدة على شروط بره سيطرتك. "المفروض نحوّل طول ما Anthropic ما رفعتش الأسعار" مش توصية، دي أمنية. خد موقف على هتعمل إيه لو الافتراض اتكسر.
لما الإجابة تبقى "ما تغيّرش"
أحياناً الإجابة الصح لسؤال الـCTO هي "لأ". المشروع الختامي مش متحيّز لإنتاج تحويل — هو متحيّز لإنتاج قرار. لو مقارنة الـ8 نماذج بتاعتك بتورّي إن Claude فعلاً النموذج المناسب للـprompt والتكلفة مبرّرة بالـquality، اشحن التوصية دي:
"خلّي [المهمة] على Claude Sonnet 4.5. اختبرنا 7 بدائل؛ أقرب منافس scored 2.4 قبال 2.85 لـClaude، مع downstream user-impact مقدّر بـ-7% conversion. الـpremium بـ$0.0027 لكل request مبرّر بـquality delta على الـprompt ده."
التوصية دي ليها قيمة زي التحويل. بتدافع عن الـcurrent spend بالـevidence وبتوثّق الـreasoning عشان السؤال ما يتعادش طرحه الـquarter الجاي.
الحركة الأخيرة بتاعت هاجر
هاجر بتدخل ستاند أب الاتنين الجاي. بتقدّم التقرير. الـCTO بيقرا القسم الأول في 15 ثانية. بيسأل سؤالين توضيحيين. بيوافق على تغيير الـrouting. الـPR بيتـmerge بعد الظهر. الـshadow rollout بيبدأ نفس اليوم.
3 أسابيع بعدين، الـmetrics بتأكّد التنبؤ. التوفير حقيقي. الـquality regression في الـnoise. المشروع التالي بتاع هاجر على الـstack.
دي الحلقة اللي الكورس ده اتبنى عشانها. 3 frontier APIs جنب بعض. 8 نماذج في المشروع الختامي. تقرير واحد. قرار واحد. PR واحد.
الكورس بينتهي هنا. المشروع الختامي مستمر — لقدّ ما الـapp بتاعك بيبعت prompts. :::
سجّل الدخول للتقييم