معرفة متخصصة تُحمَّل عند الطلب

مشكلة «حشو كل شيء في system prompt»

لديك 20 skill، كل منها مكتوب بتفصيل: pdf-processing (كيفية قراءة PDF)، code-review (قائمة مراجعة الكود)، git-workflow (أنماط git الشائعة)... الطريقة المنطقية: دمجها كلها في system prompt ليراجعها النموذج في أي وقت.

النتيجة:

• كل استدعاء يستهلك 15,000–30,000 token كمدخلات (حتى لو السؤال لا يحتاج أي skill).
• تتشتت انتباه النموذج — القواعد المذكورة في system prompt الطويل ينخفض امتثاله لها.
• تعديل skill واحد يُبطل كل الـ cache للمحادثات السابقة.

نهج s05 هو التقسيم إلى طبقتين.

البنية ذات الطبقتين

الطبقة الأولى · رخيصة: system prompt يحمل فقط اسم الـ skill وجملة وصفية (حوالي 100 token لكل skill). 20 skill = 2,000 token، مقبول.

# 系统提示里的 skill 清单
Skills available:
  - pdf: Process PDF files. Extract text, tables, metadata.
  - code-review: Systematic code review checklist.
  - git-workflow: Common git branching and rebase patterns.

الطبقة الثانية · عند الطلب: حين يحتاج النموذج skill معين يستدعي load_skill(name="pdf")، ويصل نص الـ skill الكامل (قد يبلغ 5,000–10,000 token) عبر tool_result إلى السياق. الـ skills غير المستخدمة لا تُحمَّل بأي token.

# tool_result 里返回完整 skill
<skill name="pdf">
  Step 1: Use pdfplumber for extraction...
  Step 2: Handle OCR fallback when needed...
  Step 3: Structure output as Markdown table...
</skill>

مقارنة تكلفة الـ token

اختبار بسيناريو حقيقي. افترض 20 skill، متوسط كل نص 3,000 token. المستخدم يطرح سؤالاً (مثلاً «صحح خطأ في واجهة تسجيل الدخول») — هذا السؤال على الأرجح لا يحتاج أي skill.

صيغة ملف SKILL.md

ملفات الـ skill تستخدم YAML frontmatter مع نص أساسي:

---
name: pdf
description: Process PDF files. Extract text, tables, metadata.
tags: document,parsing
---

Step 1: Use pdfplumber for extraction. Handle multi-column layouts...
Step 2: For scanned PDFs, fall back to OCR via tesseract...

الـ frontmatter للطبقة الأولى (name/description/tags)، والنص الأساسي للطبقة الثانية. هذا الأسلوب مستوحى من المدونات الثابتة (Jekyll، Hugo)، ومن يعرفها يفهمه فوراً.