设计产物与AI研发闭环

定义

设计产物的形态（GUI 文件 vs 代码）直接决定了 AI Coding 的 Harness Engineering 验证闭环能否打通。当设计稿是代码（HTML/CSS），AI 可以自主预览→截屏→验证→修复；当设计稿在 Figma 等 GUI 工具中，闭环断裂，AI 每次都要等人反馈。

这是 All In Code 原则在 UI/UX 层面的具体体现。

两种场景对比

场景一：保留 Figma（设计与代码分离）

Figma 在 Java AI Coding Harness Engineering五条方法论的工具优先级中属于最底层（GUI = AI 不可用）。设计稿和代码是两套真理来源，存在 Agent时代的生产力悖论-当协作本身成为最大的瓶颈所说的"代码和文档是分离的"问题。

桥接方式：

Figma API 脚本定期导出 Design Tokens（JSON/CSS 变量）到 repo
设计稿翻译为结构化 spec（Markdown 描述而非截图）
视觉回归测试（Playwright 截屏 vs 基线图）

Monorepo 结构：

text

project-root/
  design/
    tokens.json          # Figma API 导出的 Design Tokens
    screenshots/         # 基线截图（CI 自动从 Figma 拉）
  scripts/
    sync-figma.sh        # Figma API → tokens + screenshots

问题：仍是双源（Figma + Code），需要同步。设计师和 AI 不在同一上下文中工作。

适用：有专职设计师、对视觉品质有高要求的 ToC 产品。

场景二：AI 直接生成 HTML 设计稿（设计即代码）

设计产物 = 代码，天然 All In Code。验证闭环完全打通：

text

AI 生成 HTML/CSS → 本地预览 → 截屏 → AI 看到效果 → 修改 → 再截屏 → 收敛

这与 Java AI Coding Harness Engineering五条方法论的核心论点一致：AI 能自主验证就能自主迭代。

Monorepo 结构：

text

project-root/
  web/
    src/components/      # 生产代码
    design-drafts/       # AI 生成的 HTML 高保真原型（或直接用 Storybook）
  design/
    system.md            # 设计系统规范（结构化文字描述）
    tokens.css           # 设计令牌
    patterns.md          # 交互模式规范

更激进的做法：draft 和 production 合一——AI 直接写组件，Storybook 就是设计稿，code review 就是设计评审。设计师角色从"产出设计稿"变为"定义 system.md + 审核效果"。

适用：内部工具、ToB 产品、全栈团队、追求 AI 高自主迭代的场景。

关键维度对比

维度	保留 Figma	AI 直接生成 HTML
Source of truth	双源，需同步	单源（Code）
AI 可验证性	断裂，需人截图反馈	完整闭环（截屏自动对比）
版本化	Figma 版本 ≠ Git 版本	天然 Git 版本化可 diff
迭代速度	分钟级（人工中转）	秒级（AI 自主）
视觉品质上限	高（设计师美学决策）	取决于 spec 质量和 AI 能力
Harness 友好度	低	极高

核心洞察

Figma 在 AI 研发时代的定位应收窄为"设计师的思考工具"（类似纸笔草稿），而非"研发流程的必经环节"。设计决策确定后，产出物应是 system.md 中的结构化规范，而非 Figma 链接。

告别氛围编程-Harness治理与SDD团队级AI研发实践的 SDD 四阶段同样适用于 UI：设计的验收标准必须可测试无歧义——"好看"不是 spec，"按钮圆角8px、间距16px、hover态透明度80%"才是。

与其他概念的关系

Harness Engineering：设计产物形态决定验证闭环是否打通
All In Code：UI/UX 版的 All In Code = 设计即代码
AI Coding：设计闭环是 AI 全栈开发的关键一环
SDD：设计 spec 结构化后可直接进入 SDD 的 Specify 阶段
Context Engineering：设计规范以 Markdown 存于 repo 时，AI 天然可获取上下文