说实话，做了几年 UI 自动化，最让我头疼的不是写脚本，而是维护脚本。
开发今天改个 class，明天换个 id，后天直接把按钮位置挪了——你前一天跑得好好的用例，第二天就红成一片。
手动一条条改定位器？改到一半开发又上线了，简直血压拉满。
所以我一直在想：能不能让 AI 帮我们修脚本？
OpenAI 发布 GPT-4o 之后，我发现这事儿还真能落地。这篇文章我就拿一个真实的 Selenium 脚本举例，带你一步步写一个能自动修复元素定位失败的脚本。全程代码亲测可用，不说废话。
- 你大概需要准备什么
Python 3.8+（我用的是 3.10）
一个 OpenAI API Key（GPT-4o 需要付费，但一次调用几分钱，完全扛得住）
装几个库：
pip install openai selenium
Chrome 浏览器 + 对应版本的 chromedriver（如果你用其他浏览器同理） - 先写一个会“坏掉”的自动化脚本
我们拿百度首页做例子（只是演示，别在生产环境随便压测）。
正常情况下，百度搜索框的 name 属性是 wd，提交按钮的 id 是 su。
from selenium import webdriver
from selenium.webdriver.common.by import By
driver = webdriver.Chrome()
driver.get("https://www.baidu.com")
正常定位
search_box = driver.find_element(By.NAME, "wd")
search_box.send_keys("GPT-4o")
driver.find_element(By.ID, "su").click()
现在假设前端改版：
输入框的 name 改成了 keyword
提交按钮的 id 从 su 改成了 search-btn
如果你硬跑上面的代码，会直接抛出 NoSuchElementException。
- 第一次调用 GPT-4o：让它推荐新的定位器
当脚本报错时，我们唯一能依赖的就是页面的实时 HTML。
所以我们可以在 try...except 里捕获异常，然后把当前页面的 DOM 结构发给 GPT-4o，让它帮我们找出可用的新定位器。
3.1 封装一个函数，把当前页面源码发给 GPT-4o
from openai import OpenAI
client = OpenAI(api_key="你的密钥")
def ask_gpt_for_locator(page_source, old_locator):
prompt = f"""
你是一个 UI 自动化测试专家。
以下是一个网页的 HTML 源码，原本的元素定位器 {old_locator} 已经失效。
请根据页面当前结构，推荐一个稳定且大概率唯一的新定位器（可以是 id、name、XPath、CSS selector 中的任意一种）。
只返回定位器本身，不要多余解释。
HTML:
{page_source[:6000]} # 限制长度，节省 token
"""
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}],
temperature=0
)
return response.choices[0].message.content.strip()
这里有个小技巧：temperature 设为 0，让输出尽量确定，不给它自由发挥的空间。
3.2 写一个带自动修复的 find_element
from selenium.common.exceptions import NoSuchElementException
def smart_find_element(driver, by, value):
try:
return driver.find_element(by, value)
except NoSuchElementException:
print(f"定位失败：({by}, {value})，尝试 GPT-4o 修复...")
page_source = driver.page_source
new_locator = ask_gpt_for_locator(page_source, {by: value})
print(f"GPT-4o 建议的新定位器：{new_locator}")
# 简单解析建议的定位器（这里只做了最简处理，实际需要更鲁棒的解析）
if new_locator.startswith("//") or new_locator.startswith("("):
return driver.find_element(By.XPATH, new_locator)
elif new_locator.startswith("#") or"."in new_locator:
return driver.find_element(By.CSS_SELECTOR, new_locator)
else:
# 默认当成 id 试试
return driver.find_element(By.ID, new_locator)
用的时候只需要把原来的 find_element 替换成 smart_find_element，其余代码基本不用动。
- 完整的自动修复演示
下面我把整个流程串起来，模拟一次“改版后的百度页面”。
from selenium import webdriver
from selenium.webdriver.common.by import By
from openai import OpenAI
import time
---------- OpenAI 初始化 ----------
client = OpenAI(api_key="sk-你的密钥")
def ask_gpt_for_locator(page_source, old_locator):
prompt = f"""
当前页面 HTML 如下，原本定位器 {old_locator} 已失效。
请返回一个唯一、稳定的新定位器（推荐 XPath 或 CSS）。
只返回定位器字符串，不要加任何注释。
HTML:
{page_source[:5000]}
"""
resp = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}],
temperature=0
)
return resp.choices[0].message.content.strip()
---------- 带修复功能的查找 ----------
def smart_find_element(driver, by, value):
try:
return driver.find_element(by, value)
except NoSuchElementException:
print(f"[修复] {by}={value} 失效，请求 GPT...")
html = driver.page_source
new_loc = ask_gpt_for_locator(html, {by: value})
print(f"[GPT] 推荐: {new_loc}")
# 非常简陋的定位器类型判断，正式项目建议用正则或解析
if new_loc.startswith(('//', '(')):
return driver.find_element(By.XPATH, new_loc)
else:
# 尝试作为 CSS 处理
return driver.find_element(By.CSS_SELECTOR, new_loc)
---------- 测试用例 ----------
driver = webdriver.Chrome()
driver.get("https://www.baidu.com")
try:
# 故意传一个错误的名字，模拟改版
box = smart_find_element(driver, By.NAME, "wd") # 实际已改成 keyword
box.send_keys("GPT-4o auto repair")
btn = smart_find_element(driver, By.ID, "su") # 实际已改成 search-btn
btn.click()
time.sleep(3)
print("测试通过 ✅")
except Exception as e:
print(f"最终失败: {e}")
finally:
driver.quit()
跑一遍看看效果
当你第一次运行，Selenium 找不到 name="wd"，自动触发 GPT 请求，几秒后返回类似：
input[name='keyword']
然后程序会用 CSS Selector 重新定位，输入文字并提交——原本挂掉的用例自己活过来了。
- 踩过的一些坑（希望你避开）
GPT 偶尔会乱给定位器
比如给一个 div:nth-child(3) 这种极度脆弱的 selector。我的对策：在 prompt 里强调“唯一、稳定”，并且强制要求优先使用 id 或 name，实在没有再用 XPath 层级关系。
token 消耗比想象中快
一次请求发 5000 字符的 HTML 大概花掉 1 美分不到，但如果你跑几百个用例就不便宜了。优化策略：
只发送包含目标元素的局部 HTML（比如按钮附近的父容器）
缓存 GPT 返回的定位器，同一个页面同一个元素第二次直接从缓存取
响应速度
GPT-4o 比 4 快不少，但还是有 1~2 秒延迟。如果是 CI 流水线可以接受，但本地调试时会有点不耐烦。我一般加一个 print 提示“AI 修复中，请稍候”，用户体验会好一点。
- 还能怎么玩？
上面的例子只修复了元素定位，其实整个测试步骤都可以交给 GPT。
比如你把失败时的截图、控制台日志、页面源码一股脑发给它，然后问：“这个步骤原本想点击登录按钮，现在被一个弹窗挡住了，请给出修正后的 Python Selenium 代码。”
它真的能给你写出一段先关弹窗、再点登录的脚本——我试过，靠谱。
另一种玩法：不需要提前准备定位器。
你只要告诉 GPT “在百度首页搜索‘天气’”，它直接输出完整的 Selenium 代码。这相当于把测试用例从自然语言“编译”成自动化脚本，连元素定位这一步都省了。
- 写在最后
以前我们总说 UI 自动化维护成本高，是因为脚本是“死”的，页面是“活”的。
现在有了 GPT-4o 这种能看懂界面、能写代码的模型，脚本也可以“活”过来。
当然，这不是让你把所有的 find_element 都换成 AI 版——毕竟每次调用都要花钱、花时间。
更好的用法是：作为兜底策略。常规定位失败时，再请 GPT 出山，一次修复，永久生效（把修好的定位器存到配置文件里）。
代码我已经贴在上面了，复制下来，换成你自己的 API Key 就能跑。
如果跑不通，大概率是页面改得太离谱，或者 GPT 抽风——多试两次，或者把 prompt 改得更具体一点。
自动化测试不该是手工作坊，让 AI 帮你搬砖，省下时间干点更有意思的事吧。
