工程化设计评审助手：让视觉意见变成可执行问题清单

工程化设计评审助手：让视觉意见变成可执行问题清单

一、设计评审要从“感觉问题”转成“证据问题”

设计评审常常陷入主观表达：“这里不够高级”“层级有点乱”“感觉不顺”。AI 设计评审助手的价值，不是替设计师做审美裁判，而是把模糊意见转成可执行的问题清单。例如对齐是否一致、对比度是否达标、按钮状态是否完整、间距是否符合 Token、文案是否溢出。

一个实用的评审助手，应同时读取设计规范、截图和组件规则。仅凭截图，AI 只能做视觉猜测；结合 Token、组件 API 和页面状态，才能判断偏差是否真实。评审结果也应分级：阻塞问题、建议修复、可选优化。否则输出一堆意见会让团队无从下手。

二、评审链路：截图、Token 和组件规范要合并判断

flowchart TD A[页面截图] --> D[评审引擎] B[设计 Token] --> D C[组件规范] --> D D --> E[问题分类] E --> F[阻塞问题] E --> G[建议修复] E --> H[可选优化]

评审规则应结构化。例如间距是否命中 4px 或 8px 网格，文本对比度是否达到标准，按钮是否存在 hover、disabled、loading 状态，表单错误是否有可读文案。AI 可以负责解释和汇总，但基础规则最好由确定性检查完成。

三、问题结构：让评审结果能进入工单和代码审查

下面是一个简化的问题结构。它比自然语言评论更方便进入工单和代码审查。

type DesignIssue = { severity: "blocker" | "major" | "minor"; category: "spacing" | "contrast" | "state" | "copy" | "responsive"; location: string; evidence: string; suggestion: string; }; function assertIssue(issue: DesignIssue) { if (!issue.location || !issue.evidence) { throw new Error("issue must include location and evidence"); } }

四、自动评审边界：项目规范比通用审美更重要

AI 设计评审要避免“审美霸权”。不同产品、行业和品牌有不同视觉语言，不能用一套通用偏好评价所有界面。系统应基于项目自己的规范，而不是输出泛泛的设计建议。对于艺术性、品牌调性和营销页面，可以给出候选观点，但不能当作硬性规则。

落地时，建议从高确定性问题开始：对比度、溢出、缺失状态、断点异常和 Token 偏离。这些问题最容易自动化，也最容易被团队接受。等规则稳定后，再逐步加入更主观的层级和节奏分析。

评审助手还要记录误报。若某类问题总被设计师关闭，说明规则需要调整。自动化评审的目标是减少沟通成本，不是制造更多评论。

接入代码流程时，评审结果应分级处理。对比度不足、文字溢出、缺失禁用态可以阻塞合并；层级建议、节奏建议可以作为非阻塞评论。否则 AI 一次输出几十条意见，团队会很快产生疲劳。

还要让评审助手引用证据。比如指出某按钮间距偏离 Token，应给出当前像素值和期望 Token；指出对比度不足，应给出计算结果。没有证据的设计建议，很难被团队信任。

证据要可复查。

生产落地补充：从能跑到可维护

从生产落地角度看，这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通，真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束，读者很难判断它能否放进真实系统。

评估时建议先定义三类指标：正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信，稳定性指标回答失败时是否可控，成本指标回答持续运行是否划算。三类指标要同时进入验收清单，不能只用平均耗时或单次成功率证明方案有效。

实现层面还需要把观测数据留出来。日志至少包含请求标识、关键参数摘要、耗时、状态和错误类型；指标至少覆盖成功率、超时率、重试次数和队列长度；必要时再补 Trace 关联上下游调用。这样排查问题时不用靠猜，也能区分是代码逻辑、外部依赖还是容量配置导致的故障。

五、总结

AI 设计评审助手应把视觉反馈转成结构化、分级、可执行的问题清单。它适合提升评审效率，但必须基于项目规范，并与确定性检查结合，避免输出不可落地的主观意见。