前言
在上一篇文章《从 Vibe Coding 到责任归属》中，我们达成了一个共识：AI 不坐牢，责任人承担。
既然责任无法规避，那么作为架构师，我们唯一能做的就是：像约束 Docker 容器一样，约束 AI 产出的代码。
今天，我将分享一套名为 「AI 逻辑沙盒 (AI Logic Sandbox)」 的工程治理方案。它的核心逻辑不是靠“嘴”去命令 AI，而是通过编译时授权与静态隔离，从物理上锁死 AI 代码的破坏半径。
一、 核心痛点：AI 的“先验知识”逃逸
为什么传统的 Prompt 约束总是失效？
因为 AI（如 Claude 或 GPT）拥有庞大的先验知识。即便你在 Prompt 里写了“不要使用原生 Fetch”，但它知道这段代码运行在浏览器环境。一旦逻辑陷入复杂，它会本能地调用 window、localStorage 甚至 document.cookie。
只要环境是开放的，AI 就会存在“逻辑逃逸”。
为了解决这个问题，我们需要在项目中开辟一个特殊的目录 —— AI 逻辑沙盒区。在这个区域内，AI 的“上帝视角”将被剥夺，它只能看到你允许它看到的世界。
二、 方案设计：基于“契约”的双层宏架构
为了实现这种颗粒度的控制，我设计了一套名为 Define-Apply 的双层编译宏体系。它将权限控制从“运行时”提前到了“开发态”。
- 宿主层：定义权限边界（Define）
在沙盒的入口处，由架构师（人类）显式定义该模块的权限：
typescript
// 宿主定义：这个 AI 模块能动什么？
defineEnvContext<{
// 授权事件监听：必须成对出现，确保 AI 能够清理副作用，避免内存泄露
window: Pick<Window, 'addEventListener' | 'removeEventListener'>,
document: Pick<Document, 'getElementById'>
}>();
defineImportContext<{
debounce: typeof import('lodash/debounce') // 仅允许引入特定的工具函数
}>();
请谨慎使用此类代码。
注意： 这里我们同时
Pick出了移除监听的权限。在沙盒模式下，架构师必须通过 API 声明强制 AI 关注副作用的闭环。如果你不给 AI 移除监听的权限，它写出的代码就无法通过沙盒内部的工程审计。
- AI 侧：申请能力接入（Apply）
在逻辑沙盒内部，AI 编写的代码必须通过以下宏来获取能力：
typescript
// AI 使用：我行使被授予的能力
const { window, document } = applyEnvContext<GlobalApi>();
const { debounce } = applyImportContext<ImportModules>();
// AI 之后编写的逻辑将被锁死在上述解构出的变量中
请谨慎使用此类代码。
三、 物理沙箱：如何实现“环境抹除”？
仅仅有宏是不够 determined，我们需要利用 TypeScript 和 ESLint 的层级配置特性，为沙盒构建“边界”。
- 类型层面的“环境盲盒”
我们在沙盒文件夹下放置一个定制的 tsconfig.json。通过配置 lib: ["ESNext"] 并移除 "DOM" 库，我们从类型系统层面抹除了 window 和 document 的存在。
- 结果：AI 尝试直接写
window.location时，IDE 会直接报红。它必须通过applyEnvContext来获取那份被“阉割”过的环境对象。
- 语法层面的“铁丝网”
通过特定的 ESLint 规则，我们强制执行以下约束：
- 根规则覆盖：设置
root: true，切断父级目录的宽松配置。 - 零全局变量：开启
no-undef，且禁止任何未经宏声明的外部import。 - 禁止逃逸：拦截任何尝试通过原生
require或动态import()探测项目隐私的行为。
四、 自动化映射：从“声明”到“拦截”
这套方案最高效的地方在于：配置是自动生成的。
我设计了一个映射脚本（Mapping Script） ，它会静态扫描宿主侧的 define 宏：
- 解析泛型：提取出你
Pick出来的属性名。 - 同步配置：自动将这些属性填入该文件夹下的
.eslintrc.js白名单中。 - 动态构建：自动生成一个受限的
.d.ts类型定义文件，供该目录下的 TS 引擎使用。
这意味着：架构师只需要修改一行 TS 接口定义，整个 AI 逻辑沙盒的安全边界就会自动完成“扩容”或“收缩”。
结语：将权力关进笼子
「AI 逻辑沙盒」的本质，是把原本模糊的“代码审查”变成了清晰的 “权限审批” 。
- 你不需要读懂 AI 内部的每一行循环。
- 你只需要审批它申请的
defineImportContext是否合规。 - 只要编译通过，就代表这份代码的风险已经被物理性地限制在了你设定的方寸之间。
这是我们应对 2026 年大规模 AI 协作的底层防线。在下一篇实战篇中，我将深入底层，分享如何编写这个自动化映射脚本，以及如何通过 SWC/Babel 插件在构建时处理这些宏。
欢迎关注专栏 [《AI 原生工程：逻辑沙盒与零信任代码治理》]，我们下一篇聊聊“自动化拦截”的技术落地。
讨论点：
如果是你，你会给 AI 开放哪些“危险”权限？这种基于“编译宏”的隔离思路，是否能解决你对 AI 代码失控的担忧？欢迎评论区见。
