AI不是可以理解自然语言吗？怎么又绕回到语法树这条路了

这是一个非常本质、而且非常常见的误解点。结论先给出一句话：

AI 能“理解”自然语言，并不等于它能“可靠、可控、可执行地理解代码结构”。 语法树不是倒退，而是 把“理解”从概率问题，变成工程可控问题。

下面从工程视角，分层说明为什么最终一定会回到 AST / CST / 图结构这条路。

一、LLM 的“理解”，本质是概率，不是结构

LLM 对自然语言（以及代码）的理解，本质是：

  • 基于 token 序列
  • 基于上下文统计与模式匹配
  • 输出的是“高概率正确的文本”

这带来三个天然问题：

  1. 没有确定的结构边界

    • LLM 不“知道”函数从哪一行开始、在哪一行结束
    • 不“知道”这个调用是静态绑定还是动态分派
    • 不“知道”这个符号是否真的可达

  2. 无法保证一致性

    • 同一个问题，换种问法，结果可能不同
    • 稍微超过上下文窗口，信息就丢失

  3. 无法做精确修改

    • “把这个函数参数改成 optional”
    • “只重构这个调用链，不影响其他地方” —— 这类操作，纯靠自然语言几乎不可控

👉 LLM 擅长的是“解释”和“生成”，而不是“判定”和“约束”。

二、语法树解决的是「确定性」问题

Tree-sitter / AST / CST 的核心价值只有一个词：

确定性（Determinism）

语法树能做到什么？

  1. 结构是确定的

    • 函数、类、作用域、模块边界是明确的
    • 起止位置是精确到字符的

  2. 关系是可遍历的

    • 调用关系
    • 继承关系
    • 依赖关系
    • 作用域遮蔽

  3. 错误也是结构化的

    • Tree-sitter 即使在语法错误下也能产出“部分正确”的树
    • 这对 IDE / 自动化修改极其重要

没有 AST，你连“我到底在改什么”都说不清。

三、那为什么还要 AI？各自边界在哪里？

正确的架构不是「AI or AST」，而是「AI on AST」。

你可以把它理解为一条流水线：

代码文本
  ↓（Tree-sitter）
语法树 / 图结构
  ↓（过滤、裁剪、子图）
结构化上下文
  ↓（LLM）
推理 / 生成 / 决策
  ↓
结构化操作（修改 / 查询 / 重构）

AI 负责什么？

  • 理解“意图”

    • “我想找认证逻辑”
    • “这段代码是否有潜在问题”

  • 生成策略

    • 查哪些节点
    • 生成什么查询（Cypher / SQL / DSL）

  • 给出建议

    • 优化方案
    • 重构思路

AST / 图负责什么？

  • 精确定位
  • 严格约束修改范围
  • 保证修改后代码仍然合法
  • 做“不能错”的事情

四、为什么工程系统一定“绕回”语法树？

你可以观察所有真正落地的系统：

  • IDE（IntelliJ / VS Code）
  • 编译器
  • Linter / Formatter
  • 自动重构工具
  • 大规模代码搜索（Google / Meta 内部）

无一例外：

UI / 交互层可能是自然语言 核心层一定是 AST / IR / Graph

原因很简单：

  • 代码是形式语言
  • 形式语言必须用形式结构处理
  • 自然语言只适合做人机接口

五、回到你这个问题的本质

你真正问的，其实是：

“既然 AI 这么强，为什么不能直接理解代码？”

答案是：

AI 可以“看懂”，但系统需要“保证不出错”。

当你：

  • 要做自动修改
  • 要做大规模分析
  • 要做企业级平台
  • 要做 IDE / 编程助手

你就一定会选择：

用 AST / Graph 作为事实基础，用 AI 作为智能决策层。

这不是回到过去，而是：

在 AI 时代，重新确认哪些东西必须是确定的。

参考资料

https://github.com/tree-sitter/tree-sitter