Max.King *2026年5月2日 13:36* MaxKing宝藏 全栈开发者 × 量化交易 × AI 重度用户。这里记录我用 AI **提升效率、解决问题、优化流程** 的真实实践，也分享工具背后的判断、踩坑和可复用方法。 上次发了一个文章： [别再只让 Codex 写代码了，它更适合接管整条 UI 生产线](https://mp.weixin.qq.com/s?__biz=MzkwNzU5OTI0OA==&mid=2247483929&idx=1&sn=4615c470a1bc93064accaf47f625201d&scene=21#wechat_redirect) 本意是想着能少用一个工具就少用一个，codex能一手包，何必多用一个呢？ 但很多人发了留言关于 AI 生成图片，再生成代码的工作流。我从留言中，发现最常见的误区其实不是工具选错了，而是顺序一开始就乱了。 如果只是生成一张图，很多工具都能做到。根据图片生成一段代码，现在也有不少工具可以试。 但真实项目里的页面，不是一张静态图。 它有业务目标，有模块优先级，有数据状态，有响应式适配，有组件复用，也有后续维护成本。 所以我更愿意把 AI UI 落地工作流拆成一条完整链路：先讲需求和目标，再落 UI Spec，再做视觉探索，再进入组件化实现，接着用截图对比把偏差一轮一轮收回来。 这篇就按这个顺序拆。 我把这套链路叫做 **AI UI 工作流** 。 它不是“先出一张图，再把图转成代码”这么简单，而是把页面从想法推进到可运行、可维护状态的一组步骤。 这条链路大致分成六步： 1\. 需求与目标：先讲清楚页面服务谁，解决什么问题，用户核心动作是什么。 2\. UI Spec：把页面拆成结构化说明，包括模块、组件、状态、响应式和验收标准。 3\. 视觉探索：基于 UI Spec 生成视觉参考图，看信息层级、模块关系和视觉风格。 4\. 组件化实现：用 Codex / Cursor 根据 UI Spec + 参考图落 React 页面，优先复用组件库。 5\. 截图对比与修正：用浏览器截图和参考图对比（script可以自动生成截图），逐项修正布局、间距、密度和状态。 6\. 交付与沉淀：把 Prompt、UI Spec、组件结构、mock 数据和修正清单沉淀成模板。 AI UI 落地不是图直接转代码。 最容易踩坑的地方，是图看起来没问题，真到实现阶段才发现结构和状态都不对。 ![图片](https://mmbiz.qpic.cn/sz_mmbiz_png/76wHjqI4MlRcpBVsibrbiazbKSsicNCfy6tFL4cTdM4mVVwicnw0TNtNcJBx6dRZkEDmYbVSrwX7Qv61QWnQM5ByZFgDpNuczYZZriaWZLtJM1j0/640?wx_fmt=png&from=appmsg&watermark=1&tp=webp&wxfrom=5&wx_lazy=1#imgIndex=0) 01 \-MaxKing.cc- ## 为什么一定要有工作流？ 很多人做 AI 页面，会直接跳到工具层。 用哪个工具生成图？ 用哪个工具把图转代码？ 要不要进 Figma？ 要不要直接丢截图？ Codex、Cursor、Claude Code 该怎么搭？ 这些问题当然重要，但如果没有工作流，工具越多，反而越乱。 因为 **出图、写代码、修页面，本质上是三个不同问题** 。 出图解决的是视觉方向。它回答的是：这个页面大概应该长什么样。 写代码解决的是工程实现。它回答的是：这个页面怎么拆组件、怎么接数据、怎么维护。 修页面解决的是落地偏差。它回答的是：生成结果和预期之间差在哪里，怎么一步步收敛。 ![配图1](https://mmbiz.qpic.cn/mmbiz_png/76wHjqI4MlQ8JxwKbtPSvesorsUZ05j9zPQwfUtib1ib3ic2ibEkp1bY1icMvMT5s6Wpuoy9oe1hZCs7J3VL4EkIFxaxKAOjaKdpgXnPnaDstnZ0/640?from=appmsg&watermark=1&tp=webp&wxfrom=5&wx_lazy=1#imgIndex=1) 一开始让 AI 生成图，图很好看；然后拿图去转代码，发现结构不对；再让 AI 改代码，它开始乱改；到头来还是自己手动调。 这类问题通常不是某个工具不行，而是前后步骤没有对齐。 所以我的判断很直接：AI UI 落地不能只靠单点工具，必须靠一套输入输出明确的工作流。 每一步都要知道： 这一环输入什么？ 输出什么？ 由谁判断？ 进入下一步的标准是什么？ 只有这样，AI 才不是“随机帮你生成一下”，而是能真正进入开发流程。 02 \-MaxKing.cc- ## 第一步：先拆需求与目标 我现在做 AI 页面，第一步不是打开图片生成工具，也不是打开代码编辑器。 第一步是先问清楚： 这个页面到底要解决什么问题？ 比如一个交易仪表盘页面，不能只说： 我要一个高级一点的交易后台。 这个需求太空了。 更好的拆法，是先把人和目标说清楚：这个页面给谁用？用户打开页面后最重要的事情是什么？页面最重要的信息是什么？用户有没有关键操作？页面做到哪一步，才算满足需求？ 比如交易仪表盘，它不是单纯“做一个好看的后台”。 更准确的描述应该是： 这是一个给个人交易者 / 专业交易员使用的账户首页，目标是让用户登录后快速查看账户风险、当前持仓、交易信号和最近活动。页面优先级是：风险预警 > 账户概览 > 持仓表格 > 信号面板 > 最近活动。 这段话看起来普通，但它会决定后面所有结果。 如果这一步不清楚，AI 会自己补脑。 它可能会把页面做得很炫，但风险模块不突出。 它可能会加很多图表，但真正关键的持仓信息不清楚。 它可能会做得像展示页，但不像一个真实可用的业务页面。 先把目标、用户、主路径和信息优先级讲清楚，后面的工作才有坐标系。 03 \-MaxKing.cc- ## 第二步：把需求变成 UI Spec 需求说清楚以后，我不会马上让 AI 画图。 我会先整理一份 **UI Spec** 。 UI Spec 就是写给 AI 和工程实现看的结构化页面说明书。 它关心的不是“好不好看”，而是页面目的、模块、组件、状态和布局。也就是说，它要把一个还比较模糊的页面想法，拆成后面可以直接执行的结构。 比如一个页面至少要讲清楚： 页面目的是什么？ 目标用户是谁？ 核心动作是什么？ 页面有哪些模块？ 每个模块是什么组件类型？ 有哪些状态？ 桌面端和移动端怎么适配？ 页面怎么验收？ 还是以交易仪表盘举例，可以先写成这样： YAMLMaxKing.cc ``` page: name: 交易仪表盘 purpose: 帮助用户快速查看账户风险、持仓和交易信号 target_user: 个人交易者 / 专业交易员 primary_action: 查看当前账户风险 layout_type: dashboard sections: - name: 账户概览 component_type: Metric Cards priority: high - name: 风险预警 component_type: Alert Card priority: high - name: 持仓表格 component_type: Data Table priority: medium - name: 信号面板 component_type: Signal Cards priority: medium states: - loading - empty - error - normal ``` ![配图2](https://mmbiz.qpic.cn/sz_mmbiz_png/76wHjqI4MlRGoJI09TrIcQlHpj7R8iaRvyuh4XD7lk8UxXdx3eibUwPvVE0oroAcibCIM8A6Eam22Xl18UB6VVDLjeY2etjqXoialDeBqBVOmjY/640?from=appmsg&watermark=1&tp=webp&wxfrom=5&wx_lazy=1#imgIndex=2) 这份东西的价值很大。 因为后面的视觉生成、代码实现、截图修正，都可以围绕它展开。 没有 UI Spec，AI 只能根据一句话或一张图猜结构。 有了 UI Spec，AI 至少知道这个页面应该怎么组织。 UI Spec 是这套工作流里最关键的中间层。 它解决的是： 从“模糊想法”到“可执行页面结构”的问题。 04 \-MaxKing.cc- ## 第三步：再做视觉探索 有了 UI Spec 以后，我才会进入视觉探索。 这里可以用 gpt-image-2 或其他图片生成工具。 但这一步的目标，不是让 AI 随便画一个“高级页面”。 我会明确告诉它： 这张图只是视觉参考，不是最终设计稿。 优先保证页面结构、信息层级和模块关系清楚。 页面要像真实 SaaS 产品界面，不要像概念海报。 不要过度科幻，不要复杂 3D，不要无意义装饰。 后续要能落到 React + Tailwind + 组件库里。 也就是说，视觉探索阶段主要看四件事。 第一，信息层级是否清楚。 用户第一眼能不能看到最重要的信息？ 第二，模块关系是否合理。 账户概览、风险预警、持仓表格、信号面板之间的关系是否清楚？ 第三，视觉密度是否合适。 交易仪表盘不能太空，也不能乱成一团。 第四，是否适合组件化实现。 卡片、表格、按钮、徽章、状态提示能不能拆成真实组件？ 这里有一个很重要的判断： 视觉图不是源头，UI Spec 才是源头。 图片只是帮助我们确认视觉方向。 它不能决定产品结构，也不能替代工程约束。 如果生成图有些细节很好，可以吸收。 如果生成图和 UI Spec 冲突，我会优先相信 UI Spec。 05 \-MaxKing.cc- ## 第四步：组件化实现 视觉方向确认后，才进入代码实现。 这一步我通常会用 Codex / Cursor 这类 coding agent。 但我不会只丢一张图给它。 我会同时给它： \* UI Spec \* 视觉参考图 \* 技术栈 \* 组件库约束 \* 页面状态 \* mock 数据要求 \* 验收标准 比如技术栈可以先约束为： TEXTMaxKing.cc ``` React TypeScript Tailwind CSS shadcn/ui ``` 同时要求它： 优先复用 Card、Table、Badge、Button、Tabs、Alert 这类基础组件。 不要为了还原视觉效果写一堆不可维护的代码。 不要把所有东西写在一个大组件里。 mock 数据集中放在 `mockData.ts` 。 页面必须支持 loading、empty、error、normal 四种状态。 响应式至少支持桌面端和移动端。 代码实现阶段的目标，是根据 UI Spec 做组件化实现，并尽量贴近视觉参考。 这里要接受一个现实：第一版代码通常不会完美。 它可能布局基本对了，但间距不够好。 它可能组件结构对了，但视觉密度还要调。 它可能桌面端能看，移动端还要优化。 没关系。 第一版最重要的是： 能跑起来。 结构是对的。 组件边界是清楚的。 状态没有漏掉。 后续可以截图修正。 06 \-MaxKing.cc- ## 第五步：截图对比与修正 很多人对 AI 页面失望，是因为他们期待一次生成完美结果。 我现在不这么期待。 我更关注它能不能进入一个稳定的修正闭环。 这个闭环是： TEXTMaxKing.cc ``` 参考图 ↓ 代码实现 ↓ 浏览器截图 ↓ 对比差异 ↓ 局部修正 ↓ 再次截图 ``` 这一步非常重要。 因为浏览器里的真实页面，和静态视觉图一定会有差异。 真实页面要处理宽度，要处理数据长度，要处理字体渲染，要处理不同屏幕，要处理 loading、empty、error 状态。 所以我会让 AI 或自己对比： 布局结构是否一致？ 模块顺序是否正确？ 主次信息是否清楚？ 卡片间距是否过松或过紧？ 表格密度是否合适？ 风险预警是否突出？ 移动端是否跑版？ 然后一次只修 3 到 5 个问题。 我不建议直接说： 这个页面不像，重新写。 这样 AI 很容易把已经正确的部分也改坏。 更好的方式是： 请不要重写整个页面，只修正以下 3 个问题：风险预警权重不够、持仓表格信息过挤、移动端卡片间距过大。修改后说明涉及哪些组件和样式。 AI 页面不是一次生成出来的，而是一轮一轮收敛出来的。 07 \-MaxKing.cc- ## 第六步：交付与沉淀 很多人做到页面能用就结束了。 但我现在更关注收尾一步：沉淀。 因为真正有价值的不是这一次页面生成成功，而是下一次能不能更快。 一个页面做完以后，我会尽量沉淀这些东西： 页面需求拆解。 UI Spec。 视觉生成 Prompt。 代码实现 Prompt。 组件拆分方式。 mock 数据。 截图修正清单。 验收标准。 比如交易仪表盘这次做完以后，后面它就可以复用到： 账户首页。 数据看板。 风控页面。 策略监控页面。 后台管理首页。 只需要替换业务字段、模块优先级和视觉风格，就可以快速生成下一版。 不是每次从零开始问 AI，而是把每次成功经验变成模板。 这就是 AI 工作流真正的复利。 我把这套流程整理成了一份《AI UI 落地工作流资料包》。 下一步可以这样做 收藏这篇，后面你做 AI 页面时，先对照工作流顺序再开工具。 如果你也在做页面落地，评论区说出你最卡的一步：需求、UI Spec、视觉、代码还是修正。 想看下一篇就关注，我会继续把 AI 页面前置判断拆开。 \- END - 关于 MaxKing宝藏 我是 MaxKing，全栈开发者、量化交易实践者，也是 AI 重度用户。这里分享的不是遥远概念，而是我在真实使用、搭建和踩坑后留下的判断。 如果这篇文章对你有启发，欢迎 **点赞、在看、转发** ，也欢迎加我好友交流 AI 工具和自动化实践。 AI UI 落地工作流实战：从漂亮图到可上线页面 · 目录 继续滑动看下一个 MaxKing宝藏 向上滑动看下一个 拖拽到此处完成下载 图片将完成下载 AIX智能下载器 保存