“AI 生成的 UI 不应该因为看起来完整而被信任。它应该因为团队检查了正确的东西而被信任。”

阅读 Niharika P. Pujari 的 #Radar 文章了解更多：https://t.co/yp4AO5v3wk

评估 AI 生成的前端代码：我们到底应该测试什么？

来源：https://www.oreilly.com/radar/evaluating-ai-generated-frontend-code-what-should-we-actually-test/ AI 现在可以仅凭一句简短的描述生成相当数量的前端代码。开发者可以要求生成一个表单、表格、模态框、设置页面或仪表盘视图，并且几乎立即得到一个看起来可用的东西。它可能编译通过、正常渲染，甚至自带几个测试。这很有用，但也带来一个问题：UI 的第一个版本看起来可能比实际的完成度更高。

前端代码往往被评判得太快。如果构建通过，界面看起来和设计稿差不多，人们很容易就认为生成的代码大体完成了。但用户界面不只是页面上组件的集合，它是一条用户必须走通的路径。它需要处理输入、状态、错误、加载、导航、焦点、响应式和无障碍访问。有些最重要的故障，在截图中根本看不出来。

这就是为什么团队需要更好的方法来评估 AI 生成的前端代码。他们需要证据来证明这个 UI 已经准备好供用户使用。

构建和渲染只是起跑线

最容易执行的检查通常也是团队最先做的检查。代码能编译吗？页面能渲染吗？控制台有明显的错误吗？组件在浏览器里显示出来了吗？这些检查很重要，但它们只是起跑线。页面可以渲染出来，但表单可能很难填完。模态框可以弹出，但焦点可能停留在它后面。生成的测试可以通过，但真实的用户流程可能是坏的。

这一点在 AI 生成的代码上尤其重要，因为产出的表面往往很光鲜。代码格式可能很规整，组件名称可能听起来合理，测试文件可能让这次改动看起来比实际完成度更高。这种光鲜会让评审者更不愿意停下来追问这个界面是否真的能用。更好的评估流程应该从一个简单的假设开始：AI 生成的前端代码只是草稿，在用户行为被检查之前都是。

从页面结构开始

在查看更复杂的行为之前，值得先检查生成的 UI 是否有合理的结构。前端评估应该包含页面的基本语义，而不只是视觉布局。

这意味着要检查代码是否在可能的情况下使用了原生 HTML。按钮通常应该是一个 button，而不是一个可点击的 div。链接应该用于导航，而不是用于表现得像按钮的操作。表单字段应该有一个与之关联的 label。这些细节很容易被忽略，因为没有它们 UI 看起来也可能正常，但它们会影响人们如何导航、辅助技术如何解读页面，以及代码将来会有多好维护。

AI 工具有时会在原生元素更合适的情况下选择通用容器。它们有时还会添加 ARIA，却没有正确使用。ARIA 是 Accessible Rich Internet Applications（可访问性富互联网应用）的缩写，是 W3C 定义的一组属性，用于在原生 HTML 不够用时帮助提升 Web 界面的可访问性。W3C 的 WAI-ARIA 概述（https://www.w3.org/WAI/standards-guidelines/aria/）是一个有用的参考。ARIA 可能很重要，但它不应该被用来替代正确的 HTML 元素。第一个评估问题应该是：生成的代码是否使用了正确的构建块？

检查键盘路径

一个有价值的前端评估应该包含通过键盘操作界面的路径。许多用户依赖键盘或类键盘的导航方式，而且键盘测试还能暴露交互模型中的问题。

最简单的测试往往最有启发性：把鼠标放到一边，尝试完成任务。如果流程变得混乱，说明生成的代码还没有准备好。你能到达重要的控件吗？焦点顺序合理吗？不使用鼠标你能打开和关闭对话框吗？对话框关闭后，焦点是否回到了一个合理的位置？

这些检查对生成的 UI 尤其重要，因为 AI 可能会产生只为最明显的鼠标操作路径有效、却在不那么明显的地方失效的交互。例如，一个自定义下拉框可能点击时能展开，在演示中看起来很完整，但它可能无法正确响应键盘输入。这不是一个无关紧要的边缘情况，它是界面是否可用的一部分。

测试焦点，而不只是点击

基于点击的测试很有用，但它们可能掩盖重要的问题。一个点击按钮并等待成功消息的测试可能会通过，即使同样的流程对键盘导航的用户来说非常让人困惑。

焦点行为值得单独关注，尤其是在用户操作之后 UI 会发生变化的情况下。例如，当表单提交失败时，不应该让用户自己去猜发生了什么。错误信息应该是可见的，在适当时应该与相关字段关联起来，并且以一种能清楚引导恢复的方式呈现。在很多情况下，焦点应该移动到第一个错误处，或者移动到一个解释哪里需要关注的错误摘要上。

同样的道理也适用于模态框。模态框打开时，焦点应该移入其中；关闭时，焦点应该返回到打开它的元素上。这些是代码中的小细节，但它们对 UI 是否感觉可预测有着巨大的影响。

评估事情出错时会发生什么

AI 生成的前端代码在“理想路径“下往往表现最好：用户正确填写了所有内容，网络响应迅速，数据结构完全符合预期，一切都没有出问题。而真实的界面大部分时间都不在那条路径上。

一个务实的评估应该检查当数据缺失、延迟、为空、无效或以出乎意料的状态返回时会发生什么。这就是我说的加载状态、错误状态和空状态。它们是界面中用来解释当理想路径出问题时正在发生什么的部分。加载状态应该帮助用户理解有事情正在进行中。错误状态应该解释出了什么问题以及用户接下来可以做什么。空状态应该清楚地表明是没有内容可显示、用户需要采取行动，还是有什么东西悄悄失败了。

这些情况很容易被推迟处理，因为理想路径通常就足以让界面看起来完成了。但用户最终会遇到不那么完美的路径。一个生成的组件可能包含了一个加载动画，仅仅因为提示词里要求了，但这并不意味着加载体验是有用的。一条错误消息可能写着“出了点问题“，却不提供任何恢复手段。评估应该包含这些情况，因为很多真实的用户体验正是在这里断裂的。

测试完整的用户流程

组件层面的检查有帮助，但它们并不总能说明全部情况。一个组件本身可以正常工作，但放在更大的流程中仍然可能失败。

这就是为什么 AI 生成的前端代码应该通过用户任务来评估。有人能开始这个流程、理解预期、从错误中恢复、成功提交，并看到之后发生了什么吗？在较小的屏幕上界面还能正常工作吗？如果用户返回、修改了某些内容、或在失败后重试，状态是否保持一致？

这时，Playwright 式的测试或其他端到端测试就能派上用场。目标不是自动化每一个可能的交互，而是保护那些最重要的流程。一个好的测试应该能判断用户是否能够完成该组件所要支持的任务。

使用无障碍检查，但不要止步于此

自动化的无障碍检查很有用，应该成为评估流程的一部分。它们可以发现缺失的 label、无效的 ARIA 使用、一些对比度问题、地标（landmark）问题以及其他常见错误。在 AI 生成代码产出速度很快时，它们尤其有帮助，因为它们能在问题演变成重复模式之前将其捕获。

但自动化检查并不是完整的无障碍审查。它们无法完全判断一个流程是否易于理解、焦点移动是否自然、或者说明文字是否清晰。通过自动化无障碍扫描并不意味着 UI 是无障碍的，它只意味着一些常见问题没有被检测出来。

最好的方法是将自动化检查与基于行为的审查结合起来。运行工具，但也要实际使用这个界面。用键盘导航。触发一个错误。试一试空状态。查看生成的代码，并思考原生 HTML 是否能承担更多工作。当无障碍评估成为正常前端质量的一部分，而不是最后的单独环节时，它的效果最好。

也要审查生成的测试

当 AI 生成代码时，它可能也会生成测试。这听起来很有帮助，但这些测试需要和代码一样认真地被审查。

生成的测试往往反映的是实现已经做了什么。它们可能会检查文本是否出现、函数是否被调用、或者组件是否被渲染。这些检查并非毫无用处，但如果它们没有测试有意义的行为，就可能制造虚假的信心。更好的审查会追问：如果 UI 出了问题，这些测试能捕捉到什么？如果校验错误信息不清晰，测试会失败吗？如果重试按钮不起作用，测试会失败吗？如果键盘导航坏了，测试会失败吗？

如果答案是否定的，那这些测试可能更多是在记录实现，而不是在保护用户体验。团队可以利用 AI 来帮助编写更好的测试，但提示词很重要。“给这个组件写测试“太笼统了。更好的请求应该说明哪些行为是重要的，比如校验恢复、加载行为、成功提交以及焦点移动。即便如此，生成的测试仍然需要人工审查。

决定什么样的证据才算充分

并不是每个 UI 变更都需要同等程度的评估。一次小的文案更新不需要和新的结账流程、引导流程或账户设置页面一样的审查。团队需要判断力。

一个有用的方法是让评估与变更的风险相匹配。如果生成的代码影响了关键的用户流程、收集了用户输入、改变了导航、引入了自定义交互或处理重要的状态消息，那就值得更深入的测试。如果它只是以熟悉的模式复用了稳定的组件，审查可以轻一些。

没有必要为每个 pull request 都创建一份检查清单；只要清楚什么样的证据算充分就足够了。对于某些变更，快速审查加组件测试可能就够了。对于其他变更，团队应该期望有键盘测试、无障碍检查、错误状态审查以及用户流程测试。关键在于，不要因为生成的代码看起来光鲜就默认它同样可信。

人工审查依然重要

AI 可以生成代码并建议测试，但它无法完全理解产品、用户或前端决策背后的权衡。它不知道哪些流程最重要、哪些交互模式用户已经在依赖、以及不一致会在哪里造成困惑。

这就是为什么人工审查仍然处于核心位置。审查者的职责是判断生成的方案是否契合系统、是否支持用户的任务。有时候这意味着接受生成的代码，有时候则意味着要求一个更简单的原生元素、复用现有的组件、改进错误恢复，或者添加一个能反映真实行为的测试。

AI 生成的代码越多，这种判断力就越重要。

当 AI 编写前端代码时，团队应该测试用户所依赖的界面部分。这包括结构、键盘访问、焦点行为、加载和错误状态、表单验证、响应式行为、无障碍检查以及完整的用户流程完成度。还包括审查生成的测试本身，确保它们保护的是行为，而不只是确认当前的实现。

目标不是拖慢 AI 辅助开发的速度，而是让它用起来更安全。如果 AI 缩短了产出初稿的时间，团队就有机会花更多时间去追问：这个软件是否真的能正常工作。

这或许才是真正的转变。在前端开发中，AI 的价值不只是更快地产出代码，而是让我们有机会把更多工程精力投入到评估、用户行为和质量上。

AI 生成的 UI 不应该因为看起来完整而被信任。它应该因为团队检查了正确的东西而被信任。

AI 使用说明

本文稿在措辞、编辑和润色部分的片段中轻度使用了 AI 辅助。文章的观点、结构、示例和最终审查均由我本人完成。

作者声明

文中表达的观点仅属作者本人，不代表我所在雇主的立场。