树：Coding Agent 眼里全是它
文件目录、JSON、网页 DOM、代码语法树——AI 读你的项目时看到的是一棵棵树。点开一段代码，亲眼看它变成 AST
本页解决的问题
先给结论「树：Coding Agent 眼里全是它」要解决的关键问题是什么？
文件目录、JSON、网页 DOM、代码语法树——AI 读你的项目时看到的是一棵棵树。点开一段代码，亲眼看它变成 AST
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
假设你让 AI 帮你做一个「奶茶店小程序」。下面三个标签页，分别是这个项目的文件目录、一笔订单的 JSON 数据、点单页的网页 DOM——三样东西看着完全不同，请你点击带箭头的节点展开收起，留意一件事：它们的形状是不是一模一样？都是一个根往下分叉。
树最厉害的一次出场，是在代码本身。下面这行算总价的代码，在你眼里是一串文字，在 Coding Agent 眼里是一棵语法树（AST）。点「解析」，看它自下而上长出来——留意每一步高亮的代码片段，和树上新长出的节点是怎么对应的。
* 节点，再取它的右孩子，指哪打哪。改完再把树「打印」回文字，一个空格都不会错位。重命名变量、抽取函数、批量重构，靠的全是在这棵树上做手术，而不是碰运气的文本替换。
Agent 读项目 = 从根遍历文件树
你把项目丢给 Coding Agent，它做的第一件事就是从根目录出发，一层层展开子文件夹——和你刚才点开「奶茶店小程序」目录的动作一模一样。它先看树的形状了解项目骨架，再挑几片关键的「叶子」细读。
JSON 是 API 世界的通用树
你调用大模型 API 时发的 message list、RAG 检索回来的资料、Agent 之间传的任务，几乎全打包成 JSON——因为它是一棵用文字写出来的树，任何程序都能一层层拆开读。看懂树，就看懂了 AI 世界一大半的数据。
「一物三看 · 同一个项目，三棵树」为什么要看操作
「假设你让 AI 帮你做一个「奶茶店小程序」。下面三个标签页，分别是这个项目的 文件目录 、一笔 订单的 JSON 数据 、点单页的 网页 DOM ——三样东西看着完全不同，请你 点击带箭头的节点展开收起 ，留意一件事： 它们的形状是不是一模一样？」把结构落到了一个具体动作。这里真正要比较的不是名词谁更高级，而是数据如何被放置，以及最常发生的操作需要走多远。
读懂结构，要同时看访问方式和变化方式
「树最厉害的一次出场，是在代码本身。下面这行算总价的代码，在你眼里是一串文字，在 Coding Agent 眼里是一棵 语法树（AST） 。点「解析」，看它 自下而上 长出来——留意每一步高亮的代码片段，和树上新长出的节点是怎么对应的」揭示了一个容易被忽略的取舍：按位置读取、按键查找、从两端进出、插入新元素和遍历关系，适合的组织方式并不相同。一个结构在某个操作上很快，不代表它在所有操作上都快。
- 层级即树 ：只要有「一层套一层」的包含关系，就是树——文件目录、JSON、DOM 全是
- 三个术语 ：最顶上叫根，有孩子的叫父节点，末端叫叶子
- AST 是 AI 精确改代码的地图 ：Agent 看的不是文字，是语法树，所以能指哪打哪
把规模和更新频率一起算进去
实践时可以把「你调用大模型 API 时发的 message list、RAG 检索回来的资料、Agent 之间传的任务，几乎全打包成 JSON——因为它是 一棵用文字写出来的树 ，任何程序都能一层层拆开读。看懂树，就看懂了 AI 世界一大半的数据」当作边界提醒：先写下数据量、最常用的操作和允许的延迟，再看 AI 给出的结构是否真的匹配。
从「一物三看 · 同一个项目，三棵树」走到「重头戏 · 一行代码变成一棵树」
「一物三看 · 同一个项目，三棵树」先把问题落在「假设你让 AI 帮你做一个「奶茶店小程序」。下面三个标签页，分别是这个项目的 文件目录 、一笔 订单的 JSON 数据 、点单页的 网页 DOM ——三样东西看着完全不同，请你 点击带箭头的节点展开收起 ，留意一件事： 它们的形状是不是一模一样？ 都是一个根往下分叉」上；到了「重头戏 · 一行代码变成一棵树」，讨论继续推进到「树最厉害的一次出场，是在代码本身。下面这行算总价的代码，在你眼里是一串文字，在 Coding Agent 眼里是一棵 语法树（AST） 。点「解析」，看它 自下而上 长出来——留意每一步高亮的代码片段，和树上新长出的节点是怎么对应的」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
遇到一个新的数据结构时，不要从定义开始背。先写出最频繁的操作，再估计数据量和更新方式，最后检查结构是否让这三个条件同时成立。
- 「一物三看 · 同一个项目，三棵树」：假设你让 AI 帮你做一个「奶茶店小程序」。下面三个标签页，分别是这个项目的 文件目录 、一笔 订单的 JSON 数据 、点单页的 网页 DOM ——三样东西看着完全不同，请你 点击带箭头的节点展开收起 ，留意一件事： 它们的形状是不是一模一样？ 都是一个根往下分叉
- 「重头戏 · 一行代码变成一棵树」：树最厉害的一次出场，是在代码本身。下面这行算总价的代码，在你眼里是一串文字，在 Coding Agent 眼里是一棵 语法树（AST） 。点「解析」，看它 自下而上 长出来——留意每一步高亮的代码片段，和树上新长出的节点是怎么对应的
- 「最后的要点」：JSON 是 API 世界的通用树 ：AI 世界的数据交换，大半靠这棵「文字树」
最后的「最后的要点」把讨论落到「JSON 是 API 世界的通用树 ：AI 世界的数据交换，大半靠这棵「文字树」」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
✅ 这一课想和你分享的
- 层级即树：只要有「一层套一层」的包含关系，就是树——文件目录、JSON、DOM 全是
- 三个术语：最顶上叫根，有孩子的叫父节点，末端叫叶子
- AST 是 AI 精确改代码的地图：Agent 看的不是文字，是语法树，所以能指哪打哪
- Agent 读项目就是遍历文件树：从根出发一层层展开，先看骨架再读叶子
- JSON 是 API 世界的通用树：AI 世界的数据交换，大半靠这棵「文字树」
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。