element-source：点一下页面元素，告诉 AI 它来自哪个源文件
阅读时间: 大约 7 分钟
element-source：点一下页面元素，告诉 AI 它来自哪个源文件
AI 编程助手改前端代码时有个经典尴尬：你对着页面指着一个按钮说”这里改一下”，Agent 却不知道这个按钮渲染自哪个组件——它看到的是编译后的 DOM，不是你的 Button.tsx。传统解法是 React DevTools 手动定位，再把文件路径手敲给 Agent。element-source（作者 Aiden Bai——Million.js、Nano Stores 的作者，MIT 协议）把这件事做成了一个库：传任意 DOM 元素进去，异步返回它来自哪个源文件、哪一行哪一列、以及完整的组件调用栈。本文基于官方 README 实读。
一、它解决的问题：给 Agent 一双”看见源码”的眼睛
README 里作者把动机写得很坦白：这个库最初是为了驱动他做的 React Grab——在浏览器里圈选元素，把源码位置作为上下文喂给编码 Agent。他的判断是：“Agents are incredibly good and token efficient at using file sources.”（Agent 在使用文件源码这件事上极其高效且省 token）。现在他把 React Grab 背后的能力抽成了独立开源库。
返回的数据结构（README 示例）：
const info = await resolveElementInfo(document.querySelector("#root button"));
// {
// tagName: "button",
// componentName: "Counter",
// source: { filePath: "src/Counter.tsx", lineNumber: 12, columnNumber: 5 },
// stack: [
// { filePath: "src/Counter.tsx", lineNumber: 12, columnNumber: 5, componentName: "Counter" },
// { filePath: "src/App.tsx", lineNumber: 8, columnNumber: 3, componentName: "App" },
// ]
// }拿到这个 stack，Agent 就不用全文搜索定位了——直接打开 src/Counter.tsx:12 就是渲染这个按钮的地方。
二、API 设计：为”喂给 LLM”而优化
README 提供四个层次的函数：
resolveElementInfo(node)：一站式拿全部信息；resolveSource(node)：只要主源位置；resolveStack(node)：完整组件栈（React 与框架栈合并）；resolveComponentName(node)：只要最近的用户组件名；- 外加
createSourceResolver({ resolvers: [svelteResolver, vueResolver] })自定义组合，和formatStack/formatStackFrame——后者直接输出”in Counter (at src/Counter.tsx:12:5)“这种栈轨迹风格的字符串，明显就是为了拼进 prompt。
框架覆盖：React、Preact、Vue、Svelte、Solid 五大主流框架。作者甚至让 getTagName 能识别 Ink（终端 React）的 nodeName，说明它的野心不止浏览器 DOM。
三、口径与局限（必须讲清）
- 依赖框架的开发态元数据。 它靠的是 React/Vue 等在 dev 模式下注入的 owner stack / 源位置信息。README 明确警告：用 Preact 必须在开发环境
import preact/debug——生产构建里这些元数据会被剥掉，这个库在生产环境基本拿不到准确位置。它是开发期工具，不是运行时遥测。 - 行号是开发态映射，不等于产物里的行号。 依赖 source map 与 dev hook，混淆/压缩后的产物对不上。
- 项目极早期。 仓库只有 2 个贡献者、129 行 README、1 个 open issue——是作者的个人实验性发布，API 随时可能变；别在严肃产品里强依赖。
- SSR / 静态生成的元素拿不到。 没有客户端组件树挂钩的纯 HTML 元素，解析结果为 null。
- 它只给位置，不给源码内容。 这是设计取舍——让 Agent 自己按路径去读文件，比库内嵌文件内容更省 token，也更符合 Agent 工作流。
四、客观评价
优势：
- 切中 AI 编码工作流的真实痛点：从 UI 到源码的精确上下文桥接；
- 多框架统一 API，React/Vue/Svelte/Solid 一把梭；
- MIT、类型完整、API 克制（四个函数覆盖全场景）；
- formatStack 直接产出 prompt 友好格式，作者懂 Agent 用法。
局限：
- 仅限开发环境，生产不可用；
- 项目早期、维护者少，长期演进不确定；
- 依赖各框架 dev hook 的稳定性，框架升级可能悄悄破坏定位精度；
- 不解决”定位之后改代码”，只是供料环节。
五、谁该关注
做浏览器内 AI 编码工具（类似 React Grab、Cursor 的 Devtools 联动、可视化 IDE 插件）的工程师——这是你要找的基础设施。普通开发者日常改代码，用 DevTools 组件面板人肉定位就够，不需要专门装这个库。但它代表的方向值得记住：AI Agent 的上下文精度，正在从”给它文件”进化到”给它像素到代码的精确映射”。