让 AI 看得见、判得准、改得对—— D2C 从设计稿到三端真机达标的自动化实践

开场 · 一个现实的问题

AI 会写代码,这在 2026 年已经不是新闻。真正的问题是:AI 写完之后,谁来验收?

行业正在形成一个共识:Agent = Harness + LLM —— 光有模型能力远远不够,Agent 能不能可靠工作,取决于外面套的那层工程脚手架(Harness)。而这层脚手架的质量,可以拆成三件事:

质量 = 输入约束 × 生成约束 × 验证闭环

• 输入约束:给 AI 看什么上下文(读懂项目代码、拿到设计稿数据、了解业务规则)

• 生成约束:让 AI 按什么规范写(编码规范、组件复用、目录约定)

• 验证闭环:AI 写完之后,自己知道对不对、能自己迭代修复

前两项,业界已经有相对成熟的方案。但第三项 —— 验证闭环 —— 在移动端是断的。

Web 端早就闭合了这个环:Playwright 跑截图、Chrome DevTools 拿日志、Headless Browser 做回归 —— AI 生完码,自己跑一遍就知道对不对。但移动端呢? AI 写完一个 DX 卡片或 Weex 组件,它看不到真机上渲染成什么样、判不了对和错、更不会自己迭代优化。

具体到 D2C(Design to Code)场景,断裂带体现为三个具体问题:

• 问题一 · AI 生完码就"闭眼交卷"  拿不到真机截图、判不了视觉还原度、不会自己迭代修复。常常"看起来 OK"就交付 —— 结果 badge 圆角被截了、暗黑模式颜色错了、鸿蒙上文字截断了。AI 自己完全不知道。

• 问题二 · 三端渲染差异靠人肉  iOS、Android、鸿蒙 的字体栅格化、单位换算(px / dp)、暗黑模式行为各不相同 —— 同一份代码在三端上渲染出来是三个样子,上线前必须人工三端都验一遍，AI一个验证不了。

• 问题三 · 端上 UI 技术栈碎片化  团队业务同时跑着 多套渲染框架,每接一条链路,都要从零造一遍验证工具 —— 工作量比较大。

这些都不是模型能力问题,是 Harness 工程问题 —— 验证闭环这一环,在移动端比较缺失。

所以我们决定做一件事:建一个 D2C Harness 打通三端真机验证闭环 —— 让 AI 自己看到真机、自己判断对不对、自己改到达标。把移动端的验证断裂带,像 Web 端一样闭合起来。

AI 生码不难,难的是让 AI 自己知道自己写对了 —— 这就是验证闭环。

结果

过去一段时间，我们做了一件事：把 D2C 从"设计稿生完码就结束"，升级到"从设计稿出发，AI 一路自己走完生码、编译、三端真机验证，直到视觉还原达标"。

用户使用方式:内部研发平台创建Issue ，贴设计稿链接 和代码仓库，剩下的 AI 自动完成 —— 生码、编译、三端真机截图、diff 对比、迭代修复、代码提交 —— 全程不需要人。   

设计思考 · 不只是生码工具，

而是一套端上 UI 的 Harness 体系

如果 D2C 只是一个生码工具，那 AI 生完码就结束了，剩下的编译、预览、验证、修复全靠人——断裂带还是断的。

我们要做的不是"更好的生码工具"，而是一套面向端上 UI 的 Harness 体系——把 AI 生码之后的所有环节都工程化地闭合起来：

我们踩过一个坑：一开始，我们把所有步骤写进一份近千行的 SKILL 说明书，让 AI 照着一步步执行。逻辑很自然——步骤写得越细，AI 应该做得越好，对吧？

结果恰恰相反：

• 漏步骤率 ~30%：明确写了"按 1→2→3→…→9 执行"，AI 实际跑的是 1→2→4→7→9

• 幻觉式完成：AI 自信地输出"步骤 3 已完成"，但实际从未调用对应工具

• 2 小时白干：其中 40 分钟卡在"等截图超时"——这种事根本不需要 AI 判断，一个 if file.exists() 就够了

根因只有一句话：把确定性流程塞进了概率性 prompt。

我们回头分析那份 SKILL，发现 大部分的内容是流程编排——分支切换、编译重试、URL 管理、截图轮询——这些操作的容都是可以固化为程序代码的。但我们把它们交给了一个本质上是"大概率会照做"的概率系统。

CLI化改造

改造的本质是让AI不那么听话也能得到正确结果

我们做了什么 —— 把原 74 个决策点里的 66 个确定性步骤从 SKILL 说明书下沉到 CLI 命令 · 状态持久化到磁盘(上下文压缩、中断、重启都不影响) 。分清 AI 与程序的边界 —— 确定性流程固化到程序,AI 只做真正需要推理的事。

AI 漏步骤 / 假交付怎么办? —— 两层机制拦截:

• 每步执行前 — CLI 前置校验 state ， AI 若跳过 verify 直接跑 done CLI 立即 exit 3 + stdout 打 "必须先跑 verify" ，漏步骤根本执行不下去。

• AI 声称"完成"时 — Stop Hook 最终校验交付契约(pxdiff 达标 / real_bugs=0 / MR 已建 / CDN URL 等等) 不满足则反注入指令让 AI 继续跑 ，假交付根本 stop 不了。

流程调度靠 AI · 校验靠 CLI 前置 + Stop Hook 兜底 —— 不寄希望于 AI 自觉把"AI 会不会漏"变成"CLI 会不会放行"。

具体链路实现 · 让 AI 写对

三条链路大体流程是类似的，这里就用D2Weex 为例具体介绍下。

一次 D2Weex 生码任务:9 个阶段 —— 从 AST(把设计稿解析成结构化数据)分析、到生码、到编译、到三端真机预览、到视觉迭代修复、到走查闭环 —— 其中大部分步骤由 CLI 骨架自动完成 · AI 只在少数需要推理的决策点介入。

下面挑三个最能体现"让 AI 写对"这条主线的能力展开讲。

解决什么问题

如果 AI 生的代码是一个大文件 · UI / 数据 / 业务逻辑全混在一起 · 那接下来:

• 想改一处 UI · 得在一堆逻辑代码里翻

• 想加个数据接口 · 得动到 UI 组件

• 想加个业务逻辑 · UI 层也得跟着改

一次生码不难 · 难的是生完之后还能持续迭代维护。所以我们从生码那一刻就给 AI 定了架构约束:代码必须分层、必须组件化。

我们做了什么

Step 1 · 页面自动组件拆分

复杂页面不是一个大文件。AI 先分析设计稿 AST · 识别出可独立的单元(卡片、区块、模块) · 把一个页面拆成多个组件:

• 拆分候选评分 · AI 判断哪些单元该独立成组件

• 每个组件都是一个独立目录 · 可以单独预览、单独维护

• 页面组件 = 若干子组件的组合

Step 2 · 三层目录结构 · 数据 / UI / 业务逻辑分离

每个组件都遵循严格的三层目录:

为什么这么分

• UI 组件是"纯"的 —— 独立可预览 · 不依赖后端

• Mock 和 UI 分离 —— preview 用 mock 数据 · 上线用真实数据 · 切换零代价

• 逻辑层留空 · 支持并行开发 —— 业务开发写 logic/ 时 · UI 层不用动 · 两条线并行

• Mock 不进生产包 —— 构建时自动剔除 · 零冗余

代码架构解决的是"AI 写得可维护" —— 通过 SKILL 规则 + rulePath 让 AI 每次生出来的代码结构统一。

同时交付门禁会check 修改的文件是否符合预期，不满足要求禁止提交不允许任务完成，打回修复。

解决什么问题

Diff 只有一个分数不够 —— AI 会"看走眼"。举个真实案例:

一张订单卡片 · badge 圆角被截 —— badge "3" 圆角上半被白卡背景截切了。 AI 看到的 diff 只扣了 0.5 分(被截像素面积极小) · 心理锚定"分数高应该 OK" · 自评"96% 还原"、修了错的地方(marginLeft 微调) · 真结构 bug 一路漏诊到最终交付。

单靠像素 diff 分不清"渲染抖动"和"真 bug" · 单靠 AI 看图会被缩略图和分数误导。

我们做了什么

四层信号融合 · 每层回答一个不同的问题。关键点是 L2 —— 光有 diff 分数不够 · AI 还得知道实际渲染成什么样才能对症下药。所以我们不仅从设计稿拿到期望值(Pixelator AST) · 还从真机拿到 实际渲染的 DOM 树 —— 两者双向对比 · 定位到具体是哪个字段差了(位置?尺寸?颜色?字号?)    

同时 · 交付门禁的 7 项检查中 6 项有独立交叉验证 —— CLI 检测到 badge 被截、AI 却在门禁里填"badge 完整"?必须提供反驳理由说明为什么 CLI 判断有误。没有反驳 · 直接拒绝交付。

具体表现

• 视觉检测准确度:60-70% → 91%+

• 单个 badge 漏诊率:~50% → ~10%

• 交付门禁防绕过覆盖:0/7 → 6/7

解决什么问题

Agent 自动生完了代码 · 也有了三端截图和 diff 报告 —— 但光看截图不够。

业务场景大多数带交互:点击进详情、滑动切 tab、加购弹动画、暗黑模式切换、异常态回退 —— 这些必须真机上跑才能体验。而传统链路是:研发拿到代码 → 打包 → 装机 → 打开对应页面 —— 每一步都得开发在真机边上操作。产品、运营、设计想看效果只能"喊人"。

我们做了什么

Agent 生完码 → 自动推真机 → 自动屏投到浏览器 —— 分享一个链接 · 任何人随时随地都能看到实时效果:

• 产品看效果:不用找开发装机 · 浏览器打开链接直接看

• 设计走查:不用回办公室摸真机 · 手机/电脑打开就能看

• 复现问题:不用截图 + 文字描述 —— 直接把浏览器链接甩过去 · "自己看"

具体表现

• 交互场景可验收:不只是静态截图 · 完整交互动线都能真机上体验

• 无门槛访问:浏览器打开链接即可 · 不需要装 debug 手淘、不需要连真机、不需要 IDE

• 实时反馈:Agent 改一次码 → 浏览器页面自动刷新 · 秒级看到最新效果

• 开发角度：对于开发可能习惯在自己手机上看到或者操作，我们在issue 评论里面也准备了预览二维码，扫码可以一键预览到手机上确认。

同时这里也想说清楚一点，不是所有的视觉稿我们生码的时候都需要人工参与，实践的过程中，我们也有一些页面或者卡片AI直接完成，设计师走查一遍过的。我们目标还是追求AI自动闭环，现阶段的确还有一些问题没能彻底解决，在这前提下更好的辅助AI 快速完成修复。

解决什么问题

四层视觉门禁把准确度做到 91%+，但剩下的 5-10% 里藏着最难的问题。

实际跑下来我们发现，这些残留问题不是一种形态，而是三类完全不同的场景混在一起。机器一视同仁去修，有的修不动、有的修错方向、有的根本不该修。

实测数据也印证了这一点：AI 自修复在 3轮内 ROI 最高，3 轮以上必然要转人工——要么源头就是错的，要么是算法极限，要么是端上渲染必然差异。

三类典型场景：

走查页的价值：把"3 轮后转人工"这个动作，从"现实中不标准化的流程（设计师钉钉上反馈一些信息，然后整体给到AI），压缩成一次浏览器里拖框标注、分钟级修复。

我们做了什么

一张流程图看清整个闭环(下图 6 步 · 对应本节 3 句话:01-03 → 人的输入结构化;04 → Agent 上下文精准;05-06 → 闭环全自动):

核心 3 句话:

• 人的输入结构化:用户屏投手淘 · 在浏览器 走查页拖框标注(位置 + 一句问题描述) · 结果结构化写入 Agent 上下文 —— 不是自然语言 bug 单

• Agent 上下文精准:标注已经指定"改哪个组件的哪个属性" · Agent 直接改 —— 不用重读全组件代码

• 闭环全自动:标注 → Agent rerun → 修 TSX/CSS → 回写结果 → 页面实时刷新 —— 用户在同一个页面完成全流程 · 不切工具

具体表现

• 主观项也能收敛:从"pxdiff 91% + Vision LLM 通过" 补齐到 "用户真机看着满意"

• 人机协作范式升级:从"人在 Agent 外提 bug" 到 "人的判断变成 Agent 的一个决策节点"

这就是"走查即自动修复" —— 前面绝大多数问题靠机器自动化 · 最后一公里让人的判断结构化嵌入 Agent 决策循环 · 让整体的 ROI 更高。

方法论沉淀 · 让 AI Agent 变可靠的 5 条原则

前面讲的是 D2C 场景，但这套东西不只对 D2C 有用 —— 过去半年做的过程中，我们沉淀出了 5 条可迁移的方法论 · 任何 AI Agent 工作流都能用。

• 持续打磨：从"能用"到"好用"，稳定性和性能是长期投入 —— 拉高交付成功率 、缩短端到端耗时 、覆盖更多业务边界场景 ，让 Agent 在复杂场景下也能自己收敛

• 人人可用：让产品、设计、运营也能直接用 issue 触发生码并最终上线 ，而不只是研发的工具

• 能力标准化：让 D2C 从"独立生码链路" → 进化为"可插拔进任何项目 AI 生码流程"的能力