惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

aimingoo的专栏
aimingoo的专栏
I
InfoQ
B
Blog RSS Feed
D
Docker
GbyAI
GbyAI
N
Netflix TechBlog - Medium
Y
Y Combinator Blog
F
Fortinet All Blogs
P
Proofpoint News Feed
Microsoft Azure Blog
Microsoft Azure Blog
人人都是产品经理
人人都是产品经理
Martin Fowler
Martin Fowler
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
M
MIT News - Artificial intelligence
C
Check Point Blog
Vercel News
Vercel News
云风的 BLOG
云风的 BLOG
博客园 - Franky
Google DeepMind News
Google DeepMind News
WordPress大学
WordPress大学
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
V
V2EX
Last Week in AI
Last Week in AI
L
LangChain Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
AI还原页面设计怎么做?我实测后总结了这套「块状精修法」! ...
B端设计情报局 · 2026-05-23 · via 人人都是产品经理

AI辅助还原设计稿并非一键生成完事的魔法,而是需要层层迭代的精细活。本文通过实战还原后台Dashboard的完整过程,揭秘如何让Cursor与MasterGo MCP协同作战——从骨架搭建到细节调整,从资源管理到Git版本控制,带你掌握分块精修的核心方法论,看清AI在落地环节的真实能力边界与提效空间。

一、全文速览图

前面那篇,我先把环境跑通了:Cursor +Node.js + MasterGo MCP +CodeX

那一篇解决的是:这件事到底怎么开始。

拒绝劝退!我把跑通 Cursor + MasterGo 的全过程写给你

这一篇,我想继续写更真实、也更有价值的部分:

当我真的拿一个 dashboard 去还原时,AI 到底能做到哪一步,又会在哪些地方翻车。

先说结论:

能做,但绝对不是一句话生成一个可交付页面。

第一轮,它通常只能把页面骨架搭出来;

真正决定还原度高低的,是后面你怎么带着它,一轮一轮把页面调到接近设计稿。

二、 第一轮能出骨架,但离设计稿还差得较远

一开始我当然也想偷懒。

最理想的状态当然是:

我把设计稿链接一丢、本地参考图一放,它就直接给我还原出一个七七八八的页面。( AI 赋能直接朝九晚五,有没有)

实际跑下来我发现,它确实能出第一版, 但这个第一版更像一个能继续修改的半成品,而不是一个已经能交差的页面。

我后面依旧采用上一篇说的方式,两种参考一起喂。

1、本地参考图

把关键模块截图、页面截图放进 reference 文件夹里,让 AI 先“看到页面长什么样”。(这边拿一个常见的后台页面做案例)

2、MasterGo 设计稿链接

给它更完整的设计上下文,告诉它:这才是真正的参考来源,具体的间距、色值、字号都要以设计稿为准。

这两种方式一起用,比只给其中一种要稳很多。

因为只给链接,它经常理解不稳定;只给截图,它又容易只学个表面。

但即便这样,第一轮出来的效果也只能说:

两种参考一起喂,结构和氛围能保住 70%;剩下那 30% 的细节,才是真正拉开差距的地方。

这是第一轮我跑出来的效果,乍一看其实还可以。 比较显眼的问题,首先是框架不对——这也是我踩的第一个坑,没有优先去修框架。

其次,每个模块也都有细节问题,所以后面我基本是从上到下,一块一块开始修改。

而真正开始踩坑,其实也是从第二轮开始的。

三、 最容易翻车的地方,是头部 6 个卡片

这次实战中,我踩坑最深、重做次数最多的地方,就是顶部的 6 个统计卡片。(这也是后台系统里为数不多还能稍微做点样式的区域。)

因为它们看起来像是“只是几张卡片”,但其实里面同时叠了很多东西:

这些东西一旦实现思路不对,后面会一路乱下去。

坑 1:把文字和图标一起切成图

一开始我图省事,想的是:

既然这 6 个卡片视觉最复杂,那我就直接切成图给它用,这样不是最快吗?

于是我最开始切图时,把卡片标题+icon 和背景切一块了。

结果页面一跑起来,问题立刻就出来了

窗口一缩放,标题开始变形。

图标也跟着被拉伸,自适应时,文字和图形一起失真,就连 SVG 也被当作背景一起带着跑偏。

输入指令,要求 Codex 进行调整

这个结果其实也证明了一件很基础、但自己上手时特别容易偷懒的事:

上面的结果就证明:纯文本信息,真的尽量不要切图。

其实平时和研发对接时,大家都知道文字最好不要切图,但轮到自己上手的时候,真的很容易忍不住偷个懒。

只能说,人对自己总是容易宽容一点。

正确的做法,小 icon 可以切 SVG,大的背景就单独切图

然后再把资源放进对应文件夹。

这里我新建了一个叫 card 的文件夹,依次把切出来的内容放到这里

坑 2:把文字拿出来,但背景图“位置乱跑”

我吸取教训之后,把文字改成代码写,icon 用 SVG,背景图只留装饰。

这已经比第一版好很多了。

但新的问题又来了:

背景图的位置很难精准定位

它要么贴边不准,要么左右对不齐。

AI 似乎理解不了这张装饰图到底该往哪儿摆,缩放时背景和文字各走各的。

继续给出指令,进行修改调整

所以这里我后面采取的办法也很简单:

给出非常明确的数值。

比如高度、间距、颜色直接作为指令发送,这一类问题,越具体,修改越准。

坑 3: 图片资源替换后依旧失效,要及时刷新

还有一个很容易忽略的小坑是:

图片资源明明已经替换了,但页面里还是旧的。

这时候问题往往是资源没有及时刷新,或者 AI 并没有真的把新资源替换到位。

所以这一步一定要明确告诉它:替换哪张图片

命令执行后,我们看下第一排基本已经还原度很高了,接下来一次调整剩余模块

小结:

通过这一章节的踩坑和调整,我发现,这种复杂卡片,必须彻底拆散实现,AI 才能真正搞定。

四、 核心方法论:必须“一块一块改”

这个点我一定要加粗提醒大家:

AI 最怕的指令就是“请把整体再优化一下”。

这件事其实特别像真实项目里的设计评审。

不怕甲方爸爸说一堆细节修改:

这一页的标题换个字体,那一页的色调再柔一点,这些都还算好办。

最怕的是那种:

“啧,怎么说呢,我觉得还是不够高端大气,说不上来哪里不对,你是专业的,你再出 10 版我看看。

这种话一出来,人都头大。

对 AI 也是一样,当你发整页精修的指令时,它大概率会理解成:“好,那我把能动的地方都动一遍。”

结果往往是:头部刚改对,底部图表乱了;导航修好了,卡片样式又跑偏了。

多次试错后我总结出来,AI 更适合块状精修,所以后面我基本按这个思路来调整:

一次只改一个区域

比如“现在只修顶部导航、只改第二排排名模块、只改趋势图区域”,改对、验收、存档。

一次只解决一种问题

比如“这轮只调所有卡片的标题层级”,或者“这轮只修图片接入路径”,再或者“只修间距和高度”

你得像个严厉的监工,指着一个块对它说:“就改这里,别动其他的。

第一轮可以让它快速出整体骨架,但从第二轮开始,越往后越要拆着改、分块改、逐段验收。

一旦问题拆清楚了,AI 才开始真正变得好用。

五、 骨架问题永远优于样式问题

一开始,我总在纠结卡片的投影重不重、胶囊按钮的圆角对不对,描边的颜色好像淡了点。

但后来我发现,如果页面骨架错了,细节再美也是“无效化妆”。

比如,AI 一开始把页面做成了贯穿到底的两列,但设计稿其实是顶部横向通栏,下面才是两列。

这时候你如果还在纠结按钮圆角,根本没有意义。

顺序必须是:先修骨架 -> 再修模块关系 ->再修模块细节 -> 最后整体检查

这个顺序一旦理顺,整页的可控性会一下子高很多。

六、 没有 Git,真的很容易改到崩溃

这个坑我也得写进去。

因为在精修阶段,我们会不断地让 AI “再试一次”。

最怕的事情就是:AI 这一轮改崩了,而我回不去了。

我中间就遇到过一次很典型的情况:

先修的细节,后面一轮改框架时全乱了,Undo 也不一定能完整救回来。

所以我现在会把 Git 当成一个很基础的兜底动作。

1、先检查有没有 Git

在 Cursor 里打开终端(Terminal → New Terminal),输入:

git –version

如果能看到版本号,比如:

git version 2.xx.x

说明已经安装好了,可以直接用。

如果提示 command not found,说明还没装。

2、没装的话怎么解决(Mac)

直接在终端里跑一次 git –version,系统一般会自动弹出安装提示。 按步骤装完,再跑一遍,有版本号就可以了。

小提示:(可选操作)第一次使用 Git,可以配置一下你的用户名和邮箱:

git config –global user.name “你的名字” git config –global user.email “你的邮箱”

不配置也不影响本教程的使用,只是 Git 记录提交信息时会更规范一些。

3、给项目建一个 baseline

当项目已经跑出第一个“能看的版本”时,执行:

在终端执行:

git init

git add

. git commit -m “baseline”

这一步的意思是:

把当前状态,保存成一个“起点版本”,设计师可以理解为“设计稿第XX版”

4、后面每次大改完,再存一次

比如:

git add . && git commit -m “顶部卡片结构调整完成”

一句话总结

AI 可以帮你快速往前铺页面,但 Git 是帮你随时能“回头”的Ctrl+Z。

七、这次做完 dashboard,我对 AI 落地页面这件事更清楚了

然后就按上面的 办法依次调整各个模块。

最后得到以下的页面,内容区域基本和设计稿接近。

跑完整个过程以后,我现在对这类工具的看法反而更具体了。

AI 无论生页面还是写代码,不可否认它的提效价值。

但它的价值从来不是“一键替你做完”。

它能帮你快速铺满 70-80% 的繁琐工作,但剩下的 20-30% ,是最需要人工介入、设计判断和落地控制力的地方

从当前工具演进趋势和真实工作流痛点来看, “设计稿 + MCP + AI 辅助还原”

很可能会成为未来专业设计师的重要生产力工具之一。

尤其适用于从设计稿到前端落地的协作场景。

技术革新日新月异,不管哪个岗位都要时刻保持敏锐去关注这些信息,同时不要被信息洪流淹没,从个人需要、项目需要的角度出发,选择性学习。

本文由 @B端设计情报局 原创发布于人人都是产品经理,未经授权,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。