هندسة الأوامر للبرمجة: 7 أنماط نستخدمها يوميًا في Claude Code وCursor (2026)

هندسة الأوامر للبرمجة هي الفارق بين وكيل يسلّم طلب سحب (pull request) يعمل فعليًا، ووكيل يكسر شيئًا في الإنتاج بهدوء دون أن يلاحظ أحد. تعلّمنا هذا الدرس بالطريقة المكلفة: تعليمة واحدة غامضة في خط الأنابيب الخاص بنا أنتجت في مرة واحدة 54 صفحة مكرّرة منشورة فعليًا قبل أن ينتبه أحد. اليوم، تكتب مجموعة من 16 وكيل Claude Code محتوانا وتترجمه وتنشره، والأوامر التي تقود هذه العملية لا تشبه إطلاقًا قوائم الـ50 قالبًا التي تتصدر نتائج جوجل. إليك الأنماط السبعة التي نكتبها كل يوم، مع مثال حقيقي قبل/بعد لكل واحد منها.

إجابة سريعة: الأوامر البرمجية الجيدة تشترك في شكل واحد. تذكر الهدف وتعريف "الانتهاء"، وتسمّي الملفات المحددة بدقة ضمن النطاق، وتفرض وضع خطة قبل أي تعديل، وتسلّم الاختبارات جاهزة، وتطالب بدليل بدلًا من عبارة "يبدو جيدًا". افعل هذا وسيكتب وكيل حديث (Claude Code أو Cursor أو GitHub Copilot) كودًا يجتاز المراجعة من المحاولة الأولى في معظم الأحيان. تجاهله وستحصل على هراء واثق من نفسه لكنه يبدو مقنعًا.

الأنماط السبعة، مرتّبة حسب تكرار استخدامنا لها:

1. تأطير المهمة: الهدف والقيود وتعريف "الانتهاء" منذ البداية
2. اختيار السياق: سمِّ الملفات وحصّن الباقي خارج النطاق
3. الخطة أولًا: اجعله يقترح قبل أن يعدّل
4. الاختبار أولًا: ضع اختبارات القبول داخل الأمر نفسه
5. تصحيح الأخطاء: الخطأ + إعادة الإنتاج + النتيجة المتوقعة، والسبب الجذري قبل الإصلاح
6. إعادة الهيكلة: غيّر البنية، حافظ على السلوك، اعرض الفرق (diff)
7. المراجعة: قائمة تحقق تُقارَن بها، إضافة إلى دليل

هندسة الأوامر للبرمجة مقابل ملفات الإعداد: ما الذي يوضع أين

ملفات الإعداد وأوامر المهام تؤديان وظيفتين مختلفتين تمامًا، والخلط بينهما هو الخطأ الأكثر شيوعًا في هذا المجال. ملف CLAUDE.md أو .cursor/rules هو سياسة ثابتة يقرؤها الوكيل في كل جلسة: مكدّسك التقني، قواعد التسمية لديك، أمر تشغيل الاختبارات. أما الأمر (prompt) فهو المهمة المحددة التي تسلّمها له الآن. القواعد الدائمة مكانها ملف الإعداد؛ والمهمة مكانها الأمر.

معظم قوائم "أوامر البرمجة" الشائعة تخلط بين الاثنين وتنصحك بلصق أمر شخصية (persona) ضخم داخل .cursorrules. هذا يضخّم ملف الإعداد الذي يحمّله الوكيل في كل مهمة على حدة، ومع ذلك يفشل في تأطير المهمة الفعلية التي أمامه. أبقِ الاثنين منفصلين:

إن أردت إتقان جانب الإعداد، فقد تناولناه بالتفصيل في أفضل ممارسات CLAUDE.md ودليل قواعد Cursor. هذا المقال هو النصف الآخر: الأوامر التي تكتبها من جديد كل مرة. كلاهما يندرج تحت دليل هندسة الأوامر الأشمل إن أردت الأساسيات أولًا.

هندسة الأوامر للبرمجة: الأنماط السبعة التي نستخدمها يوميًا

كل نمط أدناه له نسخة ضعيفة يكتبها الناس فعليًا، ونسخة قوية تُنتج كودًا يعمل. الفجوة بين الضعيف والقوي هي دائمًا تقريبًا الحركة ذاتها: استبدال الأمنية بمواصفة (spec) دقيقة.

1. تأطير المهمة: اذكر الهدف والقيود وتعريف "الانتهاء"

تأطير المهمة يعني كتابة الهدف والقيود وشكل "الانتهاء" قبل أن يلمس الوكيل أي سطر. الوكيل يُحسّن أداءه وفق ما طلبته حرفيًا، فالطلب الغامض يُنتج تصحيحًا غامضًا. سمِّ الملف، والسلوك الذي تريده، ومعيار القبول، والأشياء التي يجب ألا تتغير.

هذا هو النمط الذي كلّفنا 54 صفحة. تعليمتنا القديمة للترجمة كانت في جوهرها مجرد أمنية:

ضعيف: أعد ترجمة هذا المقال إلى الألمانية واحتفظ بأسماء العلامات التجارية.

لا شيء في هذه التعليمة يحدد ما يُسمح للرابط المختصر (slug) أن يفعله. فعند إعادة التشغيل، "حسّن" الوكيل رابط الصفحة، ولأن رابطًا جديدًا يعني مستندًا جديدًا، انتهى بنا الأمر بصفحتين ألمانيتين منشورتين لنفس المقال. اضرب هذا في عدد اللغات والمقالات القديمة وستحصل على 54 نسخة مكررة وكومة من استبعادات المحتوى المكرر في نتائج البحث. الحل كان مواصفة دقيقة، لا أمنية أجمل:

قوي: أعد ترجمة هذا المقال إلى الألمانية.
- إن كان هناك ملف ألماني موجود بالفعل، انسخ رابطه (slug) الحالي حرفيًا. لا
  تعِد اشتقاقه أو "تحسينه" أبدًا.
- قبل إنشاء أي مستند، ابحث عن المستند الموجود عبر مرجعه الأساسي (canonical)
  وأعد استخدام ذلك السجل.
- إن كان الرابط الذي ستولّده مختلفًا عن الرابط المنشور فعليًا، توقف وأخبرني.
  الرابط المتغيّر ينشئ عنوان URL ثانيًا منشورًا لنفس الصفحة.

الأمر القوي يسمّي نمط الفشل بصوت عالٍ. هذه العادة الوحيدة، ذكر ما يجب ألا يحدث ولماذا، هي أقيم تغيير يمكن لمعظم الفرق تبنّيه. كما ننهي كل أمر مهمة بعقد مخرجات صريح ("يجب أن تذكر رسالتك الأخيرة عدد الكلمات، ودرجة التحقق، وأي ملفات تم لمسها")، حتى يعرف الوكيل ما الذي ينتجه "الانتهاء"، لا ما يجب فعله فقط.

2. اختيار السياق: سمِّ الملفات وحصّن الباقي خارج النطاق

اختيار السياق يعني إخبار الوكيل بدقة بالملفات التي يجب أن يقرأها وتلك التي يجب أن يتركها وشأنها، بدلًا من تركه يبحث (grep) في كل مكان ويملأ نافذته بالضجيج. إرشادات Anthropic نفسها واضحة في تعليل ذلك: نافذة السياق تمتلئ بسرعة وتنخفض الجودة كلما امتلأت، لذا فإن معظم أفضل الممارسات موجودة أساسًا لحمايتها (أفضل ممارسات Claude Code).

ضعيف: أصلح الخطأ في تدفق الدفع (checkout).

قوي: اقرأ فقط src/checkout/cart.ts وsrc/checkout/tax.ts. تقريب الضريبة
خاطئ للطلبات التي تتجاوز $1,000 (فهو يقرّب كل عنصر سطر على حدة بدلًا من
إجمالي الطلب). أصلح التقريب. لا تلمس أي شيء خارج src/checkout/.

نحن نضع حدودًا صارمة. سطر حقيقي من أوامر وكلائنا يقول: "لا تكتب إلى url-mapping.json أو pipeline.md أو config.json، ولا تلمس أبدًا أي ملف خارج مجلد العمل المؤقت الخاص بك (scratchpad)." هذه الجملة الواحدة منعت من الأضرار العرضية أكثر مما فعلته أي عملية تنظيف لاحقة. عندما تحتاج المهمة فعليًا إلى مستندات حية أو أدوات إضافية، نضيفها عمدًا عبر خوادم MCP بدلًا من الأمل في أن يعثر الوكيل على الملف الصحيح بنفسه. وإن كان أي جزء من هذا السياق قادمًا من خارج مستودعك، فعامله كمصدر غير موثوق: راجع ملاحظتنا حول منع حقن الأوامر قبل أن تلصق صفحة مُستخرَجة من الويب داخل وكيل برمجي.

3. الخطة أولًا: اجعله يقترح قبل أن يعدّل

أسلوب "الخطة أولًا" يجعل الوكيل يسلّمك نهجًا مقترحًا قبل أن يعدّل أي شيء. في Claude Code، وضع التخطيط (Plan Mode) هو حالة قراءة فقط صارمة ومفروضة فعليًا، وليس مجرد طلب مهذّب لـ"التفكير أولًا" يمكن للنموذج تجاوزه، لذا فهو لا يستطيع الكتابة حرفيًا حتى توافق على الخطة. فصل البحث والتخطيط عن التنفيذ هو الممارسة الوحيدة التي تعتمد عليها Anthropic أكثر من غيرها لتجنّب حل المشكلة الخطأ.

ضعيف: أضف تحديد معدل الطلبات (rate limiting) إلى الـ API.

قوي: قبل كتابة أي كود، أعطني خطة مرقّمة: أي طبقة وسيطة (middleware)
ستستخدم، وأين تعيش العدّادات، وكيف تتعامل مع استجابة 429 والترويسات
(headers)، وأي اختبارات ستضيفها. انتظر موافقتي قبل التعديل.

لماذا ينجح هذا: الخطة رخيصة القراءة ورخيصة التصحيح. إصلاح خطة خاطئة يكلّف جملة واحدة؛ أما إصلاح كود خاطئ فيكلّف دورة مراجعة كاملة. هذا يتناسب طبيعيًا مع مطالبة النموذج بالتفكير خطوة بخطوة أولًا (راجع التلقين بسلسلة التفكير)، وهو العمود الفقري لـسير عمل Claude Code متعدد الخطوات الذي نشغّله لأي مهمة غير بسيطة.

4. الاختبار أولًا: ضع اختبارات القبول داخل الأمر

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

ضعيف: اكتب دالة لتحليل تواريخ ISO 8601.

قوي: اجعل هذا الاختبار الفاشل ينجح دون تغيير الاختبار:

  parseIso("2026-07-20T15:00:00Z")   -> تاريخ عند تلك اللحظة الدقيقة بتوقيت UTC
  parseIso("2026-07-20")             -> تاريخ عند 2026-07-20T00:00:00Z
  parseIso("not-a-date")             -> يطلق RangeError
  parseIso("")                       -> يطلق RangeError

أعد فقط الدالة واستيراداتها (imports).

الأمثلة الملموسة تتفوق على الصفات دائمًا. عبارة "تعامل مع الحالات الحدّية" مجرد أمل؛ أما أربعة صفوف من مدخل إلى مخرج فهي مواصفة يمكن للنموذج أن يحقّقها فعليًا، ويمكنك تشغيلها بمجرد وصول الكود.

5. تصحيح الأخطاء: الخطأ، إعادة الإنتاج، المتوقع، والسبب الجذري قبل الإصلاح

أمر تصحيح الأخطاء الجيد يعطي الوكيل نص الخطأ، والمدخل الذي يستحضره، وما كنت تتوقعه، ثم يطلب السبب قبل أي إصلاح. تجاهل هذا وسيرقّع الوكيل العرَض فقط، فينتقل الخطأ ببساطة إلى مكان أهدأ.

ضعيف: هذا يُطلق خطأ، أصلحه.

قوي: هذا يُطلق خطأ عند الدفع (checkout). إليك تتبع المكدس (stack trace):
[الصق هنا]. يحدث فقط عندما تحتوي السلة على رمز خصم وبطاقة هدية معًا (لإعادة
الإنتاج: أضف الاثنين، ثم أكمل الدفع). المتوقع: يُطبّق الاثنان معًا، وبطاقة
الهدية أخيرًا. جِد السبب الجذري واشرحه في جملة واحدة قبل أن تغيّر أي شيء.
لا تلفّه بـ try/catch يخفي الخطأ.

جملة "اشرح السبب في جملة واحدة أولًا" تؤدي عملًا حقيقيًا. فهي تُجبر النموذج على الالتزام بتشخيص يمكنك التحقق من معقوليته، بدلًا من تسليم إصلاح لا ترى منطقه أبدًا. أما جملة "لا تخفه بـ try/catch" فتغلق أكثر مخرج هروب شيوعًا.

6. إعادة الهيكلة: غيّر البنية، حافظ على السلوك، اعرض الفرق

أمر إعادة الهيكلة يُقيّد النطاق بشدة: غيّر البنية، حافظ على السلوك مطابقًا تمامًا، واعرض الفرق (diff). دون حدود واضحة، "يرتّب" الوكلاء أشياء لم تطلبها أبدًا، فتفقد القدرة على مراجعة التغيير الذي كان مهمًا فعلًا.

ضعيف: نظّف هذا الملف.

قوي: استخرج منطق التحقق من submitOrder() إلى دالة نقية باسم
validateOrder(). حافظ على كل توقيع عام (public signature) وكل سلوك
مطابقًا تمامًا. لا تغيّر أي شيء آخر في هذا الملف. أرني فرق (diff)
قبل/بعد، مع سطر واحد يوضح لماذا كل تغيير يحافظ على السلوك.

هذا هو الوجه الآخر لتقسيم الإعداد مقابل الأمر الذي ذكرناه سابقًا: قواعد الأسلوب الثابتة لديك تعيش في قواعد Cursor، لكن نطاق هذه العملية بالذات لإعادة الهيكلة ينتمي إلى الأمر. عبارة "لا تغيّر أي شيء آخر" هي التي تُبقي عمليات إعادة الهيكلة قابلة للمراجعة.

7. المراجعة: قائمة تحقق تُقارَن بها، إضافة إلى دليل

أمر المراجعة يسلّم الوكيل قائمة تحقق يقارن بها الكود، ويطالب بدليل لا بحكم. عبارة "يبدو جيدًا" عديمة القيمة؛ أما الأمر الذي شغّله والمخرجات التي حصل عليها فليست كذلك. توضح Anthropic هذا بصراحة: اجعل الوكيل يُظهر دليلًا (مخرجات الاختبار، الأمر ونتيجته) بدلًا من التأكيد على النجاح، لأن قراءة الدليل أسرع من إعادة التحقق بنفسك.

ضعيف: راجع طلب السحب (PR) الخاص بي.

قوي: افحص هذا الفرق (diff) مقابل هذه العناصر الخمسة بالضبط:
1. لم تُضَف أي أسرار أو مفاتيح API
2. كل دالة جديدة لها اختبار
3. لا تغيير في السلوك خارج src/checkout/
4. مسارات الأخطاء تُعيد أخطاءً مُصنَّفة (typed errors)، لا نصوصًا
5. لم يتبقَّ أي console.log
لكل عنصر، اقتبس السطر الذي يحققه أو ينتهكه. ثم شغّل مجموعة الاختبارات
والصق المخرجات. لا تقل "تم"؛ أرني ذلك.

بوابة المراجعة الخاصة بنا مبنية بهذه الطريقة بالضبط. قبل أن يُسمح لوكيل بالإبلاغ عن نشر مقال، يبحث في المسودة عن قائمة كلمات محظورة (حاجز صارم، بلا أي تسامح) ويُشغّل استعلامًا للتأكد من أن جسم المستند ليس فارغًا. الوكيل لا يملك حق الادّعاء بالنجاح؛ عليه أن ينتج مخرجات الفحص فعليًا. أما أدوار المراجعة التي تعيد استخدامها كثيرًا، فرقِّها إلى شخصية محفوظة (persona)، وهنا يأتي دور أمثلة أوامر النظام.

Claude Code مقابل Cursor مقابل Copilot: أين يعيش كل نمط

الوكلاء الثلاثة الرئيسيون لعام 2026 يدعمون كل نمط من الأنماط أعلاه، لكن الواجهة تختلف. يعتمد Claude Code على وضع التخطيط (Plan Mode) والوكلاء الفرعيين (subagents)، ويعتمد Cursor على وضع الوكيل (Agent mode) ونافذة الوكلاء (Agents window) الخاصة به، ويعتمد GitHub Copilot على وضع الوكيل بالإضافة إلى ملفات التعليمات. اختر الأداة التي يعيش فيها فريقك؛ الأنماط تنتقل بسلاسة.

بضعة تفاصيل حالية تستحق المعرفة. وضع التخطيط في Claude Code هو قفل قراءة فقط حقيقي، ووكلاؤه الفرعيون يعمل كل منهم في سياق معزول بأدواته الخاصة (وثائق الوكلاء الفرعيين). أضافت سلسلة Cursor لعام 2026 نافذة وكلاء تُشغّل وكلاء متوازيين، كل منهم في شجرة عمل (git worktree) خاصة به (Cursor 2.0). يقرأ وضع الوكيل في GitHub Copilot تعليمات مخصصة من .github/copilot-instructions.md، بالإضافة إلى ملفات .instructions.md المحددة بالمسار مع حقل applyTo (تعليمات Copilot المخصصة). إن كان Cursor أداتك اليومية، راجع مقالنا عن استخدام Cursor بكفاءة أكبر.

كيف نصوغ أوامر وكلائنا البرمجيين في Techsy

نُشغّل خط أنابيب للمحتوى كفريق من 16 وكيل Claude Code: باحث، وكاتب موجز، وكاتب محتوى، وتسعة مترجمين، ومدقق، وناشر، جميعهم منسّقون عبر رسائل مهام. هناك عرفان (conventions) من هذا النظام ينتقلان إلى أي فريق برمجي.

أولًا، كل أمر مهمة ينتهي بعقد مخرجات. السطر الأخير هو دائمًا نسخة ما من "يجب أن تذكر رسالتك الأخيرة X وY وZ." الوكيل الذي يعرف الشكل الدقيق لـ"الانتهاء" يضل الطريق أقل بكثير من وكيل قيل له فقط ماذا يبدأ.

ثانيًا، لا نسمح أبدًا لوكيل بتقييم واجباته الخاصة بأسلوب نثري. التوليد والتحقق خطوتان منفصلتان، والتحقق أمر ينتج مخرجات، لا رأيًا. هذا الفصل بين البناء والفحص جوهري في الطريقة التي تصف بها Anthropic بناء وكلاء موثوقين، ولهذا السبب تبحث بوابة المراجعة لدينا وتستعلم بدلًا من أن تثق بعبارة "يبدو جيدًا".

هذا أيضًا عملنا اليومي. في Techsy، نبني وكلاء ذكاء اصطناعي وأتمتة لفرق B2B، وانضباط الأوامر بهذا الشكل هو أكبر ما يفصل بين عرض تجريبي وشيء يمكنك عرضه فعليًا على عميل. إن أردت إعداد سير عمل برمجي أو وكيل بطريقة صحيحة، فإن خدمة تكامل الذكاء الاصطناعي لدينا هي حيث نفعل ذلك بالضبط، ويمكنك حجز استشارة مجانية للحديث عن مكدّسك التقني.

قالب أمر جاهز للنسخ واللصق يمكنك تكييفه

إليك الهيكل الذي ننطلق منه لأي مهمة برمجية غير بسيطة. احذف الأقسام التي لا تحتاجها، لكن حافظ على الترتيب، لأنه يعكس الأنماط السبعة.

الهدف
جملة واحدة: ما الذي يجب أن يكون صحيحًا عند الانتهاء.

السياق
اقرأ فقط: <الملفات المحددة>. تجاهل كل شيء آخر.
حقائق ذات صلة: <القيود، الإصدارات، مسبّب الخطأ>.

الخطة أولًا
قبل التعديل، أعطني خطة مرقّمة وانتظر الموافقة.

الاختبارات / الانتهاء
الانتهاء يعني: <الصق الاختبار الفاشل أو صفوف المدخل->المخرج>.
لا تغيّر الاختبارات.

القيود
حافظ على كل التوقيعات العامة والسلوك مطابقًا ما لم يُذكر خلاف ذلك.
لا تلمس <الملفات/المناطق>. سمِّ أي افتراض تضعه.

المخرجات
أرني فرقًا (diff) قبل/بعد، شغّل الاختبارات، والصق المخرجات.
لا تقل "تم"؛ أرني الدليل.

احفظه كمقتطف (snippet)، أو الأفضل، قسّمه: القيود الثابتة تذهب إلى ملف الإعداد، والهدف والسياق والاختبارات تذهب إلى الأمر. هذا التقسيم هو بيت القصيد.

عن الكاتب

مرت باتور غوربوز (Mert Batur Gurbuz) هو الشريك المؤسس لـ Techsy.io، حيث يقدّم الفريق وكلاء ذكاء اصطناعي وأنظمة أتمتة وخطوط أنابيب صوتية/SDR لعملاء B2B. يدرس في جامعة برمنغهام ويكتب عن مجموعة أدوات LLM التي يستخدمها فريق Techsy فعليًا في الإنتاج.

المؤهلات: شريك مؤسس، Techsy.io، جامعة برمنغهام. تواصل عبر LinkedIn.

الأسئلة الشائعة

ما هي هندسة الأوامر للبرمجة؟

هندسة الأوامر للبرمجة هي ممارسة كتابة تعليمات تجعل وكيل الذكاء الاصطناعي ينتج كودًا صحيحًا وقابلًا للمراجعة. عمليًا، تعني ذكر الهدف وتعريف "الانتهاء"، وتسمية الملفات ضمن النطاق، وفرض خطة قبل التعديل، وتوفير الاختبارات، والمطالبة بدليل. هي أقرب إلى كتابة مواصفة (spec) منها إلى كتابة جملة بارعة.

كيف تختلف عن كتابة ملف CLAUDE.md أو .cursor/rules؟

ملفات الإعداد تحمل سياسة ثابتة يقرؤها الوكيل في كل جلسة: مكدّسك التقني، وأعرافك، وأمر الاختبار. أما الأمر الخاص بالمهمة فهو المهمة المحددة التي تسلّمها له الآن. ضع القواعد الدائمة في الإعداد والمهمة في الأمر. لصق أوامر مهام كاملة داخل ملف إعداد يُضخّم كل جلسة ومع ذلك يفشل في تأطير المهمة الفردية.

ما هي أفضل بنية للأوامر الموجهة لوكلاء البرمجة بالذكاء الاصطناعي؟

استخدم أقسامًا موسومة بدلًا من فقرة واحدة: الهدف، السياق، الخطة، الاختبارات، القيود، والمخرجات. الوكلاء يحلّلون الأوامر المُهيكلة بموثوقية أكبر من جدران النصوص. اذكر معايير النجاح منذ البداية، وقدّم من مثال إلى ثلاثة أمثلة ملموسة بدلًا من الصفات، وحدّد صيغة المخرجات الدقيقة التي تريدها.

كيف أكتب أمر تصحيح أخطاء جيدًا؟

أعطِ الوكيل أربعة أشياء: نص الخطأ الدقيق أو تتبع المكدس، والمدخل الذي يعيد إنتاجه، وما كنت تتوقعه، وطلبًا للسبب الجذري قبل أي إصلاح. أضف "اشرح السبب في جملة واحدة قبل تغيير أي شيء" حتى تتمكن من التحقق من التشخيص، و"لا تخفه بـ try/catch" حتى يصلح الخطأ بدلًا من إخفائه.

هل يجب أن أضمّن اختبارات في أوامري البرمجية؟

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

هل تعمل هذه الأوامر في Cursor وGitHub Copilot أيضًا؟

نعم. الأنماط مستقلة عن الأداة. يُظهرها Claude Code عبر وضع التخطيط والوكلاء الفرعيين، ويُظهرها Cursor عبر وضع الوكيل ونافذة الوكلاء الخاصة به مع شجرة عمل لكل وكيل، ويُظهرها GitHub Copilot عبر وضع الوكيل بالإضافة إلى .github/copilot-instructions.md. الواجهة تتغيّر؛ أما تأطير المهمة، واختيار السياق، والخطة أولًا، والمراجعة القائمة على الدليل، فلا تتغيّر.

كم يجب أن يكون طول الأمر البرمجي؟

طويلًا بما يكفي ليكون مواصفة، وقصيرًا بما يكفي ليبقى مركّزًا. جودة الاستدلال تتراجع كلما امتلأ السياق، لذا فضّل البنية على الحجم: أمر موسوم من 150 إلى 300 كلمة مع الملفات والاختبارات الصحيحة يتفوق على أمر مطوّل ومتشعب. انقل أي شيء ينطبق على كل مهمة إلى ملف الإعداد بدلًا من تكراره.

كيف أمنع وكيل الذكاء الاصطناعي من تغيير كود لم أطلب تغييره؟

حصّن النطاق داخل الأمر. حدّد بدقة أي الملفات يُسمح له بتعديلها، وأضف "لا تغيّر أي شيء آخر"، واطلب "حافظ على كل التوقيعات العامة والسلوك مطابقًا ما لم أقل خلاف ذلك". أما لعمليات إعادة الهيكلة، فاطلب فرقًا (diff) قبل/بعد مع سطر واحد يوضح لماذا كل تغيير يحافظ على السلوك، حتى يكون أي تعديل غير مطلوب واضحًا عند المراجعة.

هل تستحق مكتبات الأوامر الجاهزة للنسخ واللصق العناء؟

كنقطة انطلاق، أحيانًا نعم. كأداة نهائية جاهزة، نادرًا. مكتبة من 50 أمرًا تمنحك صياغة، لكنها لا يمكن أن تعرف ملفاتك أو اختباراتك أو قيودك، وهناك بالضبط تعيش الصحة الفعلية. تعلّم الأنماط، احتفظ بقالب واحد قابل للتكييف، واملأ تفاصيل المهمة التي أمامك بنفسك.