当沙盒泄漏时：跨 LLM 工作空间的上下文污染

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文并保持原有的格式。

Introduction

我有两个工作空间。一个是沙盒——凌乱、探索性、在 GitHub 上进行版本控制。另一个是精心策划的作品集——打磨过的、面向雇主的、仅本地使用。它们之间的边界在架构上非常清晰：研究留在沙盒，完成的成果单向提升到作品集。很简单。

但这条边界总是会失效。

我在机器的不同位置找到了我的 Obsidian 金库的三个副本——Systemic_Intelligence_Vault、Systemic_Intelligence_Vault_Antigravity 和 Systemic_Intelligence_Vault_Claude。每个都是内容略有差异的变体。脚本会指向错误的根目录。作品集中的绝对路径硬编码在沙盒文件里，导致本应独立的两个系统相互耦合。而最让我应该在意的部分——我早在几个月前就已经为这些问题设计了解决方案：信标文件、验证脚本、提升门槛。这些都记录在我的 Program Architecture 中，只是没有得到执行。

那时我意识到：文档不是边界，执行才是边界。

我叫约翰，过去六个月里一直在多个 LLM 环境和工作空间之间构建知识管理系统——一个用于研究的沙盒，一个用于策划作品的作品集，以及在两者之间运行的模型。这是 Building at the Edges of LLM Tooling 系列的 第 2 部分，探讨持续 LLM 工作流中会出现的破坏。请从开头开始阅读这里。

为什么会出错

工作区之间的污染并不剧烈，它是熵增的。你复制一个文件夹来备份。你在脚本中引用一个路径。你为测试创建一个变体。每个动作都很小且合理。但如果没有强制执行，它们会累积成我开始称之为 spaghetti — 纠结、边界不清的状态，混乱的研究渗入整理好的空间，整理好的假设又泄漏回探索性工作中。

LLM 辅助的工作流会放大这种熵。每个 IDE 代理、每个模型会话、每个工具都会对事物所在位置和规则形成自己的假设。运行在你仓库的一个副本中的模型并不知道还有另一个副本的存在。它不知道它的配置文件与规范版本的配置文件不同。它只会遵循它找到的任何指令。

这导致了我一直碰到的三种污染向量。

1. 路径污染

• 项目在不同位置有多个副本，没有唯一的规范根目录。
• 脚本崩溃。
• 模型引用了错误的目录。

当我的 MP 助手指出我之前已经遇到过 “错误根目录、错误名称、引用 ~” 的失败 — 而且我已经设计了信标文件来防止它们 — 这就是信号。我在第二次解决同一个问题，因为第一次的解决方案是文档，而不是一道门。

2. 行为污染

• 隐形的，这让情况更糟。

• 对主库和 Antigravity 变体进行 diff 时，内容几乎相同，但 .cursorrules 文件却不同：

  • Main vault: “You are working inside the Systemic Intelligence Vault — a living knowledge system using Expansive Closure Protocol methodology.”
  • Antigravity variant: “You are working inside a local Obsidian vault.”

  内容相同，提示相同，却出现了完全不同的 AI 行为 — 对项目、方法论和文件处理的假设不同。没有错误信息，只有悄然错误的输出，直到我对比了配置文件才解释得通。

3. 推广污染

• 从 sandbox 到 portfolio 的单向流应该是一个干净的门。
• 架构文档明确写道：“不允许混乱研究跨污染到 MP；推广保持单向。”
• 没有预检，草稿会泄漏进整理好的空间。
• 没有来源追踪，你会失去源头与已推广产物之间的血缘关系。
• 没有通道强制，原始聊天记录和代理日志可能会意外地与完成的工作一起被推广。

我尝试过的办法

第一反应是程序化——检查清单、交接协议、命名约定。

• 记录了哪些文件夹禁止提升。
• 编写了架构文档，解释单向流动。
• 创建了命名标准：在 sandbox 中使用 YYYYMMDD_Title_v#.#.md，在 portfolio 中使用类似约定。
• 在概念、流程、语义、结构、行为五个类别中详细列出了防护措施。

但这并没有奏效。手动纪律在高负荷下会退化。你在快速推进时会跳过清单。离开项目一周后，你会忘记哪个副本是规范的。

于是我转向 技术强制。出现的模式有三层。

1. 用于规范根目录的信标文件

在 portfolio 的真实根目录放置一个零字节的 .MASTER_PORTFOLIO_ROOT 文件。每个脚本在操作前都会检查它。如果信标缺失，脚本会立即失败，而不是悄悄在错误的目录上工作。

“选定一个规范根目录，其他一切都视为副本。” – MP 助手

实现方式是一个极简的 bash 脚本：

#!/usr/bin/env bash
# abort if the beacon file is not present in the current directory tree
if ! find . -type f -name ".MASTER_PORTFOLIO_ROOT" -print -quit | grep -q .; then
  echo "Error: .MASTER_PORTFOLIO_ROOT not found – aborting."
  exit 1
fi
# …rest of script…

它听起来非常简单，实际上也是。这正是它能起作用的原因。因为它是硬性门槛，而不是软性约定，你不可能忘记它。

2. 跨界操作前的预检

在任何内容从 sandbox 移动到 portfolio 之前，脚本会验证：

1. 源文件是否真的位于 sandbox 仓库？
2. 是否来自允许的通道？
3. 是否包含会导致耦合的硬编码 portfolio 路径？
4. 元数据是否标记为 准备提升？

任何失败都会阻止操作。

3. 仅指针的来源记录

提升的制品不复制源上下文，而是携带仅包含元数据的来源记录：

provenance:
  source_system: sandbox
  source_reference: "Systemic_Intelligence_Vault/20240312_DeepDive_v1.2.md"
  date: 2024-03-12
  promoted_items:
    - "DeepDive_v1.2.md"
  excluded_items:
    - "raw_chat_log.txt"
  rationale: "Final report for client presentation"
  hash: "sha256:3a7f5e..."

没有内容泄漏。portfolio 保持干净，同时保留可验证的溯源，指向原始研究。

Takeaways

文档告诉你应该发生什么。强制执行确保它真的发生。

可追溯链保持完整。

对于行为污染问题，解决方案需要思维方式的转变：将配置文件视为系统的一部分，而不是本地偏好。对 *.cursorrules* 和 *.claude/settings.json* 进行版本控制。将一个副本标记为规范，并对每个变体进行明确标记。当 AI 的行为与预期不符时，首要的诊断是**“我位于哪个副本？”**——信标系统能够立即给出答案。

揭示内容

LLM 工作流中的边界存在于两个层面，而大多数从业者只构建了第一层。

1. 概念层面 – 这片空间用于探索，那片空间用于完成的工作，推广单向流动。大多数会考虑工作区整洁的人止步于此。他们记录架构并相信自己会遵循它。

2. 执行层面 – 当脚本位于错误根目录时使其失败的信标、阻止禁用路径的预检、通过版本控制的配置文件防止不可见的行为漂移。这才是边界真正起作用的地方。

层面一与层面二之间的空隙就是意大利面条般混乱产生的地方。其表现是反复出现的失败。当我的助手提示我几个月前已经设计了信标和验证脚本——正是为了解决我再次遇到的同样失败——这就是信号。如果你两次遇到相同的污染模式，说明你在设计上没有失误，而是在执行上失误。

另一个洞见涉及 不可见的污染。

• 内容漂移 是嘈杂的——你可以 diff 文件，查看变化并合并差异。
• 配置漂移 是沉默的。不同的 *.cursorrules* 在保险库副本之间导致 AI 行为不同，却没有错误信息，也没有内容上的可见差异，只有输出感觉微妙地不对。这是最难捕捉的污染，因为在你主动去查看之前没有任何信号。

可复用规则

如果你为探索性工作和策划工作维护独立的工作空间——并且如果大型语言模型代理在这些空间中运行——在没有强制执行基础设施的情况下，污染是默认状态。

1. 从诊断开始。

   • 当你发现自己在重新寻找文件所在位置时，这就是 路径污染 —— 放置一个信标文件，并让你的脚本检查它。
   • 当 AI 对相同提示产生意外不同的输出时，检查你所在的工作空间副本 —— 很可能是 配置漂移。
   • 当你将工作从沙盒提升到作品集时，询问提升路径是否有预检检查，还是仅依赖你的注意力。你的注意力会失效。

2. 反意大利面条原则：

   每个工作空间之间的边界都需要相应的强制执行机制。

   • 概念边界 记录意图。
   • 强制执行机制 保留 那一意图。

当同样的故障重复出现时，缺失的环节几乎从不是设计本身——而是使设计成为可选的那道门。