工程化落地：利用 TS/ESLint 自动化构建 AI 权限围墙

donecoding
34 阅读5分钟

前言

在上一篇方案篇中，我们构思了“AI 逻辑沙盒”的双层宏契约：通过 define 与 apply 模式，将 AI 的破坏半径锁死在受限的环境中。

但架构设计如果不落实为自动化工具，就只是纸上谈兵。在 2026 年的开发环境下，我们追求的是 “开发态极高压约束，运行态零开销脱离” 。今天，我们进入深水区，探讨如何利用 TypeScript Compiler API、ESLint 定制规则以及编译时宏处理，将这套逻辑打造成一套闭环的自动化准入体系。

一、 自动化基石：从“宏声明”到“规则映射”

手动维护每个 AI 文件夹的配置是不可持续的。我们的目标是：架构师修改一行 TS 类型定义，工程环境自动完成“布防”。

  1. 静态扫描器 (The Scanner)

我们需要编写一个 Node.js 脚本（利用 ts-morph 或 SWC 的解析能力），专门扫描宿主侧的权限声明。

  • 核心逻辑：

    1. 识别 defineEnvContext<T> 调用的位置。
    2. 静态解析泛型 T 中的属性。例如，如果 T 是 Pick<Window, 'addEventListener' | 'removeEventListener'>，脚本将提取出 window 及其成对的授权属性。这种成对授权是必须的，它确保了 AI 具备清理副作用的能力，从根源规避内存泄露。
    3. 解析 defineImportContext<T> 中定义的外部模块映射路径。
  1. 配置自动生成 (The Generator)

脚本扫描完成后，会立即在对应的 AI 逻辑沙盒 文件夹下生成/更新两个关键的“围墙”文件：

  • 生成 .eslintrc.js：
    必须设置 root: true。这是为了彻底切断父级目录中可能存在的“宽松规则”干扰，确保沙盒规则的纯净。

    javascript

    // /src/ai_modules/xxx/.eslintrc.js
module.exports = {
  root: true, // 核心：断绝父级规则合并，建立独立“法律体系”
  env: {
    browser: false, // 禁用默认环境，防止隐式逃逸
    es2022: true
  },
  rules: {
    "no-undef": "error", // 配合抹除 DOM 库，禁止直接访问全局变量
    // 这里的 "error" 是等级（Severity），确保任何违规代码都无法通过编译
    "no-restricted-globals": ["error", "window", "document", "location", "localStorage"], 
    "no-restricted-syntax": [
      "error",
      {
        // 仅允许从我们的宏解构出的变量，禁止绕过宏直接调用
        "selector": "VariableDeclarator[init.callee.name='applyEnvContext'] > ObjectPattern > Property",
        "message": "解构变量未在宿主 define 宏中授权。"
      }
    ]
  }
};

    请谨慎使用此类代码。

  • 生成 tsconfig.json：
    通过 compilerOptions.paths 将全局类型重定向到我们生成的受限 .d.ts 定义，确保 AI 编写时 IDE 提示仅包含被 Pick 出来的安全属性。

二、 编译时魔法：宏的“彻底消失术”

宏（Macros）的本质是“开发态的严格约束，生产态的纯净幻觉”。在构建阶段，我们需要通过编译器插件进行物理处理。

1. applyEnvContext 的运行时脱除

这是方案最优雅之处：由于宿主环境天然存在全局对象，我们只需要在编译时把宏“删掉”即可。

  • 转换前（AI 源码） ：
    const { window } = applyEnvContext<GlobalApi>();
  • 转换后（产物代码） ：
    const { window } = globalThis;（或直接物理移除，让变量引用回退到原生全局访问）。
  • 工程意义：开发态通过宏实现解构变量并赋予受限类型以通过审计；构建态则让其消失，保证产物零开销。

2. applyImportContext 的逻辑提升

与环境宏不同，第三方模块需要真实的引入逻辑。

  • 处理逻辑：编译器扫描该宏，根据映射关系在文件顶部插入 import debounce from 'lodash/debounce'，随后删除原始宏调用行。

三、 防御性审计：如何防止 AI “逃逸”？

AI 可能会尝试利用先验知识，通过 window['loc' + 'ation'] 这种手段绕过静态拦截。为此，我们在 AI 逻辑沙盒 内实施  “零信任审计” ：

  1. 禁止成员表达式动态访问：通过 ESLint 拦截 MemberExpression 的计算属性访问，强制要求 API 调用必须是静态可见的。
  2. 强制单一入口：禁止任何非宏声明的外部 import。所有依赖必须通过 applyImportContext 申请。
  3. 二次编译校验：在构建插件中，我们会对解构的属性进行二次核对。如果 AI 试图解构一个未经 define 授权的属性，构建将直接阻断。

四、 架构总结：将权力关进“基建”的笼子

至此，我们构建了一套完整的 AI 原生工程治理流水线：

  1. 架构师（人） ：在宿主层通过 define 宏拨发微小的、经过 Pick 裁剪的权限。
  2. 自动化脚本：将权限实时映射为沙盒内部的 root: true 的 ESLint 规则与 TSConfig。
  3. AI（执行者） ：在受限的 AI 逻辑沙盒 内，通过 apply 宏行使能力。
  4. 编译器（拦截者） ：在构建时校验并抹除所有宏逻辑，产出纯净代码。

在这种架构下，人担责的压力被降到了最低。  你不再需要死磕业务逻辑，只需要审计那几行“契约”。例如： “AI 申请了 addEventListener 但没有申请 removeEventListener，这是否会引入内存风险？”  这种基于权限边界的审计，才是真正的高效。

结语

「AI 逻辑沙盒」不仅是一套工具，它代表了我们在 2026 年对防御性编程的终极实践。

我们正处在一个分水岭：一边是 Vibe Coding 带来的生产力狂欢，一边是工程严谨性的崩塌。而这套方案试图在两者之间架起一座桥梁：用最硬核的基建，去拥抱最不确定的 AI 生产力。

感谢阅读系列文章《AI 原生工程：逻辑沙盒与零信任代码治理》。这场关于 AI 准入的革命，才刚刚开始。

avatar
文章
阅读
粉丝