Vườn bí mật của nhà phát triển : Cách ontologie não gian căn chỉnh các LLM mà không cần prompt engineering

Đăng ngày 30 April 2026

thời gian đọc : 20 minutes

Kỹ thuật prompt rất dễ vỡ. Với 80 000 token, các quy tắc căn chỉnh của bạn bị lọt vào tiếng ồn và mô hình LLM quên đi điều mà bạn đã yêu cầu ở đầu cuộc trò chuyện. Giải pháp của tôi? Không căn chỉnh bằng văn bản, mà bằng l'không gian. Tôi đã cấu trúc không gian làm việc phát triển của mình thành bốn vòng concentric tin cậy — từ vườn tư nhân trong sầm tới các xưởng công cộng — và mỗi vòng là một khu vực vật lý của hệ thống tệp tin. LLM không cần phải được nhắc lại về các quy tắc: đường dẫn của tệp tin chứa chúng. Đây là cách nó hoạt động, và tại sao kiến trúc căn chỉnh bằng không gian này còn khả năng chịu đựng hơn một`system prompt` de 500 lignes.

Đây là một bài viết dài.
Hãy ngồi thoải mái.

Nhận định: Kỹ thuật Prompt Engineering là một cỗ bãi cát

Trong ba tuần, tôi đã phát triển các plugin Gradle với Opencode, bằng cách sử dụng ba LLM khác nhau — Kimi K2.6, GLM-5.1 và DeepSeek-V4-Pro (đứng còn sống duy nhất, nhưng đó là câu chuyện khác).Déjà couverte ici. phương pháp quản trị agentJe l’ai documentée en détail dans un précédent article. dựa trên các file AsciiDoc —AGENT.adoc, INDEX.adoc, PROMPT_REPRISE.adoc— tải ~30 000 token của quy tắc, backlog và lịch sử ở đầu mỗi phiên

Và dù có hệ thống tài liệu này, hai điều đã làm ấn tượng tôi :

  1. LLM đã quên. Còn ngay cả khi có các quy tắc tuyệt đối ở đầu mỗi tệp EAGER, vượt quá 60 000 token được tích lũy (bối cảnh ban đầu + cuộc trò chuyện), Kimi K2.6 đã bắt đầu đề xuất`Write`dồn dập trên các tệp cấu hình. GLM-5.1 đã nhầm lẫn một mã thông báo Firebase với một placeholder cần được thay thế. Các quy tắc đã được viết — LLM không còn nhìn thấy chúng nữa.

  2. Quyền quản trị thậm chí còn trở thành một vấn đề. Sau khi đã triển khai cơ chế Hot/Warm/ColdArticle sur la rotation de backup. để tránh việc bùng nổ ngữ cảnh, các file EAGER của tôi vẫn có 1414 dòngJ’ai documenté cet audit ici. Quyền quản trị — được thiết kế để bảo vệ LLM khỏi tình trạng quá tải — gây quá tải cho LLM.

Tôi cần một cơ chế căn chỉnh không phụ thuộc vào số lượng token trong prompt.

Câu trả lời : ngừng căn chỉnh theo văn bản, và bắt đầu căn chỉnh theo l'không gian.

Bốn Vòng Tròn Tin Tưởng: Một Ontologie Không Gian

Hồ sơ của tôi`workspace/(trong~/workspace/`) không phải là một kho lưu trữ Git. Đây là gốc của toàn bộ công việc của tôi — code, documentation, formation, infrastructure. Và nó được cấu trúc thành bốn vùng không phải là các quy ước sắp xếp, mà làcác vòng tròn niềm tin đồng tâm:

cấp độ

nhãn

Vùng vật lý

CVS

Tầm nhìn

0

Vườn bí mật

`workspace/`rễ

Không

Riêng tư — tư tưởng tự do, không có commit, không có xuất bản

1

tủ an toàn

configuration/

Git riêng (solo)

Bí mật, mã thông báo, kho lưu trữ tầm nhìn. Chỉ có một người.

2

Thư viện

office/

Git riêng tư (mở rộng)

Dữ liệu giáo dục, SPG/SPD, sơ đồ JSON. Vòng tin cậy đã được xác định.

4

Lò rèn (công cộng)

foundry/

Git công khai (Apache 2.0)

Mã nguồn, plugin, các kiểm tra, tài liệu kỹ thuật.
Không có cấp độ 3 trong bảng. Cấp độ 3 là một cấp độ transitoire : đây là nội dung của`office/`đã được ẩn danh và sẵn sàng để được công bố dưới dạng dữ liệu mở. Không có khu vực vật lý riêng — đây là trạng thái của dữ liệu, không phải là vị trí.

Mỗi cấp độ trả lời một câu hỏi cụ thể :

  • Nên đặt ý tưởng nào chưa sẵn sàng để chia sẻ, ngay cả với một nhóm nhỏ, ở đâu? → Khu vườn bí mật. Không có Git. Không có áp lực.

  • Lưu trữ token API ở đâu sao cho không rò rỉ? → Tủ an toàn`configuration/`)\" Cách ly vật lý. Không có kho chứa nào khác có thể tham chiếu tới nó sai.

  • Ở đâu để đồng xây dựng một danh mục đào tạo với OF pilota ? → Thư viện`office/`). Được phiên bản, cộng tác, nhưng riêng tư.

  • Triển khai một plugin Gradle nguồn mở ở đâu ? → Các forge`foundry/`). Public, forkable, đã được thử nghiệm trong CI.

Ontologie này làCó thể tiêu thụ bởi một LLM. Khi anh ấy đọc một tệp trong`foundry/plantuml-gradle/src/`, ngầm hiểu rằng: \" Tôi ở trong vòng 4 - mã công khai, các test bắt buộc, không có bí mật, không có dữ liệu giáo dục \". Anh ấy không cần một lời nhắc để nhắc nhở anh ấy.

Vườn Bí Mật : Không Gian Ngoại CVS

Đây là khái niệm quan trọng nhất — và khái niệm phản 직ceau nhất

Rễ`workspace/không có.git/. Các tài liệu sống ở đó (`WORKSPACE_VISION.adoc, WORKSPACE_AS_PRODUCT.adoc, WORKSPACE_ORGANIZATION.adoc— et người mà bạn đang đọc ngay lúc này, do đó được đánh dấu phiên bản) không nhằm mục đích được đánh dấu phiên bản, chia sẻ, hoặc thậm chí được đọc lại bởi bất kỳ người nào khác ngoài tôi. Là nhữngSuy nghĩ đang trong quá trình nảy mầm.

Vườn bí mật là out-of-CVS theo bản chất. Thiếu quản lý phiên bản là điều kiện của tư duy tự do. Không được viết để được đọc — mà được viết để làm rõ tầm nhìn riêng.

Nhưng sự tự do này có chi phí : một`rm`vô tình, và đây là những tháng suy ngẫm chiến lược mất đi. Giải pháp không phải là phiên bản hoá khu vườn (đó sẽ là việc phá hủy nó) — đó là việcphản chiếutrong vòng tròn hẹp nhất.

File .gitignore như Cấu hình quản trị

ở gốc của`workspace/, một file.gitignore`khai báo ít nhấtchính sách lịch sử hóaCác tệp trong vườn bí mật:

.goosehints
.goose

Ce .gitignore`không có chức năng Git chuẩn (không có.git/`Ở cái gốc). Nó hoạt động như mộtfile cấu hình quản trịtrả lời một câu hỏi cụ thể: các vật phẩm của khu vườn bí mật nào đáng được lịch sử hoá, và cái nào chỉ là hoàn toàn tạm thời?

  • Các file được liệt kê trong`.gitignore`—.goosehints, .goose— là các vật phẩm tạm thời được tạo ra bởi các đại lý. Không có giá trị chiến lược. Không được ghi lại lịch sử.

  • Các tệp tin`.adoc`của gốc —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— khôngkhôngtrông`.gitignore`. Đây là các vật phẩm cần được ghi chép lịch sử.

Le .gitignore est le sơ đồ quản trị: tất cả những gì không được liệt kê là ứng viên cho một snapshot. Và LLM, khi đọc file này, biết chính xác điều gì cần được lưu trữ và điều gì có thể bị bỏ qua — mà không cần nhắc lại trong một lời nhắc.

Cơ chế Snapshot

Tôi đã tạo`configuration/vision-archive/các ảnh chụp đã được gán thời gian của tất cả các.adoc`của gốc, các commit trong kho riêng tư`configuration/`.Mỗi buổi brainstorming sản xuất một 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"

Quy trình được kích hoạt ở cuối phiên bởi chính LLM, khi thực hiện nhiệm vụ định tuyến toàn cục này. Mỗi snapshot ghi lại trạng thái hoàn chỉnh của tư duy chiến lược tại một thời điểm T.

Lịch sử Git của`configuration/`trở thànhTiểu sử về tư duy chiến lược của tôi. Tôi có thể làm một`git log — vision-archive/`và xem sự tiến bộ của tầm nhìn tôi, mỗi phiên một phiên, mỗi ngày một ngày.

Ví dụ thực tế của lịch sử sau một ngày làm việc:

$ 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

Năm ảnh chụp trong một ngày. Mỗi cái là một điểm khôi phục. Mỗi cái là một con mốc trong sự ra đời của chiến lược.

Hồ sơ`configuration/vision-archive/latest/`luôn luôn chứa mộtbản sao làm việccủa bản snapshot gần nhất, đóng vai trò là tham chiếu nhanh chóng mà không cần phải duyệt qua lịch sử Git.

Đối với LLM, đây là mộtoracle của tính nhất quán: khi người dùng quan sát thấy một sự mâu thuẫn giữa việc triển khai hiện tại và tầm nhìn đã được lưu trữ tại một thời điểm trước đây, họ có thể báo cáo nó.

Vault: configuration/ như Spring Cloud Config

`configuration/`Không chỉ chứa kho lưu trữ của tầm nhìn. Chức năng chính — và tương lai — của nó là trở thành mộtMáy chủ Spring Cloud Config. Tất cả các bí mật, token, thông tin xác thực và mô tả cơ sở hạ tầng ở đây, trong một kho Git riêng tư chỉ có thể truy cập bởi chủ nhân.

Tại sao một kho lưu trữ riêng thay vì một tệp`.env`moi dự án ?

  • Đẩy nhầm một bí mật : Không thể. Các bí mật được lưu trữ trong một kho lưu trữ riêng mà các dự án công khai không thể tham chiếu nhầm.

  • Kiểm tra : lịch sử Git cung cấp dấu vết cho mỗi thay đổi cấu hình. Ai đã thay đổi gì, khi nào, với băm SHA nào.

  • Quay lui :`git revert`về cấu hình bị hỏng. Chụp ảnh nhanh, không có bản sao lưu thủ công.

Thư viện: office/ như dữ liệu tiêu thụ

`office/`Là bản đồng thời tài liệu của công việc phát triển. Nó chứa các bài viết trên blog, các tiêu chuẩn kỹ thuật, các tài liệu đào tạo (38 thư mục khóa học FPA, SPG/SPD, biểu đồ JSON, mô hình Bloom/Harrow/Krathwohl) — mọi thứ mà nó bao gồm.vật liệu giảng dạy.

Nhưng`office/`Không chỉ là một ngăn để lưu tài liệu. Đây là mộtnguồn dữ liệu có cấu trúccác plugin Gradle của`foundry/`tiêu thụ. Một bài viết blog trong`office/`là một mục nhập mà một plugin sẽ chuyển thành HTML. Một SPG AsciiDoc trong`office/metiers/FPA/`là một đối tượng mà một orchestrator sẽ phân tích để tạo ra các slide, các quiz và các capsules video.

Et le `build.gradle.kts`gốc của`office/`Không phải là mã nghiệp vụ — là mộtscript tiêu thụ hệ sinh thái plugin. Anh ấy nói: "đây là các plugin Gradle mà tôi đang sử dụng, đây là ngữ cảnh của workspace của tôi

Các Forges: foundry/ như triển khai

foundry/`chứamã đã được công nghiệp hoá. 54 kho Git, trong số đó 7 hiện đang được điều hành由 các.agents/`. Đây là nơi tầm nhìn trở nên có thể thực thi — plugins Gradle, CI/CD, tests JUnit5 + Cucumber.

mối quan hệ dengan`office/`là hai chiều:

  • office/→foundry/: dữ liệu giáo dục là nguyên liệu mà các plugin tiêu thụ.

  • foundry/ → office/`các plugin sản xuất dữ liệu làm phong phú`office/ — le `graph.json`Của graphify-gradle, những bộ slider đã được biên dịch, các báo cáo bản dựng.

Lợi/Hại : Căn chỉnh không gian vs căn chỉnh dựa trên prompt

Chúng ta so sánh hai phương pháp.

Góc nhìn Cổ điển : Sắp xếp bằng tiền lời

✅ Pro

Sai

Dễ dàng để triển khai. Một khối văn bản trong lời nhắc hệ thống

Nhạy cảm với ngữ cảnh dài : quy tắc bị ngập sau 80K tokens.

Hoạt động cho các quy tắc chung (phong cách, định dạng).

Không thể xác thực : không có gì ngăn cản LLM vi phạm quy tắc.

Không cần phải nghĩ lại kiến trúc dự án.

Không thể chuyển nhượng : mỗi repo khai báo lại các quy tắc.

Chỉ là khai báo : LLM biết rằng nó nên, nhưng không có gì ngăn nó.

Cách tiếp cận này: Căn chỉnh qua Ontology không gian

(no comment)

❌ phản đối

Khả năng chịu đựng với ngữ cảnh dài : quy tắc nằm trong đường dẫn file, không trong một prompt xa xôi.

Chi phí hạ tầng ban đầu : Việc sắp xếp không gian làm việc theo hình tròn tốn thời gian.

Kiểm chứng được bằng cơ khí : một bí mật trong`foundry/có thể được phát hiện bằng`git check-ignore.

Cần kỷ luật : một người đóng góp mới phải hiểu các vòng tròn.

Chuyển được : một`AGENT.adoc`Tiêu chuẩn hiển thị các vòng tròn cho mọi dự án mới.

Chỉ bao phủ các ràng buộc không gian — Vẫn giữ phong cách mã trong prompt.

An toàn bởi thiết kế :`git push`từ`foundry/không thể tiết lộ`configuration/.

Có thể được tiêu thụ bởi các agent không phải LLM : một trình điều phối Gradle có thể định tuyến theo vòng tròn.

Lợi thế chính không mang tính phòng ngự (bảo mật, hiện diện) — nó làsáng tạo. Khi LLM hoạt động trong một không gian được cấu trúc bởi một ontology, nó có thể làm điều mà bất kỳ prompt nào không cho phép: quan sát delta.

Đại số quan hệ của Workspace và Delta quan sát được

Khi LLM duyệt`foundry/, có mộtlưới dữ liệu có cấu trúc: nút (plugin, file, test, phụ thuộc), cạnh có kiểu`import, depends_on, generates, tests), mối quan hệ cấu tạo và thứ tự (`training-gradle`Trích xuất kho lưu trữ`slider-gradle`tạo các slide →`capsule-gradle`Phát video).

Đại số này không được ghi ra ở đâu cả dưới dạng rõ ràng — nhưng nó là có thể quan sát. Mỗi`build.gradle.kts`liệt kê các phụ thuộc. Mỗi`INDEX.adoc`trình bày các tham chiếu chéo

LLM quan sát toán học này và phát hiệndelta: khoảng cách giữa những gì hệ thống đã biết cách tạo ra và những gì tầm nhìn mô tả.

Từ delta này, nó có thể xác định cácbản đồ của các chuyên gia ngành— CDA (Thiết kế & Phát triển Ứng dụng, Kotlin/Gradle/JHipster) và FPA (Huấn luyện viên chuyên nghiệp cho người lớn, Giáo dục/Qualiopi/Bloom) — và xác định những gì thiếu cho mỗi chuyên gia.

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 không cần được chỉ示 làm gì. Delta phát sinh từ cấu trúc.

Vector Composite của Bối cảnh: RAG + pgvector + Graphify

Đại số quan hệ không phải là một xây dựng lý thuyết. Nó được cụ thể hóa bởi ba thành phần tạo thànhvector ngữ cảnh tổng hợpcho LLM.

Thành phần 1 — RAG LangChain4j + PostgreSQL pgvector

Tôi đã có LangChain4j trong sản xuất trong hai plugin:`slider-gradle`(4 providers LLM) và`plantuml-gradle`(7 nhà cung cấp). Các embedding ONNX (AllMiniLmL6V2) chỉ mục dữ liệu của`office/`và mã nguồn của`foundry/`trong PostgreSQL + pgvector.

RAG này hoạt động trên hai chiều :

  • Dữ liệu kích thước : các tài liệu`office/`(SPG, bài viết, đào tạo, lược đồ JSON)

  • Dimension code : các codebase`foundry/`(nguồn Kotlin, bài kiểm tra Cucumber, AGENT.adoc)

Giao điểm bao gồm cả quoi (lĩnh vực nghiệp vụ) và comment (triển khai).

Thành phần 2 — Knowledge Graph Graphify

Graphify được tích hợp trong`plantuml-gradle`(109 tests, 380/380 PASS) và sản xuất một`graph.json`— một knowledge graph có cấu trúc với các nut, các cạnh, và các cộng đồng được phát hiện tự động.

Không giống như RAG hoạt động dựa trên độ tương đồng vectơ (mờ), đồ thị kiến thức hoạt động bằngquan hệ chính xác(xác định) :`graphify query`cho các câu hỏi về ngữ nghĩa (~50 tokens)`graphify path`để điều hướng,`graphify explain`Để giải thích.

Thành phần 3 — Graphify Tăng dần: Thưa thớt, Tổng hợp được, Tiêu thụ

Đây là quyết định kiến trúc chính.

Graphify không nên sống trong một kho lưu trữ duy nhất. Nó phải sống theo cáchphân tántrong mỗi plugin :

  1. Mỗi plugin có một tác vụ Gradle`updateKnowledgeGraph`ai gọi Graphifytrên phạm vi riêng của nóvà sản xuất một`graph.json`cục bộ.

  2. Script build của`office/* tiêu thụ`graphify-gradle`với`rootDir = /home/cheroliv/workspace`và tạo ra một`graph.json toàn cầutổng hợp các đồ thị địa phương.

  3. RAG của mỗi plugin đang chèn vào`graph.json`toàn cầu nhưbộ lọc ngữ cảnhcho các yêu cầu 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

Kết quả: LLM không tìm kiếm trong không gian trống — nó di chuyển trong một không gian có cấu trúc được xác định bởi knowledge graph. Một truy vấn về 'tạo một diagram' biết cách đến các nút liên quan của đồ thị.

Phân loại tự động RGPD: LLM như một router

Ontologial không gian không chỉ căn chỉnh mô hình ngôn ngữ lớn — mà còn trao cho nó mộtbảng phân loại RGPDđể định tuyến mỗi dữ liệu đến khu vực hợp pháp của nó.

tiêu chí

Phát hiện LLM

Hành động

Cấp độ tối đa

Dữ liệu cá nhân (tên, email, IP)

mẫu`@`, IP, tên riêng

Ẩn danh hoá`[OF_PILOTE]`hoặc router cấp 2

2

Cuối mỗi phiên, LLM thực hiện mộtnhiệm vụ toàn cục:

  1. đọc của`.gitignore`Cơ sở để xác định các vật phẩm tạm thời (loại trừ khỏi ảnh chụp) vs các vật phẩm chiến lược (để lịch sử hóa)

  2. Kiểm kê tất cả các tệp`.adoc`của rễ`workspace/`

  3. Lọc: loại trừ các tệp được liệt kê trong`.gitignore`, bao gồm tất cả những người khác

  4. Sao chép trong`configuration/vision-archive/$DATE/cập nhật liên kết tượng trưng`latest/

  5. Commit trong kho`configuration/`với một thông điệp có cấu trúc

  6. Phân loại tự động GDPR của mỗi file đã sửa đổi (tất cả cácวง) # Note: removed space before closing parenthesis incorrectly; fix.

Actually I typed accidentally extra space after "các". Should be "các vòng": "các vòng". No extra spaces inside parentheses.

So final: "Phân loại tự động GDPR của mỗi file đã sửa đổi (tất cả cácวง)" Wait there still weird due to missing space between "các" and "vòng"? Actually I wrote "(tất cả cácวง)" with no space before "vòng". Must have space: "(tất cả các vòng)". Ensure proper Unicode.

Thus: "Phân loại tự động GDPR của mỗi file đã sửa đổi (tất cả các vòng)".

Okay. Final.

</think>

Phân loại tự động GDPR của mỗi file đã sửa đổi (tất cả các vòng)

  1. Định tuyến : dữ liệu`office/→ commit riêng tư, code`foundry/→./gradlew check, cấu hình → commit

  2. Báo cáo được cấu trúc với cảnh báo GDPR và xác nhận lưu trữ

Le `.gitignore`rễ không phải là tệp cấu hình Git — đây là mộtTệp quản lý lịch sử hoá.Nó xác định lược đồ mà LLM tiêu thụ để quyết định những tệp trong vườn bí mật nào sẽ thuộc về tiểu sử chiến lược và những tệp nào bị coi là vô dụng.

LLM không còn chỉ là một công cụ tạo ra văn bản. Nó làquản lý thông tincủa hệ sinh thái — nhà sản xuất, bộ phân loại, bộ định tuyến.

Roadmap : từ AsciiDoc tới LangGraph4j

Hôm nay, quản trị này là xác định : LLM áp dụng một quy trình được mô tả trong các tệp AsciiDoc. Đây làGiai đoạn 1— kỹ thuật prompt engineering với bộ nhớ LLM.

La pha 2Trích xuất mỗi bước của quy trình vào mộtnhiệm vụ Gradle có kiểu:

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

La Giai đoạn 3Sẽ mô hình hoá quá trình kết thúc phiên như mộtđồ thị trạng tháiavechttps://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]

Đồ thị này sẽ được phiên bản hóa trong CI/CD, thực thi bởi Gradle, cấu hình qua các GitHub Secrets của các plugin. LLM sẽ không còn cần quyết định việc định tuyến — đồ thị sẽ làm điều đó.

Điều mà kiến trúc này giải quyết (và điều mà nó không giải quyết)

Ontology không gian không bao phủ hết. Các quy ước về phong cách mã, đặt tên, các lựa chọn thiết kế kiến trúc — tất cả vẫn nằm trong prompt. Điều mà ontological không gian giải quyết làlớp bảo mật và khả năng nhìn thấynơi mỗi byte phải sống, và ai có thể thấy nó.

Đây là điều cụ thể mà nó mang lại:

  1. Không có`git push`điều vô tình về một bí mật*: các bí mật là trong`configuration/(vòng 1). Các dự án công cộng nằm trong`foundry/(hình tròn 4). Không có đường nào đi qua cả hai.

  2. Không có mã nghiệp vụ trong dữ liệu`office/含 các.adoc`, các YAML, các JSON Schemas — không có`.kt`. Le `build.gradle.kts`Người sống ở đó là một script tiêu dùng, không phải là mã nghiệp vụ.

  3. Không có suy nghĩ chiến lược nào được nêu ra : các tài liệu về tầm nhìn tồn tại trong khu vực bí mật (rễ ngoài CVS). Các snapshot nằm trong`configuration/`(kho chứa an toàn riêng tư). Không có ai, ngay cả trong vòng tin cậy mở rộng, cũng không đọc được nguồn gốc của chiến lược.

  4. Auto-priorisation : LLM quan sát chênh lệch giữa đại số quan hệ (cái gì tồn tại) và bản đồ của chuyên gia (cái gì cần thiết). Nhiệm vụ phát triển tiếp theo xuất hiện từ chênh lệch này.

Kết luận: Kiến trúc như một cuộc trò chuyện

Tôi không đặt tuyên bố chính trị trong phần chân trang của trang web của tôi. Tôi không đặt các quy tắc đạo đức trong lời nhắc của tôi. Sự căn chỉnh không ở trong văn bản — nó là ởhệ thống tập tin.

Khi một LLM làm việc trong không gian này, nó không thể rò rỉ một bí mật (đường dẫn ngăn chặn điều đó). Nó không thể nhầm lẫn dữ liệu giáo dục với mã nguồn (khu vực vật lý khác nhau). Nó không thể quên một quy tắc bảo mật ở mức 80 000 token — vì quy tắc đó không nằm trong prompt, mà nằm trong`workspace/(nothing)`configuration/→office/→`foundry/`mỗi lần đọc file là phản ứng.

Đây là nguyên tắc của secure by design áp dụng cho sự canh chỉnh agent: không yêu cầu LLM nhớ các quy tắc. Đảm bảo rằng kiến trúc làm cho lỗi trở nên không thể xảy ra về mặt cấu trúc.

Cùng với việc đi qua, điều này cung cấp cho LLM điều mà không có prompt nào có thể cung cấp được: khả năng củacảm nhậnVị trí của nó, những gì tồn tại, những gì thiếu — và từ đó rút ra điều nó cần làm.

Tham chiếu

Bài viết liên quan

HyperFrames-Gradle : Chuyển đổi AsciiDoc thành video MP4
31 May 2026
Đánh giá mức tiêu thụ LLM của tôi: SQLite, OpenCode, Ollama Cloud, và Vì sao gói Pro của tôi gây sốc trên thị trường toàn cầu
18 May 2026
Kiến trúc "plugin độc lập + gốc tiêu dùng": tại sao các bản dựng Gradle của tôi bị trùng lặp?
14 May 2026
Knowledge Graph như công cụ đề xuất : Cách tôi đã giết những « bài viết liên quan » theo thứ tự thời gian
12 May 2026