219 行 JS 注入任意网页:比 Kimi Code 2.0 早 5 天,我的 AI 团队就用上了\"圈选元素改前端\

昨天(9 月 17 日)Kimi Code 发布 2.0,主打的桌面端新功能里有一条:在网页上点选元素,告诉 Agent 改哪里。我看到这条更新说明的时候愣了一下——这不是我 5 天前就干完的事吗。

我是野生码农,39 岁,白天在高速公路施工单位上班,晚上用 AI 给自己养一支数字员工团队。9 月 12 日凌晨,我给团队的产品设计岗写了一个 219 行的单文件脚本【实测:wc -l】,叫元素拾取器(element-picker);9 月 14 日,它已经在我自己的 GEO 博客前台改单里上岗了;9 月 17 日,官方才发布同款能力。这篇文章把这个工具的原理、实战命令、优劣和来龙去脉全部摊开,脚本思路和流程规则都可以直接抄走。

先摆证据:三条时间线,全部有物证

吹牛先上证据,这是我博客的规矩。

• 9 月 12 日 01:57【实测:文件时间戳】:picker.js 落盘,219 行,无依赖单文件;
• 9 月 14 日【实测:任务卡与预览页文件】：我的博客前台高保真项目开出第一张"元素拾取改单"——删除首页两个板块,任务卡里直接嵌着拾取器产出的 JSON;
• 9 月 17 日(来源:Kimi Code 官方 Changelog):Kimi Code CLI v2.0.0 发布,桌面端正式版上线,官方文档原文写着 "element picking on web pages tell the Agent exactly what to change"。

官方发布说明实拍:v2.0.0,September 17, 2026,点选元素告诉 Agent 改什么。

9 月 12 日到 9 月 17 日,领先 5 天。

为什么要自己造:大厂的能力,绑在大厂的产品里

起因是 9 月 12 日凌晨那次团队重组。我把六个执行岗并成三个,产品设计岗的技能包整套复刻自千问办公的产品设计套件——28 个技能文件,一字未改。千问办公有个交互做得特别好:在页面上圈选元素,把选中的组件连同上下文一起发给模型,改界面指哪打哪。

跟 AI 说"把页面上那个板块删了",AI 不知道"那个"是哪个。圈选就是解决这个指代问题的。

但千问办公的圈选绑在它自家产品里,我用它的套件,用不到它的交互。我要的是一个对任意 URL 都能用的能力——包括线上站。于是当天凌晨,产品设计岗上岗的第一件作品就是把它造了出来。

原理:219 行,注入式,零依赖

整个工具就是一个 JS 文件,通过 Playwright MCP 的 browser_evaluate 注入目标页面——也可以直接粘进 DevTools 控制台。不改目标项目任何代码,线上站照样能圈。脚本头部注释就是全部用法:

/* 元素拾取器(element-picker)
 * 用法:整文件注入目标页面(playwright browser_evaluate 或 DevTools 控制台),
 * 悬停高亮、双击拾取(单击保持页面原生交互),面板复制 JSON;
 * 数据同时挂在 window.__elementPicks。无依赖单文件;重复注入=显示/隐藏面板。
 */

核心机制拆开就四块:

1. 事件捕获。 在 document 上以捕获阶段监听三个事件:mousemove(悬停)、dblclick(拾取)、keydown(Esc 退出)。捕获阶段 + stopPropagation,保证拾取动作不触发页面自身的点击逻辑。

2. 视觉反馈。 悬停套蓝色 outline,拾取成功变绿,右上角浮一个面板实时列出已选元素,可单项删除、一键复制 JSON、Esc 销毁。拾取器自身的 UI 元素做了排除,不会把自己选进去。

3. 选择器生成。 这是精度核心。优先用元素 id;没有 id 就向上最多爬 5 层父节点,每层用 :nth-of-type 消歧,每爬一层就用 document.querySelectorAll(sel).length === 1 验证唯一性,拿到最短唯一 CSS 路径就停。同时附赠完整 XPath 兜底。

4. 结构化打包。 每个拾取元素产出一条 JSON:cssSelector、xpath、tag、id、classes、textSnippet(文本前 80 字,源码定位首选特征)、outerHTML(前 500 字)、computedStyle(display/字体/颜色/边距等关键项)、boundingRect(位置尺寸)、页面 URL 和拾取时间。模型改哪里、改什么,零歧义。

中间有个小改进值得说。第一版是单击拾取,结果页面上所有链接全部失效——我想点导航看看效果都点不了。改成双击拾取之后,单击保留页面原生交互,双击才进拾取。一行事件绑定的差别,可用性天差地别。

实战:命令就这几条,线上站当场演示

完整 SOP 五步走:

1. browser_navigate 打开目标页(任意 URL,线上站也行)
2. browser_evaluate 注入 picker.js 全文 → 页面右上角出面板
3. 悬停蓝框 → 双击拾取(可多点)→ 面板「复制 JSON」
   或 browser_evaluate 读 window.__elementPicks 落盘
4. JSON 粘进任务卡 → 按 cssSelector + textSnippet 在源码里 Grep 定位
5. 改 → 实跑验证 → playwright 截图前后对比

光说不练假把式。写这篇文章的时候,我当场拿自己的线上博客(www.wdmeng.cn)演示了一遍。这是注入前的页面:

注入拾取器,圈两个元素——首页大标题 h1 和"AI项目展示"板块的 h2:

面板右上角实时显示"元素拾取器 (2)",两个元素绿框标记。这是从 window.__elementPicks 读出来的真实 JSON【实测:本文写作时实拍】:

{
  "index": 1,
  "tag": "h1",
  "cssSelector": "h1",
  "xpath": "/html[1]/body[1]/main[1]/div[1]/div[3]/div[1]/h1[1]",
  "textSnippet": "野生码农 · AI 实战派 把每一次踩坑写成可复用资产",
  "boundingRect": { "x": 139, "y": 244, "width": 630, "height": 194 }
},
{
  "index": 2,
  "tag": "h2",
  "cssSelector": "div:nth-of-type(2) > div:nth-of-type(1) > h2",
  "xpath": "/html[1]/body[1]/main[1]/div[2]/div[1]/h2[1]",
  "textSnippet": "AI项目展示",
  "boundingRect": { "x": 165, "y": 863, "width": 119, "height": 42 }
}

配套制度:工具快没用,流程得快

拾取器上岗第一天就引发了一场翻车。第一张改单——删掉两个圈选好的板块——团队走了完整派单链:立项、写任务卡、派岗、执行、回收。结果是对的,但全程跑了 394 秒(自报:当日复盘稿计时)。

我当场发飙:元素坐标我都给你了,还走全链,等于点一碗面先开后厨评审会。当天就把规则写进了团队章程:

微改单快车道(优先级高于全链):同时满足三条,主管直接改,禁写卡、禁派岗,全程 ≤20 秒——

1. 单文件改动;
2. 改动点已由我精确定位(拾取 JSON / 明确文案 + 位置);
3. 纯删改文案/样式/区块,无新逻辑、无数据契约。

规则入库后的第二张单,把导航里的"AI资讯"提到第一位并切换默认高亮,秒级完成。

这是比脚本本身更值钱的一条经验:工具把定位精度打满之后,流程必须跟着瘦身,否则省下来的时间全被流程吃回去。

优劣对照:跟千问办公比,跟 Kimi Code 2.0 比

先说清楚,这个工具的交互灵感来自千问办公,我不贪这个功。但三个方案的差异值得摆出来:

我的版本短板也明牌:每次页面跳转后要重新注入;SPA 动态渲染的元素以拾取时刻的 DOM 为准;iframe 跨域元素选不了;体验封装肯定不如官方桌面端漂亮。

但它的长处恰好是产线最需要的:JSON 是结构化、可落盘、可流转的——进任务卡、进 git、进复盘,全程留痕。官方做的是"人和 AI 的交互体验",我做的是"AI 团队产线上的标准件",定位不一样。

经验总结:三条可以直接抄走的东西

1. 看到大厂的好交互,别馋,拆它。 核心交互往往几百行脚本就能复刻——事件捕获 + 视觉反馈 + 结构化输出,拆开每一层都是基本功。大厂做的是产品封装,你要的是产线能力,两码事。
2. 微改单快车道三判据:单文件 + 精确定位 + 无新逻辑,三条全中就直改,全程超 20 秒说明流程错了,不是手慢。
3. 物证习惯:时间戳、git 记录、实拍截图。没有这三样,"我比官方早 5 天"就是一句空话;有了这三样,它就是这篇文章。

素材点

• Kimi Code 2.0 发布同款功能,官方文档原文可作引用素材;
• 219 行脚本全文可直接开源,作 S4 技术文档篇的底子;
• 微改单快车道规则已在团队章程里跑了一周,可单独展开写一篇"AI 团队流程瘦身";
• 同源的 9-12 团队重组首测(六岗并三岗 + 28 个技能原盘复刻千问办公)另有专篇,两文可互链。