استخدام الذكاء الاصطناعي باحتراف: من المحادثة إلى نظام عمل قابل للقياس

استخدام الذكاء الاصطناعي باحتراف: من المحادثة إلى نظام عمل قابل للقياس

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

هذا المقال موجه خصوصًا للمطورين والمهندسين، لكنه مناسب لأي شخص يريد الانتقال من استخدام ChatGPT أو Claude كأداة سؤال وجواب إلى استخدام نماذج الذكاء الاصطناعي كجزء من Workflow حقيقي.

1. لماذا تعلم استخدام AI أصبح مهارة مستقلة؟

قبل انتشار النماذج التوليدية، كان جزء كبير من العمل المعرفي يتم بهذه الدورة:

مشكلة
  ↓
بحث
  ↓
قراءة
  ↓
تجربة
  ↓
تنفيذ
  ↓
مراجعة

مع أدوات الذكاء الاصطناعي أصبحت دورة العمل أقرب إلى:

مشكلة
  ↓
صياغة المشكلة
  ↓
AI
  ↓
اقتراحات / تنفيذ / تحليل
  ↓
اختبار وتحقق
  ↓
قرار بشري

الفرق المهم هنا أن AI لم يلغِ المراحل القديمة كلها.

هو خفض تكلفة بعض المراحل.

يمكنه مساعدتك في:

• استكشاف حلول.
• تلخيص مستندات.
• شرح كود.
• توليد boilerplate.
• تحليل أخطاء.
• كتابة اختبارات.
• تحويل البيانات إلى شكل منظم.
• مقارنة البدائل.
• البحث في مصادر خارجية عندما تتوفر أدوات البحث.
• استخدام أدوات وبرمجيات أخرى من خلال tool/function calling.

لكن هذا لا يعني أن كل output صحيح.

OpenAI توضح صراحة أن ChatGPT يمكن أن ينتج معلومات غير صحيحة أو مضللة، وقد يبدو واثقًا وهو مخطئ، ولذلك يجب التحقق من المعلومات المهمة من مصادر موثوقة. كما أن أدوات مثل البحث وتحليل البيانات يمكن أن تحسن قابلية التحقق والدقة الواقعية عندما تكون متاحة.
المصدر: https://help.openai.com/en/articles/8313428-does-chatgpt-tell-the-truth

إذًا المهارة الجديدة ليست:

"كيف أجعل AI يكتب لي أكثر؟"

بل:

"كيف أبني دورة عمل تجعل AI مفيدًا، قابلًا للتحقق، وآمنًا؟"

2. افهم ما الذي تتعامل معه: LLM ليس محرك بحث ولا قاعدة حقائق

النموذج اللغوي الكبير، بصورة مبسطة، يتعلم أنماطًا من كميات ضخمة من البيانات ثم يستخدم السياق الذي تعطيه له لتوليد output.

هذا يفسر شيئًا مهمًا جدًا:

الطلاقة ليست دليلًا على الصحة.

يمكن أن تحصل على إجابة:

مكتوبة بشكل ممتاز
منظمة
مقنعة
ومليئة بالتفاصيل

ومع ذلك تحتوي على معلومة خاطئة.

لذلك افصل دائمًا بين:

Fluency

و:

Correctness

وبين:

Confidence

و:

Evidence

هذه من أهم الأفكار التي يجب أن تتعلمها قبل حفظ أي Prompt.

3. الفرق بين المعرفة، السياق، والأداة

هناك ثلاثة أشياء مختلفة يجب ألا تخلط بينها.

المعرفة الموجودة في النموذج

هي ما يستطيع النموذج إنتاجه اعتمادًا على تدريبه وقدراته.

السياق الذي تعطيه له

مثل:

• الكود.
• ملف PDF.
• مواصفات المشروع.
• Logs.
• Database schema.
• Business rules.
• صور.
• أمثلة.

الأدوات

مثل:

• Web search.
• File search.
• Code execution.
• Database tools.
• APIs.
• Custom functions.

النموذج القوي قد يعطي نتيجة سيئة إذا أعطيته سياقًا ناقصًا.

والنموذج الأبسط قد يعطي نتيجة ممتازة في مهمة محددة إذا كان لديه:

سياق واضح
+
أمثلة جيدة
+
Tool مناسبة
+
Output محدد

لذلك لا تبدأ دائمًا بسؤال:

"ما أقوى Model؟"

ابدأ بـ:

"ما المشكلة التي أحاول حلها، وما المعلومات والأدوات المطلوبة لحلها؟"

4. اختيار النموذج هو قرار هندسي

لا يوجد Model واحد هو الأفضل لكل شيء.

عند اختيار نموذج، فكر في مجموعة أبعاد:

مثال

لو عندك:

100,000 support tickets

والمطلوب:

Classify:
billing
technical
account
other

ليس من المنطقي تلقائيًا اختيار أقوى وأغلى نموذج.

قد يكون نموذج أصغر وأسرع كافيًا.

لكن لو المطلوب:

تحليل Architecture معقدة
+
مقارنة trade-offs
+
اكتشاف race conditions
+
اقتراح migration strategy

فقد تحتاج نموذجًا أقوى في reasoning.

القاعدة

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

5. Prompt Engineering ليس كتابة "Prompt سحري"

أكثر شيء يضلل المبتدئين هو البحث عن:

The ultimate prompt

أو:

The magic words

لا يوجد Prompt واحد يجعل كل Model ممتازًا في كل مهمة.

Prompt Engineering الحقيقي أقرب إلى تصميم واجهة بين الإنسان والنموذج.

أنت تحدد:

الهدف
+
السياق
+
المطلوب
+
القيود
+
المادة المدخلة
+
شكل الناتج
+
معايير الجودة

6. المكونات الأساسية للـPrompt الجيد

يمكنك التفكير في Prompt احترافي بهذا الشكل:

Objective
Context
Input
Constraints
Tasks
Output format
Quality criteria

ليس شرطًا أن تكتب هذه العناوين حرفيًا في كل مرة.

لكن يجب أن تكون المعلومات نفسها موجودة عندما تكون مهمة.

مثال سيئ

راجع الكود ده.

مثال أفضل

أنت تراجع Backend production code.

التقنية:
- Node.js
- PostgreSQL
- JWT
- Redis

المشكلة:
بعض المستخدمين يحصلون على 401 بعد Refresh Token.

المطلوب:
1. تتبع دورة حياة access token وrefresh token.
2. حدد الأسباب المحتملة.
3. افصل بين ما تثبته الأدلة وما هو مجرد فرضية.
4. ابحث عن race conditions.
5. راجع cookie وCORS behavior.
6. اقترح أقل تعديل آمن.

القيود:
- لا تعيد كتابة النظام كاملًا.
- لا تفترض behavior غير موجود في الكود.
- إذا كانت هناك معلومة ناقصة، اذكرها.

الناتج:
جدول يحتوي:
Issue | Evidence | Severity | Recommendation

لاحظ أن القوة هنا ليست في كلمة معينة.

القوة في تقليل الغموض.

7. الوضوح أهم من البلاغة

Google توصي في إرشادات Gemini الحديثة بأن تكون التعليمات دقيقة ومباشرة، وأن تستخدم بنية واضحة وفواصل واضحة بين أجزاء الـPrompt، كما توصي بوضع التعليمات المهمة في موضع واضح، ومع السياقات الطويلة يمكن وضع البيانات أولًا والتعليمات المحددة في النهاية.
المصدر: https://ai.google.dev/gemini-api/docs/prompting-strategies

المبدأ العام:

Don't make the prompt fancy.
Make the task unambiguous.

بدل:

I want you to be the world's greatest developer and give me an absolutely perfect solution...

قل:

Review this API for authorization flaws.
Focus on IDOR, privilege escalation, tenant isolation, and missing authorization checks.

8. السياق Context غالبًا أهم من الـPrompt نفسه

تخيل أنك تقول لمهندس:

"صلح المشكلة."

بدون:

• الكود.
• الـerror.
• الـexpected behavior.
• الـactual behavior.
• البيئة.
• آخر تغيير حصل.

لن يستطيع التشخيص بدقة.

AI نفس الفكرة.

في Debugging

أعطه:

Error
+
Stack trace
+
Relevant code
+
Expected behavior
+
Actual behavior
+
Reproduction steps
+
Environment
+
Recent changes

في Architecture Review

أعطه:

Requirements
+
Current architecture
+
Scale
+
Constraints
+
Failure modes
+
Budget
+
Team constraints

كلما كان السؤال متعلقًا بمشروع حقيقي، أصبح السياق الحقيقي أهم من Prompt طويل مليء بالكلام العام.

9. لا تعطِ النموذج Context عشوائيًا

إرسال كل شيء ليس دائمًا أفضل.

مثلاً لديك Bug في:

Refresh Token

لا تبدأ بإرسال:

500 files
+
200,000 lines
+
كل Logs المشروع

ابدأ بـ:

Auth Controller
Auth Service
Token Service
Refresh Token Repository
Relevant Config
Relevant Logs

ثم وسّع السياق إذا ظهرت حاجة.

الفكرة:

Relevant Context
>
Maximum Context

السياق الزائد قد يزيد التكلفة والـlatency ويصعب على النموذج التركيز على المعلومات المهمة.

10. استخدم أمثلة عندما تكون القاعدة صعبة الوصف

إذا كان المطلوب output له شكل معين، يمكن أن يكون المثال أكثر وضوحًا من فقرة كاملة.

مثلاً:

Input:
{
  "age": 16
}

Output:
{
  "category": "minor"
}

ثم:

Input:
{
  "age": 27
}

هذا يسمى غالبًا:

Few-shot prompting

الأمثلة مفيدة جدًا عندما تريد:

• Format محدد.
• Classification.
• Extraction.
• Style.
• Transformation.
• Consistent decisions.

لكن انتبه:

المثال السيئ ليس مجرد مثال سيئ؛ قد يصبح instruction فعليًا للنموذج.

لذلك اختبر الأمثلة نفسها.

11. اطلب Output يمكن للبرنامج التعامل معه

إذا كانت النتيجة ستذهب إلى برنامج آخر، لا تجعلها نصًا حرًا بلا داعٍ.

بدل:

حلل المخاطر وأعطني رأيك.

يمكن أن يكون المطلوب:

{
  "risk_level": "high",
  "issues": [
    {
      "title": "Missing authorization",
      "severity": "critical",
      "evidence": "...",
      "recommendation": "..."
    }
  ]
}

وهنا تظهر أهمية:

Structured Outputs
Function Calling
JSON Schema

في منصات الـAPI الحديثة يمكن تعريف tools/functions يختار النموذج استدعاءها، ويمكن تقييد parameters باستخدام schema. توثيق OpenAI يوضح أيضًا استخدام JSON Schema وstrict validation في function calling وStructured Outputs.
المصدر: https://platform.openai.com/docs/api-reference/evals

12. Tool Calling يغير طبيعة تطبيقات AI

هناك فرق ضخم بين:

AI → Text

و:

AI → Tool → Result → AI → Decision

مثلاً:

User:
"هل الطلب رقم 5834 اتشحن؟"

Model
 ↓
get_order_status(5834)
 ↓
Backend
 ↓
Database
 ↓
Result
 ↓
Model
 ↓
Answer

هنا النموذج لم يخمن حالة الطلب.

هو استخدم مصدرًا خارجيًا.

وهذا هو أحد أهم الانتقالات من:

Chatbot

إلى:

AI Application

13. لا تستخدم AI عندما تكون أداة تقليدية أفضل

هذه قاعدة مهمة جدًا.

إذا كان المطلوب:

2 + 2

استخدم calculator.

إذا كان المطلوب:

SELECT user WHERE id = 15

استخدم Database.

إذا كان المطلوب:

Validate email format

استخدم validator.

إذا كان المطلوب:

Sort 1,000,000 records

استخدم algorithm/database.

لا تجعل AI مسؤولًا عن شيء deterministic يمكن لأداة تقليدية تنفيذه بشكل أدق.

الـAI ممتاز في:

Ambiguity
Language
Reasoning
Transformation
Planning
Classification
Interpretation

والبرامج التقليدية ممتازة في:

Deterministic computation
Validation
Authorization
Transactions
Exact lookup

أفضل الأنظمة تجمع الاثنين.

14. Reasoning: لا تخلط بين التفكير الداخلي والنتيجة القابلة للمراجعة

النماذج الحديثة قد تمتلك قدرات reasoning أقوى من النماذج الأبسط.

لكن في التطبيقات العملية، ما تحتاجه عادة هو:

Conclusion
+
Relevant evidence
+
Assumptions
+
Checks

وليس بالضرورة طلب أو حفظ سلسلة التفكير الداخلية كاملة.

مثلاً:

أعطني النتيجة.
اذكر أهم الافتراضات.
اذكر الأدلة التي بنيت عليها النتيجة.
اذكر ما الذي ما زلت غير متأكد منه.

هذا يعطيك نتيجة قابلة للمراجعة بدون تحويل كل workflow إلى نص طويل.

15. Hallucination ليست مشكلة "Prompt سيئ" فقط

من الخطأ أن تقول:

"لو كتبت Prompt ممتاز، النموذج لن يهلوس."

لا.

حتى مع Prompt ممتاز، يمكن أن تنتج النماذج معلومات غير صحيحة.

OpenAI تذكر أمثلة تشمل:

• حقائق خاطئة.
• تواريخ خاطئة.
• اقتباسات مختلقة.
• دراسات غير موجودة.
• References وهمية.
• إجابات واثقة على أسئلة غامضة.

المصدر الرسمي: https://help.openai.com/en/articles/8313428-does-chatgpt-tell-the-truth

لذلك الحل ليس فقط:

Better Prompt

بل:

Better Prompt
+
Grounding
+
Tools
+
Verification
+
Tests
+
Human review

16. متى يجب أن تستخدم Web Search؟

إذا كانت الإجابة تعتمد على شيء يتغير:

أسعار
إصدارات
APIs
Libraries
Security advisories
News
Documentation
Current products
Current policies

فلا تعتمد على ذاكرة النموذج وحدها.

استخدم:

Official documentation
+
Current sources

خصوصًا إذا كانت المعلومة ستؤثر على Production.

17. لا تثق في Citation لمجرد وجود Citation

AI يمكن أن يخترع:

Paper
Author
URL
Quote
Version
API method

وجود شكل يشبه المصدر لا يعني أن المصدر حقيقي.

اعمل:

Claim
 ↓
Source
 ↓
Open source
 ↓
Check relevant section
 ↓
Confirm claim

ولو المعلومة مهمة:

Source A
+
Source B

أفضل من الاعتماد على citation واحد مجهول.

18. من "الإجابة" إلى Evidence-Based AI

يمكنك تصميم الـWorkflow بحيث لا يطلب من AI مجرد answer.

بل:

Answer
+
Evidence
+
Confidence / uncertainty
+
Source

مثلاً:

Claim:
The library supports feature X.

Evidence:
Official documentation section Y.

Confidence:
High.

Unknown:
Support in version Z was not confirmed.

هذا أسلوب أفضل بكثير في الأنظمة الحساسة.

19. AI في البرمجة: لا تجعله مجرد Code Generator

أكبر استخدام ضعيف للـAI كمبرمج هو:

"Build the entire feature."

ثم نسخ الناتج.

الاستخدام الأقوى هو تقسيم العمل:

Understand
 ↓
Design
 ↓
Implement
 ↓
Test
 ↓
Review
 ↓
Verify

يمكنك استخدام AI في كل مرحلة، لكن كل مرحلة لها هدف مختلف.

20. استخدم AI في فهم الكود قبل تغييره

عند دخول codebase كبير:

Explain this repository.

قد يكون سؤالًا عامًا جدًا.

الأفضل:

Map the request lifecycle for POST /orders.

Trace:
Route
→ Controller
→ Service
→ Repository
→ Database
→ Events
→ External services

For each step:
- file
- function
- responsibility
- important side effects

النتيجة تصبح Architecture map بدل شرح عام.

21. استخدم AI في Code Review

بدل:

Is this code good?

استخدم checklist.

مثلاً:

Review this code for:

Correctness
Security
Authorization
Race conditions
Transactions
Error handling
Resource leaks
Performance
Observability
Testability
Maintainability

For every finding:
- severity
- evidence
- impact
- recommended fix

Do not report style issues unless they affect maintainability.

هذا أفضل لأنك حولت:

Open-ended opinion

إلى:

Defined evaluation criteria

22. استخدم AI في Debugging كـHypothesis Generator

لا تسأله فقط:

What's wrong?

اطلب:

Generate the 5 most likely causes.

For each:
- supporting evidence
- contradicting evidence
- test to confirm/refute

هنا AI يساعدك في التفكير، وليس فقط في إعطاء answer.

مثلاً:

Cause A
→ Test A

Cause B
→ Test B

Cause C
→ Test C

ثم أنت تنفذ الاختبارات.

23. استخدم AI في Testing

يمكنه مساعدتك في:

Test cases
Edge cases
Unit tests
Integration tests
Regression scenarios
Property-based test ideas
Failure scenarios

لكن لا تسأله فقط:

Write tests.

قل:

Given this business rule...

Generate:
- happy path
- boundary cases
- invalid input
- authorization failures
- concurrency scenarios
- retry behavior
- idempotency cases

وهكذا تجعل الاختبارات مرتبطة بالسلوك.

24. AI لا يعفيك من تشغيل الكود

هذه قاعدة للمبرمجين:

Code generated by AI is unexecuted code until you run it.

لا يكفي:

Looks correct.

يجب أن يمر عبر:

Compiler
Linter
Unit tests
Integration tests
E2E where relevant
Security checks
Manual review

وإذا كان SQL:

EXPLAIN
Test data
Constraints
Transactions

وإذا كان infrastructure:

Plan
Validate
Dry run
Review

25. Evaluation أهم من "الإحساس أن النتيجة أفضل"

لو تبني AI feature، لا تعتمد على:

"جربته مرتين وحلو."

اعمل Evaluation Set.

مثلاً لديك 200 حالة حقيقية:

Input
Expected behavior
Reference answer / criteria

ثم اختبر:

Model A
Model B
Prompt A
Prompt B

وقارن.

يمكن أن تكون المقاييس:

Accuracy
Precision
Recall
Pass rate
Tool success rate
Latency
Cost
Human rating

منصة OpenAI توفر مفهوم Evals وGraders لتقييم المخرجات آليًا، بما في ذلك graders للمقارنة والتشابه وغيرها.
المصدر: https://platform.openai.com/docs/api-reference/evals

26. Prompt Optimization بدون Evaluation مجرد تخمين

لو غيرت Prompt:

A → B

ثم قلت:

"B أحسن."

اسأل:

على كام حالة؟
وبأي معيار؟
وهل تحسن نوعًا من الحالات وأفسد نوعًا آخر؟

هذه هي عقلية الـengineering.

Change
 ↓
Measure
 ↓
Compare
 ↓
Keep / Revert

27. Regression Testing للـAI

مثل Software Testing، يمكن أن تحدث regression في AI behavior.

مثلاً:

Prompt v1
→ 92% success

Prompt v2
→ 95% on new cases
→ 78% on old cases

أنت لم تحسن النظام فعليًا.

لقد حسنت جزءًا وكَسرت جزءًا آخر.

لذلك احتفظ بـ:

Golden Dataset

واختبره كل مرة تغير فيها:

Prompt
Model
Tool
Context
Retrieval strategy
Output schema

28. RAG: عندما تكون المشكلة في المعرفة لا في النموذج

لو عندك:

Company policies
Internal docs
Product manuals
Knowledge base

ليس من المنطقي دائمًا إعادة تدريب النموذج.

قد تستخدم:

Retrieval-Augmented Generation

الفكرة المبسطة:

User Question
 ↓
Retrieve relevant documents
 ↓
Context
 ↓
Model
 ↓
Answer grounded in retrieved information

وهنا يصبح:

Retrieval quality

مهمًا جدًا.

لأن نموذجًا ممتازًا مع context خاطئ سيعطي نتيجة سيئة.

29. RAG ليس مجرد Vector Database

من الأخطاء الشائعة:

"عملت embeddings وحطيتهم في Vector DB، إذًا عندي RAG ممتاز."

لا.

الـRAG pipeline تشمل عادة:

Ingestion
 ↓
Parsing
 ↓
Chunking
 ↓
Embedding / indexing
 ↓
Retrieval
 ↓
Filtering / reranking
 ↓
Context construction
 ↓
Generation
 ↓
Evaluation

المشكلة قد تكون في:

Chunking
Retrieval
Metadata filtering
Reranking
Context size

وليس في الـLLM نفسه.

30. Agents: لا تبدأ بها لمجرد أنها Trend

الـAgent يمكن تبسيطه إلى:

Model
+
Tools
+
State
+
Loop
+
Decision making

مثلاً:

User request
 ↓
Model
 ↓
Search
 ↓
Read result
 ↓
Call API
 ↓
Check result
 ↓
Call another tool
 ↓
Final response

لكن كل خطوة إضافية تضيف:

Latency
Cost
Failure modes
Security risk
Debugging complexity

لذلك لا تحول كل feature إلى Agent.

إذا كان:

function call واحد

يكفي، لا تحتاج:

10-step autonomous agent

31. Security: AI يغير شكل الـThreat Model

بمجرد أن تعطي AI وصولًا إلى:

Email
Files
Database
Browser
Shell
GitHub
Cloud
Payments
CRM

لم تعد تتعامل مع chatbot فقط.

أنت تبني نظامًا له صلاحيات.

وهنا تظهر مشاكل مثل:

• Prompt Injection.
• Sensitive Information Disclosure.
• Insecure Output Handling.
• Supply-chain risks.
• Excessive Agency.
• Unbounded consumption.

OWASP تضع هذه المخاطر ضمن Top 10 لتطبيقات LLM، وتؤكد أن Prompt Injection يمكن أن يؤدي إلى سلوك غير مقصود، بينما Excessive Agency يرتبط بإعطاء النظام وظائف أو صلاحيات أو استقلالية أكبر مما يحتاجه.
المصادر:
https://owasp.org/www-project-top-10-for-large-language-model-applications/
https://owasp.org/www-project-top-10-for-large-language-model-applications/2_0_vulns/LLM06_ExcessiveAgency.html

32. لا تجعل الـLLM هو Authorization Layer

هذه قاعدة شديدة الأهمية.

لا تفعل:

LLM:
"أعتقد أن المستخدم مسموح له بحذف الملف."

ثم تنفذ الحذف.

يجب أن يكون:

LLM
 ↓
Request tool
 ↓
Backend authorization
 ↓
Policy check
 ↓
Action

الـLLM قد يقرر ما الذي يريد فعله.

لكن النظام التقليدي يجب أن يقرر:

هل هذا مسموح أصلًا؟

OWASP توصي بفرض authorization في الأنظمة downstream وعدم الاعتماد على النموذج وحده لاتخاذ قرار الصلاحيات، مع تقليل الوظائف والصلاحيات وطلب موافقة بشرية على العمليات عالية التأثير.
المصدر: https://owasp.org/www-project-top-10-for-large-language-model-applications/2_0_vulns/LLM06_ExcessiveAgency.html

33. Principle of Least Privilege ينطبق على AI أيضًا

لو الـAgent يحتاج:

Read orders

لا تعطه:

Read
Write
Delete
Refund
Change permissions

لو يحتاج:

read-only database

استخدم:

SELECT

وليس:

ALL PRIVILEGES

لو يحتاج:

send email

لا تعطه:

delete inbox

كل tool يجب أن تكون:

Narrow
Explicit
Authorized
Audited
Rate-limited

34. Human-in-the-loop ليس ضعفًا

هناك عمليات لا تريد أن ينفذها AI وحده:

Delete production data
Refund money
Send legal document
Publish public statement
Deploy production
Change permissions
Rotate secrets

هنا:

AI proposes
 ↓
Human reviews
 ↓
Human approves
 ↓
System executes

ليس هذا فشلًا في الـAI.

هذا تصميم آمن.

35. Cost Engineering

عند استخدام AI على نطاق كبير، كل طلب له تكلفة.

التكلفة قد تتأثر بـ:

Input tokens
Output tokens
Model
Tool calls
Number of steps
Context size
Retries
Caching
Batching

لذلك:

"استخدم أقوى Model"

ليس استراتيجية تكلفة.

الأفضل:

Simple task
→ smaller / cheaper model

Hard task
→ stronger model

ثم قياس النتائج.

36. Latency Engineering

إذا كان المستخدم ينتظر:

2 seconds

فقد تكون تجربة ممتازة.

إذا صار:

15 seconds

قد تكون سيئة.

لو Agent ينفذ:

Model
→ Search
→ Model
→ API
→ Model
→ Database
→ Model

قد يصبح latency كبيرًا.

الحل قد يكون:

Parallel tool calls
Caching
Smaller model
Fewer steps
Streaming
Precomputation

لكن لا تقلل quality بدون قياس.

37. Data Privacy قبل أن تلصق بيانات الشركة في أي Model

قبل استخدام AI مع بيانات حقيقية، اسأل:

What data am I sending?
Where does it go?
How long is it retained?
Is it used for training?
Who can access it?
What are the organization's policies?

في استخدام API، راجع سياسة الـprovider والـdata controls الخاصة بالخدمة التي تستخدمها، ولا تفترض أن كل منتج AI له نفس سياسة الاحتفاظ بالبيانات.

مثلاً، OpenAI توضح في توثيق API الخاص بها سياسة استخدام بيانات الـAPI وشروط retention المرتبطة بها، وتذكر أن بيانات API لا تُستخدم لتدريب النماذج افتراضيًا إلا إذا تم الاشتراك في ذلك، مع وجود سجلات abuse-monitoring واحتفاظ افتراضي محدد لها. يجب دائمًا مراجعة السياسة الحالية للخدمة التي تستخدمها قبل إرسال بيانات حساسة.
المصدر: https://platform.openai.com/docs/models/default-usage-policies-by-endpoint

38. لا ترسل Secrets إلى الـModel

ممنوع عمليًا أن تضع:

DATABASE_PASSWORD
JWT_SECRET
AWS_SECRET_KEY
PRIVATE_KEY
Production credentials

في Prompt لمجرد أن النموذج طلبها.

لو tool تحتاج credential:

Backend
 ↓
Secure credential store
 ↓
Tool

وليس:

Prompt
 ↓
Secret
 ↓
Model

39. AI Workflow احترافي للمطور

Workflow عملي:

1. Define the problem
        ↓
2. Collect evidence
        ↓
3. Decide whether AI is useful
        ↓
4. Select model/tool
        ↓
5. Prepare relevant context
        ↓
6. Give clear instructions
        ↓
7. Generate hypothesis / solution
        ↓
8. Verify with tools/tests/sources
        ↓
9. Review security and edge cases
        ↓
10. Apply the change
        ↓
11. Run regression tests
        ↓
12. Measure the result

هذه الدورة أهم بكثير من حفظ عشرات الـPrompts.

40. مثال كامل: Debugging Production Issue

لنفترض:

المستخدمون يتم تسجيل خروجهم عشوائيًا.

Prompt ضعيف

Why are users logged out?

Workflow أقوى

<role>
You are reviewing a production authentication issue.
</role>

<context>
Stack:
- Next.js
- Node.js
- JWT access tokens
- Rotating refresh tokens
- HttpOnly cookies

Symptom:
Users are randomly logged out after 10–20 minutes.

Expected:
Users remain authenticated while the refresh token is valid.

Observed:
Some users receive 401 after refresh.

Relevant logs:
[logs]

Relevant files:
[files]
</context>

<tasks>
1. Trace the token lifecycle.
2. List the most likely causes.
3. Separate confirmed evidence from hypotheses.
4. Look for refresh-token race conditions.
5. Check cookie and CORS behavior.
6. Suggest the smallest safe fix.
7. Suggest tests that can reproduce the issue.
</tasks>

<constraints>
- Do not rewrite the entire authentication system.
- Do not assume framework behavior without evidence.
- If information is missing, say what is missing.
</constraints>

<output>
Return:

1. Confirmed facts
2. Likely causes
3. Evidence
4. Tests to run
5. Recommended fix
6. Remaining uncertainty
</output>

هنا أنت لا تطلب من AI "حل المشكلة".

أنت تبني تحقيقًا هندسيًا.

41. مثال ثاني: اختيار Architecture

بدل:

Should I use microservices?

اسأل:

We are building a SaaS platform.

Current scale:
- 50k users
- 5 engineers
- PostgreSQL
- Node.js
- Expected 10x growth in 2 years

Requirements:
- high availability for payments
- independent deployment is useful but not mandatory
- small engineering team
- limited DevOps budget

Compare:
1. Modular monolith
2. Microservices

Evaluate:
- operational complexity
- deployment
- data consistency
- debugging
- scaling
- team ownership
- cost
- failure modes

Do not choose based on popularity.
Give a recommendation and explain when the recommendation should change.

هذا Prompt ممتاز لأنه لا يطلب:

"قل لي أفضل Architecture"

بل يحدد معايير القرار.

42. مثال ثالث: استخدام AI في Code Review

Review the following PR.

Do not focus primarily on style.

Check:
- correctness
- security
- authorization
- concurrency
- transactions
- error handling
- performance
- observability
- test coverage
- backward compatibility

For each finding provide:
- severity
- file/function
- evidence
- impact
- recommended fix

If no issue is supported by evidence, do not invent one.

At the end:
- Critical findings
- Important findings
- Suggestions
- What I should test manually

الجملة المهمة هنا:

If no issue is supported by evidence, do not invent one.

لأن بعض workflows تجعل النموذج يشعر أنه يجب أن يجد مشكلة حتى عندما لا توجد.

43. كيف تتعلم AI فعليًا؟

بدل دراسة AI كقائمة مصطلحات، اعمل مشاريع صغيرة.

مشروع 1 — Smart Document Analyzer

PDF
 ↓
Extract
 ↓
AI
 ↓
Structured JSON

تعلم منه:

Files
Prompting
Structured output
Validation

مشروع 2 — Code Review Assistant

Git diff
 ↓
AI
 ↓
Findings
 ↓
JSON
 ↓
PR comment

تعلم:

Tool use
Context
Evaluation
Security

مشروع 3 — Company Knowledge Assistant

Documents
 ↓
Chunk
 ↓
Embed
 ↓
Retrieve
 ↓
LLM
 ↓
Cited answer

تعلم:

RAG
Retrieval
Grounding
Evaluation

مشروع 4 — AI Agent

User
 ↓
Model
 ↓
Tools
 ↓
Approval
 ↓
Action

تعلم:

Function calling
State
Permissions
Human-in-the-loop
Audit logs

44. Roadmap تعلم عملية

المرحلة الأولى: أساسيات النماذج

افهم:

• LLM.
• Tokens.
• Context window.
• Multimodal input.
• Reasoning.
• Tool calling.
• Structured output.
• Hallucinations.

لا تحتاج في هذه المرحلة إلى دراسة training من الصفر.

المرحلة الثانية: Prompt Design

تعلم:

• Clear instructions.
• Context.
• Constraints.
• Delimiters.
• Examples.
• Few-shot.
• Output schemas.
• Iterative refinement.

استخدم الأدلة الرسمية بدل تجميع نصائح TikTok وReels.

المرحلة الثالثة: AI-Assisted Engineering

استخدم AI في:

• Debugging.
• Refactoring.
• Code review.
• Test generation.
• Documentation.
• SQL.
• Architecture analysis.
• Research.

المرحلة الرابعة: Evaluation

تعلم:

Datasets
Golden cases
Graders
Human evaluation
Regression evaluation
A/B comparison

لأنك إذا لم تستطع قياس التحسن، فأنت غالبًا تخمن.

المرحلة الخامسة: AI Applications

تعلم:

API integration
Function calling
RAG
Embeddings
Vector search
Tool orchestration
Agents

المرحلة السادسة: Production AI

تعلم:

Security
Prompt injection
Permissions
Observability
Cost optimization
Latency
Caching
Rate limiting
Privacy
Evaluation
Failure handling

45. ما الذي لا تحتاج إلى تعلمه في البداية؟

لا تبدأ مباشرة بـ:

Training a foundation model
CUDA optimization
Distributed GPU training
Transformer implementation from scratch
Fine-tuning every model
Kubernetes for an AI demo
Multi-agent swarm

إلا إذا كان هدفك فعلًا:

ML / Research / Model Engineering

لو هدفك:

أن تصبح Software Engineer يستخدم AI بكفاءة عالية

فالأولوية غالبًا:

Software Engineering fundamentals
+
AI usage
+
AI application development

46. AI لا يعوض أساسيات Software Engineering

لو لا تفهم:

HTTP
Databases
Transactions
Concurrency
Security
Testing
Architecture
Git
Debugging

يمكنك أن تجعل AI يكتب كودًا أكثر.

لكن لن تعرف بالضرورة:

هل الحل صحيح؟
هل هو آمن؟
هل scalable؟
هل فيه race condition؟
هل كسر transaction؟
هل authorization ناقص؟
هل التكلفة مقبولة؟

لذلك AI يزيد قيمة الـfundamentals.

ولا يلغيها.

47. الفرق بين مستخدم AI وAI Engineer

مستخدم AI

Question
 ↓
Answer
 ↓
Copy

مستخدم محترف

Problem
 ↓
Context
 ↓
Prompt
 ↓
Answer
 ↓
Verification

AI Application Engineer

Problem
 ↓
Workflow
 ↓
Model
 ↓
Context
 ↓
Tools
 ↓
Structured output
 ↓
Validation
 ↓
Evaluation
 ↓
Security
 ↓
Observability

الفرق ليس في عدد الـPrompts.

الفرق في تصميم النظام حول النموذج.

48. أخطاء شائعة يجب أن تتجنبها

الخطأ الأول: البحث عن Prompt سحري

لا يوجد Prompt يصلح لكل شيء.

الخطأ الثاني: استخدام أقوى Model دائمًا

قد تدفع أكثر بدون فائدة.

الخطأ الثالث: إعطاء Context قليل جدًا

النموذج سيضطر للتخمين.

الخطأ الرابع: إعطاء Context كثيرًا بلا تنظيم

قد يصبح السياق noisy وغير مفيد.

الخطأ الخامس: تصديق الإجابة لأن شكلها ممتاز

الأسلوب ليس دليلًا.

الخطأ السادس: استخدام AI بدل أدوات deterministic

Calculator وDatabase وValidator قد تكون أفضل.

الخطأ السابع: عدم اختبار الكود

AI ليس compiler.

الخطأ الثامن: إعطاء Agent صلاحيات واسعة

هذا خطر أمني.

الخطأ التاسع: بناء Agent بينما function واحدة تكفي

التعقيد ليس ميزة.

الخطأ العاشر: عدم وجود Evaluation

بدون evaluation لن تعرف هل Prompt أو Model الجديد أفضل.

49. Checklist قبل إرسال Prompt مهم

اسأل نفسك:

المشكلة

• هل المهمة محددة؟
• هل الـexpected result واضح؟

السياق

• هل أعطيت المعلومات الضرورية؟
• هل أزلت المعلومات غير المتعلقة؟

التنفيذ

• هل يحتاج AI أصلًا؟
• هل يحتاج Tool؟
• هل يحتاج Web Search؟
• هل اخترت Model مناسبًا؟

النتيجة

• هل حددت Output format؟
• هل حددت Quality criteria؟
• هل طلبت عدم اختلاق المعلومات عند غياب الأدلة؟

التحقق

• هل يمكن اختبار النتيجة؟
• هل تحتاج مصدرًا خارجيًا؟
• هل هناك Human review؟

الأمان

• هل يوجد بيانات حساسة؟
• هل يوجد Tool عالي الصلاحية؟
• هل هناك Authorization مستقل؟
• هل يمكن تنفيذ Action خطير بدون موافقة؟

50. Checklist لبناء AI Feature في Production

قبل إطلاق AI feature، فكر في:

Model
Prompt
Context
Tools
Data
Permissions
Output validation
Evaluation
Monitoring
Cost
Latency
Rate limits
Privacy
Failure handling
Human approval
Audit logs

ثم اسأل:

ماذا يحدث إذا أعطى النموذج إجابة خاطئة؟

ثم:

ماذا يحدث إذا أعطى إجابة خاطئة بثقة؟

ثم:

ماذا يحدث إذا حاول مستخدم استغلاله؟

ثم:

ماذا يحدث إذا تعطلت الـTool؟

ثم:

ماذا يحدث إذا أصبحت التكلفة 10x؟

هذه الأسئلة هي بداية AI Engineering الحقيقي.

51. القاعدة الذهبية

لا تستخدم AI كالتالي:

AI said it.
Therefore it is true.

استخدمه كالتالي:

AI proposed it.
 ↓
Evidence
 ↓
Test
 ↓
Review
 ↓
Decision

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

52. خلاصة عملية

إذا أردت أن تبدأ اليوم، لا تحفظ 100 Prompt.

ابدأ بهذه المهارات:

1. Understand the task
2. Choose the right model
3. Provide relevant context
4. Give clear constraints
5. Use examples when useful
6. Request structured output when appropriate
7. Use tools instead of asking the model to guess
8. Verify important claims
9. Test generated code
10. Evaluate AI workflows
11. Protect tools with least privilege
12. Measure cost and latency

ثم انتقل إلى:

RAG
Tools
Agents
Evaluation
Security
Observability
Production AI

53. الخلاصة النهائية

الناس التي ستستفيد من AI بشكل كبير ليست بالضرورة التي تحفظ أكبر عدد من الـPrompts.

هي التي تفهم أن AI أصبح مكوّنًا داخل طريقة العمل.

المعادلة الأقوى هي:

Strong Fundamentals
        +
Clear Problem Definition
        +
Relevant Context
        +
Right Model
        +
Right Tools
        +
Verification
        +
Evaluation
        +
Security
        +
Human Judgment
        =
Reliable AI Workflow

وأهم سؤال قبل استخدام أي Model ليس:

"إيه أحسن Prompt؟"

ولا:

"إيه أقوى Model؟"

لكن:

"إيه أفضل Workflow لحل المشكلة دي بأعلى جودة ممكنة، وبتكلفة ووقت ومخاطر مقبولة؟"

هذه هي النقلة من:

AI User

إلى:

AI-Assisted Engineer

ثم إلى:

AI Engineer

مصادر ومراجع أساسية

OpenAI

• Does ChatGPT tell the truth?
  https://help.openai.com/en/articles/8313428-does-chatgpt-tell-the-truth

• OpenAI API Quickstart
  https://platform.openai.com/docs/quickstart/make-your-first-api-request

• OpenAI Evals / Graders
  https://platform.openai.com/docs/api-reference/evals

• OpenAI API Data Controls
  https://platform.openai.com/docs/models/default-usage-policies-by-endpoint

Anthropic

• Claude Documentation
  https://docs.anthropic.com/en/docs/welcome

• Anthropic Prompt Engineering
  https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview

Google

• Gemini Prompt Design Strategies
  https://ai.google.dev/gemini-api/docs/prompting-strategies

OWASP

• OWASP Top 10 for LLM Applications
  https://owasp.org/www-project-top-10-for-large-language-model-applications/

• OWASP LLM06: Excessive Agency
  https://owasp.org/www-project-top-10-for-large-language-model-applications/2_0_vulns/LLM06_ExcessiveAgency.html

ملاحظة عن المصادر

هذا المقال لا يتعامل مع نصائح الـPrompting كقواعد سحرية ثابتة. إرشادات النماذج تتغير مع تطور النماذج والمنصات، لذلك الأفضل دائمًا الرجوع إلى documentation الرسمية للـprovider الذي تستخدمه، ثم اختبار الطريقة على بيانات ومهام حقيقية.

المبدأ الذي لن يتغير بسهولة:

لا تجعل AI مصدر الحقيقة الوحيد. اجعله جزءًا من نظام يفهم المشكلة، يستخدم الأدوات المناسبة، ويختبر النتيجة قبل الاعتماد عليها.