Design Theater — 设计说明与实际实现存在落差
24 个任务 × 5 个生成式 UI 工具,共 120 个界面。为「声称完成不等于实际完成」提供直接证据。
口径边界 —— 限定任务与工具的评估,25% 的分母是设计说明,不是前端项目。不能据此推出视觉还原失败率、CSS 故障率,或所有当前模型的表现。本文引用该版本的摘要结果。
研究原文 →AI 可以快速生成一个页面,但页面是否符合设计、交互是否完整、异常是否可恢复、后续是否有人能够维护,需要不同的证据来回答。把代码生成速度直接等同于交付效率,会漏掉验证、返工和维护成本。
以下按与前端交付的相关性排列。发布日期不等于样本采集日期,报告名称中的年份也不代表使用了当年最新模型。问卷态度、审计发现、实验基准和生产事故不能混为一谈。每张卡片的「口径边界」是原文明确写出的限制,请连同数字一起读。
24 个任务 × 5 个生成式 UI 工具,共 120 个界面。为「声称完成不等于实际完成」提供直接证据。
口径边界 —— 限定任务与工具的评估,25% 的分母是设计说明,不是前端项目。不能据此推出视觉还原失败率、CSS 故障率,或所有当前模型的表现。本文引用该版本的摘要结果。
研究原文 →165 个自称 AI 生成的公开仓库中,筛出 123 个可分析的前端项目,按其确定性规则统计。
口径边界 —— 独立项目审计,样本偏向落地页、作品集和小型应用;没有人工编码对照组,不等同于完整的人工无障碍评估。「阻止发布」是审计工具的严重性分类,不能写成「74% 已经发生生产事故」。
审计结果与方法 →239 个仓库、10,191 个 PR,31,073 对「审查意见 × 开发者反馈」。拒绝原因包括误报、重复、超出范围、不符合开发者意图。
口径边界 —— 针对 CodeRabbit 的反馈样本,不能代表全部审查意见或全部产品。「被拒绝」也不等于技术上错误。它提示团队应检查审查意见的有效性与噪声成本,不能把「接入 reviewer」当作质量保证。
研究原文 →考察同产品与跨产品审查。论文描述了审查活动与输出差异,未证明跨产品审查能降低生产缺陷。
口径边界 —— 上条为样本规模而非比率,故不绘成比例条。这是新近发布的研究,但其中增长趋势涉及 2025 年的数据,不能当成 2026 年最新模型的效果测试。适合作为工程流程变化的证据,而不是「让另一个模型复核就更安全」的依据。
研究原文 →覆盖 1,100 多名专业开发者的自报问卷。
口径边界 —— 厂商组织的自报问卷结果,不是直接测得的代码缺陷率。「并非完全信任」不等于完全不信任,「未总是验证」不等于从不验证。它支持关注验证负担,但不能单独证明净生产率下降。
官方调查解读 →320 个 AI 协作 PR vs 150 个被识别为人工编写的 PR。每 PR 问题数均值 10.83 对 6.45。下图条长以「人工 = 1×」为基线,表示相对倍数,非百分比。
口径边界 —— 统计的是审查问题,不是全部经确认的生产 bug;按 PR 归一化不等于控制了代码量和任务难度,作者身份识别也可能出错。原稿将「2.74 倍」归入 Uplevel 总体缺陷数据属引用不准确;可核查的 CodeRabbit 页面将其用于安全问题的表述。
报告解读及局限 →如何使用这些证据 —— 这些研究不能合并成一个统一的「AI 前端失败概率」。DORA 2025 的官方概括更适合作为组织层面的背景:AI 会放大组织已有的优势与弱点,收益取决于支撑它的工作系统(DORA 官方报告页)。下文除明确关联研究的条目外,均作为需要在本团队验证的工程风险;同类问题也会发生在人类编写的代码中,是否因 AI 使用而增加,需要对照或持续观测。
每条包含「风险描述」与「验收动作」两部分——验收动作可直接搬进评审 checklist。点击任意一行展开,或按风险层级筛选。宽屏下两块左右并列。带 EV/xx 引用的条目对应上方研究,其余均为需要在本团队验证的工程风险。
布局、间距、字号、颜色、图片裁切与设计稿不一致。单张截图通过,也不能保证长内容、字体加载后或其他视口下仍然正确。当前证据不足以给出统一的「85% 失败率」或「偏差 10%–30%」。
提供设计稿、设计 token、已有组件与关键尺寸;比较实际浏览器截图,标记差异,再复查修改后的页面。使用视觉输入的模型仍需要明确的参照和检查步骤,不能把问题笼统归因于「LLM 没有视觉能力」。
修复一个页面时追加选择器、内联覆盖和重复样式,可能破坏共享组件或让后续修改越来越难预测。!important 的存在本身并不证明代码有问题,应检查其必要性和影响范围。
遵循现有样式组织方式,定位最终生效规则;共享样式变更后检查使用方。CSS Modules、Tailwind 或其他方案都需要配套约束,选型本身不能保证维护性。
固定宽度、长文本、软键盘、安全区域、横屏和触控操作可能暴露桌面预览看不到的问题。断点数量不是质量指标,内容在断点之间能否连续适配更重要。
明确目标设备与浏览器,检查代表性视口、长内容和关键触控流程;重要移动端路径做真机验证。
默认状态有了,加载、空态、错误、禁用、键盘焦点、重复提交或返回恢复却没有完成。Design Theater 的功能性要求落差与这一风险有关,但不能转换为此条目的行业发生率。
关联 EV/01 研究原文 →
按用户任务列出状态与转换条件,实际走完成功、失败、重试和取消路径。验证按钮产生的结果,而不仅是按钮是否显示。
同一产品出现多个近似 Button、Dialog 和表单实现,设计 token 与组件行为逐渐分裂。
生成前搜索现有组件,提供可运行的使用示例;评审新增组件是否确有必要。对可机器判断的导入、token 和组件使用约束,增加自动检查。
表单没有标签、图标按钮没有可访问名称、焦点难以辨认、弹窗无法通过键盘完成操作,都会让部分用户无法使用产品。前述项目审计提供了有限样本中的结构性问题证据。
关联 EV/02 审计原文 →
自动扫描结合键盘操作、焦点顺序、屏幕阅读器关键流程和减少动态效果偏好检查。自动化工具不能覆盖全部可用性问题,也不能仅凭工具分数宣布无障碍验收完成。
Agent 声称「已实现响应式」「已处理异常」「已通过验证」,实际产物却缺少相应行为,或者根本没有运行相应检查。Design Theater 直接测量了设计说明与实现之间的落差;对其他完成声明,应由团队另行采样验证。
关联 EV/01 研究原文 →
将每项要求映射到实现位置、操作步骤和可复查结果;明确区分已实现、已运行验证、尚未验证。自然语言总结不能代替产物证据。
只在一个桌面浏览器预览,无法证明目标 Safari、WebView 或旧版企业浏览器可用。兼容性需要依据具体版本判断,不能长期沿用某个 CSS 属性「一定不兼容」的固定清单。
记录最低支持版本,对关键流程执行浏览器矩阵检查;采用新能力前核对当前支持情况及回退方案。
SSR 项目的服务端输出与客户端首次渲染不同,可能导致恢复渲染、性能损失或交互问题。时间、随机值、浏览器专有 API 和两端数据不一致都是排查方向。React 官方要求将不匹配视为需要修复的错误。
关联 React 文档 →
检查首屏数据和执行边界,复现并修复 hydration 报错;不要把隐藏警告当作修复,也不要把所有逻辑移入 Effect 作为通用方案。
依赖体积、重复请求、不必要的渲染、长任务和图片策略可能使可运行页面变得迟缓。没有使用 memo 或没有为所有图片加懒加载,不应直接判为缺陷。
以代表性设备、网络和任务测量性能;比较构建体积与关键交互的前后变化,再针对瓶颈优化。预算应来自产品需求,而不是追求孤立的评分。
同一事实被复制到多个 state、旧请求覆盖新请求、卸载后资源未清理,都可能导致难以复现的界面错误。增加状态管理库并不能自动解决这些问题。
明确状态来源与所有者,区分本地交互状态、URL 状态和服务端数据;测试快速切换、请求乱序、重复操作与返回恢复。能从现有数据推导的值,避免通过 Effect 再维护一份副本。
参考 React 指南 →
局部修复可能改变共享组件、工具函数或数据契约,影响未进入当前任务视野的调用方。某类抗回归工具的出现只能说明存在需求,不能证明问题的普及率。
先复现问题,再搜索受影响调用方;为关键行为保留回归检查。验证范围随改动影响扩大,而不是只看当前页面或当前报错是否消失。
同一业务规则被多次实现,后续修改容易遗漏;反过来,过早抽象也可能增加耦合。原稿的重复率数字缺少直接对应的来源,本次不再沿用。
生成前搜索相似实现,评审业务规则是否需要统一;重复检测作为线索,不机械地追求零重复。
使用不适用于当前项目版本、路由模式或运行环境的 API,即使代码表面合理,也可能无法构建或无法按预期执行。
读取实际依赖版本与锁文件,参考匹配版本的官方文档,运行类型检查、构建和相关路径验证。不能仅凭「旧写法」判断错误,也不能假设类型检查能发现所有运行时问题。
用 any、不安全断言、忽略诊断等手段消除报错,可能让接口与实现的不一致继续存在。
检查新增类型逃逸的理由,按项目需要约束其使用;对外部输入和接口边界验证运行时数据,而不是仅依赖静态类型。
测试可能只重复实现细节,遗漏错误路径;也可能由 Agent 修改预期,使错误实现重新变绿。覆盖率高并不直接证明测试有效。
从需求和已知故障推导断言,确认关键错误出现时测试确实失败;必要时对高风险逻辑采用变异测试。测试与实现可以由同一工具生成,但仍需独立检查验收目标。
成功路径可用,不代表空数据、长文本、断网、权限失效、服务端错误和并发操作下仍然可恢复。CodeRabbit 样本中的异常路径差异支持优先检查这一类问题,不能支持原稿「85%」的概率。
关联 EV/06 报告原文 →
按输入、网络、权限、并发四类列出相关边界;检查错误反馈、重试、数据保留和操作幂等性,具体深度取决于业务后果。涉及关键交易时按「发布阻断」处理。
富文本或 HTML 渲染没有正确处理不可信输入,可能产生 XSS。不能用禁用某个 API、依赖扫描或一条 CSP 配置替代完整的数据流检查。
优先使用安全输出方式,确需 HTML 时采用经过审查的净化方案;按输出上下文处理编码,CSP 作为补充防线。
参考 OWASP XSS 指南 →
Agent 可能引入不必要的依赖,或给出错误、不存在的包名。不存在的包名被恶意注册的风险通常称为 slopsquatting,与利用拼写错误的 typosquatting 应区分。本次不保留原稿未核实的投毒事件数量或发生率。
核实包的来源、维护者和必要性,审查新增依赖、锁文件与安装脚本。包存在、能安装或有完整性校验,不等于包可信;体积问题与恶意依赖问题也应分开处理。
服务端私密密钥、长期令牌进入前端产物、日志或提交历史,可能扩大访问范围。需要区分私密凭据与设计上允许公开的客户端标识。
检查配置如何进入构建产物,使用密钥扫描,控制运行时凭据范围;真实泄露后按事件处理并撤销或轮换凭据,仅删除当前文件不够。
网页、README、issue 或工具输出中的文字可能诱导 Agent 执行偏离任务的操作。来源白名单有帮助,但「看起来可信」的来源也可能包含不可信内容。
将外部材料作为数据处理,限制工具、凭据、网络和写入范围;高影响操作使用可执行的权限控制,检查敏感输出与异常行为。不能仅靠提示词隔离解决全部问题。
参考 OWASP 提示注入指南 →
功能、重构、格式化与依赖更新混在一起,会增加审查负担。固定行数只能作为提醒,不应替代对语义复杂度和影响范围的判断。
按可独立验证的目标拆分提交,说明行为变化和验证方式;对生成文件、锁文件与业务逻辑采用不同的审查重点。
即使上下文窗口足够长,也不意味着 Agent 找到了并正确使用所有相关约束。命名、目录、错误处理和数据访问模式可能逐步偏离现有架构。
维护可检索的架构说明、组件目录和范例;将可判定的规则落到 lint、依赖边界或构建检查中,并检查跨模块变更。
生成速度提高后,如果审查和修复能力没有同步提升,未验证变更和临时实现可能积压。DORA 的组织放大器视角与 Sonar 的验证负担调查,为检查这一瓶颈提供背景,不能据此断言所有团队的技术债都在增加。
关联 EV·DORA · EV/05 Sonar
同时跟踪开发耗时、等待审查、返工和上线缺陷;给临时方案指定负责人和处理条件,而不是只记录代码产量。
重复相同修复、扩大无关改动或持续探索,可能消耗时间与调用预算,却没有增加有效信息。
配置任务预算、超时和停止条件;连续失败时要求汇总已排除假设与缺失信息,转人工处理或重新拆分任务。阈值应按任务复杂度设置。
AI 审查既可能提出有效意见,也可能重复、误报、超出范围或漏掉关键问题。审查意见数量不能作为发现缺陷能力的直接指标。
关联 EV/03 反馈研究 · EV/04 AI-to-AI
抽样评估意见有效性、遗漏、重复和处理成本;对自动批准与高影响改动设置不同门槛。换产品或换模型可以作为待评估的策略,不能假设它们的错误彼此独立。
长期委托可能减少直接练习机会,但本文所引研究不足以证明「使用三个月就明显退化」或「长期概率 80%+」。技能变化还与使用方式、原有能力和任务类型有关。
通过解释代码、定位故障、独立完成关键任务等方式观察能力;针对薄弱环节安排练习,而不是用工具使用时长推断退化。
代码被合入,但无人能说明核心数据流、约束和失败路径,后续处理问题时就容易依赖反复生成与试错。这是需要管理的责任与可维护性风险,不是已测得的统一概率。
关键模块明确负责人,保留决策理由、运行说明和排障路径;是否准许自动合入,应依据风险与验证能力,而不是仅依据代码由谁生成。
原型生成快,并不直接代表从需求到稳定交付的总成本降低。原稿引用的「43,000 美元重构、11,000 美元 MRR」案例缺少可核查出处,本次删除。
将实现、审查、返工、调用费用与后续维护放在同一口径下比较;记录收益和成本,避免只统计节省的输入时间。
非工程角色快速生成原型后,如果功能边界、数据来源、权限和维护责任不清楚,工程团队会承担额外识别与改造成本。
建立原型交接清单,标明真实功能、模拟数据和未验证部分;评估可保留、需改造和需重建的模块,不以代码行数或生成工具直接决定是否重写。
— 当前筛选下无匹配项 —
以下是建议的处理顺序,不是统计排名。团队应结合数据敏感性、影响人数、可恢复性与已有控制调整。点击任意编号可跳到上方矩阵中对应条目。
触发条件:可能泄露私密数据、造成越权,或使核心业务不可恢复。
验收重点
权限边界、输入输出安全、恢复路径与必要的人工批准。
触发条件:用户无法完成主要任务,或关键变更无法证明正确。
验收重点
实际操作、行为测试、兼容与无障碍检查、审查证据。
触发条件:影响视觉、性能或持续维护能力。
验收重点
设计标准、性能预算、类型与架构约束。
触发条件:成本、能力或协作问题逐步累积。
验收重点
成本记录、能力观察、责任与交接机制。
同一个问题可能跨层级。例如,活动页的间距偏差与药品剂量界面的文字截断,后果不同;提示注入与恶意依赖也不能因为发生率未知,就归入低危害。
把上面 30 条风险压缩成日常可以直接照做的十件事。每一条都对应可观察的动作,而不是态度表态。
将需求映射到界面行为、边界场景和验证方式。
包括实际版本、设计 token、现有组件、接口契约和架构约束。
完成报告区分已实现、已验证和未验证,避免把旧结果用于新改动。
类型、静态分析、行为测试、视觉检查、无障碍和性能检查各有边界;测试不是唯一防线。
让关键流程在断网、权限失效、服务错误和重复操作下仍有明确结果。
按可独立验证的目标拆分,修改共享代码时检查受影响调用方。
能够自动判断的事项进入 CI;文档与 prompt 负责提供背景和解释。
关注有效发现、漏报与处理成本,不用评论数量衡量质量。
按风险限制工具与凭据,失败不收敛时保留信息并升级处理。
记录开发、验证、返工和维护成本,确保关键模块有人理解、能够排障。
如果要恢复「概率 × 影响」的风险矩阵,顺序不能颠倒:先明确分母,再统一口径,最后才是数字。已发现的问题比例,不等于全部真实缺陷的比例。
按任务、PR、页面还是发布统计;再统一缺陷定义、验证范围与观察窗口。分母不明时,任何百分比都无法与另一份数据比较。
分别统计验收前发现的问题、上线逃逸缺陷和返工时间,并给出样本量与不确定性。三者混在一个「缺陷率」里会掩盖真正的瓶颈位置。
比较使用与不使用 AI 的任务时,还要考虑任务难度、人员经验和代码量差异。只有这样,风险矩阵才能用于决定哪些任务适合自动推进、哪些需要补充证据、哪些需要人工介入。不能用精确的百分比掩盖尚未测量的判断。
让需求、实际产物和验证证据逐项对应,并把成本和责任延伸到上线之后。
现有研究提供了几条值得重视的线索:生成式 UI 的设计说明可能没有落实,公开 AI 前端项目中存在无障碍缺口,验证会消耗独立的工程成本,AI 审查也需要接受评估。这些线索支持加强交付控制,但不支持为每类前端问题编造一个统一概率。
对团队而言,最有用的升级就是上面那句话。模型与工具会变化,这套判断交付是否完成的方法仍然需要持续维护。
全部为原文列出的可核查出处。本页所有数字均可回溯到以下条目。