为什么我说,用上这个 skill 之后,一周都没怎么打开编辑器了
因为很多原来必须在编辑器里完成的中间动作,被直接省掉了, 就像是为coding agent 加了一双眼睛。
过去你通常要这样做:
- 在页面里看到问题
- 打开编辑器
- 全局搜索组件
- 跳来跳去找文件
- 对照页面确认是不是这里
- 再回来修改
- 再刷新验证
现在很多时候变成了这样:
- 在页面上直接选中那个元素
- 对 Agent 说你的修改需求
- skill 自动检查插件和上下文
- Agent 基于准确位置直接修改
- 你在页面里直接看结果
表面上看,好像只是少了“打开编辑器”这一步。
但实际上,真正被省掉的是整段上下文切换。
你不再需要频繁在“浏览器里的视觉结果”和“编辑器里的代码结构”之间来回跳转。你只需要指出目标,然后让 Agent 开始干活。
1. 自动把“选中哪个元素”变成真实上下文
当你在页面上选中目标元素后,skill 会去读取当前选择对应的结构化上下文,而不是继续靠自然语言猜。
这意味着它知道:
- 你指的是哪个元素
- 这个元素来自哪个文件
- 代码大概在哪一行
- 它在组件树里处于什么位置
这一步,直接砍掉了大量沟通损耗。
2. 把“先拿上下文,再改代码”变成稳定流程
很多 AI 改代码不稳定,不是模型不行,而是流程不稳定。
有时候先看代码,有时候先猜文件,有时候先搜关键词。
而这个 skill 把流程固化成了:
- 先检查插件
- 再获取选中上下文
- 再让 Agent 修改
一旦流程稳定,结果通常也会稳定很多。
它不只是一个代码定位插件
如果你之前知道 code-inspector-plugin,你大概率会先想到它的经典能力:
点击页面元素,自动打开 IDE,并把光标定位到对应源码位置。
这个能力到现在依然很好用,而且很适合:
- 快速定位页面元素来源
- 熟悉陌生项目
- 联调复杂页面
- 处理大型老项目里的“这块到底谁写的”问题
但 Agent Eyes 显然不只停在“点一下跳编辑器”这一步。
它往前走了一层,开始真正服务 AI 协作。
它更像一个“页面上下文基础设施”
- 选中页面元素后,自动采集源码路径、行列号、DOM 信息、文本和组件层级
- 支持多选上下文,让一次修改可以覆盖多个位置
- 提供内置 AI 对话面板,直接在浏览器中和 Agent 交互
- 支持 ACP 协议,可以接入 Codex、Claude Code 等 Agent
- 支持 SSE 流式输出,可以实时看到 Agent 的执行过程
- 支持图片和文件输入,让页面改造时能带更多参考材料
- 提供 MCP Server,把选中上下文能力暴露为标准工具
- 提供 Codex Skill,把“检查插件 -> 获取上下文 -> 执行修改”沉淀成可复用工作流