Agent 设计协作：先把约束、设计系统和交付物定义清楚，再谈生成创意

“AI 设计师”这个说法很容易让项目一开始就走偏。因为设计工作里真正难的部分，往往不是把一个画面拼出来，而是下面这些判断：

• •需求是否被正确定义
• •方案是否符合现有设计系统
• •交互是否解决真实用户问题
• •视觉方向是否符合品牌语境
• •最终交付是否足够方便研发落地

所以在产品团队里，设计 Agent 更适合扮演“设计流程协作者”，而不是最终视觉负责人。

设计场景很宽，从界面布局、设计系统、插画、营销海报，到可用性评审都可能用到模型。但第一版最好只选一条链路。

更容易落地的切入点通常是：

• •落地页文案与版式变体探索
• •设计评审纪要整理
• •组件改版的约束检查
• •设计稿与前端实现的对比 QA

例如“设计 QA 助手”就是一个很现实的第一版：

• •读取设计稿说明、组件规范和截图
• •对比实现结果和设计约束
• •标出明显的间距、字号、文案和状态偏差
• •输出给研发和设计师可复核的问题清单

这类场景比“让模型独立做一套完整产品视觉”更容易产生真实价值。

1. 需求与约束层

设计工作不是从画图开始，而是从约束开始：

• •页面目标是什么
• •面向哪些用户
• •受哪些业务字段和组件能力限制
• •哪些视觉元素必须沿用设计系统
• •哪些部分允许做探索

如果这层不清楚，模型生成再多方案，设计师也只是在筛废稿。

2. 方案探索层

这一层适合模型参与发散：

• •帮忙生成信息架构草案
• •给出布局与文案方向的变体
• •总结竞品页面的共同模式
• •根据反馈快速改写标题、标签和解释文案

它的作用更像“扩大第一轮备选范围”，而不是替设计师做最终定稿。

3. 设计系统贴合层

这层决定方案能不能落地。需要回答的问题包括：

• •是否复用了已有组件
• •是否违反了 spacing、颜色、字体等 token
• •是否引入了新的交互状态
• •响应式和空态是否被考虑到

很多看起来“挺好看”的 AI 方案，真正问题就出在根本不兼容现有系统。

4. 交付与 QA 层

设计不是在 Figma 里结束的。Agent 还可以继续参与：

• •把设计意图整理给研发
• •生成交付 checklist
• •对比设计稿和实现截图
• •汇总设计评审意见

这部分往往比“生成一张更酷的概念图”更能真正节省团队时间。

在设计场景里，一个更稳的职责拆分通常是：

更适合模型处理的部分

• •解析需求文档
• •提炼页面结构和内容层次
• •生成若干可讨论的文案与布局方向
• •对截图、设计稿和实现结果做差异检查
• •汇总评审意见并转成 action items

更适合人处理的部分

• •决定最终视觉语言
• •判断品牌与审美方向
• •做关键交互取舍
• •审核无障碍、合法性和版权风险
• •确认最终交付是否可以上线

如果把这些职责混在一起，最后最常见的问题就是方案看起来热闹，但很难进真实项目流程。

比较推荐的方式，是先让模型输出一个受限的设计任务对象，再决定走探索、评审还是 QA 链路。

from typing import Literal
from pydantic import BaseModel, Field


class DesignTask(BaseModel):
    lane: Literal["exploration", "copy", "qa", "handoff"]
    platform: Literal["web", "ios", "android"]
    goal: str
    constraints: list[str] = Field(default_factory=list)
    design_system_refs: list[str] = Field(default_factory=list)
    deliverables: list[str] = Field(default_factory=list)
    requires_human_review: bool = True


def run_design_task(task: DesignTask, tools):
    context = tools.fetch_design_context(task.design_system_refs)

    if task.lane == "exploration":
        return tools.generate_layout_directions(task.goal, context, task.constraints)

    if task.lane == "qa":
        return tools.compare_spec_and_impl(context, task.deliverables)

    if task.lane == "handoff":
        return tools.prepare_dev_notes(task.goal, context)

    return tools.rewrite_ui_copy(task.goal, context)

这个模式的价值在于：

• •先区分当前是在做探索、文案、QA 还是交付
• •设计系统引用和业务约束可以显式注入
• •是否必须人工复核不会被遗漏

很多“AI 设计效果差”的根源，不是模型不会设计，而是上下文太少。

真正有用的输入通常包括：

• •页面目标和业务约束
• •现有设计系统文档
• •组件使用规范
• •竞品截图或参考页面
• •当前实现截图

只有让 Agent 同时看到这些信息，它才更可能给出贴近现实的建议，而不是生成脱离上下文的视觉描述。

在设计工作里，图像生成工具当然有用，但它更适合做这些事情：

• •概念方向探索
• •情绪板和风格参考
• •插画或海报草案
• •封面图和宣传素材的初稿

它不太适合直接替代下面这些工作：

• •核心产品界面的最终定稿
• •依赖精确 token 和组件约束的系统页面
• •没有经过版权和品牌审查的正式资产发布

把图像生成的价值放在“探索”和“沟通”上，通常比强行把它塞进最终交付更稳。

如果团队已经有设计系统和前端页面，设计 QA 往往是最先能跑出价值的场景。

因为它不要求模型创造完整方案，而是要求它做三件更具体的事：

• •识别明显差异
• •按规则输出问题
• •帮设计和研发减少重复比对

这类任务对审美创造力依赖不高，但对团队效率帮助很直接，也更容易评估。

设计 Agent 的评估，更适合围绕流程结果，而不是主观地问“生成图漂不漂亮”。

比较值得关注的指标包括：

• •第一轮可讨论方案的采纳率
• •设计评审到定稿的轮次
• •设计稿和实现之间的偏差发现率
• •研发返工次数
• •新增组件是否被滥用

这些指标更能反映 Agent 是否真的帮助团队减少了沟通和返工。

1. 没有设计系统输入，就要求模型产出可落地方案

没有 token、组件和业务约束，模型给出的往往只是“看起来合理”的界面描述。

2. 把图像生成结果当成最终交付

探索稿和正式资产是两种完全不同的产物，审核流程也不一样。

3. 只把 Agent 用在发散，不沉淀评审规则

如果设计评审总在重复指出同类问题，但这些规则没有回流进系统，Agent 的价值就会停留在“偶尔帮点忙”。

设计 Agent 真正可交付的价值，不是让模型替设计师做所有视觉决策，而是把需求理解、方案探索、系统约束、设计 QA 和研发交付这些环节连起来：

• •先把目标和约束说清楚
• •让模型参与发散与整理
• •用设计系统约束收紧输出范围
• •在交付和 QA 环节持续复用 Agent

只要工作流设计得当，Agent 就能成为设计团队的加速器，而不是不断制造新稿和新分歧的噪音源。

• •OpenAI Images and Vision
• •OpenAI Image Generation
• •OpenAI Structured Outputs