Cursor: محرر مبني حول السياق
درس 5 من 12
5Cursor: محرر مبني حول السياق
النموذج نفسه، النتيجة مختلفة. السبب ليس «ذكاءً أعلى» بل ما يراه، وهذا الجزء عن إدارة السياق وعن ملف قواعد واحد يغيّر جواب المساعد كلّيًا.
ماذا تشاهد في الرسم: الملفات المفتوحة وملف القواعد تدخل نافذة السياق مع سؤالك، والجواب يتغيّر بتغيّر ما رآه النموذج.
خارطة هذا الجزء
المفاهيم بالترتيب، اضغط أيًّا منها للقفز إليه:
طريقان إلى نفس الفكرة
سؤالان متطابقان لشخصين: الأول أعطيته ورقة واحدة، والثاني أعطيته الملف كاملًا وقائمة قواعد الفريق. سيجيب الثاني أفضل لا لأنه أذكى، بل لأنه يرى أكثر. Cursor محرّر مبني حول هذه الفكرة: أن تختار بدقة ما يراه المساعد.
جودة الجواب تتبع السياق: الملفات المشار إليها بـ@، وفهرسة المستودع، وملف القواعد .cursor/rules الذي يضيف تعليمات ثابتة لكل طلب. سياق كثير غير مرتبط يضر كما يضر السياق الناقص، فأضف ما يحتاجه السؤال فقط.
المتطلبات قبل البداية
الجزء الرابع
رأيت كيف يكتب الوكيل ملفات، ورأيت اختباره الذي لا يفشل. هذا الجزء يشرح لماذا كتبه كذلك.
مشروع فيه أكثر من ملف
مجلد mini-agent-demo من الجزء السابق يكفي. الفكرة لا تظهر على ملف واحد.
VS Code يعمل عندك
لأن Cursor نسخة معدّلة منه؛ ستتعرّف على كل شيء فورًا، وستستورد إعداداتك في أول تشغيل.
استعداد لتغيير فكرة
ستترك فكرة «أي مساعد أذكى؟» وتأخذ فكرة «أي مساعد يرى أكثر؟». الثانية هي الصحيحة.
المفاهيم الأساسية
محرر مبني على VS Code نفسه (fork)، فاختصاراتك وإضافاتك ومظهرك تنتقل معك. الاختلاف ليس في المحرر بل في أن الذكاء مدمج في مركزه لا ملحق به.
السياق هو المنتج. كل المساعدين يستخدمون نماذج متشابهة؛ الفرق في كمية ودقّة ما يُحمَّل في نافذة السياق قبل أن يجيب. مساعد يرى مشروعك يتفوّق على مساعد أذكى يرى ملفًا واحدًا.
المحرر يبني فهرسًا للمشروع ليجيب عن «أين تُستخدم هذه الدالة؟» بلا أن تفتح الملفات. وهذا يعني أن كودك يُقرأ ويُرسل، فاعرف سياسة مشروعك قبل أن تفهرس مستودعًا خاصًا.
ملف نصّي في مشروعك يُقرأ مع كل طلب: أسلوبك، ممنوعاتك، تعريفك لكلمة «اختبار». تُكتب القواعد في AGENTS.md أو في ملفات .mdc داخل مجلد .cursor/rules.
@ تُحمّل ملفًا أو مجلدًا أو رمزًا بعينه. الإشارة الصريحة أدقّ من الفهرسة التلقائية دائمًا، والمهارة الحقيقية هي أن تعرف ماذا تُرفق، لا أن تُرفق كل شيء.
محرر منفصل، واشتراك، واعتماد على أداة واحدة. خطط الأسعار وأسماء الميزات تتغيّر كثيرًا، راجع الموقع الرسمي، والمهارة المنقولة هي إدارة السياق لا اسم الزرّ.
كيف يعمل؟
شكل 1، كل جواب يُبنى من هذا الخليط فقط، وما لم يدخل النافذة غير موجود بالنسبة للنموذج
شكل 2، سلّم الصلاحية والرؤية: كل درجة ترى أكثر وتستطيع أكثر، وتحتاج مراجعة أكثر
وهذه صيغ الإشارة التي ستكتبها أكثر من غيرها:
@dice.js one file @mini-agent-demo/ a whole folder @AGENTS.md the rules, pinned explicitly #roll a symbol, wherever it is defined @web the live internet, not the training data
التمرين: ملف قواعد واحد يصلح خطأ الجزء السابق
في الجزء الرابع طلبنا «اختبارًا» فحصلنا على ملف يطبع ولا يفحص. الوكيل لم يكن مخطئًا بمعايير لم نعطه إياها: كلمة «اختبار» غامضة، وهو اختار أبسط تفسير. الحل ليس طلبًا أفضل، بل قاعدة مكتوبة مرة واحدة.
# Project rules for mini-agent-demo ## Testing - A test MUST assert. A file that only calls `console.log` is not a test. - Every test MUST exit non-zero when a check fails. - Cover: the happy path, the boundaries, and at least one invalid input. - Name real tests `*.spec.js`. Never name a print-only script `*.test.js`. ## Style - CommonJS (`require` / `module.exports`), no build step. - Validate arguments at the top of a function and throw a typed error. - No new dependencies without asking first. ## Before you say you are done - Run `node dice.spec.js` and paste the real output. - Break the implementation once, re-run, and confirm the test goes red.
ضع هذا الملف في جذر المشروع فيصير هيكل المجلد:
mini-agent-demo/ ├── AGENTS.md <- standing instructions, read every time ├── dice.js ├── dice.spec.js <- the real test (asserts, can fail) ├── dice.test.js <- the print-only script from part 4 └── README.md
console.log فقط ليس اختبارًا» هو بالضبط الخطأ الذي وقع فيه الوكيل في الجزء السابق.dice.js وشغّل الاختبار. إن لم يحمرّ، فالقاعدة لم تُطبَّق وليست المشكلة في النموذج.| بلا ملف قواعد | مع ملف قواعد | |
|---|---|---|
| تعريف «اختبار» | تخمين النموذج | جملتك أنت |
| ثبات النتيجة بين الجلسات | لا | نعم |
| ينتقل لبقية الفريق | لا | نعم، مع المستودع |
| يحتاج إعادة شرح كل مرة | نعم | لا |
| المراجعة المطلوبة منك | كاملة | كاملة، القاعدة تقلّل الخطأ لا المسؤولية |
اعتقاد شائع × الحقيقة
| الاعتقاد | الحقيقة |
|---|---|
| «Cursor أذكى لأنه يعطي أجوبة أفضل.» | غالبًا يستخدم نفس النماذج. ما يتغيّر هو السياق المحمّل قبل الجواب، وهذا شيء تتحكّم فيه أنت. |
| «أرفق المشروع كله ليفهم أكثر.» | النافذة محدودة. الإرفاق الزائد يزاحم المهم ويجعل الجواب أعمّ، لا أدقّ. |
| «ملف القواعد تنظيم زائد.» | هو الفرق بين مساعد يخمّن معاييرك ومساعد يعرفها. وهو أرخص وثيقة في المشروع. |
| «يجب أن أتعلّم Cursor تحديدًا.» | المهارة المنقولة هي إدارة السياق وكتابة القواعد والمراجعة. الأداة تتغيّر؛ هذه لا تتغيّر. |
| «الفهرسة شيء داخلي لا يهمّني.» | الفهرسة تعني إرسال الكود للمعالجة. في مشروع خاص هذا قرار سياسة لا تفصيلة تقنية. |
جرّب بنفسك
طلبت تعديل دالة في dice.js وهي تُستدعى من ثلاثة ملفات. ما أفضل ما تُرفقه؟
ترفق ما سيتغيّر، وما يحدّد العقد الصحيح، وما يحدّد أسلوبك. الأول يغرق النافذة، والثاني ينسى المستدعين، والرابع يفترض أن الفهرسة تكفي، وهي أقل دقّة من الإشارة الصريحة.
أي سطر يصلح قاعدة في AGENTS.md؟
لأنها الوحيدة القابلة للفحص: يمكن تشغيل الاختبار وقراءة رمز الخروج. البقية أمنيات لا يمكن لأحد، نموذجًا أو إنسانًا، أن يثبت أنه التزم بها.
بطاقات مراجعة سريعة
AGENTS.md في الجذر، أو ملفات .mdc داخل .cursor/rules.@ تفعل ماذا؟تحقّق من فهمك
1. بجملة واحدة: لماذا يعطي نفس النموذج جوابًا أفضل داخل محرر مبني حول الذكاء؟
لأنه يجيب عن سؤال مختلف: السؤال الأول «أكمل هذا السطر»، والثاني «أكمل هذا السطر وأنت ترى الملفات المرتبطة والقواعد والاختبار». الذكاء ثابت، والمعطيات تغيّرت.
2. لماذا الإرفاق الزائد يضرّ؟
لأن نافذة السياق محدودة ولها أولوية: كل ملف غير ضروري يحتلّ مكانًا كان سيأخذه الملف المهم، ويدفع النموذج إلى تعميم أوسع. الدقّة تأتي من الاختيار لا من الكمية.
3. (اكتشف الخطأ) زميل كتب ملف قواعد من ١٢٠ سطرًا، والنتائج لم تتحسّن. ما الأرجح؟
أن القواعد غير قابلة للفحص («كود نظيف»، «أداء عالي»)، أو متناقضة، أو طويلة لدرجة أنها تستهلك السياق الذي كان سيذهب للكود. العلاج: اختصرها إلى عشر جمل يمكن إثبات الالتزام بها.
4. مديرك يسأل: نشتري اشتراكات للفريق كله؟ ماذا تحتاج تعرف أولًا؟
ثلاثة أشياء: ما سياسة الشركة في إرسال الكود للمعالجة (الفهرسة)، وهل المشروع كبير بحيث يُحسّن فهم المشروع فعلًا، وهل الفريق يراجع الـdiff. بلا المراجعة ستشتري سرعة في إنتاج كود لا أحد يفهمه.
5. (قرار) تحسّنت سرعتك كثيرًا، وبدأت تلاحظ أنك لا تعرف كيف يعمل نصف مشروعك. ماذا تفعل؟
تعتبرها إشارة لا إنجازًا. العلاج عملي: اكتب أنت أول نسخة من أي جزء جديد، واستخدم المساعد في التكرار والشرح لا في القرار، واشترط على نفسك أن تستطيع شرح كل ملف تدمجه بجملة واحدة. السرعة التي تتجاوز فهمك دين لا إنتاج.