العمل داخل Cursor / Claude Code / Aider / Copilot

Copilot: تشكيل الـ completions بالـ comments

4 دقيقة للقراءة

GitHub Copilot، Tabnine، JetBrains Code Completion، وأدوات completion inline مشابهة مش بياخدوا prompts على طول. بياخدوا الملف زي ما كتبته لحد الـ cursor. الـ "prompt" هو الكود اللي فوق. ده فيه الـ imports، اسم الـ function، أسامي الـ parameters، الـ docstring، وأي comments كتبتها.

ده بيخلّي نمط prompt engineering بسيط بس عكس الحدس: مش بتكتب prompt منفصل — بتكتب الملف بطريقة تخلّي الـ completion الجاي واضح.

قارن طريقتين لبدء function. الاتنين syntactically valid. الـ completion اللي بتجيب مختلف جداً.

إعداد ضعيف:

def parse(s):
    # cursor here

الـ completion ما عندهاش حاجة تتمسك بيها. Copilot بيختار JSON parse عام، أو يخترع Parser class داخلية، أو يطلّع placeholder. هتعيد 3 مرات قبل ما تقرّب.

إعداد قوي:

def parse_invoice_line(line: str) -> dict:
    """
    Parse a single invoice line like '3 x Latte @ 65.50' into a dict
    with keys: qty (int), item (str), unit_price (float).
    Raises ValueError if the line doesn't match the expected format.
    """
    # cursor here

دلوقتي الـ completion تقريباً مجبورة. اسم الـ function، type hint، والـ docstring بيضيّقوا البحث على implementation واحد واضح. هتجيب حاجة قريبة من الصح من أول محاولة.

النمط: كل ما السطح فوق الـ cursor مقيّد، الـ completion أحسن. تحديداً، العناصر دي بتحرّك الـ completion ناحية الصح:

العنصربيقيّد إيه
اسم function محددالـ intent على مستوى عالي
Type hints على الـ parametersشكل الـ input
Type hint على الـ returnشكل الـ output
Docstring بمثال I/Oالتحويل بالظبط
Imports موجودة بالفعلالمكتبات اللي الموديل يستخدمها
Function مشابهة قريبةستايل الفريق

هتلاحظ إن دي حاجات المفروض تكتبها على أي حال. هي الـ documentation اللي زميل بحرص هيحطّها قبل ما يطبّق. Inline-completion tools بتحوّل الانضباط ده لمضاعف إنتاجية — كل ما الإعداد بحرص، الـ completion أحسن.

اللي محرّك الـ completion "بيشوفه" فوق الـ cursor:

تكنيك مفيد لما الـ completion غلط: اكتب comment فوق الـ cursor بيوصف اللي توقعته. ما تمسحش الـ completion الغلط — سيبه. الـ completion الجاي بيشوف المحاولة الغلط وتصحيحك، وبيتعدّل. 3 أو 4 turns من ده والموديل بيتقارب على الـ implementation اللي عايزه.

def parse_invoice_line(line: str) -> dict:
    """..."""
    # Note: must handle whitespace around the 'x' and '@' tokens
    # Note: unit_price is float, not int — '@ 65' returns 65.0
    # cursor here

كل comment هو constraint الـ completion الجاي بيحترمه. إنت فعلياً بتكتب prompt — بس باللغة الطبيعية اللي قارئ مستقبلي هيستفيد منها. الـ comments بتفضل في الملف كـ documentation؛ مش بتختفي زي chat message.

النمط ده مهم أكتر مما يبان عشان completion tools هي الـ LLM اللي معظم المهندسين بيستخدموه. فريق بيكتب أسامي functions و docstrings كويسة بيجيب completions أحسن بكتير من فريق ما بيكتبش — من غير ما يغيّر أدوات، موديلز، أو أي settings.

التالي: conventional commit messages، وليه أسهل مكسب في prompt engineering. :::

اختبار

الوحدة 5: Prompts الأدوات و الـ IDE

خذ الاختبار
هل كان هذا الدرس مفيدًا؟

سجّل الدخول للتقييم

نشرة أسبوعية مجانية

ابقَ على مسار النيرد

بريد واحد أسبوعياً — دورات، مقالات معمّقة، أدوات، وتجارب ذكاء اصطناعي.

بدون إزعاج. إلغاء الاشتراك في أي وقت.