我第一次看到 impeccable 这个名字是在周末翻开源仓库的时候。impeccable 是“无可挑剔”的意思但在 AI 圈子里这个名字更像一个宣言与其继续逼大模型背设计手册不如直接给它装上一颗设计师的脑子。我一开始以为它只是个花哨的 prompt 工程合集真正用下来才发现它把设计判断力、审美标准、改稿流程全都抽成了工程模块是一套可以落地到业务里的 AI 设计智能体方案。它不解决“AI 怎么画出好看的图”这种伪命题它解决的是更实际的问题AI 生成完一版东西凭什么说它好怎么让它知道自己哪错了怎么让它像人一样改稿这篇文章我会把自己搭建和接入 impeccable 的过程完整拆一遍。里面会讲到我为什么选 Spring AI 来做工程底座怎么把设计原则变成评审代理能读懂的评分卡怎么用多 Agent 协作避免 AI 反复自嗨也会把部署、测试、成本控制这些容易翻车的地方原原本本记录下来。产品经理、前端、独立开发者或者想在公司里推 AI 设计落地的人都可以直接参考这套思路。它不需要你成为设计专家但要求你愿意先把“什么是好设计”这件事用代码定义出来。1. 先从问题说起AI 设计最缺的到底是能力还是脑子1.1 扩散模型的生成原理决定了它不容易自带审美我接触过不少刚上手 AI 绘画的开发者他们最常见的困惑是我 prompt 写得很详细风格也有明确参考为什么生成的图总有种说不出来的廉价感答案跟大模型本身的工作原理有关。以当前最常用的扩散模型为例它生成图片的过程不是设计师构图的过程而是一个从纯噪声开始、逐步去噪还原图像分布的过程。模型训练时见过海量图文对学到的是“prompt 和图像之间的统计相关性”不是“这张海报的信息层级应该怎么排”。用生活里的话来解释这就好比让一个非常勤奋的实习生去模仿公司所有历史提案他能模仿出风格却不一定知道这次提案的客户是谁、要传达什么、强引导的按钮该放哪。AI 绘画工具的本质就是那个勤奋的实习生它在像素分布上极其熟练但在功能目标、视觉节奏、阅读顺序这些设计核心问题上完全没有概念。只要把生成链路的输出直接当成交付物翻车就是大概率事件。所以“给 AI 装设计师的脑子”这句话的关键不在“设计师”而在装“脑子”。它不是让模型再多看几万张漂亮图而是要让系统里有一个具备判断能力的角色。这个角色可以不是最聪明的模型但它必须知道设计原则如何在具体场景里生效。1.2 生成和评审解耦才是设计脑的骨架我在使用 impeccable 时第一个启发就是它把“生成”和“评审”彻底解耦了。大多数 AI 工具都是单模型走到底给它一个需求它给你一个结果。如果结果不好你只能改 prompt 再来一次。这个流程最大的问题在于模型既是运动员又是裁判它天然倾向于相信自己生成的东西是对的根本没有自我纠错的空间。我在一个落地页项目里做过对照实验第一轮直接用大模型生成完整 HTML 页面第二轮先用生成代理出稿再用评审代理按十个维度打分不达标就带着具体意见打回去改。同样的一次任务前者出的稿子第一眼很好看细节经不起推敲后者虽然不能保证每一次都惊艳但交付物的可用性和一致性明显高出一截。这套“生成代理 评审代理”的双角色结构本质上是在模仿设计公司里的工作流。设计师出初稿设计总监或者资深同事做评审给出“这里对比度不够、那里信息层级混乱”的具体意见再回到设计师手上修改。AI 不需要变成天才设计师它只需要有一套可靠的外挂判断机制就能规避大部分低级错误。1.3 别把所有希望押在“更强的模型”上我见过有人为了得到更好的设计效果不停换更大的模型从开源小模型换到旗舰 API结果最多好了两三成成本却涨了十倍。impeccable 给我的另一个认知是设计产出质量的瓶颈很多时候不在模型的生成能力而在系统有没有把好设计的目标定义清楚。举个例子让模型生成一张“高端护肤品的电商主图”它的审美下限由模型决定但审美上限取决于你怎么定义高端。品牌色是什么构图中心是什么促销信息要不要强调“高端”是冷色调还是暖色调这些约束如果只写在 prompt 里模型大概率会丢掉一半但如果把它们变成评分卡上的硬性判定条件再交给评审代理逐条检验模型就会被迫去满足这些指标。所以项目里有一句话对我启发很大先让“不好”能被发现再让“好”能被生成。工具不是帮你做一个更好的设计师而是帮你做一个更严格的质检员。2. impeccable 的设计脑要怎么搭2.1 整体架构的四个角色整个 impeccable 最核心的设计是把一次设计任务拆成四个角色策略规划器、生成执行器、评审代理、修复执行器。它们的名字听上去很抽象实际职责非常清晰。策略规划器负责理解需求输出策略卡。它要回答的问题是这次设计的目标是什么给谁看在什么场景里用需要传递什么情绪。生成执行器负责把策略变成具体产物可能是 HTML、图片描述、视频分镜脚本也可能是界面代码。评审代理是这套系统里最重要的部分它拿着一套设计评分卡逐项打分给出可执行的修改意见。修复执行器拿到意见后回到生成环节做定向修改。这四个角色之间不是简单的线性流水线而是循环直到评审通过。我在代码里给它设了最大循环次数默认三轮。连续三轮评审都无法达到合格线系统会把产物降级输出并明确标注风险项。这套机制防止了 AI 在死循环里反复改稿也保证了交付时间是可预期的。2.2 设计知识不是喂给模型的提示词而是可检索的资产很多人以为设计知识就是写一段“你是资深设计师请遵循尼尔森可用性原则”的 prompt。这其实远远不够。impeccable 的做法是把设计知识做成可检索的资产用向量数据库存起来。知识库里除了常规的《写给大家看的设计书》四大原则亲密性、对齐、重复、对比还有尼尔森十项可用性启发式、无障碍设计标准、常见 UI 稿的评分维度等。为什么要这么麻烦因为大模型的上下文窗口再大也不可能在一次请求里把所有设计规则完整塞进去。硬塞进去的后果就是关键约束被稀释模型看到后面忘前面。向量检索的好处是每当任务进来系统根据任务目标去知识库里检索最相关的几条原则附带示例再注入到 context 里。这样既控制 token 成本又能让模型在最需要的时刻看到最需要的知识。我实际用的 embedding 模型是 bge-m3粗算下来每个设计任务额外消耗不到两万 token。相比直接把设计手册塞进 prompt检索增强方案在效果和成本上有明显优势。这一层就是最基础的大模型 RAG 应用但放在设计场景里它解决了一个非常真实的问题AI 不会主动想起设计规范。2.3 一次设计任务从输入到输出的完整链路我以一次品牌官网落地页设计为例把完整链路说清楚。第一步用户提交输入包括项目背景、目标人群、品牌色彩倾向、偏好字体风格、参考站点链接。第二步策略规划器把这些信息转成结构化的设计策略包括栅格选型、字体比例、颜色系统、页面模块顺序、每个模块的预期效果。第三步生成执行器把这个策略翻译成 HTML 和 CSS画面细节尽量贴近策略卡。第四步评审代理加载页面截图和代码按评分卡打分。如果分数低于阈值它会输出类似“正文与背景的对比度不足按钮在移动端偏小”这样的意见。第五步修复执行器拿到意见重新调用生成执行器只针对问题部分修改不做全局重构。第六步评审再次启动直到通过或达到循环上限。这套链路文字描述起来就是几行真正跑起来需要非常多细节。比如评审代理对页面截图的观察能力直接决定它能不能发现按钮太小。为了让评审更可靠我会在截图之外再给它一份结构化的 DOM 分析报告包括每个元素的坐标、字号、颜色值、间距而不是单纯让它“看”图。这样它就等于有了工程师视角而不是只靠视觉猜测。3. 核心实现把审美拆成可以被计算的东西3.1 评审代理的评分卡设计原则的可执行化impeccable 最值得学习的部分是它把审美这个模糊概念拆成了十个可打分项。我经过实践后做了微调目前的评分卡是这样的。评分维度判定内容权重目标一致性画面是否服务于任务最初的目标20%视觉层次主次信息是否明确眼睛先看哪里15%对齐与栅格元素是否对齐栅格是否统一10%对比度前景与背景对比是否足够文字是否可读15%留白与节奏留白是否合理节奏是否舒适10%一致性字体、颜色、组件风格是否统一10%可用性按钮、导航、交互元素是否容易使用10%无障碍是否考虑色盲、弱视、大字体适配5%情绪匹配氛围是否符合品牌调性5%总分超过 80 分才算合格单项低于 50 分的直接打回。这套评分卡不是凭空拍脑袋定的它把视觉设计领域的基础共识转化成了可执行判定。最初我担心 AI 评审会不会过于机械但实际用下来机械恰恰是它的优势。人类评审容易看心情AI 评审只要指标清晰它在同一套标准下就能保持稳定。3.2 评审代理的 prompt决定了它能不能给出可用意见评审代理的 prompt 是整个系统工程里最值得打磨的部分。我把它的角色定义成“挑剔但不刻薄的设计总监”要求它必须给出具体问题与修改建议禁止只写空话。下面是一段精简后的核心 prompt可直接参考。你是一名资深设计总监正在评审一份设计交付物。 评审目标{task_goal} 目标用户{target_user} 交付物页面截图、DOM结构报告、设计策略卡 请按以下维度逐项打分 1. 目标一致性画面是否服务于目标 2. 视觉层次主次是否清晰阅读顺序是否合理 3. 对齐与栅格元素是否对齐栅格是否统一 4. 对比度文字可读性是否合格 5. 留白与节奏拥挤还是空旷 6. 一致性配色、字体、风格是否统一 7. 可用性核心交互是否容易识别 8. 无障碍对比度、字号、点击区域是否达标 评分要求 - 每个维度 0 到 5 分需说明理由 - 总分低于 40 分时输出最多五个最严重的问题 - 问题必须带具体位置或元素描述不能写“整体感觉不平衡” - 修改建议必须可执行比如“标题字号从 24px 提到 32px主色对比度从 2.1 提升到 4.5 以上” 额外注意 - 不要因为视觉好看而忽略可用性 - 不要为了修改而修改没有问题的维度保持原样这段 prompt 里最重要的一句是“不要为了修改而修改”。因为 AI 在评审模式下很容易过度批评每一轮都要求大改导致修复执行器来回折腾。加了这句之后循环轮次明显降低修改也更精准。3.3 Spring AI 在工程层的用处类型化调用与链路稳定性项目最初想用 Python 直接写毕竟开源模型生态都在 Python 上。但当我开始接公司现有业务时发现后端团队用 Java于是引入了 Spring AI。Spring AI 最大的价值不是提供炫酷的 Agent 能力而是把 LLM 调用变成了工程上更可维护的模块。我用物化的比喻来说原生 API 调用就像把一张写着地址的纸条递给司机Spring AI 的 ChatClient 则像是 Booking 预约单出发时间、车型、联系人全部有固定格式。它在 Java 里把 prompt 模板、调用参数、返回结构都封装成了类型安全的方法。比如评审代理的调用我可以定义这样一段接口逻辑传入任务目标和 DOM 报告返回一个带状态字段的 DTO。如果解析 JSON 失败系统能自动重试一次如果模型返回了不合法结构评审结果直接标为失败不会进入修复循环。这些在 Python 脚本里也能做但放到 Java 工程里CI、监控、灰度发布这些基础设施都能直接复用。对于要长期维护的 AI 项目这不是可选项而是必要条件。3.4 多 Agent 协作与循环修复避免死循环多 Agent 协作听起来热闹实际最容易踩的坑是角色之间互相踢皮球。策略规划器说颜色要大胆评审代理说大胆导致对比度不足修复执行器就不知道该听谁的。impeccable 在架构上做了一个仲裁机制每次修复前修复执行器需要同时读取策略卡和评审意见把冲突项标记出来回给规划器做二次确认。我在实践里遇到的典型场景是规划器希望页面体现科技感用了非常激进的蓝色渐变评审代理却批评文字对比度不足。修复执行器如果只顾对比度会削弱科技感如果只顾科技感又会继续被评审打回。所以我在评审意见里增加了一个“约束优先级”字段当出现冲突时可用性永远高于情绪表达。这是设计行业里的真实原则信息优先于装饰。循环上限的设置也很有讲究。我试过设成五轮结果有三个项目在三轮以后出现明显“过度设计”评审分数反而下滑。后来统一改成三轮超时后直接降级输出让人工接手。从流程上看三轮足够覆盖大多数问题再多就是模型在微调随机波动了。4. 一周内接入一个最小可用版本4.1 准备设计语料和评价数据如果你想在自己的项目里复刻这套方案第一步不是写代码而是准备数据。我整理了三十套设计案例涵盖了电商、官网、数据后台、海报等常见类型。每个案例都附四段信息任务目标、原设计稿截图、评审结论、修改意见。这些数据的主要用途是给评审代理做 few-shot 示例。每次评审时我从案例库里检索 style 最接近的两到三个案例把它们的“评价结论”和“修改意见”作为示例喂给模型。效果非常明显没有示例时评审代理容易给出“整体还不错细节需要优化”这种没用的意见带示例之后它会学着按照“问题定位加解决方案”的格式说话。如果你没有现成案例库可以先拿日常工作中真实发生过的改稿记录来凑。把每条“修改意见”和时间成本结构化你会得到比想象中更好的训练语料。要注意的细节是每个案例都必须写清楚目标否则评审代理会把视觉风格上的个人偏好当成通用标准。4.2 用 JSON Schema 固定任务边界在设计智能体里最怕的是多个 Agent 之间传输的数据格式自由发挥。今天传一个字符串明天传一个嵌套对象调试起来痛不欲生。我在最初版本吃了这个亏之后把所有传递数据结构统一成了 JSON Schema并在链路入口做校验。下面是最基础的任务输入结构供参考。{ task_goal: 为高端护肤品牌设计首页落地页, target_user: 25-35岁女性注重成分和品牌调性, deliverable: web_page, brand: { colors: [#F5F5F0, #1D1D1D, #B76E79], keywords: [极简, 高级感, 天然] }, constraints: [ 首屏必须一小时之内表达完核心卖点, 移动端优先, 不使用暗黑风 ], reference_links: [] }结构固定后生成执行器、评审代理、修复执行器之间的每一轮交互都变得可追踪。我甚至可以在数据库里把每一轮的 JSON 原样存下来回滚到任意版本对比。这属于最后的好习惯AI 项目里最值钱的东西不是模型参数是过程数据。没有过程数据后期想优化 prompt 都不知道从哪下手。4.3 快速落地一个 Web 设计场景如果只想做一个最小验证不建议一上来就接入图像生成模型而是先从网页生成开始。网页的反馈信号最明确评审代理可以直接读取代码检查颜色值、字体、对齐关系比“看”图片更可靠。我的做法是先用生成执行器让模型直接输出一个完整的 HTML 字符串评审代理读取 HTML 后生成一份结构化的 DOM 诊断报告报告里包含每个元素的位置和样式。这样评审就不依赖视觉模型普通大模型也能准确判断很多设计问题。比如“购物车按钮和价格文案之间的距离不够 12 像素”“正文颜色 #999 在白色背景上对比度只有 2.8”这些结论可以精确到具体数值。这条路跑通之后再扩展海报和图片场景。海报生成的评审难度会高不少因为它没有 DOM 结构可以解析只能用多模态模型去“看”。我在实际中配合使用了视觉理解和 OCR把文字提取出来跟画面排版做交叉验证效果还算可接受。4.4 自动化测试和性能基线AI 项目也要有测试这是我实践之后最深的一个体会。不能因为生成结果是概率性的就放弃自动化断言。我给 impeccable 建立了一套“设计回归测试集”每次改 prompt 或者升级底层模型之后自动跑一遍。测试集大概有 40 条任务每条任务都会记录四个指标生成是否成功、JSON 是否符合 Schema、评审分数是否达到合格线、单轮生成耗时。这套测试的开发思路来源于 AI 测试开发实践核心难点是避免模型结果随机性过大导致测试不稳定。我的处理办法是固定 temperature 为 0.2同时每次用同一套种子数据。虽然不能保证完全相同但能保证趋势稳定。性能基线也很重要。我在生产环境里给单次完整链路设定了 90 秒红线包含两次生成、一次评审和最多一次修复。如果线上平均耗时超过这个值用户体感就会变差。后来我发现耗时大头经常花在等待模型响应上于是把很多固定字段的校验逻辑移到了普通代码里而不是每次都让模型思考。比如“品牌色和背景色有没有冲突”“移动端按钮是否大于 44px”这些事情普通代码一秒就能做完完全不需要模型费 token 去判断。4.5 部署到生产的技术选型部署层面的选择取决于你对稳定性和数据隐私的要求。我测试时用的是公有模型 API上线时部分环节换成了私有化部署的开源模型。页面生成这种通用任务可以直接用 API设计评审这种频繁调用的任务用小型私有模型反而更划算因为单次推理成本更低。部署时我用的是 Docker 加 vLLM 的组合模型量化到 INT8 之后2 张推理卡可以支撑大约二十个并发任务。最初尝试过普通容器直接跑模型后来发现显存管理在并发情况下容易出问题切到 vLLM 后连续压测七天没有异常。另一个值得记下来的细节是模型部署不要跟业务后端混在一个集群里。推理任务负载波动大如果把模型服务和 Spring Boot 业务服务混在一起一个高并发任务就能把整个系统拖垮。分开部署以后出问题只会影响设计服务不会祸及核心业务。5. 实际项目里的典型案例和不那么顺利的地方5.1 改稿过头最典型的高频问题我接入 flawless 后的第一个高频 bug不是生成结果太差而是生成结果“改过头”。修复执行器拿到评审意见后本来只需要改按钮颜色它却顺手把整页的字体和配色都换了。第二轮评审分数不但没涨反而跌了。后来我在修复执行器的 prompt 里强制加入「变更最小化」原则只修复评审报告里明确指出的问题不主动变更未被标记的区域。同时我把评审意见按严重程度排序每次最多处理前五个问题而不是全量接受所有意见。效果立竿见影第二轮通过率大幅度提升。这个问题的根源在于大模型默认会对所有上下文都产生反应。你让它“按意见修改”它会认为每条意见都重要结果越改越多。就像一个新来的设计师被老板说了两句干脆把整个页面重画了一遍反而让原来的优势也丢了。5.2 评审 Agent 打分忽高忽低有一段时间同一张页面连续提交十次评审分数在 62 到 85 之间大幅波动。这让我一度怀疑评分卡设置出错。排查之后发现是温度参数的问题评审代理默认 temperature 太高同一张图每次“看”都带着不同的随机性。解决方案很简单把评审代理的 temperature 调到 0同时关闭 top_p 采样让输出尽可能确定。只有需要创意发散的生成代理才保留较高温度。现在这条经验被我写进了团队规范凡是“判定型”Agent温度一律 0.1 以下凡“产出型”Agent温度根据场景在 0.7 到 1.0 之间。另外还要注意多模态模型本身的不稳定性。如果评审代理用视觉模型它会因为截图的压缩质量、裁切位置等因素产生波动。我在截图前固定了浏览器窗口尺寸为 1440 乘 900并且关闭了动效避免截图刚好截在动画帧上。5.3 多 Agent 互相“踢皮球”多 Agent 系统最常见的外在表现就是踢皮球。规划器输出策略时说得非常好生成执行器做出来却是另一回事评审代理指出了问题修复执行器又改不回去。最终结果就是来回循环谁也说服不了谁。我后来用了两个办法解决。一个是在所有 Agent 之间增加共享上下文不再让它们各自看着不完整的信息做决策。另一个是引入我前面说的仲裁层让修复执行器在冲突时按固定优先级取舍。这个优先级本身就是设计行业里的铁律信息完整 可用性 美感 装饰。还有一次是规划器生成的策略卡本身有缺陷生成执行器照着做了评审代理怎么打都不过。这种问题向下游压没有意义必须把评审不通过的任务回流给规划器让它修改策略。我后来在 fail 条件里增加了一条回退规则如果评审连续两轮都是策略层面的问题暂停修复返回规划器重新出策略。5.4 内容安全与品牌底线聊 AI 设计安全是绕不开的一道线。impeccable 从架构上就不允许生成逻辑跳过安全策略。所有文本、图片、代码在进入生成执行器之前要过一层内容过滤器输出时再过一次。不是靠大模型自觉而是用规则词库加模型判断双保险。任何不满足合规要求的请求系统直接拒绝执行。为什么强调这个因为 AI 生成的内容一旦上线品牌风险由你承担不是由模型承担。我在这个项目里从一开始就把安全规则作为最高优先级常量不允许通过 prompt 覆盖也不允许在调试时临时跳过。这是工程底线。5.5 成本控制与推理延迟把完整链路跑起来之后很多人第一个问的就是成本。我算过一笔账一次完整设计链路平均调用四次模型生成一次、评审一次、修复一次、复评一次每次涉及多模态时 token 消耗会明显上升。严格按三轮上限跑单任务成本是第一次出稿成本的三倍左右。控制成本的手段有三个。第一个是用小型模型做评审评审任务不需要最强的推理能力只要规则清晰一个 7B 模型就能跑出不错的评分。第二个是减少无谓的视觉采集能不截图就不截图能读代码就不让模型看图。第三个是缓存同一个品牌、同类任务在数据库里命中历史策略卡直接复用规划结果省掉第一轮大模型调用。5.6 常用问题速查表现象可能原因处理方向反复修改但分数不涨修复范围太大破坏了原有结构限制修复项数量最小化变更评审分数波动大温度太高视觉评审不稳定评审温度调至 0固定截图参数多个 Agent 互相冲突缺少优先级和仲裁机制增加共享上下文和决策优先级输出 JSON 解析失败Schema 约束不够严入口校验失败自动重试一次单任务耗时过长模型响应等待太慢部分校验逻辑从模型挪到代码生成结果带有风格偏差知识库没有注入品牌约束调整检索内容增加品牌示例这张表今天看起来简单每一条背后都是踩了坑才总结出来的。真正实施的时候你会发现自己项目里的问题远不止这些。6. 把设计脑接到更多场景短剧分镜、建站、无障碍与声音设计6.1 短剧和漫剧的分镜一致性很多人以为 impeccable 只能做静态界面设计实际它同样可以接进 AI 短剧、漫剧这类视频内容生产流程。短剧和漫剧最典型的问题不是画面好不好看而是镜头之间风格漂移。同一个角色上一秒还是暖色调下一秒就切换成冷色调同一个场景前后两个镜头的人物五官都对不上。我把设计脑用在这里后做法是让策略规划器先输出一份「视觉连续性卡」里面写清楚角色特征、主色调、光源方向、镜头焦段、转场节奏。生成执行器每一帧都必须在视觉连续性卡约束下工作评审代理则拿着卡逐项核对比如“当前镜头中人物肤色是否和初始设定一致”“场景色调是否偏离主色调超过 15%”等。这套思路的本质是把原来依靠人盯人的分镜质量控制变成了可量化的自动校验。虽然复杂镜头的评审还需要人工介入但如果你的项目是按模板批量生产漫剧、短剧内容这套系统能省掉大量后期返工成本。6.2 落地页建站一分钟初稿的实操用 impeccable 做建站是我目前觉得投入产出比最高的场景。你只需要给它一个主题比如“露营装备品牌的移动端官网”策略规划器会自动拆出品牌关键词、目标用户、色彩倾向、页面模块顺序生成执行器会输出一套完整 HTML 页面。我最近用这套流程给一个旅行活动做活动页从输入需求到生成第一版耗时两分半。我原以为要大量返工结果评审代理只提了三个问题首屏标题的字体太小、导航按钮在移动端点击区域不足、活动日期信息位置不够明显。修复执行器改了一轮整体可交付程度高到可以直接发给运营同事看。这种能力对中小企业做官网初稿、活动页、产品介绍页非常有价值它不能替代专业前端但能把沟通成本压得非常低。6.3 无障碍审美也应该是设计脑的一部分我特别想强调无障碍设计因为绝大多数生成式 AI 工具会忽略这一点。设计脑的“脑”如果只追求美观那就不完整。评审代理里加入无障碍评分维度之后我注意到一个有意思的现象很多明明“好看”的页面在无障碍检查下根本不合格。比如浅灰色文字看起来很精致对比度却达不到 WCAG AA 标准按钮间距很紧凑设定视觉上很整齐却照顾不到手指更粗的用户。这些细节在人类设计评审中都容易被忽略但 AI 评审因为基于规则反而可以做得比人更严格。我建议所有做设计智能体的人都把无障碍评分权重加到至少 5%这不仅仅是社会责任做出来的产品商业上更有价值。6.4 从视觉到听觉空间音频与播报节奏如果继续往多媒体场景延伸设计脑还能覆盖听觉体验。有些产品需要在空间音频里给用户提示音比如导航应用在不同方向、不同距离播报时音量和音色的衰减策略。这些参数跟排版一样也有设计原则可循。我在实验里尝试过把评审维度扩展到时域和频域让评审代理判断“提示音是否过于突兀”“背景音乐是否压过旁白人声”。虽然这些场景还没有大规模落地但架构上 impeccable 完全支持。它本质上是把一个“什么样的体验算好”的判定标准从视觉扩展到了更广的感官范畴。7. 一些靠踩坑换回来的经验7.1 不要一开始就上最强的模型如果重新做一遍我会在项目最早期就用单卡能跑的小模型而不是直接接入旗舰级 API。原因很简单小模型便宜、速度快、部署轻易调试 prompt 和流程时可以无限次试错。等流程稳定了再换强模型效果立刻就能看到明显提升。很多人倒过来做直接用最强模型调试链路结果根本分辨不出效果提升是因为流程改对了还是因为模型本身更强。7.2 人永远保留最终决定权AI 评审分数再高也不能完全替代人的判断。我在实际生产环境里保留了一个“双人复核”规则AI 评审通过还需要一个真人确认才能在业务里发布。这个规则不是为了怀疑 AI而是防止模型在评分卡框架内出现系统性偏差。评分卡是死的设计是活的有些跨维度的权衡机器还不能完全理解。7.3 先让“不好”能被发现再让“好”能被生成我在最开始说过这句话接近尾声时我还是想强调一次。很多人做 AI 设计落地最大的误区是一上来就追求让模型生成惊艳作品。事实是先把一个可靠的问题发现机制做好哪怕是让评审 Agent 找出颜色对比度不够、按钮不够大这些笨拙的问题都已经能规避大量返工。有了稳定的“不好”检测能力再去追求“好”路径才会清晰。项目做到最后我最大感受是 impeccable 不是某一个模型而是一套工程哲学。它逼着我们把“审美”从玄学变成了可度量、可测试、可迭代的工程对象。AI 能走多远取决于我们帮它建立起多清晰的价值判断标准。这个方向远没有到终局。