WorkBuddy 实战：一句话需求 → 七屏可交互原型，户外徒步 App 的 AI 设计全流程- 惊觉

一、背景：为什么要试一次"全流程 AI 设计"

做一个 7 屏的中等复杂度 App，传统流程是这样的：

产品写 PRD → 设计师出 Figma 高保真 → 前端还原 → 联调走查。

这套流程里真正画图的时间其实不多，大头在来回沟通：产品说"这里要更突出"，设计师理解为加粗，产品想的是放大；前端问"这个间距是 16 还是 20"，设计师翻半天标注；需求一变（“配色太暗了”），设计师要从头调一遍色板，前端再跟一遍。

我想验证三件事：

AI 能不能独立完成从需求到高保真设计稿，而不只是生成某个组件、某张海报？
设计稿能不能被稳定地还原成代码，而不是"看起来像，但量不出来"？
需求变更时（配色要亮、要加页面），返工成本是多少？

选户外徒步这个题材，是因为它足够"难"：

信息密度高（路线参数、海拔剖面、轨迹、打卡记录）
视觉要求高（实景图驱动，不是纯几何图形能糊过去的）
有状态差异（日常浏览 vs 户外强光下的运动中）

结论先放在前面：能，但前提是把"审美"翻译成"约束"。 说"要好看"是没法执行的，说"底色明度 98%、主色饱和度 56%、内容边距统一 20px"才能执行。

二、目标与范围

一句话需求是这样给出去的：

设计一个适用于展示户外徒步的移动手机应用站，需要围绕户外路线的规划、展示、个人信息管理、讨论社交，还需要规划其他必要的功能。

从这句话拆出 4 大模块，落到 7 屏：

模块	屏幕	核心任务
发现	01 探索	今日推荐 + 附近路线，降低"今天走哪"的决策成本
规划	02 路线规划	地图选点 → 系统识途经节点 → 参数确认
展示	03 路线详情	头图情绪 + 硬指标 + 海拔剖面 + 真实评价
记录	04 徒步中	深色沉浸屏，行进中一眼能读
社交	05 社区	关注/推荐/附近三条流
个人	06 我的	数据资产 + 成就体系
个人	07 我的轨迹	按时间归档的轨迹库

在这里插入图片描述

📌 截图位 1：画布全览。统一 390 × 844，横向等距排布。这一步必须先做，单屏好看不等于整组好看。

三、方法论：三层能力串成一条流水线

整个实践不是"一个工具干所有事"，而是三层能力接力：

需求文本
   │
   ├─ ① 画布设计层  ──→  7 屏可编辑设计稿（图层可改、可导出）
   │
   ├─ ② 素材生成层  ──→  6 张实景图（竹林/山脊/营地/徒步者）
   │
   └─ ③ 还原实现层  ──→  可交互 HTML/CSS/JS 原型（可点击、可深链）

关键点：设计稿必须是"可编辑图层"，不是一张图。 只有结构化的图层，后面才能精确读取每个元素的坐标、圆角、色值，还原阶段才有据可依。如果一开始就生成一张位图，那还原就只能靠肉眼猜。

四、提示词工程：这一节是全文重点

我把整个过程用到的提示词分成 5 类。踩过的坑基本都集中在"我以为说清楚了，其实没有"。

4.1 需求提示词：别写"好看"，写"必须有什么"

失败写法：

设计一个好看的山野徒步 App

结果必然是一堆正确的废话：卡片、头像、渐变、什么都对，但什么功能都没有。

实际写法（结构化四段式）：

【角色】你是资深移动端产品设计师
【场景】户外徒步 App，用户是 25-40 岁有徒步经验的都市人群
【必须包含】路线规划、路线展示、个人信息管理、讨论社交
【输出要求】先给功能地图（模块 → 屏幕 → 每屏核心任务），
           我确认后再逐屏出稿，每屏 390×844

四段分别是：角色 / 场景 / 硬性功能清单 / 输出协议。

最有价值的是最后一段"先给功能地图，确认后再出稿"。它把一次性赌博变成了两步走——先对齐结构，再对齐视觉。结构错了，视觉再美也是白做。

4.2 设计系统提示词：用具体值替代形容词

第一版出来时整体偏"性冷淡"：暖纸底 + 深林绿，安全但没记忆点。问题不在设计，在于我没给约束——AI 只能取最保守的解。

修正后的写法是把设计系统当成"宪法"先立好：

【配色】底色 #F8FBF4；软面 #EFF6E9；分割 #E6EFE0
       主绿 #2FA76B（深态 #1F7D50）；强调橙 #F5813C（文字用 #D9611F）
       文字四级 #12211A / #476B57 / #6F8F7C / #8AA898
【字体】中文 Noto Sans SC，数字 Inter
【圆角】卡片 18 / 大面板 26 / 胶囊 31 / 标签 999
【间距】内容左右边距 20，卡片间距 13
【禁止】不要纯黑 #000；不要灰色描边大于 1px；同一屏最多 2 个强调色

💡 经验：圆角 18 / 大面板 26 / 胶囊 31 这种分层数值比"圆角适中"有用一百倍。它建立了层级关系——面板比卡片圆，胶囊最圆，视觉上自然形成"从容器到控件"的递进。

"禁止"条款也别省。AI 的默认审美是安全牌，不给禁区它就一定往灰色和阴影上靠。

4.3 迭代提示词：把主观感受翻译成可执行参数

这是我觉得最有意思的一环。用户（我自己）给的第一条反馈是：

整体页面配色显得太灰暗了，调整为亮色一点

这句话如果原样传下去，AI 大概率只做一件事：把颜色调浅。结果就是"灰 → 灰白"，依然没生气。

我把它拆成了三个可执行维度：

维度	初版	目标	具体动作
明度 L	主绿 30% / 底色 95%	42% / 98%	整体抬高明度
饱和度 S	主绿 40%	56%	提亮必须同时提饱和，否则会脏
色相 H	底色 48°（暖黄）	93°（薄荷绿）	背景从暖调偏移到绿调

对照结果：

Token	初版	最终	变化
页面底色	`#F5F3ED`	`#F8FBF4`	L 95% → 98%，H 48° → 93°
主绿	`#2E6B4A`	`#2FA76B`	L 30% → 42%，S 40% → 56%
强调橙	`#E1642B`	`#F5813C`	明度抬高，去掉土气

在这里插入图片描述

这里是关键洞察：所谓"太灰暗"，本质不是颜色不够浅，而是明度和饱和度同时不足。 只调明度会得到粉彩感（廉价），只调饱和会得到荧光感（刺眼）。两个一起抬，才有"清爽"的观感。

一句话总结这条提示词技巧：用户的感受词 → 拆成可测量的物理量 → 批量替换 token。

4.4 素材提示词：实景图的四要素

户外类 App 没有真实照片就是死的。生成提示词我固定成四段：

【主体】什么场景、谁在做什么
【光线】时间 + 方向 + 质感
【视角】机位高度 + 焦段感
【氛围】色彩倾向 + 情绪

实际用于详情页头图的一条：

背对镜头的高个男性徒步者站在高山草甸边缘，背着深色登山包；
清晨侧逆光，光线从左侧山脊斜射，空气中可见薄雾丁达尔效应；
低机位仰拍，35mm 视角，人物占画面下方三分之一；
冷调远山 + 暖调前景草甸，壮阔但孤独的情绪

六个字概括：具体、可拍、有光。

配合"横向排版一致性"——6 张图统一用同一套光线逻辑（清晨/侧逆光），拼在一起才像同一个品牌出的。

📌 截图位 2：素材生成结果（6 张实景图 3×2 排列）与它们在图中的实际落位。建议标注哪几张被用于头图、哪几张被用于卡片缩略图。

4.5 还原提示词：用"规约表"锁定像素

从设计稿到代码，最容易翻车的是"看着差不多，量起来全错"。所以还原阶段的提示词不是描述，是规约表：

【任务】严格按设计稿还原为 HTML/CSS/JS 单页原型，
       不得用近似值，所有数值必须与设计稿一致

【尺寸规约】
状态栏高 62 / 内容左右边距 20 / 卡片间距 13
Tab 栏 95，胶囊 62，圆角 31
规划面板 top 340、高 504、圆角 26
详情头图高 432，内容面板上移 92
我的页头区 302，统计卡 top 258

【结构规约】
所有屏内容包在 paddingLeft/Right 20 的 Content 列内
状态栏与 Tab 由脚本统一注入，不在每屏重复写
非 Tab 屏（详情/轨迹）隐藏 Tab 栏

【禁止】用 0.9rem / 1.1em 这类相对值替代像素；
       用近似色替代 token；用占位图替代实景图

💡 经验：把"不得用近似值"写进提示词，输出质量会有肉眼可见的差别。默认情况下 AI 很爱做"合理的四舍五入"，20.5 给你写成 20，31 写成 32，单处看不出来，叠 7 屏就是整体错位。

4.6 五条原则小结

结构化优于形容词 — 角色/场景/清单/协议四段式起步
具体值优于描述 — “圆角 18/26/31” 而不是"圆角适中"
给禁区 — 不说不要什么，就一定会踩
先结构后视觉 — 功能地图确认了再出稿
感受词要翻译 — “太灰暗” → 明度 +12、饱和 +16

五、工作流程：五阶段，每阶段有验收动作

阶段	输入	产出	验收动作
① 需求拆解	一句话需求	功能地图（4 模块 / 7 屏）	人工确认结构
② 设计系统	受众 + 调性	Token 表（色/字/圆角/间距）	出 1 屏样板屏先看
③ 逐屏落地	功能地图 + Token	7 屏可编辑画布	总览图查看节奏
④ 素材生成	四要素提示词	6 张实景图并落位	检查光线一致性
⑤ 代码还原	设计稿 + 规约表	可交互原型	逐屏截图比对

两个"卡点"值得单独说：

卡点一：样板屏。 阶段②不要直接铺 7 屏，先出 1 屏（我选的是探索页，因为它承载最多元素类型：图片、卡片、标签、搜索、Tab）。样板屏过了，剩下 6 屏是复制粘贴 + 局部调整，返工成本极低。样板屏不过，改 7 屏就是 7 倍浪费。

卡点二：总览验收。 单屏都漂亮，排在一起才发现节奏全乱——第一屏信息太满、第二屏太空、第四屏（深色）突兀。总览图是唯一能发现这个问题的视角。

六、设计决策复盘：几个"反直觉"的选择

这部分是我认为比"怎么生成"更值得记录的东西。

6.1 深色屏不是"没改"，是"不该改"

用户第二条反馈是"整体配色太灰暗，调亮"。

如果无脑执行，04 徒步中也会被翻成浅色。但这一屏的使用场景是户外强光下、边走边看、单手操作：

浅色底 + 阳光直射 = 反光刺眼，对比度反而更差
深色底让橙色的轨迹线和白色大数字（6.42 km）跳出最强对比
深绿是"户外"的情绪色，浅绿会显得像健身 App

所以这一屏保留了深色，只是把原来的"墨绿黑"（#12211A）换成了有层次的深林绿（底 #0C3722 / 卡片 #165438 / 按钮 #1F6B49）——同样是深色，但从"压抑"变成"沉浸"。

💡 这条我给所有用 AI 做设计的人：全局指令（“调亮”）遇到有明确场景理由的局部时，应该主动指出来并给出替代方案，而不是机械执行。这是设计判断的价值所在，也是目前 AI 最需要人补位的地方。

6.2 详情页面板上移 92px

头图高 432，面板从 y=432 开始是"标准的"，但视觉上会显得头图被切断得很生硬。

把面板上移 92px（覆盖在头图上，顶部圆角 26）之后：

头图露出的部分从"一整块"变成"一条情绪带"，更像杂志跨页
面板的圆角与头图下沿形成软过渡，不是硬切线
首屏能多露出约 1.5 行内容，海拔剖面不用滚动就能看到

代价是头图实际可视高度只有 340，但因为覆盖区域是渐隐的人像腿部，信息损失为零。这类"用遮挡换呼吸感"的手法，在图片主导的详情页里非常通用。

6.3 "我的轨迹"为什么必须独立成页

最初"我的"页面里放了一个"我的足迹"卡片，点进去是列表。但实际使用中，轨迹是徒步用户最高频回看的资产（复盘路线、看累计里程、找去年那条线），塞在二级入口里层级太低。

独立成页后重新组织了信息结构：

年份栏（2026 年 · 今年 24 次 · 386 km）
  ↓
筛选 chips（全部 / 重装 / 一日往返 / 露营）
  ↓
月份分组头（10 月 · 3 条 · 36.2 km）
  ↓
轨迹卡（72px 迷你轨迹缩略图 + 标题 + 日期 + 距离/爬升/耗时）

三个细节：

迷你轨迹缩略图是手绘 SVG 路径，不是地图截图。抽象成线条后，重装线的"大环"和穿越线的"单程"一眼可辨，比缩略图更有识别度。
月份分组带汇总（3 条 · 36.2 km），让"按月看进度"这个真实需求不用再进统计页。
筛选与分组同级，都放在列表内部而非顶部导航，滚动时不占固定空间。

6.4 配色提亮的量化做法

已在 4.3 详述，这里只补一条操作层面的：改配色不要逐个改，改 token。

初版有 4 个色值硬编码在各处，改一版要动几十处。改成 CSS 变量后，提亮只需要改 16 行：

:root{
  /* 背景 */
  --bg:        #F8FBF4;
  --surface:   #EFF6E9;
  --chip-bg:   #E8F1DE;
  --line:      #E6EFE0;
  /* 主色 */
  --green:     #2FA76B;
  --green-dk:  #1F7D50;
  --orange:    #F5813C;
  --orange-tx: #D9611F;
  /* 文字 */
  --ink-1:     #12211A;
  --ink-2:     #476B57;
  --ink-3:     #6F8F7C;
  --ink-4:     #8AA898;
}

这是"AI 能快速迭代"的真正前提：改造成本足够低，你才敢改。

七、从设计稿到代码：还原度怎么保证

7.1 三张对比图说明问题

在这里插入图片描述

其余四屏：

7.2 结构复用：别把状态栏写 7 遍

7 屏都有状态栏，5 屏都有 Tab 栏。手写 12 遍不仅啰嗦，更致命的是改一处要改 12 处。

做法是把它们做成"注入件"：

const STATUS_BAR = `<span class="time">9:41</span> ...`;
document.querySelectorAll('.statusbar').forEach(el => el.innerHTML = STATUS_BAR);

// Tab 只在需要的屏显示
const TAB_SCREENS = new Set(['explore','community','profile','tracks']);
tabbar.classList.toggle('hidden', !TAB_SCREENS.has(id));

配合 hash 深链，7 屏就是一个单文件应用：

// #explore / #plan / #detail / #track / #community / #profile / #tracks
const deepLink = (location.hash || '').replace('#','');
render(screens[deepLink] ? deepLink : 'explore');

好处是分享一个链接就能直达某屏（index.html#tracks），评审时特别省事——不用"点进来 → 点我的 → 点全部轨迹"。

7.3 视觉回归：无头截图逐屏比对

还原完不能靠肉眼扫一遍就说"好了"。做法是用无头浏览器逐屏截图，与设计稿并排看。

这一步踩了两个坑，值得记下来：

坑 1：截图窗口别小于 500px。
用 390 宽截图，得到的图右侧被裁掉，看起来像"布局溢出"。排查半小时才发现是窗口太小导致渲染裁切，不是 CSS 问题。正确做法是用 500 × 900 的窗口截取 390 宽的设备视图。

坑 2：截图前必须关掉过渡动画。
页面上有 200ms 的 opacity 过渡，截图正好落在中间态，得到一张"发灰、半透明"的图，误判成"配色没生效"。加一个 ?still 参数关闭所有 transition 再截：

if (location.search.includes('still')) {
  document.documentElement.classList.add('no-motion');
}

.no-motion *, .no-motion *::before, .no-motion *::after{
  transition: none !important;
  animation: none !important;
}

💡 经验：截图验证的价值不在于"看一眼像不像"，而在于把主观的"差不多"变成可并排比对的客观证据。7 组并排图摆出来，漏掉的问题会自己跳出来。

7.4 交互也要还原

静态还原只是及格线，原型能点才有评审价值。这一版实现了：

5 个 Tab 切换 + 真实返回栈（详情 ← 探索，轨迹 ← 我的）
卡片跳转、筛选 chips、难度分段控件
点赞 +1、SOS / 分享 / 收藏的轻提示
键盘 Esc 返回
窗口 ≤ 470px 自动全屏，桌面端保留手机外框

八、踩坑记录

除了上面两条截图相关的，还有三个比较典型的：

8.1 素材上传 403

上传本地图片到画布时，返回 403。原因：素材服务会同时返回"上传地址"和"下载地址"，两者带不同的签名。PUT 上传时误用了下载地址的签名，服务端校验失败。

结论：上传用上传地址的签名，下载用下载地址的签名，不能混。 这类问题看错误码没用，得看签名对不对得上。

8.2 矢量图形创建失败：degenerate geometry

手绘地图等高线和轨迹线时，有几个图形节点创建失败，报 degenerate geometry（退化几何）。

原因：路径坐标超出了画布 viewBox 的范围（比如 viewBox 是 0 0 390 300，路径却画到了 y=420）。

结论：SVG 的所有坐标必须落在 viewBox 内。超出边界不会自动裁剪，而是直接判定为无效几何。另外，一个超宽的地图底图（400 宽）塞进 390 的画布也会出问题，正确做法是拆成"底图"和"路线"两个 390 宽的独立图层再叠。

8.3 12MB 的图，首屏要等 3 秒

6 张 AI 生成的实景图都是 1024×1536 的 PNG，共 12MB。原型在自己机器上跑没问题，发给同事评审时首屏白屏好几秒。

转成 WebP（quality 80）后：

图片	PNG	WebP	压缩率
bamboo	2.79 MB	285 KB	90%
hiker	2.20 MB	131 KB	94%
aerial	1.36 MB	80 KB	94%
alpine	1.66 MB	152 KB	91%
candid	2.27 MB	295 KB	87%
合计	12.0 MB	936 KB	92%

体积降到 1/13，肉眼几乎看不出差别。顺手删掉了 1 张生成但没用上的图（1.7MB），整个 app/ 目录最终 1016 KB。

💡 经验：AI 生成的图默认是无损 PNG，直接用于 Web 交付是浪费。上线前一定过一遍 WebP，92% 的体积省下来是纯收益。

九、效果

指标	数值
设计稿	7 屏 × 390×844，全部为可编辑图层
迭代轮次	5 轮（需求 / 样板屏 / 全量 / 配色提亮 / 增页）
需求变更返工	配色提亮：改 16 行 token，全站生效
新增页面	"我的轨迹"独立成页，1 轮完成
布局问题	修复 7 处（卡片被 Tab 遮挡、面板遮挡路线末端、按钮错位到状态栏等）
交付体积	1016 KB（HTML + CSS + JS + 5 张 WebP）
还原度	并排比对，关键屏逐像素一致

几个"布局问题"的具体成因，基本都指向同一类错误——固定定位元素与滚动内容的层叠关系没算清：

探索页第二张路线卡被悬浮 Tab 遮挡 → Tab 是 fixed 且带渐变遮罩，内容区需要预留底部安全高度
规划页路线末端被搜索框压住 → 路径终点坐标在搜索框的 z-index 之下
我的页扫码/设置按钮跑到状态栏上 → 头部是 relative，按钮没设 absolute 而继承了文档流

十、小结

回到开头那三个问题：

Q1：AI 能独立完成从需求到高保真设计稿吗？
能。但它的输出质量完全取决于你给的约束密度。"好看"进去，"安全牌"出来；"明度 98% / 饱和 56% / 边距 20"进去，"有设计感"出来。

Q2：设计稿能稳定还原成代码吗？
能，前提是设计稿本身是结构化图层而不是一张图，并且还原时用的是像素规约表而不是形容词。7 屏并排比对下来，关键屏是逐像素一致的。

Q3：需求变更的返工成本是多少？
这是 AI 设计最大的收益点。配色提亮花了一次对话、改了 16 行 CSS 变量；新增一个页面花了一轮。传统流程下这两件事分别是半天和一天。

最后一条我觉得最值得记住的：

AI 擅长执行，不擅长判断。
"把配色调亮"是执行，AI 一秒做完；
"徒步中这一屏不该调亮"是判断，得人来。

所以好的协作方式不是"让 AI 替你做设计"，而是你把判断说清楚，它把执行做到位。提示词工程的本质，就是把判断翻译成约束的过程。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/yelangkingwuzuhu/article/details/170053850

WorkBuddy 实战：一句话需求 → 七屏可交互原型，户外徒步 App 的 AI 设计全流程