أمامك ثلاثة مسارات معقولة — build مقابل buy، هذا الـ vendor مقابل ذاك، أن تطلق الآن أم تنتظر ربعًا — ومستند مليء بملاحظات يصعب مقارنة بعضها ببعض. القرارات المتخذة من تلك الكومة تميل إلى اتباع من جادل أخيرًا أو بأعلى صوت. هذا النظام يحوّل الخيارات إلى مقارنة منظّمة، ثم إلى توصية مع تبرير صريح وأكبر مخاطرة في كل مسار. الهدف ليس أن تُسنِد القرار لغيرك — بل أن تدخل وقد اختبرت الخيار تحت الضغط مسبقًا، فتكون مراجعًا لتوصية بدل أن تبدأ من صفحة بيضاء تحت الضغط. يجري بالكامل كمحادثة في Claude Desktop — بلا حاجة إلى Terminal.
- الخيارات مكتوبة — الصقها في المحادثة في Claude Desktop، أو أسقِط ملف
options.mdيضم المرشّحين وكل ما تعرفه عن كلٍ منها (التكلفة، الوقت، من سيمتلكها). الصياغة الخام كافية؛ سيشير Claude إلى الثغرات. - معايير القرار التي تهمّ أنت فعلًا — «نُحسِّن لأجل سرعة الإطلاق هذا الربع، ثم التكلفة، ثم المرونة» — كي تكون التوصية مُوزّنة على طريقتك.
- أي قيود صارمة — سقف ميزانية، موعد نهائي، integration لا غنى عنه — تستبعد خيارات أو تثبّتها قبل أن يبدأ التفكير.
-
اطلب من Claude أن يعيد صياغة القرار وثغراته
قبل مقارنة أي شيء، اجعل Claude يعيد صياغة ما يُقرَّر فعلًا ويشير إلى ما هو ناقص. توصية مبنية على سؤال أُسيء فهمه أو خانات فارغة أسوأ من لا توصية إطلاقًا.
أنت تطلبهذه خياراتنا في options.md. قبل أن توصي بأي شيء، أخبرني: ما القرار الذي نتخذه فعلًا، وما الخيارات الحقيقية، وما المعلومة المفتاحية الناقصة (MISSING) التي سأحتاجها كي أختار باقتدار؟ لا تختر بعد.ما تحصل عليه إعادة صياغة نظيفة مع قائمة بالثغرات — «أنت تقرّر ما إذا كنت ستبني الفوترة داخليًا أم تستخدم vendor؛ الناقص: رسوم الـ vendor لكل معاملة عند حجمنا، وكم وقتًا هندسيًا يكلّفه البناء فعلًا». املأ الثغرات قبل أن تثق بأي توصية.
توصية فوق بيانات ناقصة ليست إلا تخمينًا واثقًا. اجعل Claude يسمّي الخانات الفارغة أولًا.
-
ضع المفاضلات جنبًا إلى جنب
جدول مقارنة بمعاييرك أنت يُجبر كل خيار على أن يُحكَم عليه على المحاور نفسها، بدل أن يُوصَف كلٌ بألفاظه المُجامِلة الخاصة.
أنت تطلبالآن ضع الخيارات جنبًا إلى جنب كجدول، مُقيَّمةً وفق معاييرنا بترتيب الأولوية: سرعة الإطلاق، ثم التكلفة، ثم المرونة. صف واحد لكل خيار، عمود واحد لكل معيار، إضافة إلى «لماذا» قصيرة في كل خانة. كن صادقًا حيث يكون الخيار ضعيفًا — لا تُسطّح الفروقات.ما تحصل عليه جدول مقارنة سهل المسح — «Build: بطيء في الإطلاق، تكلفة جارية منخفضة، أقصى مرونة؛ Vendor A: سريع، تكلفة عالية لكل معاملة، تخصيص محدود» — مع سطر «لماذا» واحد في كل خانة. الفروقات ظاهرة بنظرة واحدة.
-
احصل على توصية مع تبريرها وأكبر مخاطرة في كل مسار
التبرير هو بيت القصيد. توصية لا ترى منطقها هي توصية لا تستطيع الدفاع عنها في القاعة — ومخاطرة كل خيار هي ما ستُسأل عنه.
أنت تطلببالنظر إلى أولوياتنا، أوصِ بخيار واحد. اشرح لي لماذا (WHY) يتفوق على معاييرنا، وما الذي نتنازل عنه باختياره، وأكبر مخاطرة واحدة في كل (EACH) خيار لو اخترناه. ثم أخبرني بما يجب أن يكون صحيحًا كي تنقلب توصيتك.ما تحصل عليه اختيار مُعلَّل — «أوصي بـ Vendor A: المسار الوحيد الذي يُطلق هذا الربع، أولويتنا الأولى؛ نتنازل عن ~X$ سنويًا وبعض المرونة. أكبر المخاطر — Build: تجاوز الوقت الهندسي؛ Vendor A: الـ lock-in؛ Vendor B: ثغرة في الـ integration. ينقلب هذا إلى Build إذا توقفت السرعة عن كونها الأولوية الأولى».
سطر «ما الذي سيقلب هذا» هو أنفع جملة في المذكّرة — يخبرك بالضبط أي افتراض ينبغي أن تختبره تحت الضغط قبل الالتزام.
-
اختبره بأسلوب الـ red-team، ثم اكتب المذكّرة
اجعل Claude يجادل ضد توصيته نفسها قبل أن تغلّفها. اختيار ينجو من أقوى حجة مضادة لنفسه هو اختيار تستطيع الدفاع عنه فعلًا.
أنت تطلبالآن قدّم أقوى حجة ضد (AGAINST) توصيتك — ماذا سيقول متشكّك ذكي؟ ثم اجمع مذكّرة قرار من صفحة واحدة: القرار، جدول الخيارات، التوصية مع تبريرها، أكبر مخاطرة في كل مسار، والأسئلة المفتوحة التي ينبغي أن أحسمها قبل الالتزام.ما تحصل عليه تقويةٌ مختصرة لوجهة النظر المعارضة (steelman)، ثم مذكّرة نظيفة من صفحة واحدة يمكنك تعميمها — القرار، الجدول، التوصية المُعلَّلة، مخاطر كل مسار، والأسئلة المفتوحة. قابلة للدفاع لأنها واجهت بالفعل أفضل حجة مضادة لها.
- Build مقابل buy على الـ stack الخاص بك: حين يكون أحد الخيارات «نبنيها بأنفسنا»، شغّل أولًا اقرأ codebase الخاص بك بالإنجليزية البسيطة كي يكون تقدير البناء مبنيًا على ما سيمسّه فعلًا، لا على تخمين.
- مخاطرة أعلى: لقرار كبير غير قابل للعكس، اجعل Claude يجري المقارنة من منظورين متضادّين (مثلًا CFO حذِر ومؤسِّس متعطّش للنمو) ويوفّق بينهما حيث يختلفان.
- شكل مذكّرة قابل لإعادة الاستخدام (مسار `Power Track`): إن كنت تتخذ هذه القرارات كثيرًا، احفظ البنية كأمر مخصّص
/decision-memo(انظر تبويب Capabilities) كي يحظى كل قرار بالمعاملة الصارمة نفسها. الأوامر المخصّصة خطوة اختيارية في مسارPower Track— على Claude Desktop يمكنك إبقاء قالب المذكّرة في ملاحظة ولصقه بدلًا من ذلك.
- Claude يوصي؛ أنت تقرّر. المذكّرة مراجعةٌ لقرار تمتلكه أنت — توصيتها مُدخَلٌ مُوزَّنٌ بأولوياتك أنت، وليست الحُكم النهائي أبدًا. لا تُسنِد الحكم للفقرة الواثقة.
- تحقّق من الأرقام التي تقود الاختيار. توصية مبنية على تكلفة خاطئة أو رسم vendor مهلوس هي خاطئة مهما كان التبرير نظيفًا — راجع الأرقام في الجدول مقابل مصدرها، لا مقابل ما يستذكره Claude.
- إن تضمّنت الخيارات شروطًا سرية — تسعير vendor، عقود شركاء، بيانات مالية — فاستبدل التفاصيل بـ
[redacted]أو أبقها في بيئتك المُعتمَدة؛ مذكّرة القرار هي بالضبط نوع المستند الذي يُعاد توجيهه.
ستحصل في النهاية على مذكّرة قرار من صفحة واحدة — خيارات مقارَنة على معاييرك، توصية مع تبريرها، أكبر مخاطرة في كل مسار، وما الذي سيقلب القرار — كي تلتزم بقرار اختبرته تحت الضغط مسبقًا، لا قرار تتخذه في القاعة.
أسئلة يطرحها الناس
- ما الذي أحتاج تجهيزه قبل البدء؟
- اكتب خياراتك في ملف `options.md` — المرشّحون وكل ما تعرفه عن كلٍ منها (التكلفة، الوقت، من سيمتلكها). اكتب أيضًا معايير قرارك بترتيب الأولوية وأي قيود صارمة تستبعد خيارات أو تثبّتها. الملاحظات الخام كافية؛ سيشير Claude إلى الثغرات قبل أن يوصي بأي شيء.
- كيف أضمن أن تكون التوصية مُوزَّنة نحو أولوياتي، لا الافتراضيات؟
- اذكر معاييرك صراحةً وبترتيب الأولوية — مثلًا «نُحسِّن لأجل سرعة الإطلاق هذا الربع، ثم التكلفة، ثم المرونة» — قبل طلب المقارنة. التوصية مُوزَّنة فقط بقدر الأولويات التي تعطيها؛ إن لم تسمِّها، سيستنتجها Claude وقد يخطئ.
- هل أثق بالأرقام في جدول مقارنة Claude؟
- تحقّق منها مقابل المصدر قبل تعميم المذكّرة. توصية مبنية على رقم تكلفة خاطئ أو رسم vendor مهلوس هي خاطئة بصرف النظر عن نظافة التبرير — راجع كل رقم في الجدول مقابل بياناتك الفعلية، لا مقابل ما يستذكره Claude.
- هل أستطيع استخدام هذا لقرار build مقابل buy حيث أحد الخيارات هو البناء بأنفسنا؟
- نعم، ويعمل بأفضل ما يكون حين تقرنه أولًا بـ playbook اقرأ الـ codebase — كي يكون تقدير البناء مبنيًا على ما ستمسّه الميزة فعلًا في كودك، لا رقمًا اخترعته. ذلك التقدير المحدَّد النطاق يذهب مباشرةً إلى `options.md` كتكلفة ووقت لخيار البناء.