باغ راز توسعهدهنده : چگونه онтولوژی فضایی LLMs را بدون مهندسی پرامپ تراز میدهد
منتشر شده در 30 April 2026
- ملاحظه: مهندسی پرامپت یک قلعه رمل است
- چهار دایره اعتماد: یک انترولوژی فضایی
- Pro/Contra : همترازی فضایی vs همترازی مبتنی بر پرامپت
- الجبرrelational فضای کاری و دلتا مشاهدنی
- וקטور ترکیبی زمینه : RAG + pgvector + Graphify
- طبقهبندی خودکار GDPR : LLM به عنوان روتر
- نقشهی مسیر : از AsciiDoc تا LangGraph4j
- چه چیزی این معماری حل میکند (و چه چیزی حل نمیکند)
- نتیجه: معماری به عنوان گفتمان
- منابع
مهندسی پرامپت، ضعیف است. در ۸۰٬۰۰۰ توکن، قوانین ترازش شما در سرگیجه گم میشوند و LLM فراموش میکند که چه چیزی را در ابتدای گفتگو از او درخواست کردید. راهحل من؟ نه ترازش بر پایهٔ متن، بلکه بر پایهٔفضا. من فضای کاری توسعه خود را به چهار دایره امان هممرکز — از باغ مخفی شخصی تا forgeهای عمومی — سازماندهی کردم و هر دایره یک ناحیه Fizیکی از سیستم فایل است. LLM نیازی به یادآوری قوانین ندارد: مسیر فایل آنها را شامل میشود. این است که چگونه کار میکند و چرا این架构 همراستای فضا resistanttr از یک`system prompt`از 500 خطوط
این یک مقاله طولانی است.
به راحتی بنشینید.
- طقطق
-
[]
ملاحظه: مهندسی پرامپت یک قلعه رمل است
در طول سه هفته، من پلاگینهای Gradle را با Opencode توسعه دادم، با استفاده از سه LLM مختلف — Kimi K2.6, GLM-5.1 و DeepSeek-V4-Pro (تنها باقیمانده، اما این یک داستان دیگر است)Déjà couverte ici. روش مدیریت من agentJe l’ai documentée en détail dans un précédent article. به فایلهای AsciiDoc استناد دارد —AGENT.adoc, INDEX.adoc, PROMPT_REPRISE.adoc— که ~30 000 توکن از قوانین، بک لاگ و تاریخچه را در هر شروع جلسه بارگذاری میکنند.
و با وجود این زیرساخت مستندات، دو مورد به من اثر گذاشت :
-
LLM فراموش میکند. حتی با قوانین مطلق در سر هر فایل EAGER، پس از ۶۰٬۰۰۰ توکن تجمیعی ( contexte اولیه + گفتگو)، Kimi K2.6 شروع به پیشنهاد دادن کرد`Write`وزنبار بر فایلهای پیکربندی. GLM-5.1 یک توکن Firebase را با یک placeholder که باید جایگزین شود، اشتباه گرفته است. قوانین نوشته شده بود — LLM دیگر آنها را نبینید.
-
Pákimit خود به یک مشکل تبدیل شده است. بعد از پیادهسازی مکانیزم Hot/Warm/ColdArticle sur la rotation de backup. برای جلوگیری از انفجار/context, فایلهای EAGER من همچنان وزن ۱۴۱۴ خط داشتندJ’ai documenté cet audit ici. حاکمیت — که برای حفاظت از LLM از اشباع طراحی شده بود — LLM را اشباع کرد.
من به یک مکانیزم همترازی نیاز داشتم که به تعداد توکنها در پرامپت وابسته نباشد.
جواب : متوقف کردن از تراز کردن براساس متن، و شروع به تراز کردن بهفضا.
چهار دایره اعتماد: یک انترولوژی فضایی
پرونده من`workspace/(در~/workspace/`) نیست pas یک مخزن Git. این ریشه تمام کار من — code، documentation، formation، infrastructure است. و آن در چهار بخش ساختاریافته است که conventions de rangement نیستند، اما desدایرههای هممرکز اعتماد:
سطح |
برچسب |
منطقهٔ فیزیکی |
CVS |
دیدپذیری |
0 |
باغ مخفی |
`workspace/`ریشه |
هیچ |
خصوصی — فکر آزاد، بدون commit، بدون انتشار |
1 |
صندوق ایمنی |
|
گیت خصوصی (تنها) |
اسرار، توکنها، آرشیو دید. فقط یک شخص. |
2 |
کتابخانه |
|
گیت خصوصی (گسترشدار) |
دادههای آموزشی, SPG/SPD, طرحهای JSON. حلقه اعتماد شناسایی شده. |
4 |
افزانهها (عمومی) |
|
گیت عمومی (Apache 2.0) |
کد منبع، افزونهها، آزمونها، مستندات فنی. |
توجه: سطح 3 در جدول وجود ندارد. سطح 3 یک سطح transitoire است: این محتوا`office/`که ناشناسسازی شده و آماده انتشار به عنوان دادههای باز است. آن ناحیه فیزیکی خاصی ندارد — این یک وضعیت داده است، نه یک مکان.
هر سطح به یک سؤال دقیق پاسخ میدهد:
-
کجا باید یک ایدهای که هنوز برای به اشتراکگذاری آماده نیست را، حتی در یک دایره کوچک نیز، قرار دهیم؟ → باغ راز. گیت نیست. فشار نیست.
-
کجا میتوان توکن API را بدون نشت ذخیره کرد؟ → خزانه (
configuration/). فیزیکی منحل. هیچ مخزن دیگری نمیتواند به اشتباه به آن ارجاع دهد. -
کجا میتوان یک کاتالوگ آموزش را با یک OF پیلوت همساخت؟ → کتابخانه`office/`)". نسخہدار, همکاریمحور، اما خصوصی.
-
کجا میتوان یک پلاگین Gradle متن‑باز را صنعتی کرد؟ → فورجها`foundry/`). عمومی, قابل فورک، تستشده در CI.
اینОнтолژی استقابل مصرف توسط یک LLM. وقتی که یک فایل را میخواند در`foundry/plantuml-gradle/src/`, او به طور ضمنی میگوید: «من در دایره ۴ قرار دارم — کد عمومی، تستهای الزامآور، هیچ رمزی، هیچ داده آموزی». او نیازی به پرامپی که به او یادآوری کند ندارد.
باغ مخفی : فضای غیر-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/`در ریشه). او به عنوان یکفایل پیکربندی گومرنانسکدام اشیاء از باغ راز layeq-e tarikh shavand، و کدامان صرفاً عابر هستند ؟
-
فایلهای فهرست شده در`.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`از ریشه، commit شده در مخزن خصوصی`configuration/`. هر جلسه عصف ذهنی یک snapshot تولید میکند :
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/`دارد دایمان یکنسخه کاراز آخرین اسنپشات، بهعنوان یک ارجاع سریع که نیازی به ناوبری در تاریخچهٔ Git ندارد.
و برای LLM، این یکاوراکل همگنی: وقتی او یک تناقض بین پیادهسازی فعلی و بینایی که در تاریخ قبلی بایگانی شده را مشاهده میکند، میتواند آن را گزارش دهد.
خزانه: configuration/ مثل Spring Cloud Config
`configuration/`فقط شامل آرشیو دیدن نیست. وظیفه اصلی آن — و آیندهای — این است که یکسرور Spring Cloud Config. تمام رازها، توکنها، اعتبارها و توصیفکنندگان زیرساخت اینجا زندگی میکنند، در یک مخزن گیت خصوصی که صرفاً به صاحب دسترسی دارد.
چرا یک مخزن جداگانه به جای یک فایل`.env`در هر پروژه؟
-
push تصادفی یک رمز : impossible. رموزها در یک مخزن خصوصی قرار دارند که پروژههای عمومی نمیتوانند به اشتباه به آنها ارجاع دهند.
-
Audit : تاریخچه Git ردیابی هر تغییر در پیکربندی را ارائه میدهد. چه کسی چه چیزی را تغییر داد، چه زمانی، با چه hash SHA.
-
بازگشت :`git revert`روی یک پیکربندی خراب. لحظهای، بدون بکاپ دستی
کتابخانه : office/ مثل داده مصرفی
`office/`این مستندات مکمل کار توسعه است. این حاوی مقالات وبلاگ، مشخصات فنی، منابع آموزشی (38 دایرکتوری دوره FPA, SPG/SPD, اسکیمای JSON, تاکسونومیهای Bloom/Harrow/Krathwohl) — همه چیزی که تشکیل میدهدماده آموزشی.
اما`office/`این صرفاً یک کشو اسناد نیست. این یکمنبع دادههای ساختار یافتهکه پلاگینهای Gradle`foundry/`مصرف میکنند. یک مقاله وبلاگ در`office/`یک ورودی است که یک پلاگین آن را به HTML تبدیل میکند. یک SPG AsciiDoc در`office/metiers/FPA/`یک artefact است که یک اورکیسترتر آن را پارس میکند تا اسلایدها، تستها و ویدیوهای کوتاه تولید کند.
Et le `build.gradle.kts`به ریشه`office/`این کد تجاری نیست — این یکاسکریپت مصرف اکوسیستم پلاگینهاtext
-
او میگوید : "این است پلاگینهای گریدل که من استفاده میکنم، این است کنتکس وورکスペ이스 من".
کارگاهها: foundry/ به عنوان پیادهسازی
foundry/`حاوی آنکد صنعتی. 54 مخزن گیت، از آنها 7 در حال حاضر توسط.agents/`. اینجاست که بینش قابل اجرا میشود — پلاگینهای Gradle, CI/CD, تستهای JUnit5 + Cucumber
ارتباط با`office/`دوطرفه است :
-
office/(No output, as no French text was provided for translation)foundry/: دادههای آموزشی matières premières هستند که پلاگینها مصرف میکنند. -
foundry/→office/: افزونههای دادهای تولید میکنند که غنی میکند`office/` — le `graph.json`graphify-gradle، decks slider کامپایلشده، گزارشهای ساخت
Pro/Contra : همترازی فضایی vs همترازی مبتنی بر پرامپت
دو رویکرد را مقایسه کنیم.
رویکرد کلاسیک: همسازی توسط پیشپrompt
✅ Pro |
❌ در برابر |
ساده برای پیادهسازی. یک بلوک متنی در prompt سیستمی. |
ضعیف در برابر بافت طولانی : قانون پس از 80K توکن گم میشود. |
برای قوانین عمومی (ton, format) کار میکند. |
غیر قابل تأیید : هیچ چیزی مانع از این نیست که LLM این قانون را نقض کند. |
نیازی به بازنگری در معماری پروژه نیست. |
غیر قابل انتقال : هر repo قوانین را دوباره اعلام میکند. |
صرفاً اظهاری : LLM میداند که باید اما هیچ چیزی آن را متوقف نمیکند. |
این رویکرد : همسازگاری با آنتولوژی فضایی
✅ حرفهای |
❌ ضد |
مقاوم به بافت طولانی : قانون در مسیر فایل است، نه در یک prompt دور. |
هزینهٔ اولیهٔ زیرساخت : سازماندهی فضای کاری به صورت دایرهای زمان میبرد. |
قابل تأیید به صورت مکانیکی : یک رمز در`foundry/ |
نیاز به انضباط دارد : یک مشارکتکننده جدید باید دایرهها را بفهمد. |
قابل انتقال : یک`AGENT.adoc`استاندارد دایرهها را به هر پروژه جدید نشان میدهد. |
فقط محدودیتهای فضایی را پوشش میدهد — سبک کد در پرامپت میماند. |
Sécurité par conception : un |
|
قابل مصرف توسط عوامل غیر-LLM : یک اورکستراتور Gradle میتواند بر اساس دایره مسیردهی کند. |
سود اصلی دفاعی (امنیت، دید) نیست — این استخلاق. وقتی LLM در فضایی که توسط یک انگارهسازی ساختار یافته است کار میکند، میتواند کاری کند که هیچ پرمپت به آن اجازه نمیدهد : ملاحظة دلتا.
الجبرrelational فضای کاری و دلتا مشاهدنی
وقتی 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 بر دو بعد عمل می-conduct:
-
Dimension data : اسناد`office/`(SPG، مقالات، آموزشها، اسکیمهای JSON)
-
کد بعد : پایگاههای کد`foundry/`(منابع Kotlin, تستهای Cucumber, AGENT.adoc)
تقاطع هم چی (حوزه کاری) و هم چطور (پیادهسازی) را پوشش میدهد.
بخش 2 — Knowledge Graph Graphify
Graphify در یکپارچهسازی شده است`plantuml-gradle`(109 tests, 380/380 PASS) و تولید یک`graph.json`— یک گراف دانش منسجم با گرهها، لبهها وössههای شناسایی شده بهصورت خودکار.
برخلاف RAG که از طریق شباهت برداری (به صورت مبهم) عمل میکند، گراف دانش از طریقروابط دقیق(قطعی) :`graphify query`pour les interrogations sémantiques (~50 tokens)`graphify path`برای ناوبری,`graphify explain`برای توضیح.
بخش ۳ — Graphify افزایشی : پراکنده، قابل جمع، مصرف‑پذیر
این تصمیم کلی معماری است.
Graphify نباید در یک مخزن واحد زندگی کند. باید به شکلپراکندهدر هر افزونه :
-
هر پلاگین یک وظیفهٔ Gradle دارد`updateKnowledgeGraph`که Graphify را صدا میزنددر scope خودو تولید یک`graph.json`محلی.
-
シリーズت ساخت`office/
مصرف میکند`graphify-gradle`با`rootDir = /home/cheroliv/workspace`و تولید میکند یک`graph.json عالمیکه گرافهای محلی را تجمیع میکند. -
RAG هر پلاگین آن را تزریق میکند`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
نتیجه : LLM در فضا خالی جستجو نمیکند — بلکه درفضایی که توسط knowledge graph ساختار یافته، حرکت میکند. یک Query روی « تولید یک نمودار » میتواند به گرههای مرتبط graph برسد.
طبقهبندی خودکار GDPR : LLM به عنوان روتر
فضاگرایی نه تنها LLM را همگون میسازد — آن را یکجدول طبقهبندی GDPRبرای مسیر دادن هر donnée به منطقه معتبر آن.
معیار |
تشخیص LLM |
عمل |
حداکثر سطح |
اطلاعات شخصی (نام، ایمیل، آیپی) |
الگو`@`, IP, اسامی خاص |
ناشناس کردن →`[OF_PILOTE]`یا روتر سطح 2 |
2 |
توکن / راز / احراز هویت |
الگو`sk-… |
روتر → |
1 |
URL داخلی |
شامل`localhost`, IP خصوصی |
ناشناسسازی → |
2 |
داده آموزشی (SPG, درس) |
ساختار Bloom/Qualiopi |
روتر → |
3 |
کد منبع / تست |
تمدید`.kt`, |
روتر → |
4 |
در پایان جلسه، LLM یکوظیفه جهانی:
-
خواندن از`.gitignore`ریشه برای شناسهٔ artefactهای موقت (که باید از اسنپشوت حذف شوند) vs artefactهای استراتژیک (که باید در تاریخچه قرار گیرند)
-
فهرست تمام فایلها`.adoc`از ریشه`workspace/`
-
فیلتر کردن : حذف فایلهای فهرستشده در`.gitignore`, شمول تمام دیگران
-
کپی در`configuration/vision-archive/$DATE/
و بهروزرسانی لینک نمادین`latest/ -
کامیت در مخزن`configuration/`با یک پیام ساختاریافته
-
طبقهبندی خودکار RGPD هر فایل تغییر یافته (تمام دایرهها)
-
مسیر یابی: دادهها`office/
→ کامیت خصوصی، کد`foundry/→./gradlew check, پیکربندی → کامیت -
گزارش ساختاری با هشدارهای GDPR و تایید بایگانی
Le `.gitignore`ریشه یک فایل تنظیمات Git نیست — آن یکفایل حکمرانی تاریخچه. الگویی را تعریف میکند که LLM آن را مصرف میکند تا تصمیم بگیرد کدام فایلهای jardins-secret در بیوگرافی استراتژیک قرار میگیرند و کدامان قابل حذف هستند.
LLM دیگر تنها یک تولیدکنندهٔ متن نیست. اومدیر اطلاعاتاز اکوسیستم — تولیدکننده، طبقه بندی دهنده، مسیریاب.
نقشهی مسیر : از AsciiDoc تا LangGraph4j
امروز، این حاکمیت قطعی : LLM یک روش را که در فایلهای AsciiDoc توضیح داده شده است، اعمال میکند. اینمرحله ١— مهندسی پرامپت با حافظه LLM
La مرحله ۲هر مرحله از فرآیند را در یکوظیفه Gradle تایپشده:
./gradlew endSessionWorkspace → snapshot vision-archive
./gradlew endSessionProject → archive .agents/
./gradlew endSessionReport → rapport multi-zones
La فاز ۳فرآیند پایان جلسه را بهعنوان یک مدلسازی خواهد کردگراف حالتبه همراه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 Secrets پلاگینها تنظیم خواهد شد. LLM دیگر نیاز نخواهد داشت تا مسیر را تعیین کند — گراف آن را خود انجام خواهد داد.
چه چیزی این معماری حل میکند (و چه چیزی حل نمیکند)
|
L’ontologie spatiale همه چیز را شامل نمیشود. کنوانسیونهای استایل کد، نامگذاری، گزینشهای طراحی معماری — همه اینها در پرامپت میمانند. آنچه L’ontologie spatiale حل میکند، این است:لایهٔ امنیت و دیدپذیری: هر بایت باید در آن زندگی کند , و که میتواند آن را ببیند |
این است که بهطور ملموس ارائه میدهد:
-
نه`git push`راز اتفاقی : رازها در`configuration/
(دایره 1). پروژههای عمومی در`foundry/(دایره 4). هیچ مسیری به هر دو آنها عبور نمیکند. -
هیچ کد کاری در داده وجود ندارد :`office/
حاوی برخی.adoc`، YAMLها، JSON اسchemas — اما نه`.kt`. Le `build.gradle.kts`که در آن زندگی میکند یک اسکریپت مصرف است، نه کد کسبوکار. -
هیچ تفکر استراتژیک آشکار : اسناد بینش در باغ مخفی قرار دارند (ریشه خارج از CVS). اسنپشاتها در`configuration/`(خزانهٔ خصوصی). هیچکس، حتی در یک دایرهٔ اعتماد گسترش یافته، منشأ استراتژی را نمیخواند.
-
اولویتبندی خودکار : LLM دلتا بین الجبر رابطهٔ (وجود دارد) و نقشههای متخصصان (ضروری است) را مشاهده میکند. وظیفهٔ توسعه بعدی از این دلتا پدید میآید.
نتیجه: معماری به عنوان گفتمان
من بیانه سیاسی را در فوتر سایتم قرار نمیدهم. من قواعد اخلاقی را در پرامپتهای من قرار نمیدهم. همانجام در متن نیست — آن درسیستم فایل.
هنگامی که یک LLM در این فضای کار میکند، نمیتواند یک اسرار را لو دهد (چون مسیر آن آن را منع میکند). نمیتواند یک داده آموزشی را با کد منبع اشتباه بگیرد (زونا فیزیکی متفاوت است). نمیتواند یک قانون امنیتی در ۸۰٬۰۰۰ توکن را فراموش کند — چرا که این قانون در prompt نیست، بلکه در`workspace/→`configuration/`شما یک مترجم حرفهای هستید. از fr به fa ترجمه کنید. تمامی امتدادهای کد بکتیک (…) را به همان صورت حفظ کنید — هرگز محتوای بکتیک، فاصله یا موقعیت آن را تغییر ندهید. این متن ممکن است بخش از یک جمله بزرگتر باشد — این قطعه را بدون طلب زمینه بیشتر ترجمه کنید. فقط متن ترجمهشده را خروجی دهید — هیچ توضیح، نظری، معرفی، گزینش یا گزینهٔ دیگری ندهید.`office/→`foundry/`که هر بار خواندن فایل فعال میشود.
این اصل secure by design است که به همتنسازی عامل اعمال میشود: از LLM نخواهید که قوانین را به خاطر بسازد. به گونهای که معماری خطا را به صورت ساختاری ناممکن کند.
و به مرور، این LLM را میدهد که هیچ پرامپیتی نمیتواند به او بدهد: تواناییدرک کردنکه کجا است، چه چیزی وجود دارد، چه چیزی گم است — و از آن استنتاج کند که چه کاری باید انجام دهد.
منابع
-
مقاله دربارهٔ gouvernaNce عامل Eager/Lazy :حاکی کردن یک عامل هوش مصنوعی با AsciiDoc
-
مقاله دربارهٔ مکانیزم Hot/Warm/Cold :پنجره لغزنده و موج خنک
-
مقاله در مورد بررسی زمینههنگامی که حاکمیت خودتان به مشکل تبدیل میشود
-
مقاله در مورد مقایسه سه LLM :DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1