Selenium + 用于 Web 测试自动化的 AI：更快的测试设计、更智能的调试和更可靠的 UI 覆盖范围
简介
Selenium 在几次时尚的葬礼中幸存下来。每隔几年就会有人宣布经典的浏览器自动化太脆弱、太慢、太旧、与选择器联系太紧密、维护起来太烦人，因此准备被更新、更闪亮、更有可能出现在会议主题演讲中的东西所取代。然而，团队仍然使用 Selenium，原因很简单：它不断解决实际产品中的实际交付问题。
在人工智能时代更是如此。
人工智能不会使 Selenium 过时。当它应用在正确的地方时，它会使 Selenium 更加有用。浏览器驱动程序仍然执行其一贯操作：打开页面，单击该内容，等待状态更改，读取结果，并在 UI 撒谎时大声失败。改变的是该循环周围的一切。人工智能帮助团队更快地编写测试初稿，将需求转化为覆盖思路，更智能地生成和修复定位器，总结故障，建议缺失的断言，并减少通常会耗尽测试套件精力的无聊维护工作。
这就是本文的核心思想。 Selenium 和人工智能不是竞争对手。他们坐在不同的层。 Selenium 仍然是执行引擎。人工智能成为围绕规划、创作、分类和控制治疗的加速层。
如果你保持这种分离干净，这种组合就会真正富有成效。如果你过于模糊它并期望模型神奇地“拥有QA”，那么你会在更好的包装中遇到混乱。
本文将介绍这种组合的工作原理、人工智能在哪些方面最有帮助、哪些工具适合这项工作、它能很好地解决哪些类型的案例、局限性在哪里，以及初学者如何使用真实代码构建一个小型但值得尊敬的人工智能辅助 Selenium 工作流程。
AI 真正加速 Selenium 的地方
第一个有用的事实是，人工智能使浏览器计时模型完好无损。 Chrome 仍以浏览器速度启动。点击仍然遵循浏览器计时。等待网络响应仍然是等待网络响应。
真正的加速发生在浏览器周围的工程循环中。
第一个循环是测试设计。团队通常花费更多时间将需求、支持票证和错误报告转换为具体的测试场景，而不是编写最终断言。 AI擅长将一段产品行为转化为场景、边缘案例和负面路径的初稿。强大的工程师仍然会审查和重塑输出，但空白页面消失得更快。
第二个循环是定位器创作和修复。前端团队重命名类、移动容器、将按钮包装在三个新层中，并将自动化套件与昨天的选择器一起留在雨中。人工智能可以帮助从 DOM 片段和意图描述（例如“主要结帐按钮”或“帐户创建表单内的电子邮件输入”）生成候选选择器。与审查门一起使用，可以节省时间而不放弃控制权。
第三个循环是故障分类。一次不稳定的测试失败了，团队必须快速回答五个问题。 UI 改变了吗？环境变慢了吗？选择器是否过时？断言有错吗？产品真的坏了吗？人工智能在将日志、屏幕截图、DOM 片段和堆栈跟踪转化为简短的技术假设列表方面非常有用。这就是节省大量实际时间的地方。
第四个循环是覆盖范围扩大。一旦存在稳定的快乐路径测试，人工智能就可以帮助提出相邻的覆盖范围：空状态、无效凭据、禁用按钮、区域设置变化、权限差异、超时处理和多步回滚行为。当团队的职能范围广泛而人力注意力有限时，这尤其有用。
第五个循环是报告。原始测试报告通常是正确的，但同时也没有什么帮助。人工智能可以总结故障集群的业务含义，对相似的错误进行分组，并告诉团队哪些故障可能具有相同的根本原因。这并不能取代工程诊断。它使诊断从一个更好的地方开始。
因此，当人们问人工智能是否使 Selenium 更快时，诚实的答案是：它很少使浏览器更快，但它常常使浏览器周围的团队更快。
为什么 Selenium 和 AI 能够很好地协同工作
Selenium 是最强的，其中行为必须针对真实的浏览器和真实的 DOM 进行验证。当模糊性、重复性或大量语言输入减慢人类的速度时，人工智能最为强大。
这种配对比一开始听起来更健康。
Selenium 提供了决定论。它为您提供显式等待、元素状态检查、导航控制、屏幕截图、浏览器控制台访问以及通过 Selenium Grid 的远程执行。它是严格的、固执的、字面意义上的。这些都是测试执行者的良好品质。
人工智能提供弹性。它有助于解释混乱的需求、嘈杂的日志、编写薄弱的错误单、不稳定的定位器描述以及不完整的测试初稿。这些都是纯决定论变得昂贵的领域。
换句话说，当必须精确执行路径时，Selenium 非常出色。当路径必须首先被理解、扩展或修复时，人工智能就非常出色。
这就是为什么最有用的架构通常不是“人工智能取代 Selenium”。它是“人工智能准备、协助和诊断；Selenium 执行和验证。”
一旦将这种分离构建到堆栈中，组合系统就会变得更容易信任。
这种组合最能解决的情况
某些用例比其他用例更受益于人工智能辅助 Selenium。一个强有力的案例是大的UI表面且频繁更换外观。产品团队重构布局的速度通常比重构行为的速度快。结账依然结账。登录名仍然登录。表仍然过滤。但 DOM 的变化足以打破脆弱的测试。 AI 辅助定位器修复、DOM 解释和更智能的选择器生成可以节省大量维护时间。
另一个很好的案例是从产品语言而不是QA语言构建的回归覆盖率。创始人、产品经理、支持工程师和销售团队用人性化的语言描述错误。 “有时，当我回到购物车后，折扣就会消失。” “如果用户切换标签，则无法完成入门。” “角色的转变并没有完全传播。”人工智能可以将这些语言繁重的报告转化为更清晰的 Selenium 场景，比每次从头开始的速度更快。
第三个强有力的案例是嘈杂套件中的故障分类。如果夜间套件在十二个地方出现故障，人工智能层可以对这些故障进行聚类，检查其痕迹，比较屏幕截图，并建议哪三个可能是同一产品问题。这降低了早晨分诊的成本。
第四个好案例是围绕表单和权限的覆盖范围扩展。这些领域通常会产生数十种变体：必填字段、无效组合、服务器端错误状态、基于角色的可见性、区域设置格式以及不寻常但昂贵的业务路径。人工智能擅长枚举这些组合并帮助团队避免明显的盲点。
第五种情况是压力下的原型自动化。在整个系统完善之前，构建概念验证或验证有风险的产品路径的团队通常需要测试覆盖率。人工智能可以帮助更快地建立第一个有用的自动化层，而 Selenium 仍然处理真正的浏览器行为。
当 UI 很小、稳定并且已经被简单的测试很好地覆盖时，这种组合就不那么有吸引力了。当团队想要完全外包判断时，它的吸引力也会降低。当团队仍然想要工程所有权时，人工智能辅助自动化效果很好。当团队想要魔法时，它的效果很差。
通常重要的工具
工具堆栈不需要很奇特。
从核心来看，您仍然需要 Selenium 4 和严格的测试工具，例如 pytest、JUnit 或 TestNG。对于分布式执行，Selenium Grid 仍然是自然的选择。对于报告，团队通常可以很好地使用 Allure 或类似结构的 HTML 报告层。对于浏览器驱动程序设置，webdriver-manager 或等效环境控制使设置保持可预测。
AI层可以是轻量级的。在许多团队中，它只是一个薄弱的内部助手，它将受限提示发送到 LLM API 或本地模型，并期望得到结构化的 JSON 响应。特别是对于定位器修复，Healenium 是 Selenium 生态系统中的一个已知选项，即使您决定构建自己的较窄版本，也对研究很有用。主要的教训不是“安装一个神奇的工具”。主要的教训是“如果你让系统建议修复，请强制它解释修复并保持人类对升级的控制。”
支持资产也很重要。良好的人工智能辅助 Selenium 设置通常会存储：
- DOM 故障点周围的快照
- 屏幕截图
- 浏览器控制台日志
- 网络计时提示
- 每个关键步骤的用户意图的清晰文字描述
最后一项被低估了。当失败的步骤带有诸如“完成购买的主按钮”和 UI 之类的意图时，人工智能的工作效果会更好。意图将死选择器变成可恢复指令。
保持诚实的实用架构
最健康的建筑以最好的方式是无聊的。
您以通常的规范风格编写 Selenium 测试：页面对象或组件、显式等待、稳定断言、可重用帮助程序、清晰的测试数据和良好的命名。然后，围绕这个稳定的核心，你可以在三个地方添加狭窄的人工智能辅助。
第一名是剧本起草。给定需求或错误报告，人工智能会生成候选场景。这些不会直接执行。他们去找一个认可或重塑他们的人。
第二位是定位器建议。当选择器失败时，系统可以将 DOM 片段加上人类可读的步骤意图发送到模型，并请求候选选择器的简短列表。结果将被审查、记录并可选择接受。
第三位是失败总结。该模型查看测试元数据、日志、跟踪和屏幕截图，并返回结构化的假设列表，而不是模糊的段落。
注意图案。人工智能被用在不确定性的边缘。 Selenium 停留在执行点。
这才是值得保留的架构。
代码：干净的 Selenium 基线
在添加人工智能之前，有必要先展示一下基线。如果底层的 Selenium 代码是混乱的，那么 AI 层只会让混乱变得更快。
下面是一个小的 DOM 示例，用于具有显式等待和页面对象规则的登录流程。```python from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC
class LoginPage: def init(self, driver, base_url: str): self.driver = driver self.base_url = base_url.rstrip("/") self.wait = WebDriverWait(driver, 10)
def open(self) -> None:
self.driver.get(f"{self.base_url}/login")
def fill_email(self, email: str) -> None:
field = self.wait.until(
EC.visibility_of_element_located((By.NAME, "email"))
)
field.clear()
field.send_keys(email)
def fill_password(self, password: str) -> None:
field = self.wait.until(
EC.visibility_of_element_located((By.NAME, "password"))
)
field.clear()
field.send_keys(password)
def submit(self) -> None:
button = self.wait.until(
EC.element_to_be_clickable((By.CSS_SELECTOR, "button[type='submit']"))
)
button.click()
def success_banner_text(self) -> str:
banner = self.wait.until(
EC.visibility_of_element_located((By.CSS_SELECTOR, "[data-test='login-success']"))
)
return banner.textdef test_login_happy_path(driver, base_url): page = LoginPage(driver, base_url) page.open() page.fill_email("user@example.com") page.fill_password("correct-horse-battery-staple") page.submit()
assert "Welcome back" in page.success_banner_text()
## 代码：带有审查门的人工智能辅助定位器修复
现在我们添加了一个经过精心限制的人工智能助手。我们的目标不是让模型在黑暗中默默地重写你的套件。目标是让它在已知步骤失败时建议候选选择器。
下面的函数采用人类可读的步骤意图和 DOM 片段，向 AI 层请求结构化选择器候选者，验证它们，并返回在浏览器中真正解析的第一个选择器。```python
from __future__ import annotations
from dataclasses import dataclass
from selenium.webdriver.common.by import By
from selenium.common.exceptions import NoSuchElementException
from typing import Iterable
import json
@dataclass
class SelectorSuggestion:
css: str
reason: str
def call_llm_for_selectors(step_intent: str, dom_excerpt: str) -> list[SelectorSuggestion]:
"""
Replace this stub with your chosen provider.
The only contract that matters is a strict JSON response:
{
"suggestions": [
{"css": "button[data-test='checkout']", "reason": "stable data attribute"},
{"css": "form button[type='submit']", "reason": "submit button inside target form"}
]
}
"""
fake_response = {
"suggestions": [
{
"css": "[data-test='checkout-submit']",
"reason": "Most stable explicit test selector"
},
{
"css": "button[type='submit']",
"reason": "Generic submit fallback"
}
]
}
payload = json.loads(json.dumps(fake_response))
return [SelectorSuggestion(**item) for item in payload["suggestions"]]
def validate_selector(driver, css: str) -> bool:
try:
driver.find_element(By.CSS_SELECTOR, css)
return True
except NoSuchElementException:
return False
def resolve_selector_with_ai(driver, step_intent: str, dom_excerpt: str) -> SelectorSuggestion | None:
for suggestion in call_llm_for_selectors(step_intent, dom_excerpt):
if validate_selector(driver, suggestion.css):
return suggestion
return None
```以下是如何在关键点击时使用它：```python
from selenium.webdriver.common.by import By
from selenium.common.exceptions import NoSuchElementException
def click_checkout(driver, dom_excerpt: str) -> None:
primary_selector = "[data-test='checkout-button']"
try:
driver.find_element(By.CSS_SELECTOR, primary_selector).click()
return
except NoSuchElementException:
pass
suggestion = resolve_selector_with_ai(
driver=driver,
step_intent="Primary button that completes checkout",
dom_excerpt=dom_excerpt,
)
if suggestion is None:
raise AssertionError("Checkout button not found and no valid AI repair was produced.")
# Review gate: log the repair before you accept it permanently.
print(f"[AI selector repair] {suggestion.css} :: {suggestion.reason}")
driver.find_element(By.CSS_SELECTOR, suggestion.css).click()
```这是重要的部分：AI建议**用作恢复机制**，而不是作为隐形突变引擎。它产生了一个候选人。浏览器验证候选人。团队记录了原因。稍后，人们可以决定修复后的选择器是否应该成为套件中新的规范选择器。
这种模式可以让你在不放弃控制的情况下加快速度。
## 代码：在编写测试之前使用 AI 扩展场景
另一个有用的应用是将特征语言转化为场景候选。
不要从空白文档开始，而是向人工智能提供简短的功能摘要并要求结构化案例。然后只有批准的案例才能成为真正的Selenium测试。```python
import json
def generate_case_matrix(feature_description: str) -> list[dict]:
"""
In production this would call an LLM and demand a strict schema.
We keep the example deterministic here.
"""
response = {
"cases": [
{
"name": "valid_login",
"goal": "User signs in with valid credentials",
"priority": "high"
},
{
"name": "locked_account",
"goal": "User sees the correct message for a locked account",
"priority": "high"
},
{
"name": "password_reset_link",
"goal": "User can navigate from login to password reset",
"priority": "medium"
},
{
"name": "throttle_after_many_attempts",
"goal": "UI communicates rate limiting after repeated failures",
"priority": "medium"
}
]
}
return response["cases"]
feature_text = (
"The login page allows email and password sign-in, reports locked accounts, "
"links to password reset, and throttles repeated invalid attempts."
)
for case in generate_case_matrix(feature_text):
print(f"{case['priority'].upper()} :: {case['name']} :: {case['goal']}")
```这是在测试自动化中使用人工智能最不受争议的方法之一。该模型没有接触浏览器。它正在帮助团队更广泛、更快地思考。
## 加速团队通常会看到多少
这是人们常常过于简单化的部分。
人工智能很少能提供一种干净、通用的乘数。真正的收益取决于套件的成熟度、产品领域的清晰度、UI的稳定性、团队的审查纪律，以及人工智能是否正在解决真正的瓶颈，或者只是因为有人想要“人工智能测试策略”而被钉在流程上。
在实践中，最大的收益通常体现在：
- 场景初稿生成
- 重复的定位工作
- 片状故障分类
- 总结嘈杂的报告
- 将产品语言错误转变为自动化候选者
在已经稳定、精心设计的套件中，收益通常不大，而在混乱的中期增长环境中收益则要大得多，在这种环境中，UI 经常发生变化，并且非自动化行为的积压量很大。
一种有用的表述方式是：人工智能通常会在节省机器时间之前节省**工程注意力**。一旦你明白了这一点，期望就会再次变得理智。
## 您应该遵守的限制
当团队忘记什么应该保持确定性时，人工智能辅助的 Selenium 就会变得危险。
断言应该保持清晰和明确。模型不应该事后发明“好”的含义。元素相互作用应该仍然是可观察和可再现的。关键路径的测试数据不应该随便猜测。并且修复系统不应该在未经审查的情况下默默地批量重写选择器。
还有一个更人性化的限制。人工智能可以非常快速地产生许多看似合理的测试想法。合理并不等于重要。一个薄弱的团队可能会淹没在看似富有成效的“覆盖范围”中，却忽视了真正的业务风险。强大的团队使用人工智能来减少机械工作并保留对重要事情的判断力。
这就是加速和戏剧之间的真正界限。
## 实用的入门堆栈
如果您想以规范的方式构建它，一个小的入门堆栈通常就足够了：
- Selenium 4
- UI
- webdriver-manager 或 CI 中稳定的驱动程序配置
- Allure 或等效的报告层
- 一个微小的内部人工智能助手，返回严格的 JSON
- 保存失败步骤的 DOM 片段和屏幕截图
- 用于定位器维修和测试用例升级的手动审查门
在围绕它构建更大的框架之前，该堆栈足以证明其价值。
## 初学者的实践任务
如果您是 Selenium 和人工智能辅助测试自动化的新手，请不要从巨大的商业流量开始。从一个可教导的小目标开始。
使用演示站点或内部非关键环境并执行以下操作：
1. 构建一个稳定的 Selenium 登录或搜索测试。
2. 编写一个页面对象，而不是将选择器直接放入测试中。
3. 添加显式等待，使测试连续五次可靠通过。
4. 测试失败时保存页面HTML。
5. 添加一个助手，它接受失败的步骤描述以及保存的 DOM 摘录，并返回两个或三个候选 CSS 选择器。
6. 使用选择器之前，请在浏览器中验证这些选择器。
7. 记录选定的修复并手动决定它是否应成为新的官方定位器。
你的工作不是“让人工智能做QA”。您的工作是了解人工智能在哪些方面可以减少摩擦而不降低可靠性。
如果您想要具体的挑战，请尝试以下操作：
### 初学者练习
构建一个自动化流程：
- 打开登录页面，
- 尝试登录，
- 检测到原始提交选择器已被故意破坏，
- 使用人工智能建议存根来寻找替代选择器，
- 完成点击，
- 并在测试输出中记录修复原因。
然后回答这些问题：
- 修复是否节省了时间？
- 建议的选择器实际上更好吗？
- 如果没有审查，你会相信它吗？
- 流程的哪一部分感觉是确定性的，哪一部分感觉是概率性的？
这些答案教导了十多篇关于“QA 中人工智能的未来”的含糊博客文章。
## 结论
当Selenium和人工智能被允许做它天生擅长的工作时，它们就能很好地协同工作。
Selenium 应该继续拥有执行、等待、断言、浏览器行为和可重现的验证。人工智能应该帮助起草、扩展、解释、修复和总结。这种划分使系统保持有用并保持团队诚实。
回报是真实的。你写初稿的速度更快。您可以更快地从 UI 漂移中恢复。您可以更快地对故障进行分类。您可以更智能地扩大覆盖范围。而且您无需假装模型已成为您的 QA 领导。
这就是这个故事的成熟版本。不是神奇的自动化。更好的工程优势。
在真正的软件团队中，使用是推动工作的动力。
## 当系统已经处于压力下时会是什么样子
在团队希望季度安静的时刻，人工智能辅助的selenium自动化往往变得紧迫。一项功能已经呈现在客户面前，或者一个平台已经具有内部依赖性，并且系统选择了特定的一周来揭示其优雅的理论和运行时行为已经礼貌地分开生活。这就是为什么这么多严肃的工程工作都是从协调开始的。团队需要将其认为系统所做的事情与系统在负载、变化和截止日期下实际所做的事情相协调，这会让每个人都稍微更有创造力，但稍微不那么明智。
在网络产品交付中，最重要的情况通常是持续 UI 流失下的结账流程、基于角色的管理门户以及具有分支状态的长入职表单。这些情况会带来技术、预算、信任、路线图，有时甚至是声誉后果。当多个团队依赖技术问题并且没有人能够完全解释为什么它不断产生噪音、延迟和成本时，技术问题在政治上就会变得更大。这就是为什么我们建议从运营压力和交付现实的角度来看待这个问题。设计可能在理论上很漂亮，但在操作上却是毁灭性的。另一种设计可能几乎是无聊的，但却可以使产品继续前进多年，因为它是可测量的、可修复的，并且诚实地进行权衡。认真的工程师学会更喜欢第二类。它减少了史诗般的演讲，也减少了紧急回顾，每个人都用被动语态说话，没有人记得谁批准了这条捷径。
## 始终如一的实践
第一个持久的做法是不断衡量一条有代表性的路径。团队通常会在定义将改变决策的信号之前收集广泛的遥测数据。选择真正重要的道路，反复衡量，拒绝让讨论变成装饰性的故事讲述。在围绕人工智能辅助 Selenium 自动化的工作中，有用的衡量标准通常是场景起草质量、定位器修复置信度、故障聚类准确性和每个冲刺的覆盖范围增长。一旦这些决定变得可见，其余的决定就会变得更加人性化，不再那么神秘。
第二个持久的做法是将证据与承诺分开。在系统得出结论之前，工程师常常被迫说方向是正确的。抵制这种压力。首先建立一个狭义的证明，尤其是当主题与客户或金钱密切相关时。经过验证的小改进比未经验证的大目标具有更大的商业价值。这听起来很明显，直到季度末审查将假设变成最后期限，并且整个组织开始将乐观情绪视为日程安排工件。
第三个持久的做法是用所有权语言撰写建议。一段说“提高绩效”或“加强界限”的段落在情感上令人愉快，但在操作上毫无用处。一个段落说明了谁更改了什么、按什么顺序、在什么回滚条件下更改，这些内容实际上在周一早上仍然存在。这是很多技术写作失败的地方。它希望听起来先进，而不是可调度。
## 节省时间的反例
当地的成功并不能证明已经准备好迎接更艰难的环境。在扩展这个想法之前，团队必须升级测量规则并证明相同的行为在更大的压力下仍然存在。
另一个反例是工具通货膨胀。一个新的分析器、一个新的运行时、一个新的仪表板、一个新的代理、一个新的自动化层、一个承诺协调旧包装器的新包装器。这些事情本质上都不是坏事。问题是当他们被要求补偿一个没有人明确命名的边界时会发生什么。然后，系统就会变得更加仪器化、更加令人印象深刻，并且只是偶尔更容易理解。团队很快就能感受到这一点。即使没有这样的措辞，他们也能察觉到堆栈何时成为决策的昂贵替代品。
第三个反例是将人工审查视为自动化的失败。在实际系统中，人工审查通常是保持自动化在商业上可接受的控制措施。成熟的团队知道在哪里积极自动化以及在哪里保持批准或解释可见。不成熟的团队希望机器做所有事情，因为“一切”在幻灯片中听起来都很高效。然后第一个严重事件到来，突然之间，带着转换体验的诚意重新发现了手动审核。
## 我们推荐的交付模式
好的工作首先是通过足够强大的技术阅读来减轻压力，以阻止循环辩论。下一个有界实施改进了一条重要路径，并且复测使工程和领导层能够清楚地了解方向。这个顺序比确切的工具选择更重要，因为它将技术技能转化为前进的动力。
实际上，我们建议缩小第一个周期：收集工件，产生一个硬诊断，发布一个有限的更改，复测真实路径，并用简单的语言编写下一个决策。简单的语言很重要。团队很少会后悔清晰度。团队常常会在收据到达之前后悔给自己留下了深刻的印象。
这也是语气很重要的地方。强大的技术工作听起来应该像以前遇到过生产一样。冷静、精确、精确地进行权衡和证据。该音调携带操作信号。它表明该团队了解系统工程的古老真理：机器速度很快，路线图很脆弱，迟早要为每一个允许保持诗意的假设付出代价。
## 在准备就绪之前我们将使用的清单
在网络产品交付中，准备就绪不是一种情绪。这是一个带有后果的清单。在我们称人工智能辅助的Selenium自动化工作已准备好进行更广泛的推广之前，我们希望以尽可能最好的方式让一些事情变得无聊。我们想要一条在代表性负载下表现可预测的路径。我们想要一组不矛盾的测量结果。我们希望团队知道边界在哪里以及打破它意味着什么。我们希望工作的输出足够清晰，以便实施室之外的人仍然可以从中做出正确的决定。
该清单通常涉及场景起草质量、定位器修复置信度、故障聚类准确性以及每个冲刺的覆盖率增长。在昂贵的意外事件投入生产之前，使用该清单来测试解释质量、现场弹性和回滚清晰度。
这也是团队发现他们是否正在解决真正的问题或只是在其周围排练能力的地方。许多技术努力都感觉很成功，直到有人要求提供可重复性、生产证据或会影响预算的决定。在那一刻，弱的工作变得模糊，而强的工作变得异常简单。平淡就好。平淡通常意味着系统已经不再依赖魅力。## 我们建议如何谈论结果
最终的解释应该足够简短，以便在领导会议上通过，并且足够具体，以便在工程审查中通过。这比听起来更难。过于技术性的语言隐藏了顺序。过于简化的语言隐藏着风险。正确的中间立场是以一种听起来平静而不是胜利的方式描述路径、证据、有限的变化以及下一步建议的步骤。
我们推荐这样的结构。首先，说明评估了什么路径以及它为何重要。其次，说出该路径的错误或不确定之处。第三，说明更改、测量或验证的内容。第四，说出尚未解决的问题以及下一步投资将购买什么。这种结构之所以有效，是因为它尊重工程和购买行为。工程师想要细节。团队需要排序。当下一步明确时，每个人都会受益。
以这种方式说话的隐藏好处是文化。清楚地解释技术工作的团队通常也会更清楚地执行它。他们不再将模糊性视为复杂性。他们变得更难用行话打动人心，而更容易通过困难的系统获得信任。这是工程成熟度中最被低估的形式之一。
## 我们仍然拒绝伪造的内容
即使在系统改进之后，成熟的团队也会在网络产品交付中保持不确定性。弱测量需要更清晰的证据，硬边界需要简单的语言，更平静的演示需要真正的操作准备。必须减少一些不确定性；有些必须诚实地命名。令人困惑的是这两项工作是如何令人尊敬的项目变成了昂贵的寓言。
同样的规则适用于有关人工智能辅助 Selenium 自动化的决策。如果团队仍然缺乏可重复的基准、值得信赖的回滚路径或关键接口的明确所有者，那么最有用的输出可能是更明确的“否”或更窄的下一步，而不是更大的承诺。这种纪律使技术工作与其要改进的现实保持一致。
以这种方式工作会有一种奇怪的轻松感。一旦系统不再依赖乐观的故事讲述，工程对话就会变得更简单，即使工作仍然很困难。在生产中，这通常被视为一种小形式的恩典。