AST：AI 为什么不只是在“读代码文本”？

代码不是一串字，而是一棵树

很多人第一次使用 AI 编程工具时，会产生一种错觉：模型似乎“看懂了”代码。但从软件工具的角度看，真正的理解并不是把文件从头读到尾，而是先识别代码的结构。AST，也就是 Abstract Syntax Tree，中文通常译为抽象语法树，就是把源代码转换成一棵能表达结构的树。

AST 到底抽象了什么

假设代码里有一句 total = price * count。人眼会把它看成一个计算式，解析器则会把它拆成赋值节点、变量节点和乘法节点。树的根部是赋值，左边是 total，右边又是一棵乘法子树，下面挂着 price 和 count。空格、换行和括号的部分细节可能不会成为核心节点，但“谁给谁赋值”“谁和谁相乘”会被保存下来。

这和纯文本搜索的区别很大。搜索可以找到字符串 count，却不一定知道它是变量、注释里的单词，还是另一个对象的属性。AST 则可以回答“这个函数里所有返回值在哪里”“哪些调用传入了用户输入”“这次修改是不是只改变了条件表达式”。

AI 编程为什么需要它

AI 生成代码时最怕两件事：改错位置，以及误解关系。只把相关文件塞进上下文，模型仍然可能把同名变量当成同一个变量，或者把字符串里的代码误判成真正的调用。结构化表示可以为模型提供更稳定的导航线索：函数、类、导入、调用、返回值和条件分支都能成为可检索的对象。

这也是很多“智能重构”功能比普通文本替换可靠的原因。把变量重命名时，工具不是简单地替换所有同名字符串，而是先定位变量声明，再找到引用它的节点。AI 可以提出修改建议，AST 工具则帮助确认修改落在正确的结构上。

AST 不是程序的全部含义

AST 仍然只是语法层。它能告诉我们代码长什么样，却不一定知道一个函数返回的对象在业务上代表订单、用户还是缓存。要理解跨文件引用、类型、控制流和数据流，还需要符号表、类型分析或更高层的程序图。因此，AI 看到 AST 并不等于真正理解业务。

普通人怎样用这个术语

当 AI 说“我已经理解了整个项目”时，可以追问它理解的是哪一层：文件结构、语法结构、类型关系，还是运行时行为。对于小改动，要求 AI 只修改指定函数并保持公开接口不变；对于大改动，让它先列出将影响的函数和调用方。这个习惯的本质，就是把“读文本”升级成“看结构”。

想进一步了解代码结构如何被解析，可以阅读 Tree-sitter 的语法树查询文档。