开发者的秘密花园：空间本体如何在无需提示工程的情况下对齐LLM

阅读时间 : 20 minutes

提示工程很脆弱。在 80 000 tokens，你的对齐规则被噪声淹没，LLM 忘记了你在对话开始时要求它做的事情。我的解决方案是什么？不要通过文本进行对齐，而是通过空间. 我以四个同心信任圈构建了我的开发工作空间 —— 从私密的秘密花园到公共的锻造场 —— 并且每个圈都是文件系统的一个物理区域。LLM 不需要被提醒规则：文件路径包含了这些规则。这就是它的工作方式，以及为什么这种基于空间的对齐架构比`system prompt`500行

这是一篇长文章。
请放松。

观察：提示工程是一座沙堡

三周内，我使用 Opencode 开发了 Gradle 插件，使用了三种不同的 LLM — Kimi K2.6、GLM-5.1 和 DeepSeek-V4-Pro（唯一的幸存者，但那是另一个故事)Déjà couverte ici. ) 我的代理治理方法 Je 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文件开头有绝对规则，当累计超过60,000个令牌（初始上下文+对话）时，Kimi K2.6开始提出`Write`在配置文件上造成了巨大的压力。GLM-5.1 将 Firebase 令牌误认为需要替换的占位符。规则已经写好 — — LLM 不再看到它们。
治理本身成为问题。 在实施 Hot/Warm/Cold 机制 Article sur la rotation de backup. 以避免上下文爆炸后，我的 EAGER 文件仍有 1414 行 J’ai documenté cet audit ici.。治理 — 设计用于防止 LLM 饱和 — 却导致 LLM 饱和。

我需要一种不依赖于提示词中令牌数量的对齐机制。

回答：停止按文本对齐，开始按 l'空间.

四个信任圆：一种空间本体论

我的文件`workspace/（在~/workspace/`) 不是 pas Git 仓库。这是我所有工作的根源 — 代码、文档、培训、基础设施。并且它被结构为四个区域，这些区域不是存放约定，而是同心信任圈:

水平

标签

物理区域

CVS

可见性

秘密花园

`workspace/`根

没有

私密 — 自由的思想，无提交，无发布

保险箱

configuration/

私有 Git (单人)

秘密、令牌、视觉档案。只有一个人。

图书馆

office/

Git 私有 (扩展)

教学数据，SPG/SPD，JSON 模式。已识别的信任圈。

锻造 (公共)

foundry/

Git 公开 (Apache 2.0)

源代码, 插件, 测试, 技术文档。

注意：表格中没有第3级。第3级是一个*过渡*级别：这是内容的`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/`在根部)。它像一个治理配置文件回答一个具体的问题： 秘密花园的哪些文物值得被历史记载，哪些只是短暂的？

列在…中的文件`.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/`始终包含一个工作副本最新的快照，作为快速参考而无需浏览Git历史记录。

而对于LLM，它是一个一致性 oracle: 当他观察到当前实现与先前存档的愿景之间存在矛盾时，他可以报告这一点。

保险库：`configuration/` 如同 Spring Cloud Config

`configuration/`它不仅仅包含视觉的存档。其首要（及未来）功能是成为一个Spring Cloud Config 服务器. 所有的秘密、令牌、凭据和基础设施描述符都在这里，位于仅供所有者访问的私有 Git 仓库中。

为什么使用单独的仓库而不是一个文件`.env`在每个项目？

意外推送秘密 : 不可能。机密存储在私有仓库中，公共项目无法错误地引用它们。
审计 : Git 历史记录提供了每次配置更改的追踪。谁更改了什么，何时更改，以及对应的 SHA 哈希。
回滚 :`git revert`在损坏的配置上。快照，无需手动备份。

图书馆：`office/` 作为可消耗数据

`office/`是开发工作的文档对应。它包含博客文章、技术规范、培训材料（38个FPA、SPG/SPD课程目录、JSON图谱、布鲁姆/哈罗/克拉斯韦尔分类法）——构成的一切教学材料.

但是`office/`它不仅仅是一个文档抽屉。它是一个结构化数据源该 Gradle 插件的`foundry/`他们消费。一篇博客文章在`office/`这是一个插件将把它转换为 HTML 的输入。一个 SPG AsciiDoc 在`office/metiers/FPA/`这是一个编排器会解析以生成幻灯片、测验和视频片段的工件。

Et le `build.gradle.kts`在…的根源`office/`不是业务代码 — 这是一个插件生态系统的消费脚本. 他说： "这是我使用的Gradle插件，这是我的工作区上下文"。

锻造厂：`foundry/` 作为实现

foundry/`包含了工业化代码. 54个Git仓库，其中7个目前由.agents/`. 这就是愿景变得可执行的地方 — — Gradle 插件，CI/CD，JUnit5 + Cucumber 测试。

关系与`office/`是双向的:

office/→foundry/: 教育数据是插件消费的原材料。
foundry/(empty)office/`插件产生丰富的数据`office/ — le `graph.json`graphify-gradle 的已编译的slider牌组，build报告

优缺点：空间对齐 vs 提示对齐

让我们比较这两种方法。

经典方法：通过预提示进行对齐

✅ 专业

❌ 相反

易于实施。系统提示中的一段文本。

对长上下文脆弱：规则在 80K tokens 之后被淹没。

适用于一般规则（语气、格式）。

不可验证 : 没有什么能阻止LLM违反该规则。

不需要重新思考项目的架构。

不可转让：每个仓库都重新声明规则。

纯声明性：LLM 知道它应该，但没有什么能阻止它。

此方法：基于空间本体论的对齐

✅ 专业

❌ 反对

长上下文韧性：规则在文件路径中，而不是在遥远的提示中。

初始基础设施成本：将工作区构建为圆形需要时间。

可机械验证 : 一个秘密在`foundry/可以被检测到`git check-ignore.

需要纪律 : 新贡献者必须理解这些圈子。

可转移的 : 一个`AGENT.adoc`标准将各圈层暴露于任何新项目。

仅覆盖空间约束 — 代码风格仍保留在提示中。

安全由设计 : 一个`git push`自从`foundry/不能暴露`configuration/.

可供非LLM代理使用 : 一个Gradle编排器可以根据圈子进行路由。

主要收益不是防御性的（安全, 可见性） — 它是有创意的. 当LLM在由本体结构化的空间中工作时，它可以做到任何提示都无法让它做到的事情：观察增量。

工作空间的关系代数和可观测的 Delta

当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 不需要有人告诉它该做什么。Delta 从结构中浮现。

上下文复合向量 : RAG + pgvector + Graphify

关系代数不是一种理论上的构造。它由三个组成部分 matérialisée 形成一个组合上下文向量针对 LLM.

组件 1 — RAG LangChain4j + PostgreSQL pgvector

我已经在两个插件中将 LangChain4j 投入生产环境 :`slider-gradle`(4个提供商 LLM) 和`plantuml-gradle`(7 个提供者)。ONNX 嵌入（AllMiniLmL6V2）索引数据的`office/`和源代码的`foundry/`在 PostgreSQL + pgvector。

这个 RAG 在两个维度上运行：

Dimension data : 文档`office/`(SPG, 文章, 培训, JSON 模式)
代码维度 : 代码库`foundry/`(源码 Kotlin, 测试 Cucumber, AGENT.adoc)

交集同时涵盖 quoi（业务领域）和 comment（实现）。

组件 2 — Knowledge Graph Graphify

Graphify 已经集成在`plantuml-gradle`(109 次测试，380/380 通过) 并产生一个`graph.json`— 一个结构化的知识图谱，包含节点、边以及自动检测到的社区。

与通过向量相似性（模糊）运作的RAG不同，知识图谱通过精确的关系(确定的) :`graphify query`用于语义查询（约 50 个标记）`graphify path`导航`graphify explain`为了解释。

组件 3 — Graphify 增量：稀疏、可聚合、可消费

这是关键的架构决策。

Graphify 不应只存在于单一的存储库中。它应以某种方式存在。零散的在每个插件中：

每个插件 包含一个 Gradle 任务`updateKnowledgeGraph`调用 Graphify在其自身的作用域并产生一个`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 不在虚无中搜索——它在由知识图谱结构化的空间中导航。一个关于“生成图表”的查询知道如何到达图中相关的节点。

自动GDPR分类：LLM 作为路由器

空间本体不仅仅是对齐LLM — 它给予它一个GDPR分类网格将每条数据路由到其合法区域。

标准

LLM检测

动作

最高等级

个人数据 (姓名, 电子邮件, IP)

模式`@`, IP, 专有名词

匿名化 →`[OF_PILOTE]`或二级路由器

令牌 / 密钥 / 凭据

模式`sk-…, `ghp_…, ya29…

路由器 →configuration/. 被引用`${VAR}`在代码中。

内部URL

包含`localhost`, 私有IP

匿名化 →${API_URL}

教学数据 (SPG, 课程)

结构 Bloom/Qualiopi

路由器 →office/(2级). 导出时双版本。

源代码 / 测试

扩展`.kt`, .kts`在`foundry/

路由器 →`foundry/`检查是否存在任何秘密。

在会话结束时，LLM 执行了一全局任务:

读取的`.gitignore`根源用于识别临时制件（需从快照中排除）与战略制件（需进行历史化）
所有文件的目录`.adoc`根部的`workspace/`
过滤：排除列表中的文件`.gitignore`, 包括所有其他
复制到`configuration/vision-archive/$DATE/更新符号链接`latest/
在仓库中提交`configuration/`带有一个结构化的消息
每个修改文件的自动 GDPR 分类（所有圆）
路由 : 数据`office/→ 私人提交, 代码`foundry/→./gradlew check, 配置 → 提交
带有GDPR警报和存档确认的结构化报告

Le `.gitignore`根不是一个 Git 配置文件 — 它是一个历史记录治理文件. 它定义了LLM消费的模式，以决定秘密花园中的哪些文件进入战略传记，哪些是可丢弃的。

LLM不再只是一个文本生成器。它是信息管理员生态系统的 — 生产者、分类器、路由器。

路线图 : 从 AsciiDoc 到 LangGraph4j

今天，这种治理是*确定的*：LLM 应用了在 AsciiDoc 文件中描述的程序。这是第一阶段— 带有LLM记忆的提示工程。

La 阶段 2将提取过程中的每一步骤放入一个类型化的 Gradle 任务(empty output)

./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 Secrets 进行配置。LLM 不再需要决定路由 — — 图将自行处理。

此架构所解决的（及其未解决的）

空间本体论并不覆盖全部内容。代码风格约定、命名、架构设计选择——所有这些仍然保留在提示中。空间本体论所解决的是安全与可见性层: 每个字节应该存活的地方，以及谁可以看到它。

这是她具体带来的东西：

* 没有`git push`意外的秘密* : 秘密就在`configuration/(圆圈 1)。公共项目位于`foundry/(圆 4)。没有路径同时经过这两个。
没有业务代码在数据中 :`office/包含一些.adoc`, 一些 YAML,一些 JSON Schema — 但没有`.kt`. Le `build.gradle.kts`在那里运行的是消费脚本，而不是业务代码。
没有暴露的战略思考：愿景文档位于秘密花园（CVS之外的根目录）。快照位于`configuration/`(私人保险箱)。即使在扩大的信任圈中，也没有人会阅读战略的起源。
自动优先级 : LLM 观察到关系代数（存在的内容）与专家映射（所需内容）之间的差异。下一个开发任务由此差异产生。

结论：建筑作为话语

我不在网站页脚中放置政治宣言。我不在提示词中放置伦理规则。对齐不在文本中 — 它在文件系统.

当LLM在这个空间工作时，它无法泄露一个秘密（路径阻止了它）。它不能将教学数据与源代码混淆（物理区域不同）。它不能忘记80,000 tokens的安全规则——因为该规则不在提示中，它在`workspace/→`configuration/→office/→`foundry/`每次文件读取都是响应式的。

这是*secure by design*原则在智能体对齐上的应用：不要求LLM记住规则。让架构使得错误在结构上成为不可能。

顺便说一下，这给了LLM任何提示都无法给予的东西：具有……的能力感知它所在的位置，存在的东西，缺失的东西 — 并由此推断它应该做什么。

参考文献

关于 Eager/Lazy 代理人治理的文章 :使用 AsciiDoc 管理 AI 代理
关于热/温/冷机制的文章：滑动窗口和寒流
关于上下文审计的文章：当您自己的治理成为问题时
关于三个LLM比较的文章：DeepSeek-V4-Pro, Kimi K2.6, GLM-5.1

HyperFrames-Gradle: 将 AsciiDoc 转换为 MP4 视频
31 May 2026

我的 LLM 消耗审计：SQLite、OpenCode、Ollama Cloud，以及我的专业订阅为何在全球市场掀起浪潮
18 May 2026

L'Architecture « 插件独立+消费者根 » : 为什么我的Gradle构建会重复？
14 May 2026

知识图谱作为推荐引擎：我是如何杀死按时间顺序的「相关文章」的
12 May 2026

请启用 JavaScript 以查看由 Disqus 提供的评论.