AI 设计产品常用“设计系统、原型、生产级代码”等词汇描述能力，但这些名词本身不是证据。严谨评估需要确认：实际发布了什么、使用了哪个产品和模型版本、输入与权限是什么、输出格式是什么，以及人类复核如何完成。本文把“Claude Design”作为一个需要核验的产品说法，而不是未经证实的发布事实。

核心要点

  • 产品名称或演示截图不能证明功能已经公开、稳定或普遍可用。
  • 视觉生成、Design Token 提取、组件生成和设计审查具有不同的失败模式，应分别评测。
  • AI 输出在通过语义、可访问性、安全、性能和可维护性检查前都只是草稿。
  • 使用固定任务和版本记录比较工具，不要引用没有实验设计的效率倍数。
  • 前端价值会更多集中在约束设计、系统集成、验证和运行时责任。

先核验产品说法，再设计工作流

当文章声称某厂商“发布了工具”或“能输出生产级 React”时，至少记录以下证据：

证据 核验问题
官方文档或发布说明 是公开版、实验版、地区限定还是邀请制？
产品与模型版本 哪个模型、编辑器、导出格式和日期生成了结果？
可复现实例 其他团队能否使用同一需求重复任务？
条款与数据政策 Prompt、截图、源代码或客户数据是否留存或用于训练？
失败行为 素材无效、API 缺失、交互不可访问或工具超时时如何处理？

不要把路线图、社交媒体帖子、生成式 Mockup 或厂商对比表直接写成稳定事实。对于变化很快的产品，带日期的来源快照比没有时间范围的绝对结论更可靠。

“AI 设计”到底指什么

这个类别包含多个不同工作流：

  1. 视觉构思：生成布局、图像或风格变体，输出可能是位图或可编辑设计文件。
  2. Design Token 提取：根据需求或现有页面提出颜色、字体、间距和组件状态，需要人工维护命名与治理。
  3. 组件生成：输出 HTML、CSS、React 或其他框架代码；代码不是语义和行为正确的证明。
  4. 原型生成：用模拟状态连接页面，可以帮助验证信息架构，却可能隐藏 API、加载、错误和授权路径。
  5. 设计审查：提示对比度、间距或一致性问题，自动结果仍需人工和辅助技术验证。

不要用同一个 Prompt 给五类能力打分；应为每类能力定义独立的验收测试。

可复现的评测 Harness

基准任务应接近真实工作，而不是只展示漂亮的 Gallery Prompt：

yaml 
task: "developer-dashboard"
constraints:
  framework: "React 18"
  styling: "existing-token-library"
  viewport: ["390x844", "1440x900"]
  requirements:
    - keyboard navigation
    - loading, empty, error, and permission-denied states
    - reduced-motion support
    - localization-ready labels
inputs:
  assets: "synthetic-fixtures-v3"
  api_schema: "orders-api-2026-01"
record:
  tool_version: "记录确切版本"
  model: "记录确切模型"
  prompt: "保存不可变 Prompt"
  human_edits: "保存审阅 diff"

用证据评价结果：

  • 任务成功：键盘和屏幕阅读器用户能否完成主流程？
  • 语义正确：标题、地标、标签、表格、对话框和错误信息是否有意义？
  • 视觉一致：不同视口和组件状态是否遵守同一 Token 体系？
  • 运行时质量：加载、取消、重试、焦点恢复和响应式切换是否正确？
  • 工程成本：需要重写多少代码，其他工程师能否理解？
  • 治理能力：能否复现、审计、确认许可证并删除生成产物？

重复运行时报告中位数和分布。一张漂亮截图不能证明稳定性，也不能支持固定的“节省多少时间”结论。

设计系统需要明确的所有者

AI 可以提出 Token，但设计系统是设计、代码、内容和产品策略之间的契约。人工所有者必须决定：

  • 哪些 Token 是语义层而非组件私有值；
  • 亮色和暗色主题如何保持对比度；
  • disabled、pending、invalid、selected 和权限受限控件有哪些状态；
  • 本地化如何处理文字长度、方向和密度变化；
  • 弃用与迁移如何记录。

把生成建议放在可审阅分支中，不要允许模型静默覆盖规范源文件，也不要让每个页面自动发明一套新的间距体系。

前端审查就是运行时审查

生成代码应与手写代码经过相同门禁：

text 
需求 → 生成草稿 → 静态检查 → 可访问性测试
    → 响应式测试 → 交互/异常路径测试
    → 安全与依赖审查 → 人工批准 → 发布

检查对话框是否管理并恢复焦点、表单错误是否被宣布、图标是否有可访问名称、状态是否不只依赖颜色、触控目标是否可用，以及是否尊重减少动态效果偏好。还要检查包体积、图片加载、水合行为、不可信 HTML、URL 处理、授权校验和遥测脱敏。“看起来正确”不是测试规格。

可落地的工作流

  1. 写明需求、约束、非目标、用户角色、数据状态和验收测试。
  2. 使用合成内容和已批准素材生成一个有边界的草稿。
  3. 要求输出决策记录：Token、假设、未决问题和依赖。
  4. 先审查语义和交互状态，再打磨视觉细节。
  5. 将最小可用切片接入现有仓库并运行项目检查。
  6. 记录 diff、缺陷、人工修改、工具/模型版本和实际复核时间。
  7. 用多个代表性任务的证据决定是否保留这条流程。

这样可以让 AI 在可靠的环节减少重复草稿工作，同时把产品和运行时责任留在工程团队。

局限与风险边界

AI 界面常见问题包括通用化视觉、凭空添加需求、缺少错误状态、不可访问控件、过时框架 API、许可证不明的素材，以及将敏感截图或源代码泄露给不合规服务。这些问题不是单靠更长 Prompt 就能解决的。

对于受监管或高风险产品，应要求数据分级、批准的服务商、留存控制、人工签署和可审计产物链。对于品牌核心页面，在验证原创性、字体、动效和本地化行为前，只把 AI 当作探索工具。

延伸阅读

总结

AI 设计工具适合在受控流程中缩短一个可测量的步骤。当产品名称、基准截图或生成组件被当作可用性、质量和安全的证明时，它就会变成风险来源。先核验事实，固定任务和版本，测试真实运行时行为，并由人类对用户最终操作的界面负责。