让 AI 直接写源代码真的太危险了

现在的 AI 编程工具，无论是 Cursor 还是 Claude Code，底层逻辑其实都极其相似：模型吐出源代码，然后人类去读、去运行。这套逻辑默认了一个前提——“人会进行 Code Review”。但实际开发中，当生成的代码量超过几个文件，人的注意力就会迅速崩塌。如果是写个 React 组件没问题，但如果 AI 正在写后端逻辑，顺手在 scope 里带出了数据库凭证，或者生成了一段带后门的系统调用，这种风险谁也扛不住。

我最近关注到一个挺硬核的思路，他们干脆不让 AI 写代码了，而是让 AI 写 AST（抽象语法树）。

这个思路的核心在于：与其试图通过各种手段去“限制”模型，不如直接“定义”它能用的语言。他们搞了一个叫 Hyperlambda 的东西，本质上是一个可执行的 AST 运行时。

• 从“减法”变“加法”： 传统的沙箱思维是“减法”，先给模型一个全能的运行环境，然后拼命去堵漏洞、去禁掉 shell、去限制权限，但这永远会有漏网之鱼。而 AST 模式是“加法”，初始状态什么能力都没有，我只定义哪些节点（Node）是合法的。
• 语法层面切断风险： 如果我的语法定义里根本没有“执行 Shell 命令”这个节点，那么无论用户怎么通过 Prompt Injection（提示词注入）去诱导模型，模型也写不出 rm -rf。因为在语法树的层级，这个操作根本不存在。
• 结构化校验： 校验代码逻辑如果用正则去扫源代码，那简直是自寻死路。但如果输出的是树状结构，你可以非常确定地检查：这个节点是不是在访问它不该碰的数据库表？这种检查是确定性的，而且毫秒级完成。

当然，这种做法是有代价的，那就是牺牲了通用性（Expressiveness）。你没法用它写任何复杂的算法，但如果你只是想通过自然语言描述需求，然后快速生成一套带 Auth、带 CRUD、带不同数据库支持的后端 API，这种工作流的安全性确实是降维打击。

这种思路其实给很多做 AI Agent 的开发者提了个醒：在构建执行环境时，与其折腾复杂的权限管理，不如直接构建一个高度受限、只有白名单操作的 DSL（领域特定语言）。

// 理想中的 AI 输出，不是一段字符串，而是一个结构化的 AST 节点
{
  "type": "QueryNode",
  "params": {
    "table": "users",
    "fields": ["id", "username"],
    "filter": { "id": 101 }
  },
  "permission": "read_only"
}