初稿 2026-09-19 研究更新 2026-09-20 风险识别 · 验收清单 Cursor / Claude Code / Copilot / Codex

前端转向 AI Coding
的常见问题全景

AI 可以快速生成一个页面,但页面是否符合设计、交互是否完整、异常是否可恢复、后续是否有人能够维护,需要不同的证据来回答。把代码生成速度直接等同于交付效率,会漏掉验证、返工和维护成本。

阅读口径 —— 文中研究数字仅描述各自样本;问题清单与验收优先级属于工程建议,不代表行业发生概率。本页是一份风险识别与验收清单,不是对所有前端项目的故障率预测。
0
类问题域
视觉 · 运行时 · 代码质量 · 安全 · 协作 · 长期能力
0
条具名风险
每条附「验收」动作,可直接进入评审流程
0
项可核查研究
替换了原稿中没有出处的精确概率
0
级风险分层
按业务后果排验收优先级,非统计排名
§ 01 — Data Base

数据底座:研究测到了什么,
又没有测到什么

以下按与前端交付的相关性排列。发布日期不等于样本采集日期,报告名称中的年份也不代表使用了当年最新模型。问卷态度、审计发现、实验基准和生产事故不能混为一谈。每张卡片的「口径边界」是原文明确写出的限制,请连同数字一起读。

EV / 012026-07-24

Design Theater — 设计说明与实际实现存在落差

24 个任务 × 5 个生成式 UI 工具,共 120 个界面。为「声称完成不等于实际完成」提供直接证据。

面向用户的设计说明未落实>25%
功能性要求未落实34%

口径边界 —— 限定任务与工具的评估,25% 的分母是设计说明,不是前端项目。不能据此推出视觉还原失败率、CSS 故障率,或所有当前模型的表现。本文引用该版本的摘要结果。

研究原文 →
EV / 022026-07 更新

designwithclaude — 截图之外的可用性问题

165 个自称 AI 生成的公开仓库中,筛出 123 个可分析的前端项目,按其确定性规则统计。

存在「阻止发布」级严重错误74%
严重无障碍错误52%
表单输入缺少标签49%
图标按钮缺少可访问名称19%

口径边界 —— 独立项目审计,样本偏向落地页、作品集和小型应用;没有人工编码对照组,不等同于完整的人工无障碍评估。「阻止发布」是审计工具的严重性分类,不能写成「74% 已经发生生产事故」。

审计结果与方法 →
EV / 032026-07-03

Is Agentic Code Review Helpful? — 有意见,不等于有有效保护

239 个仓库、10,191 个 PR,31,073 对「审查意见 × 开发者反馈」。拒绝原因包括误报、重复、超出范围、不符合开发者意图。

被接受36.4%
引发讨论7.3%
被拒绝56.3%

口径边界 —— 针对 CodeRabbit 的反馈样本,不能代表全部审查意见或全部产品。「被拒绝」也不等于技术上错误。它提示团队应检查审查意见的有效性与噪声成本,不能把「接入 reviewer」当作质量保证。

研究原文 →
EV / 042026-08-21

AI-to-AI Code Reviews — 流程规模不等于质量收益

考察同产品与跨产品审查。论文描述了审查活动与输出差异,未证明跨产品审查能降低生产缺陷。

样本:至少接受过一次 AI 审查的 AI 归因 PR248,641
该项研究未给出可比的比率型结论,因此本卡不绘比例条——只呈样本规模与研究结论方向。

口径边界 —— 上条为样本规模而非比率,故不绘成比例条。这是新近发布的研究,但其中增长趋势涉及 2025 年的数据,不能当成 2026 年最新模型的效果测试。适合作为工程流程变化的证据,而不是「让另一个模型复核就更安全」的依据。

研究原文 →
EV / 052026-01-08

Sonar《2026 State of Code》— 验证成本成为独立问题

覆盖 1,100 多名专业开发者的自报问卷。

提交代码由 AI 生成或辅助42%
并非完全信任 AI 代码96%
总是在提交前验证48%
认为审查 AI 代码比审查同事代码更费力38%

口径边界 —— 厂商组织的自报问卷结果,不是直接测得的代码缺陷率。「并非完全信任」不等于完全不信任,「未总是验证」不等于从不验证。它支持关注验证负担,但不能单独证明净生产率下降。

官方调查解读 →
EV / 062025-12-17

CodeRabbit PR 质量对比 — 异常处理值得重点检查

320 个 AI 协作 PR vs 150 个被识别为人工编写的 PR。每 PR 问题数均值 10.83 对 6.45。下图条长以「人工 = 1×」为基线,表示相对倍数,非百分比。

每 PR 问题总数≈1.7×
逻辑与正确性问题≈1.75×
错误处理与异常路径缺失≈2×

口径边界 —— 统计的是审查问题,不是全部经确认的生产 bug;按 PR 归一化不等于控制了代码量和任务难度,作者身份识别也可能出错。原稿将「2.74 倍」归入 Uplevel 总体缺陷数据属引用不准确;可核查的 CodeRabbit 页面将其用于安全问题的表述。

报告解读及局限 →

如何使用这些证据 —— 这些研究不能合并成一个统一的「AI 前端失败概率」。DORA 2025 的官方概括更适合作为组织层面的背景:AI 会放大组织已有的优势与弱点,收益取决于支撑它的工作系统(DORA 官方报告页)。下文除明确关联研究的条目外,均作为需要在本团队验证的工程风险;同类问题也会发生在人类编写的代码中,是否因 AI 使用而增加,需要对照或持续观测。

§ 02 — Risk Matrix

六类问题域 · 30 条具名风险

每条包含「风险描述」与「验收动作」两部分——验收动作可直接搬进评审 checklist。点击任意一行展开,或按风险层级筛选。宽屏下两块左右并列。带 EV/xx 引用的条目对应上方研究,其余均为需要在本团队验证的工程风险。

Filter 显示 30 / 30
A

视觉与 UI 层Visual & UI

7 项
B

浏览器与运行时Browser & Runtime

4 项
C

代码质量与正确性Code Quality & Correctness

6 项
D

安全与供应链Security & Supply Chain

4 项
E

工程流程与协作Process & Collaboration

5 项
F

个人与团队长期能力Long-term Capability

4 项
§ 03 — Triage

风险分层:按业务后果确定验收优先级

以下是建议的处理顺序,不是统计排名。团队应结合数据敏感性、影响人数、可恢复性与已有控制调整。点击任意编号可跳到上方矩阵中对应条目。

TIER 01

发布阻断

触发条件:可能泄露私密数据、造成越权,或使核心业务不可恢复。

对应问题

验收重点
权限边界、输入输出安全、恢复路径与必要的人工批准。

TIER 02

核心流程必须通过

触发条件:用户无法完成主要任务,或关键变更无法证明正确。

对应问题

验收重点
实际操作、行为测试、兼容与无障碍检查、审查证据。

TIER 03

纳入明确质量预算

触发条件:影响视觉、性能或持续维护能力。

对应问题

验收重点
设计标准、性能预算、类型与架构约束。

TIER 04

持续监测与改进

触发条件:成本、能力或协作问题逐步累积。

对应问题

验收重点
成本记录、能力观察、责任与交接机制。

同一个问题可能跨层级。例如,活动页的间距偏差与药品剂量界面的文字截断,后果不同;提示注入与恶意依赖也不能因为发生率未知,就归入低危害。

§ 04 — Defense

十条可执行的防御清单

把上面 30 条风险压缩成日常可以直接照做的十件事。每一条都对应可观察的动作,而不是态度表态。

01

先定义可观察的完成条件

将需求映射到界面行为、边界场景和验证方式。

02

提供项目真实上下文

包括实际版本、设计 token、现有组件、接口契约和架构约束。

03

要求证据对应当前产物

完成报告区分已实现、已验证和未验证,避免把旧结果用于新改动。

04

用多种检查覆盖不同风险

类型、静态分析、行为测试、视觉检查、无障碍和性能检查各有边界;测试不是唯一防线。

05

优先检查异常与恢复

让关键流程在断网、权限失效、服务错误和重复操作下仍有明确结果。

06

控制改动范围

按可独立验证的目标拆分,修改共享代码时检查受影响调用方。

07

把约束变成可执行规则

能够自动判断的事项进入 CI;文档与 prompt 负责提供背景和解释。

08

评估审查机制本身

关注有效发现、漏报与处理成本,不用评论数量衡量质量。

09

给 Agent 设置权限和停止条件

按风险限制工具与凭据,失败不收敛时保留信息并升级处理。

10

为交付与维护落实责任

记录开发、验证、返工和维护成本,确保关键模块有人理解、能够排障。

§ 05 — Measurement

如何得到本团队可信的发生率

如果要恢复「概率 × 影响」的风险矩阵,顺序不能颠倒:先明确分母,再统一口径,最后才是数字。已发现的问题比例,不等于全部真实缺陷的比例。

Step 01 / 定分母

先说清楚「按什么统计」

按任务、PR、页面还是发布统计;再统一缺陷定义、验证范围与观察窗口。分母不明时,任何百分比都无法与另一份数据比较。

Step 02 / 记字段

为每个样本记录可比字段

  • 任务类型、项目成熟度
  • 模型与工具版本、AI 参与方式
  • 改动范围、验证投入
  • 最终结果
Step 03 / 分三层统计

把「发现时机」拆开算

分别统计验收前发现的问题、上线逃逸缺陷和返工时间,并给出样本量与不确定性。三者混在一个「缺陷率」里会掩盖真正的瓶颈位置。

Step 04 / 做对照

比较前先扣除难度差异

比较使用与不使用 AI 的任务时,还要考虑任务难度、人员经验和代码量差异。只有这样,风险矩阵才能用于决定哪些任务适合自动推进、哪些需要补充证据、哪些需要人工介入。不能用精确的百分比掩盖尚未测量的判断。

§ 06 — Conclusion

让需求、实际产物和验证证据逐项对应,并把成本和责任延伸到上线之后。

现有研究提供了几条值得重视的线索:生成式 UI 的设计说明可能没有落实,公开 AI 前端项目中存在无障碍缺口,验证会消耗独立的工程成本,AI 审查也需要接受评估。这些线索支持加强交付控制,但不支持为每类前端问题编造一个统一概率。

对团队而言,最有用的升级就是上面那句话。模型与工具会变化,这套判断交付是否完成的方法仍然需要持续维护。

§ 07 — References

参考资料

全部为原文列出的可核查出处。本页所有数字均可回溯到以下条目。

01
Design Theater: A Benchmark for Generative UI,2026-07-24 版本本文使用其初始版本摘要中的评估口径,后续版本标题可能变化。
02
How accessible is AI-generated UI?页面更新于 2026 年 7 月。
04
AI-to-AI Code Reviews of GitHub Pull Requests2026-08-21。页面标注获 ESEM 2026 Emerging Results, Vision, and Reflection Papers Track 接收。
07
DORA:State of AI-assisted Software Development 2025组织放大器视角:AI 放大已有优势与弱点。
08
React:hydrateRoot · You Might Not Need an Effect官方文档,用于 B2 / B4。