الحديقة السرية للمطور: كيف تُوجّه الأونتولوجيا المكانية نماذج اللغة الكبيرة دون هندسة المطالبات

Publié le 30 April 2026

وقت القراءة : 20 minutes

هندسة المطالب هشة. عند 80 000 توكن، قواعد التوجيه الخاصة بك مغمورة في الضوضاء، وينسى نموذج اللغة الكبيرة ما طلبته منه في بداية المحادثة. حلي؟ عدم التوجيه عبر النص، بل عبرفضاء. قمت بتنظيم مساحة التطوير الخاصة بي إلى أربع دوائر ثقة متحدة المركز — من الحديقة السرية الحميمة إلى المعامل العامة — وكل دائرة هي منطقة مادية في نظام الملفات. لا يحتاج نموذج اللغة الكبيرة إلى تذكيره بالقواعد: مسار الملف يحتوي عليها. إليك كيف يعمل ذلك، ولماذا هندسة التماثل المكاني أكثر مرونة من`system prompt`من 500 سطر

هذا مقال طويل.
اجلس براحة.

تشنج

(empty)

الملاحظة : هندسة المطالبات هي قلعة رملية

خلال ثلاثة أسابيع، قمت بتطوير مكونات Gradle مع Opencode، باستخدام ثلاثة LLMs مختلفة — Kimi K2.6، GLM-5.1، و DeepSeek-V4-Pro (البقاء الوحيد، لكن هذه قصة أخرىتم تغطيتها هنا.) طريقة إدارة الوكيل agentقمت بتوثيقها بالتفصيل في مقال سابق. تعتمد على ملفات AsciiDoc —AGENT.adoc, INDEX.adoc, PROMPT_REPRISE.adoc— تحمّل حوالي 30 000 رمز من القواعد، والbacklog، والتاريخ في بداية كل جلسة.

ورغم هذه البنية التحتية الوثائقية، لفت انتباهي شيئين:

  1. النموذج اللغوي ينسى. حتى مع القواعد المطلقة في مقدمة كل ملف EAGER، بعد أكثر من 60000 رمز متراكم (السياق الأولي + المحادثة)، بدأ Kimi K2.6 في اقتراح`Write`ساحقة على ملفات التكوين. GLM-5.1 خلط رمز Firebase مع علامة احتياطية ليتم استبدالها. كانت القواعد مكتوبة — لم يعد LLM يراها voyait أكثر.

  2. الحُكم نفسه أصبح مشكلة. بعد تنفيذ آلية Hot/Warm/Coldمقال حول دوران النسخ الاحتياطي. لتجنب انفجار السياق، كانت ملفاتي EAGER لا تزال تزن 1414 سطرًالقد وثّقت هذا التدقيق هنا.. الحُكم — المصمم لحماية LLM من التشبع — كان يشبع LLM.

كنت بحاجة إلى آلية محاذاة لا تعتمد على عدد الرموز في الموجه.

الجواب: توقف عن المحاذاة حسب النص، وابدأ بالمحاذاة حسب المساحة.

الأربع دوائر من الثقة: أنطولوجيا مكانية

ملفي`workspace/(داخل~/workspace/`) ليس مستودع Git. إنها جذر كل عملي — الكود، والتوثيق، والتدريب، والبنية التحتية. وهو منظم في أربع regiones ليست اتفاقيات ترتيب، بلدوائر ثقة مركزة :

مستوى

العلامة

المنطقة الفيزيائية

CVS

الرؤية

0

حديقة سرية

`workspace/`جذر

لا شيء

شخصي — فكرة حرة، لا يوجدcommit، لا يوجدنشر

1

خزنة

configuration/

Git خاص (منفرد)

الأسرار، والرموز، أرشيف الرؤية. شخص واحد فقط.

2

مكتبة

office/

Git خاص (موسع)

البيانات التربوية، SPG/SPD، مخططات JSON. تم تحديد دائرة الثقة.

4

المصاهر (العامة)

foundry/

Git عام (Apache 2.0)

شفرة المصدر، الإضافات، الاختبارات، التوثيق التقني.

ملاحظة: لا يوجد مستوى 3 في الجدول. المستوى 3 هو مستوى transitoire : إنه محتوى من`office/`الذي تم إخفاء هويته وجاهز للنشر كبيانات مفتوحة. ليس له منطقة فيزيائية خاصة — إنه حالة للبيانات، وليس موقعًا.

كل مستوى يجيب على سؤال دقيق :

  • أين أودع فكرة ليست جاهزة بعد للمشاركة، حتى مع دائرة محدودة ؟ → الحديقة السرية. لا يوجد Git. لا ضغط.

  • أين يمكن تخزين رمز API دون أن يتسرب؟ → الخزنة`configuration/`). معزول جسديًا. لا يمكن لأي مستودع آخر الإشارة إليه عن طريق الخطأ.

  • أين يمكن إنشاء كتالوج التدريب بشكل مشترك مع OF تجريبي؟office/) ذو إصدارات, تعاوني, لكن خاص.

  • أين يمكن تصنيع إضافة Gradle مفتوحة المصدر؟ → المصانع`foundry/`). عامة, قابل للشوكة, تم اختباره في CI.

هذه الأنطولوجيا هيقابل للاستهلاك بواسطة LLMعندما يقرأ ملف في`foundry/plantuml-gradle/src/`, هو يعلم ضمنا : "أنا في الدائرة 4 — كود عام، اختبارات إلزامية، لا أسرار، لا بيانات تعليمية". لا يحتاج إلى تذكير عبر دعوة.

الحديقة السرية : الفضاء خارج CVS

إنه المفهوم الأهم — والأكثر عكسًا للحدس.

الجذر`workspace/ليس لديه.git/. الوثائق التي تعيش هناك (`WORKSPACE_VISION.adoc, WORKSPACE_AS_PRODUCT.adoc, WORKSPACE_ORGANIZATION.adoc— والّذي تقرأه الآن، الذي ينشأ عنه) غير مخصّصين للإصدار، المشاركة، أو حتى إعادة القراءة من قبل شخص آخر غيري. هذه هيأفكار في طور الإنبات.

الحديقة السرية هي out-of-CVS بطبيعتها. غياب نظام التحكم في الإصدارات هو شرط حرية التفكير. لا يكتب هناك ليُقرأ — بل يكتب هناك لتوضيح رؤيته الخاصة.

لكن هذه الحرية لها تكلفة : واحد`rm`عرضي، إنها أشهر من التفكير الاستراتيجي التي تختفي. الحل ليس في إصدار نسخ من الحديقة (لأن ذلك سيؤدي إلى تدميرها) — أنهيعكسفي الدائرة الأكثر تقييدًا.

ملف .gitignore كإعداد للحوكمة

في جذر`workspace/, ملف.gitignore`الحد الأدنى يعلنسياسة الأرشفةملفات الحديقة السرية:

.goosehints
.goose

Ce .gitignore`لا يحتوي على وظيفة Git تقليدية (لا يوجد.git/`إلى الجذر). يعمل كـملف إعدادات الحوكمةالذي يجيب على سؤال دقيق: أي artefacts من الحديقة السرية يستحقون أن يُتَارَخوا، وأيهما صِرفًا مؤقتًا؟

  • الملفات المذكورة في`.gitignore`—.goosehints, .goose— إنها قطع أثرية عابرة تم إنشاؤها من قبل الوكلاء. لا توجد قيمة استراتيجية. لا توثيق تاريخي.

  • الملفات`.adoc`من الجذر —WORKSPACE_VISION.adoc, WORKSPACE_ORGANIZATION.adoc, WORKSPACE_AS_PRODUCT.adoc, WHAT_THE_GAMES_BEEN_MISSING.adoc, depots_implementes_strategie.adoc, synthese-LLMs-long-contexte.adoc— ليسوالافي`.gitignore`هذه هي الآثار التي يجب تأريخها.

Le `.gitignore`هومخطط الحوكمة: كل ما ليس مدرجًا هناك هو مرشح لأخذ لقطة. والـ LLM، عند قراءة هذا الملف، يعرف بالضبط ما يجب أرشفته وما يمكن تجاهله — دون أن نحتاج إلى تذكيره بذلك في موجه.

آلية اللقطة

أنشأت`configuration/vision-archive/: لقطات مؤرخة من جميع.adoc`من الجذر، متعهدون في المستودع الخاص`configuration/`. كل جلسة عصف ذهني تنتج لقطة :

DATE=$(date +%Y-%m-%d)
mkdir -p /home/cheroliv/workspace/configuration/vision-archive/$DATE
cp /home/cheroliv/workspace/*.adoc /home/cheroliv/workspace/configuration/vision-archive/$DATE/
cd /home/cheroliv/workspace/configuration && git add vision-archive/ && \
  git commit -m "vision-archive: snapshot $DATE"

يُشَغَّل الإجراء في نهاية الجلسة بواسطة الـLLM نفسه، الذي ينفذ هذه المهمة العالمية للتوجيه. كل لقطة تلتقط الحالة الكاملة للتفكير الاستراتيجي في لحظة T.

تاريخ Git لـ`configuration/`يصبح الـسيرة ذاتية لتفكيري الاستراتيجي. أنا أستطيع أن أفعل واحدًا`git log — vision-archive/`ورؤية تطور رؤيتي، جلسة بجلسة، تاريخ بتاريخ.

مثال حقيقي للتاريخ بعد يوم عمل :

$ git -C configuration log --oneline -- vision-archive/
1089d1b vision-archive: fin de session finale 2026-05-03
6b21eaf vision-archive: fin de session 2026-05-03-1300
1690f82 vision-archive: post-article 2026-05-03
28e6593 vision-archive: post-migration 2026-05-03
3707b78 vision-archive: snapshot 2026-05-03 — jardin secret initial

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

الملف`configuration/vision-archive/latest/`يحتوي باستمرار علىنسخة عملمن آخر snapshot، يعمل كمرجع سريع دون الحاجة إلى التنقل في تاريخ Git.

وبالنسبة للـ LLM، هومرجعية الاتساق: عندما يلاحظ تناقضًا بين التنفيذ الحالي والرؤية المؤرشفة في تاريخ سابق، يمكنه الإبلاغ عنها.

الخزنة: configuration/ مثل Spring Cloud Config

`configuration/`لا يحتوي إلا على أرشيف الرؤية. وظيفتها الأساسية — والمستقبلية — هي أن تكونخادم Spring Cloud Config. جميع الأسرار، والرموز، وبيانات الاعتماد، ووصفات البنية التحتية موجودة هنا، في مستودع Git خاص يمكن الوصول إليه فقط للمالك.

لماذا مستودع منفصل بدلاً من ملف`.env`في كل مشروع؟

  • دفع غير مقصود لسر : مستحيل. الأسرار موجودة في مستودع خاص لا يمكن للمشاريع العامة الإشارة إليه عن طريق الخطأ.

  • Audit : يُعطِي سجل Git مسار كل تعديل في التكوين. من غير ما، ومتى، وبأي هاش SHA.

  • إرجاع :`git revert`على تكوين مكسور. لقطة فورية، بدون نسخ احتياطي يدوي.

المكتبة : office/ كبيانات قابلة للاستهلاك

`office/`هو المكمل الوثائقي لعملية التطوير. يحتوي على مقالات المدونة، والمواصفات الفنية، ومواد التدريب (38 دليلاً لدورات FPA، SPG/SPD، مخططات JSON، تصانيف بلوم/هارو/كراثوول) — كل ما يشكل الجزءمادة تعليمية.

لكن`office/`ليس مجرد درج للوثائق. إنهمصدر بيانات منظمةأن المكونات الإضافية لGradle من`foundry/`يستهلكون. مقالة مدونة في`office/`هو إدخال سيُحوّله برنامج إضافي إلى HTML. مستند AsciiDoc SPG في`office/metiers/FPA/`إنه artefact الذي سيحلله منسّق لإنشاء الشرائح، والاختبارات، وكبسولات الفيديو.

Et le `build.gradle.kts`في جذر`office/`ليس كود عمل — إنهسكريبت استهلاك نظام الإضافات. يقول: "هذه هي إضافات Gradle التي أستخدمها، هذا هو سياق مساحة العمل الخاصة بي

المصاطب : foundry/ كالتنفيذ

foundry/`يحتوي علىكود مصنع. 54 مستودعات جيت، من بينها 7 التي تُدار حاليًا بواسطة.agents/`. هنا تصبح الرؤية قابلة للتنفيذ — إضافات Gradle، CI/CD، اختبارات JUnit5 + Cucumber.

العلاقة مع`office/`وهي ثنائية الاتجاه :

  • office/→foundry/: البيانات التعليمية هي المادة الأولية التي تستهلكها الإضافات.

  • foundry/ → office/: الإِضافَات تُنتِجُ البَيَانَاتُ الَّتِي تُثْرِى`office/` — le `graph.json`من graphify-gradle, decks slider مترجم, تقارير من build.

الإيجابيات/السلبيات : المحاذاة المكانية vs المحاذاة حسب المطالبة

لنقارن الطريقتين.

النهج الكلاسيكي: محاذاة بالتحفيز المسبق

�✅ محترف

❌ ضد

بسيط التنفيذ. كتلة نص في موجه النظام.

هشّ مع السياق الطويل : القاعدة تغرق بعد 80 ألف رمز.

يعمل للقواعد العامة (النبرة، التنسيق).

غير قابل للتحقق : لا شيء يمنع نموذج اللغة الكبيرة من انتهاك القاعدة.

لا تحتاج إلى إعادة التفكير في معمارية المشروع.

غير قابل للتحويل : كل مستودع يعيد إعلان القواعد.

بحت تصريفي : النموذج اللغوي الكبير يعلم أنه يجب, لكن لا شيء يمنعه.

هذا النهج: التماثل عبر Ontologie spatiale

✅ محترف

❌ ضد

مرن إزاء السياق الطويل : القاعدة في مسار الملف، وليس في مطالبة بعيدة.

التكلفة الأولية للبنية التحتية : تنظيم مساحة العمل على شكل دوائر يستغرق وقتًا

قابل للتحقق آليًا : سرّ في`foundry/يمكن اكتشافه بواسطة`git check-ignore.

يتطلب الانضباط: يجب على المساهم الجديد فهم الدوائر

قابل للتحويل : واحد`AGENT.adoc`المعيار يعرض الدوائر على أي مشروع جديد

لا يغطي سوى القيود المكانية — يظل نمط الكود في المطالبة

الأمان بالتصميم : واحد`git push`منذ`foundry/لا يمكن أن يعرض`configuration/.

قابل للاستهلاك من قبل وكلاء غير LLM : يمكن لمنسق Gradle التوجيه وفقًا للدائرة.

الربح الرئيسي ليس دفاعيًا (الأمان، الرؤية) — إنهمبدع. عندما يعمل LLM في فضاء منظم بواسطة’ontologie، يمكنه أن يفعل ما لا يسمح به أي prompt: مراقبة الفارق

الجبرالعلائقي لمساحة العمل والدلتا القابلة للملاحظة

عندما يتجول LLM`foundry/, لديهشبكة البيانات المنظمة: عقد (الإضافات, الملفات, الاختبارات, الاعتماديات), حواف ذات نوع (`import, depends_on, generates, tests), العلاقات التركيبية والمرتبة (`training-gradle`يستخرج المرجع`slider-gradle`يولّد الشرائح →`capsule-gradle`ارفع الفيديو)

هذه الجبر غير مكتوبة بشكل صريح في أي مكان — لكنها مرئية. كل`build.gradle.kts`يعرض الاعتماديات. كل`INDEX.adoc`يعرض المراجع المتقاطعة.

LLM يلاحظ هذا الجبر ويكتشف الـدلتاالفارق بين ما يعرف النظام كيف ينتجه بالفعل وما تصفه الرؤية.

من هذا الدلتا، يمكنه تعريفخرائط الخبراء المتخصصين— CDA (مصمم ومطور تطبيقات، Kotlin/Gradle/JHipster) و FPA (مدرب مهني للكبار، التعليم/Qualiopi/Bloom) — وتحديد ما يفتقر إليه كل خبير.

Expert CDA (Kotlin/Gradle/JHipster)
  ├── Plugins : jhipster-gradle-plugins, plantuml-gradle,
  │   codebase-gradle
  ├── Delta : pas encore de SPG CDA formalisé,
  │   pas de fine-tuning expert CDA

Expert FPA (Pédagogie/Qualiopi/Bloom)
  ├── Plugins : training-gradle, slider-gradle,
  │   school-backoffice/forms, capsule-gradle
  ├── Matériel : 38 modules cours, SPG/SPD, taxonomies
  └── Delta : parser AsciiDoc→JSON à créer,
      orchestrateur à coder

لا يحتاج LLM إلى أن يُخبر ما عليه أن يفعله. ينشأ الدلتا من الهيكل.

متجه السياق المركب: RAG + pgvector + Graphify

الجبر العلاقاتي ليس بناءًا نظريًا. هي مُجَسَّمَة بواسطة ثلاث مكونات تشكلمتجه مركب للسياقللـ LLM.

المكوّن 1 — RAG LangChain4j + PostgreSQL pgvector

لديّ بالفعل LangChain4j في الإنتاج في ملحقين:`slider-gradle`(4 providers LLM) و`plantuml-gradle`(7 موردون). تضمينات ONNX (AllMiniLmL6V2) تفهرس البيانات`office/`و شفرة المصدر`foundry/`في PostgreSQL + pgvector.

يعمل هذا RAG على بعدين :

  • بيانات البعد : المستندات`office/`(SPG, المقالات, التكوينات, مخططات JSON)

  • رمز البعد : قواعد الكود`foundry/`(المصادر Kotlin, الاختبارات Cucumber, AGENT.adoc)

التقاطع يغطي كلاً من ماذا (مجال العمل) و كيف (التنفيذ).

المُكوّن 2 — Knowledge Graph Graphify

Graphify مدمج في`plantuml-gradle`(109 اختبارات، 380/380 نجاح) و ينتج`graph.json`— رسم معرفة منظم مع العقد، الحواف، والمجتمعات التي تم اكتشافها تلقائيًا.

خلافًا لـ RAG الذي يعمل بالتشابه المتجهي (ضبابي)، يعمل مخطط المعرفة بـالعلاقات الدقيقة(تحديدي) :`graphify query`للاستفسارات الدلالية (~50 رمزًا)`graphify path`للتنقل،`graphify explain`للتفسير.

المكون 3 — Graphify الإضافي: متفرق, قابل للتجميع, قابل للاستهلاك

هذه هي القرار المعماري الرئيسي

Graphify لا يجب أن يعيش في مستودع واحد. يجب أن يعيش بطريقةمُتَبعثرفي كل مكون إضافي :

  1. يحتوي كل إضافة على مهمة جرادل`updateKnowledgeGraph`الذي ينادي Graphifyعلى نطاقه الخاصويُنتج`graph.json`محلي.

  2. *السكريبت البناء من`office/يستهلك`graphify-gradle`مع`rootDir = /home/cheroliv/workspace`ويُنتجُ`graph.json عالميالتي تجمع الرسوم البيانية المحلية.

  3. راج كل مكوّن يحقن`graph.json`عالمي كمافلتر السياقللطلبات LLM.

TÂCHE GRADLE (dans chaque plugin)
    ↓
graphify → graph.json (scope local)
    ↓
office/build.gradle.kts → graph.json (scope global)
    ↓
RAG pgvector (dans slider, plantuml, codebase...)
    ↓  ← injection du graph.json comme filtre
LLM (deepseek-v4-pro)
    ↓  ← observation algèbre relationnelle
    ↓  ← détection delta vs cartographies experts
PRIORISATION → prochaine tâche

النتيجة: لا يبحث نموذج اللغوي الكبير في الفراغ — بل يتنقل في مساحة منظمة بواسطة رسم المعرفة. استعلام على "يُنتج مخططًا" يعرف كيف يصل إلى العقد ذات الصلة في الرسم البياني.

التصنيف التلقائي لـ RGPD : نموذج LLM كجهاز توجيه

الأ ontology الفراغية لا تقتصر على محاذاة النموذج اللغوي الكبير — بل تمنحهمصفوفة التصنيف RGPDلتوجيه كل بيان إلى منطقته الشرعية

معيار

كشف LLM

فعل

أقصى مستوى

بيان شخصي (الاسم، البريد الإلكتروني، IP)

نمط`@`, IP, الأسماء الخاصة

إخفاء الهوية →`[OF_PILOTE]`ou راوتر المستوى 2

2

توكن / سر / بيانات اعتماد

نمط`sk-…​, `ghp_…​, ya29…​

راوتر →configuration/. مرجَّع بواسطة`${VAR}`في الكود.

1

URL داخلي

يحتوي`localhost`, IP خاصة

إخفاء الهوية →${API_URL}

2

معلومة تربوية (SPG, مقرر)

الهيكل بلوم/كوالوبي

راوتر →office/(المستوى 2). نسخة مزدوجة إذا تم التصدير.

3

الرمز المصدري / اختبار

امتداد`.kt`, .kts`في`foundry/

راوتر`foundry/`. تحقق من عدم وجود أسرار.

4

في نهاية الجلسة، ينفّذ الـLLM شيئًاالمهمة العامة :

  1. قراءة`.gitignore`الجذر لتحديد الآثار العابرة (التي يجب استبعادها من اللقطة) مقابل الآثار الاستراتيجية (التي يجب توثيقها)

  2. قائمة بجميع الملفات`.adoc`من الجذر`workspace/`

  3. التصفية: استبعاد الملفات المدرجة في`.gitignore`, إدماج جميع الآخرين

  4. انسخ في`configuration/vision-archive/$DATE/و تحديث الرابط الرمزي`latest/

  5. الالتزام في المستودع`configuration/`مع رسالة منظمة

  6. تصنيف RGPD التلقائي لكل ملف تم تعديله (جميع الدوائر)

  7. التوجيه : البيانات`office/→ الالتزام الخاص، كود`foundry/→./gradlew check, الإعداد → commit

  8. تقرير منظم مع تنبيهات GDPR وتأكيد الأرشفة

Le `.gitignore`الجذر ليس ملف تكوين Git — إنهملف حوكمة التاريخة. إنه يحدد المخطط الذي يستهلكه نموذج اللغة الكبير (LLM) لتحديد أي ملفات من الحديقة السرية تدخل السيرة الذاتية الاستراتيجية وأيها يمكن التخلص منها.

لم يعد نموذج اللغة الكبيرة مجرد مولد نص. إنهمدير المعلوماتمن النظام البيئي — المنتج، المصنف، الموجه

خريطة الطريق : من AsciiDoc إلى LangGraph4j

اليوم، هذه الحوكمة محددة : LLM يطبق إجراءً موصوفًا في ملفات AsciiDoc. هذا الالمرحلة 1— هندسة المُحفِّزات مع ذاكرة LLM

La مرحلة ٢سيستخرج كل خطوة من العملية فيمهمة Gradle المكتوبة:

./gradlew endSessionWorkspace    → snapshot vision-archive
./gradlew endSessionProject      → archive .agents/
./gradlew endSessionReport       → rapport multi-zones

La المرحلة 3سيُنمذج عملية انتهاء الجلسة كـرسم الحالةمعhttps://github.com/langgraph4j/langgraph4j[LangGraph4j]:

[Start] → [Inventaire fichiers modifiés]
       → [Classification RGPD] (nœud ONNX)
       → [Branchement par cercle]
            ├→ cercle 0 → snapshot → commit
            ├→ cercle 2 → anonymisation → commit
            ├→ cercle 4 → archive → commit
            └→ cercle 1 → commit configuration/
       → [Rapport] → [End]

سيتم إصدار هذا الرسم البياني في CI/CD، وسيُنفّذ عبر Gradle، وسيُكوّن عبر أسرار GitHub الخاصة بالمكوّنات. لن يحتاج النموذج اللغوي الكبير بعد الآن إلى اتخاذ قرار بشأن التوجيه — سيقوم الرسم البياني بذلك.

ما تحله هذه المعمارية (وما لا تحله)

ال’ontologie spatiale لا تغطي كل شيء. اتفاقيات نمط الكود، التسمية، خيارات التصميم المعماري — كل ذلك يبقى في المطالب. ما تحله ال’ontologie spatiale هوطبقة الأمان والرؤية: حيث يجب أن يعيش كل بايت، ومن يمكنه رؤيته.

هذا ما تقدمه عمليًا :

  1. لا`git push`عرضي لسِرّ : الأسرار في`configuration/(الدائرة 1). المشاريع العامة هي في`foundry/(دائرة 4). لا يمر أي مسار عبر الاثنين.

  2. لا يوجد كود عمل في البيانات :`office/يحتوي على.adoc`, من YAML، من مخططات JSON — لكن ليس من`.kt`. Le `build.gradle.kts`الذي يعيش فيه هو سكريبت استهلاك، ليس كودًا تجاريًا.

  3. لا توجد فكرة استراتيجية مكشوفة : وثائق الرؤية موجودة في الحديقة السرية (الجذر خارج CVS). اللقطات موجودة في`configuration/`(خزنة خاصة). لا أحد، حتى في دائرة الثقة الموسعة، يقرأ أصل الاستراتيجية.

  4. التحديد التلقائي : يلاحظ نموذج اللغة الكبير (LLM) الفارق بين الجبر العلائقي (ما هو موجود) وخرائط الخبراء (ما هو ضروري). المهمة التالية للتطوير تنشأ من هذا الفارق.

الخاتمة: العمارة كخطاب

لا أضيف manifesto سياسي في تذييل موقعي. لا أضيف قواعد أخلاقية في مُحفّزاتي. المحاذاة ليست في النص — إنها فينظام الملفات.

عندما يعمل نموذج لغوي كبير في هذا الفضاء، لا يمكنه تسريب سرًا (المسار يمنعه). لا يمكنه الخلط بين بيانات تعليمية ومصدر كود (المنطقة الفيزيائية مختلفة). لا يمكنه نسيان قاعدة أمان عند 80,000 توكن – لأن القاعدة ليست في المطالبة، إنها في ال`workspace/` → configuration/→office/ → `foundry/`أن كل قراءة لملف تُعيد التفعيل

إنه مبدأ secure by design المطبق على توجيه الوكيل: لا نطلب من نموذج اللغة الكبيرة أن يتذكر القواعد. نجعل الهندسة تجعل الخطأ هيكليًا مستحيلًا.

وبالمناسبة، هذا يعطِي لLM ما لا يمكن لأي مَprompt أن يعطيه: القدرة علىيُدركأين هو، ما موجود، ما مفقود — ثم يستنتج ما عليه أن يفعله

المراجع

Articles connexes

HyperFrames-Gradle : تحويل AsciiDoc إلى فيديو MP4
31 May 2026
تدقيق استهلاكي ل LLM: SQLite, OpenCode, Ollama Cloud, ولماذا اشتراطي الاحترافي يُكسِر السوق العالمي
18 May 2026
هندسة « المكوّن المستقل + جذر المستهلك » : لماذا تتكرر بناءات Gradle الخاصة بي؟
14 May 2026
الرسم البياني للمعرفة كمحرك للتوصية: كيف قتلت المقالات « ذات الصلة » الزمنية
12 May 2026