16 نوفمبر 2025·3 دقيقة
أنماط التوجيه لهندسة برمجيات أنظف وإعادة كتابة أقل
تعلّم أنماط توجيه مجرّبة توجه الذكاء الاصطناعي نحو متطلبات أوضح، تصاميم مُجزّأة، وكود قابل للاختبار — مما يقلل عمليات إعادة الهيكلة وإعادة الكتابة.
تعلّم أنماط توجيه مجرّبة توجه الذكاء الاصطناعي نحو متطلبات أوضح، تصاميم مُجزّأة، وكود قابل للاختبار — مما يقلل عمليات إعادة الهيكلة وإعادة الكتابة.
«الهندسة الأنظف» في هذا المقال لا تعني إطار عمل معين أو مخطط مثالي. تعني أن بإمكانك شرح النظام ببساطة، تغييره دون كسر أجزاء غير متعلقة، والتحقق من السلوك دون اختبارات بطول العمر.
الوضوح يعني أن الغرض وشكل النظام واضحان من وصف قصير: ما الذي يفعله، من يستخدمه، ما البيانات التي يتعامل معها، وما الذي يجب ألا يفعله أبداً. في العمل بمساعدة الذكاء الاصطناعي، يعني الوضوح أيضاً أن النموذج يستطيع إعادة صياغة المتطلبات بطريقة يمكنك الموافقة عليها.
التجزيء يعني أن المسؤوليات لها حدود واضحة. لكل وحدة وظيفة، مدخلات/مخرجات، ومعرفة قليلة عن داخل الوحدات الأخرى. عندما يولّد الذكاء الاصطناعي كوداً، فإن التجزيء يمنع نشور قواعد العمل عبر المتحكمات، الواجهة، ووصول البيانات.
القابلية للاختبار تعني أن البنية تجعل من "إثبات عملها" رخيصاً. يمكن اختبار قواعد العمل دون نظام تشغيل كامل، وتتركز اختبارات التكامل على عقود قليلة بدل كل مسار كود.
عادة لا تُسبب إعادة الكتابة "كود سيئ" بحد ذاته — بل يُسببها القيود المفقودة، نطاق غامض، وافتراضات خفية. أمثلة:
يمكن للذكاء الاصطناعي أن يسرّع هذا النمط الفاشل بإنتاج مخرجات مقنعة بسرعة، مما يجعل من السهل البناء على أساسات هشة.
الأنماط التالية هي قوالب قابلة للتكييف وليست مطالبات سحرية. الهدف الحقيقي هو إجبار المحادثات الصحيحة مبكراً: توضيح القيود، مقارنة الخيارات، توثيق الافتراضات، وتعريف العقود. إذا تخطيت هذا التفكير، سيملأ النموذج الفراغات بسرور — وستدفع ثمن ذلك لاحقاً.
ستستخدمها عبر دورة التسليم كاملة:
إذا كنت تستخدم سير عمل يعتمد على التوليد التفاعلي (حيث يُولَّد النظام ويتكرر عبر الدردشة)، فهذه نقاط التفتيش تصبح أكثر أهمية. على سبيل المثال، في Koder.ai يمكنك تشغيل حلقة "وضع التخطيط" لتثبيت المتطلبات والعقود قبل توليد كود React/Go/PostgreSQL، ثم استخدام لقطات/التراجع للتكرار بأمان عند تغير الافتراضات — دون أن تُحوِّل كل تغيير إلى إعادة كتابة.
قيمة أنماط التوجيه تكمن في تقليل تذبذب القرارات. الحيلة هي استخدامها كنقاط تفتيش قصيرة ومتكررة — قبل البرمجة، أثناء التصميم، وأثناء المراجعة — ليُنتج الذكاء الاصطناعي مخرجات قابلة لإعادة الاستخدام، لا نصوصاً إضافية عليك غربلتها.
قبل البرمجة: شغّل حلقة "المواءمة" لتأكيد الأهداف، المستخدمين، القيود، ومعايير النجاح.
أثناء التصميم: استخدم أنماط تجبر التنازلات الصريحة (مثل البدائل، المخاطر، حدود البيانات) قبل البدء بالتنفيذ.
أثناء المراجعة: استخدم مطالبة على شكل قائمة تدقيق للكشف عن الفجوات (حالات الحافة، المراقبة، الأمان، الأداء) بينما التغييرات لا تزال رخيصة.
ستحصل على مخرجات أفضل بحزمة مدخلات صغيرة ومتسقة:
إذا لم تكن تعرف شيئاً، اذكر ذلك صراحة واطلب من الذكاء الاصطناعي سرد الافتراضات.
بدلاً من "فسّر التصميم"، اطلب مخرجات يمكنك لصقها في مستندات أو تذاكر:
قم بدورات 10–15 دقيقة: مطالبة → مسح سريع → ضيق. دائمًا تضمّن معايير القبول (ما الذي يجب أن يكون صحيحاً ليكون التصميم مقبولاً)، ثم اطلب من الذكاء الاصطناعي أن يفحص نفسه مقابلها. هذا يمنع العملية من الانزلاق إلى إعادة تصميم لا نهائية ويجعل الأنماط التالية سريعة التطبيق.
معظم "إعادات بناء الهندسة" لا تُسبَّبها مخططات سيئة — تُسبَّب ببناء الشيء الصحيح للمشكلة الخاطئة (أو الناقصة). عند استخدام LLM مبكراً، لا تطلب الهندسة أولاً. اجعله يكشف الغموض.
استخدم النموذج كمقابل متطلبات. هدفك هو مواصفة قصيرة ذات أولوية يمكنك تأكيدها قبل أن يصمم أحد المكوّنات، يختار قواعد البيانات، أو يلتزم بواجهات برمجة.
إليك قالب يمكنك نسخه ولصقه:
You are my requirements analyst. Before proposing any architecture, do this:
1) Ask 10–15 clarifying questions about missing requirements and assumptions.
- Group questions by: users, workflows, data, integrations, security/compliance, scale, operations.
2) Produce a prioritized scope list:
- Must-have
- Nice-to-have
- Explicitly out-of-scope
3) List constraints I must confirm:
- Performance (latency/throughput targets)
- Cost limits
- Security/privacy
- Compliance (e.g., SOC2, HIPAA, GDPR)
- Timeline and team size
4) End with: “Restate the final spec in exactly 10 bullets for confirmation.”
Context:
- Product idea:
- Target users:
- Success metrics:
- Existing systems (if any):
### ما الذي تبحث عنه في المخرجات
تريد أسئلة تُجبِر على اتخاذ قرارات (لا "أخبرني أكثر" العامة)، بالإضافة إلى قائمة "ضروري" قابلة للإنهاء ضمن الجدول الزمني. اعتبر إعادة صياغة الـ"10 نقاط" كعقد: الصقها في تذكرة/PR، احصل على نعم/لا من أصحاب المصلحة، ثم انتقل للتصميم. خطوة واحدة تمنع السبب الأكثر شيوعاً لإعادة التصميم المتأخرة: بناء ميزات لم تكن مطلوبة حقاً.
## النمط 2: رحلات المستخدم أولاً، ثم الاختيارات التقنية
عندما تبدأ بالأدوات ("هل نستخدم event sourcing؟") غالباً ما تصمم على أساس الهندسة بدل المستخدم. طريق أسرع للهيكل النظيف هو طلب النموذج لوصف رحلات المستخدم أولاً بلغة بسيطة، ثم ترجمة تلك الرحلات إلى مكونات وبيانات وواجهات برمجة.
### قالب مطالبة بسيط يركز على الرحلات
استخدم هذا كنقطة بداية قابلة للنسخ:
- **الأدوار:** مستخدم / مشرف / نظام
- **الإجراءات الرئيسية:** ما يسعى كل دور لإنجازه
- **حالات الحافة:** ما الذي يمكن أن يخطئ (مدخل غير صالح، أذونات مفقودة، إكمال جزئي)
ثم اطلب:
1) "وصف تدفق خطوة بخطوة لكل إجراء بلغة بسيطة."
2) "قدّم مخطط حالة بسيط أو قائمة حالات (مثلاً: Draft → Submitted → Approved → Archived)."
3) "سجل سيناريوهات غير المسار السعيد: مهلات، محاولات إعادة، طلبات مكررة، إلغاءات، ومدخلات غير صالحة."
### تحويل الرحلات إلى قرارات (دون القفز مقدماً)
بمجرد وضوح التدفقات، يمكنك أن تطلب من الذكاء الاصطناعي ربطها بالاختيارات التقنية:
- أين نحتاج **التحقق** مقابل **قواعد العمل**؟
- أي خطوات تتطلب **idempotency** (محاولات آمنة)؟
- ما البيانات التي يجب **تخزينها**، وما الذي يمكن اشتقاقه، وما الذي يحتاج سجل تدقيق؟
فقط بعد ذلك اطلب مخطط هندسي (خدمات/وحدات، حدود، ومسؤوليات) مرتبط مباشرة بخطوات التدفق.
### حول التدفقات إلى معايير قبول قابلة للاختبار
اختم بأن تطلب من الذكاء الاصطناعي تحويل كل رحلة إلى معايير قبول يمكنك اختبارها فعلياً:
- "Given/When/Then لكل خطوة وحالة فشل."
- "ماذا يجب أن يُرجع النظام أو يعرض؟"
- "ماذا يجب تسجيله، ومتى يجب أن يؤدي إلى محاولة إعادة أو خطأ يظهر للمستخدم؟"
هذا النمط يقلل إعادة الكتابة لأن الهندسة تنمو من سلوك المستخدم — لا من افتراضات حول التقنية.
## النمط 3: سجل الافتراضات لمنع مفاجآت إعادة الكتابة
معظم إعادة العمل لا تُسبَّب بتصميم سيئ بقدر ما تُسبَّب بالافتراضات الخفية التي تتبين لاحقاً خطأ. عندما تطلب من LLM بنية، غالباً ما يملأ الثغرات بتخمينات معقولة. يجعل سجل الافتراضات تلك التخمينات مرئية مبكراً، حين تكون التغييرات رخيصة.
### ماذا تطلب من النموذج أن يفعل
هدفك فصل واضح بين **الحقائق التي قدمتها** و**الافتراضات التي اختلقها**. استخدم نمط المطالبة التالي:
> **Template prompt**
> “Before proposing any solution: list your assumptions. Mark each as **validated** (explicitly stated by me) or **unknown** (you inferred it). For each unknown assumption, propose a fast way to validate it (question to ask, metric to check, or quick experiment). Then design based only on validated assumptions, and call out where unknowns could change the design.”
### قالب«سجل الافتراضات» القابل لإعادة الاستخدام
اجعله قصيراً حتى يستخدمه الناس فعلياً:
- **Assumption:** …
- **Status:** validated / unknown
- **Why it matters:** what decision it affects
- **How to validate:** question, check, or spike
- **If wrong, likely change:** what you’d redesign
### محفزات "ما الذي سيغير إجابتك؟"
أضف سطر واحد يطلب من النموذج إخراج نقاط التحول:
- “List 5 triggers: **what would change your answer?** (e.g., user volume, latency targets, compliance needs, data retention rules).”
هذا النمط يحوّل الهندسة إلى مجموعة قرارات شرطية. لا تحصل على مخطط فقط — تحصل على خريطة لما يجب تأكيده قبل الالتزام.
## النمط 4: قارن عدة هندسات قبل اختيار واحدة
أدوات الذكاء الاصطناعي بارعة في إنتاج تصميم "الأفضل" المفترض — لكن هذا غالباً مجرد خيار معقول أول. تظهر الهندسة الأنظف عندما تُجبر على المقارنة مبكراً، بينما التغييرات لا تزال رخيصة.
### قالب المطالبة الأساسي
استخدم مطالبة تطلب *متعدد* من الحلول وجدول مفاضلات منظم:
```text
Propose 2–3 viable architectures for this project.
Compare them in a table with criteria: complexity, reliability, time-to-ship, scalability, cost.
Then recommend one option for our constraints and explain why it wins.
Finally, list “what we are NOT building” in this iteration to keep scope stable.
Context:
- Users and key journeys:
- Constraints (team size, deadlines, budget, compliance):
- Expected load and growth:
- Current systems we must integrate with:
المقارنة تجبر النموذج (وأنت) على إظهار الافتراضات الخفية: أين يعيش الـstate، كيف تتواصل الخدمات، ما الذي يجب أن يكون متزامناً، وما يمكن تأجيله. جدول المعايير يمنع مناقشات "microservices vs monolith" من أن تتحول إلى آراء شخصية، ويُؤسس القرار لما تهتم به فعلاً: الشحن السريع، تقليل عبء التشغيل، أو تحسين الاعتمادية.
لا تقبل "يعتمد" كإجابة. اطلب توصية واضحة والقيود التي تُحسنها. كما أصرّ على "ما الذي لن نبنيه". أمثلة: "لا تفعيل تعافي متعدد المناطق"، "لا نظام إضافات"، "لا إشعارات في الزمن الحقيقي". هذا يمنع الهندسة من التوسع سرياً لدعم ميزات لم تلتزم بها بعد، ويمنع مفاجآت إعادة الكتابة لاحقاً.
معظم عمليات إعادة الكتابة تحدث لأن الحدود كانت غامضة: كل شيء "يتصل بكل شيء"، وتؤثر تغييرات بسيطة على قاعدة الكود بأكملها. هذا النمط يفرض مطالبات تُجبر على ملكية واضحة للوحدات قبل أن يُنقاش الإطار أو مخططات الصفوف.
اطلب من الذكاء الاصطناعي تعريف وحدات ومسؤوليات، وما لا ينتمي لكل وحدة. ثم اطلب واجهات (مدخلات/مخرجات) وقواعد تبعية، لا خطة بناء أو تفاصيل تنفيذ.
استخدم هذا عند رسم ميزة جديدة أو إعادة تنظيم منطقة فوضوية:
أدرج الوحدات مع:
لكل وحدة، عرّف الواجهات فقط:
قواعد التبعية:
اختبار التغيير في المستقبل: مع تلك التغييرات المحتملة: \u003clist 3\u003e، أظهر أي وحدة يجب أن تستوعب كل تغيير ولماذا.
تهدف لوحدات تستطيع وصفها لزميل تنفيذياً في أقل من دقيقة. إذا اقترح النموذج وحدة "Utils" أو وضع قواعد العمل في المتحكمات، اعترض: "انقل اتخاذ القرار إلى وحدة المجال واجعل المحولات رقيقة." عند الانتهاء، لديك حدود تُقاوم متطلبات جديدة — لأن التغييرات لها ملاذ واضح وقواعد تبعية تمنع الاقتران العرضي.
إعادة العمل في التكامل غالباً لا تُسبَّب بـ"كود سيئ" — بل بوضوح العقود. إذا تقرر شكل البيانات وواجهات الـAPI متأخراً، كل فريق (أو وحدة) يملأ الفراغات بشكل مختلف، وتقضي السبرنت التالي في التوفيق بين الافتراضات المختلِفة.
ابدأ بمطالبة تطلب العقود قبل الحديث عن الأطر، قواعد البيانات، أو الميكروخدمات. العقد الواضح يصبح المرجع المشترك الذي يبقي الواجهة الأمامية، الخوادم، وأنابيب البيانات متناغمة.
استخدم هذه المطالبة المبكرة مع مساعدك الذكي:
ثم تابع فوراً بـ:
تريد مستندات ملموسة، وليس نثرًا. مثال:
Subscription
ومخطط API مثال:
POST /v1/subscriptions
{
"customer_id": "cus_123",
"plan_id": "pro_monthly",
"start_date": "2026-01-01"
}
201 Created
{
"id": "sub_456",
"status": "active",
"current_period_end": "2026-02-01"
}
422 Unprocessable Entity
{
"error": {
"code": "VALIDATION_ERROR",
"message": "start_date must be today or later",
"fields": {"start_date": "in_past"}
}
}
اطلب من الذكاء الاصطناعي ذكر قواعد مثل: "الحقول المضافة مسموح بها دون ترقية الإصدار؛ إعادة التسمية تتطلب /v2؛ يجب على العملاء تجاهل الحقول غير المعروفة." هذه الخطوة الواحدة تمنع تغييرات كسرية صامتة — وإعادة الكتابة التي تتبعها.
تُعاد كتابة البنى عندما يلتقي تصميم "المسار السعيد" بحركة حقيقية، تبعيات متقلبة، وسلوك مستخدم غير متوقع. هذا النمط يجعل الاعتمادية مخرج تصميم صريح، لا مشروع بعد الإطلاق.
استخدم هذا مع وصف الهندسة المختارة:
List failure modes; propose mitigations; define observability signals.
For each failure mode:
- What triggers it?
- User impact (what the user experiences)
- Mitigation (design + operational)
- Retries, idempotency, rate limits, timeouts considerations
- Observability: logs/metrics/traces + alert thresholds
ركز الاستجابة بتسمية الواجهات التي قد تفشل: واجهات خارجية، قاعدة البيانات، الطوابير، مزوّد المصادقة، والمهام الخلفية. ثم اطلب قرارات ملموسة:
اختم المطالبة بـ: "أعد قائمة تحقق بسيطة يمكن مراجعتها خلال دقيقتين." تشمل قائمة جيدة عناصر مثل: مهلات التبعيات مضبوطة، المحاولات محدودة، idempotency مُطبّق لعمليات الإنشاء/الخصم، وجود إدارة ضغط/حدود معدل، مسار تدرج لالتفاف الأداء.
اطلب أحداثاً حول لحظات المستخدم (لا مجرد داخلية النظام): "user_signed_up", "checkout_submitted", "payment_confirmed", "report_generated". لكل حدث، اطلب:
هذا يحوّل الاعتمادية إلى مخرج تصميم يمكنك التحقق منه قبل وجود الكود.
طريقة شائعة تجعل التصميم بمساعدة الذكاء الاصطناعي يخلق إعادة كتابة هي تشجيع "الهندسة الكاملة" مبكراً. الحل بسيط: أَجْبر الخطة أن تبدأ بأصغر شريحة قابلة للاستخدام—واحدة تقدم قيمة، تثبت التصميم، وتبقي الخيارات المستقبلية مفتوحة.
استخدم هذا عندما تشعر أن الحل يتوسع أسرع من المتطلبات:
قالب: “Propose the smallest usable slice; define success metrics; list follow-ups.”
اطلب من النموذج الرد بـ:
أضف تعليمات ثانية: "أعط خارطة طريق مرحلية: MVP → v1 → v2، واشرح أي مخاطر يخفف كل مرحلة." هذا يبقي الأفكار المستقبلية مرئية دون إجبارها في الإصدار الأول.
السطر الأقوى في هذا النمط: "أدرج ما هو خارج النطاق صراحةً لـMVP." تحمي الاستثناءات قرارات الهندسة من التعقيد المبكر.
أمثلة جيدة على الاستثناءات:
أخيراً: "حوّل MVP إلى تذاكر، كل واحدة مع معايير قبول وتبعيات." هذا يجبر الوضوح ويكشف الاقترانات الخفية.
تفكيك تذاكر نموذجي جيد يشمل:
إذا رغبت، اطلب من النموذج إخراجها بصيغة سير عمل فريقك (مثلاً حقول على طريقة Jira) واحتفظ بالمراحل اللاحقة كقائمة انتظار منفصلة.
طريقة بسيطة لمنع انحراف الهندسة هي إجبار الوضوح عبر الاختبارات قبل أن تطلب التصميم. عند مطالبة LLM بكتابة اختبارات قبول أولاً، يضطر لتسمية السلوكيات، المدخلات، المخرجات، وحالات الحافة. هذا يكشف المتطلبات الناقصة ويدفع التنفيذ نحو حدود وحدوية واضحة.
استخدم هذا كنقطة بوابة عندما تكون على وشك تصميم مكوّن:
تابع بـ: "جمّع الاختبارات حسب مسؤولية الوحدة (طبقة API، منطق المجال، التخزين، التكاملات الخارجية). لكل مجموعة، حدد ما يُموَّه وما الحقيقي." هذا يحرّك النموذج بعيداً عن تصاميم متشابكة حيث يلمس كل شيء كل شيء. إذا لم يستطع شرح أين تبدأ اختبارات التكامل، فهندستك ربما ليست واضحة بعد.
اطلب: "اقترح خطة بيانات اختبار: fixtures vs factories، كيف تولّد حالات الحافة، وكيف تحافظ على حتمية الاختبارات. أدرج أي تبعيات يمكن أن تستخدم بدائل في الذاكرة وأيها يحتاج خدمة حقيقية في CI." كثيراً ما تكتشف أن ميزة "بسيطة" تحتاج عقداً، مجموعة بيانات أولية، أو معرفات ثابتة — من الأفضل اكتشاف ذلك الآن بدل أثناء إعادة الكتابة.
اختم بقائمة تحقق خفيفة:
لا يجب أن تحدث مراجعات التصميم فقط بعد وجود الكود. باستخدام الذكاء الاصطناعي، يمكنك تشغيل "مراجعة ما قبل المأتم" على مسودة الهندسة (حتى لو كانت فقرة أو وصف مخطط بالكلمات) والحصول على قائمة ملموسة بالضعف قبل أن تصبح إعادة كتابة.
ابدأ بموقف ناقد واجبر التحديد:
Prompt: “Act as a reviewer; list risks, inconsistencies, and missing details in this design. Be concrete. If you can't evaluate something, say what information is missing.”
ألصق ملخَّص التصميم، القيود (الميزانية، الجدول الزمني، مهارات الفريق)، وأي متطلبات غير وظيفية (زمن استجابة، توافر، امتثال).
تفشل المراجعات عندما تكون الملاحظات غامضة. اطلب مجموعة إصلاحات مُرتبة حسب الأولوية:
Prompt: “Give me a prioritized punch list. For each item: severity (Blocker/High/Medium/Low), why it matters, suggested fix, and the smallest validation step.”
هذا ينتج مجموعة مهام جاهزة للقرار بدلاً من نقاش.
أداة مفيدة هي درجة بسيطة:
Prompt: “Assign a rewrite risk score from 1–10. Explain the top 3 drivers. What would reduce the score by 2 points with minimal effort?”
لا تبحث عن دقة مفرطة؛ هدفك إظهار أكثر الافتراضات عرضة لإعادة الكتابة.
أخيراً، امنع توسيع النطاق أثناء المراجعة:
Prompt: “Provide a diff plan: minimal changes needed to reach the target design. List what stays the same, what changes, and any breaking impacts.”
عندما تكرر هذا النمط على كل تكرار، تتطوّر هندستك عبر خطوات صغيرة قابلة للعكس — والمشاكل الكبيرة تُكتشف مبكراً.
استخدم هذه الحزمة كسير عمل خفيف يمكنك تكراره على كل ميزة. الفكرة هي سلسلة مطالبات بحيث ينتج كل خطوة مخرجات يمكن للخطوة التالية إعادة استخدامها — مما يقلل "فقدان السياق" وإعادة الكتابة المفاجئة.
عملياً، تنفذ الفرق غالباً هذه السلسلة كـ"وصفة ميزة" قابلة للتكرار. إذا كنت تبني باستخدام Koder.ai، يتطابق نفس الهيكل جيداً مع عملية بناء مدفوعة بالدردشة: اجمع المخرجات في مكان واحد، ولّد الشريحة العاملة الأولى، ثم كرّر بلقطات بحيث تبقى التجارب قابلة للعكس. عندما يصبح MVP جاهزاً، يمكنك تصدير الشيفرة المصدرية أو النشر/الاستضافة مع نطاق مخصص — مفيد عندما تريد سرعة التوليد بمساعدة الذكاء الاصطناعي دون التقيّد ببيئة واحدة.
SYSTEM (optional)
You are a software architecture assistant. Be practical and concise.
Guardrail: When you make a recommendation, cite the specific lines from *my input* you relied on by quoting them verbatim under “Input citations”. Do not cite external sources or general industry claims.
If something is unknown, ask targeted questions.
1) REQUIREMENTS CLARIFIER
Context: <product/system overview>
Feature: <feature name>
My notes: <paste bullets, tickets, constraints>
Task:
- Produce: (a) clarified requirements, (b) non-goals, (c) constraints, (d) open questions.
- Include “Input citations” quoting the exact parts of my notes you used.
2) ARCHITECTURE OPTIONS
Using the clarified requirements above, propose 3 architecture options.
For each: tradeoffs, complexity, risks, and when to choose it.
End with a recommendation + “Input citations”.
3) MODULAR BOUNDARIES
Chosen option: <option name>
Define modules/components and their responsibilities.
- What each module owns (and does NOT own)
- Key interfaces between modules
- “Input citations”
4) DATA & API CONTRACTS
For each interface, define a contract:
- Request/response schema (or events)
- Validation rules
- Versioning strategy
- Error shapes
- “Input citations”
5) TEST-FIRST ACCEPTANCE
Write:
- Acceptance criteria (Given/When/Then)
- 5–10 critical tests (unit/integration)
- What to mock vs not mock
- “Input citations”
6) RELIABILITY + DESIGN REVIEW
Create:
- Failure modes list (timeouts, partial failure, bad data, retries)
- Observability plan (logs/metrics/traces)
- Review checklist tailored to this feature
- “Input citations”
If you want a deeper companion, see /blog/prompting-for-code-reviews. If you’re evaluating tooling or team rollout, /pricing is a practical next stop.
في العمل بمساعدة الذكاء الاصطناعي، يعني أيضاً أن النموذج يستطيع إعادة صياغة المتطلبات بطريقة يمكنك الموافقة عليها.
يمكن للذكاء الاصطناعي إنتاج كود وتصاميم مقنعة بسرعة، مما يجعل من السهل البناء فوق أساسات هشة. هذه السرعة يمكن أن تضخّم محفزات إعادة الكتابة مثل:
الحل ليس "أقل استخداماً للذكاء الاصطناعي"، بل استخدام مطالبات تجبر على إظهار القيود والعقود والافتراضات مبكراً.
استخدم الأنماط كنقاط تفتيش قصيرة تنتج مخرجات قابلة لإعادة الاستخدام (لا نصوص إضافية):
اجعل التكرارات 10–15 دقيقة: مطالبة → مسح سريع → ضبط → تحقق ذاتي مقابل معايير القبول.
قدّم حزمة صغيرة ومتسقة:
إذا كان شيء غير معروف، اذكر ذلك واطلب من النموذج بدل التخمين بصمت.
اطلب مخرجات يمكنك لصقها في المستندات/التذاكر/PRs:
هذا يجعل مخرجات الذكاء الاصطناعي قابلة للتنفيذ ويقلل إعادة العمل الناتجة عن «فقدان السياق».
استخدم النموذج كمحاور متطلبات. اجعله:
ابدأ بالأدوار والإجراءات، ثم اطلب:
بعد وضوح التدفقات، اربطها بقرارات مثل أين تنتهي صلاحية التحقق وأين تبدأ قواعد العمل، أين يلزم idempotency، وما الذي يجب تخزينه مقابل اشتقاقه. ثم حول التدفقات إلى معايير قبول قابلة للاختبار (Given/When/Then).
اطلب سجل افتراضات يميّز بين:
اطلب أن يضع كل افتراض كـ مؤكّد أو مجهول، وأضف:
اطلب من النموذج اقتراح 2–3 هندسات قابلة للمشروع وقارن بينها في جدول مع المعايير: التعقيد، الاعتمادية، زمن الشحن، القابلية للتوسع، التكلفة. ثم اطلب:
هذا يمنع الاعتماد على الخيار الأول الظاهر ويقلل من توسع النطاق الصامت الذي يؤدي لإعادة الكتابة.
اتباع نهج قائم على العقود يقلل إعادة العمل بالتكامل بجعل أشكال البيانات وقواعد التوافق صريحة. اطلب:
عندما تشارك الواجهة الأمامية، الخادم، والتكاملات نفس وثيقة العقد، سيتم قضاء وقت أقل في التوفيق بين الافتراضات المختلفة لاحقًا.
عامل تلك الـ10 نقاط كعقد: الصقها في تذكرة/PR واطلب نعم/لا من الأطراف المعنية قبل البدء بالتصميم.
واطلب أيضاً «ما الذي سيغيّر إجابتك؟» (مثلاً حجم المستخدمين، أهداف زمن الاستجابة، متطلبات الامتثال، قواعد احتفاظ بالبيانات) لجعل التصميم قرارياً وأقل عرضة لإعادة الكتابة.