这几期把 VibeBlog 开源过程一路写下来到本篇已经是第九篇前几篇都在死磕 Agent 的编排能力、记忆机制和工具调用链路功能攒得差不多了。但说实话每次打开博客页面我都觉得别扭——功能很“AI”界面却很“传统博客”。这期决定对前端做一次彻底的重新设计用的方案就是标题里说的:基于 ui-ux-pro-max 这套工作流让 AI 参与整个界面重构而不是只把布局裁一裁、颜色换一换。这期就把整个过程拆开讲清楚:为什么要重做、ui-ux-pro-max 到底解决了什么问题、我是怎么一步步把设计落地成代码的以及中间踩过的那些坑。适合正在做 AI 产品重构、想让 AI 深度参与前端设计、又不想把界面搞成“AI 味”模板的人参考。1. 为什么 VibeBlog 必须动这次前端:重构背后的真实驱动1.1 一个 AI 博客 Agent 为什么还需要“脸面”升级VibeBlog 从立项开始定位就不是普通博客它是一个以 Agent 为核心的创作与阅读工具。自动摘要、话题聚类、智能推荐文章、文章之间的关联发现这些能力都要靠 Agent 跑。第一版前端用的是常见的博客模板文章列表、详情页、标签页规规矩矩。但用户真正的使用方式和以往完全不同:读者进入一篇技术文章后更习惯直接向 Agent 提问“这篇文章和上一篇的结论有没有冲突”“帮我梳理里面的核心观点”甚至希望 Agent 在页面右侧实时生成思维导图。这种交互模式对前端提出了三个新要求。第一界面必须支持流式输出Agent 回答是逐字返回的页面得能平滑渲染。第二信息结构要重组普通博客的正文优先原则已经不够用现在需要正文、Agent 对话、关联内容三者动态平衡。第三视觉层级要为“阅读 对话”同时服务不能让对话面板只是附加品也不能让正文被挤到角落。老的模板界面做不到这些于是重构不是“想美化一下”而是功能倒逼设计升级。1.2 旧前端的问题清单与这次重构的边界动手之前我先做了一次代码与体验双维度盘点问题集中在三块。交互上Agent 对话入口被塞在页面底部每次提问都要滚动到最下面毫无存在感流式输出时整页重新渲染打字机效果卡顿。代码层面样式文件是按页面堆出来的主题色散落在十几个文件里改一个按钮颜色要全局搜索很多组件的 class 命名混乱改起来像拆炸弹。体验层面暗色模式是硬编码的没有跟随系统切换文章阅读排版也没有针对长文优化正文宽度直接铺满整屏行宽超过 90 字符根本读不下去。这次重构我给自己定了四条边界避免项目失控。第一不做功能重构Agent 的所有能力保持不变只改表现层。第二不换技术栈沿用现有的 Next.js React Tailwind 体系。第三不无限堆设计每页只保留一个核心任务视觉上做减法。第四所有设计决策必须能被“还原成参数”为后续开源社区自定义主题留好接口。这四条边界保证了项目不会走上“重写一切”的老路。1.3 为什么选定 ui-ux-pro-max 作为重构方法论一开始我也想过把重设计直接交给常规的对话式 AI——把我博客地址发过去说一句“帮我重新设计一下”。试了几次之后发现完全不行AI 给出的方案漂亮是漂亮但充满了“AI 作品”的套路:圆角卡片堆叠、玻璃拟态、大标题居中、渐变色块放在博客场景里既不符合阅读需求也没有记忆点。后来我梳理了一下问题症结:不是 AI 审美不行是我给的输入太弱。设计是一个系统工程需要用户、信息架构、视觉语言、组件规范、交互反馈一整套上下文普通对话给不出这种上下文。于是我开始尝试 ui-ux-pro-max 这套更结构化的设计工作流。它的核心思想是“把设计过程拆成可验证的环节把每个环节沉淀成 AI 能理解的规格”而不是依赖 AI 自由发挥。它能让你在一个可控的框架里获取 AI 的生成能力又不至于让设计长成一棵无人修剪的树。2. ui-ux-pro-max 是如何工作的:一套让 AI 深度参与设计的工程流程2.1 不只是提示词,而是设计工程流程很多人以为 ui-ux-pro-max 就是一段写得很长、很花哨的提示词这是误解。它本质是一套角色化、分步骤、带验收标准的“设计任务流”。我理解的 ui-ux-pro-max核心由五层组成。角色设定层给 AI 一个明确的身份——比如“资深产品设计师兼前端工程师”并要求它遵循设计原则而不是随口给建议。用户与场景层描述真实用户是谁、在什么情境下使用、核心任务是什么这一层决定功能优先级。结构清单层列出需要设计的页面与模块明确信息架构避免 AI 在真空中设计。视觉规范层包含设计 Tokens 的推导逻辑也就是色彩、字号、间距、阴影等基础变量要从“为何这样选”说清楚。验收标准层从美观之外提出可检查的指标——排版可读性、交互合理性、可访问性、延展性。每一层都会输出一个中间产物我确认后再进入下一层。这个流程解决了我之前用 AI 设计时“一步到位不可控”的问题。它不是让 AI 一次性给出终结方案而是像一个设计评审流程一样逐级递进每一步都有据可依。2.2 对比直接让 AI 设计的一个本质差异拿我之前踩过的坑来对比。常规操作是:给 AI 看现有网站截图 → 描述“我想要更现代的博客” → 让 AI 给出建议。结果它给出的方案连系统的字体变量都不知道更别说暗色模式下的对比度问题。你在执行层面还是要手动补齐大量细节。而 ui-ux-pro-max 的核心是把隐性设计经验显性化。比如在设计 Tokens 环节AI 需要给出一个完整的 token 清单包括主色、中性色、语义色在暗色与亮色下的具体色值并附带对比度计算确保正文与背景对比度至少达到 WCAG AA 标准。它不能只说“主色调为青色”它得回答为什么是这个色相、什么场景用 600 号色、什么场景用 700 号色。这种规格化的输出让我能从“改布局”深入到“搭设计系统”后期维护成本大幅降低。我总结的差异是:前者让 AI 设计一个页面后者让 AI 建立一套设计语言。2.3 这套工作流对个人开发者的实际价值作为独立开发者我没有人帮我做设计评审视觉能力也可能不专业这是项目开源后最容易被社区挑剔的地方。ui-ux-pro-max 对单人团队的价值在于:它把设计审查从“主观感觉”变成“客观规格”。我可以拿 AI 生成的规格去对照产品目标逐项确认而不是凭一句“我觉得挺好”决定页面去留。比如文章详情页设计时AI 最初把目录放在左侧固定栏然后问它为什么,它的回答是因为技术类文章用户常常需要跳读左侧目录符合阅读动线。但这个决策在移动端会失效,于是规则里补一条:目录在桌面端常驻平板端折叠移动端变成顶部悬浮入口。这种“原则驱动 场景推演”的流程比普通 AI 对话健壮得多。它让我这种没有专职设计的项目也能拿出能进社区的设计方案。3. 基于 ui-ux-pro-max 的完整重构实操:从信息架构到组件落地3.1 第一步:重新梳理信息架构与用户路径重构第一步不是打开 Figma 或者写 Tailwind而是梳理信息架构。我利用 ui-ux-pro-max 的角色设定让 AI 扮演“产品设计师”输入五类页面信息和四个核心用户任务要求它画出一份文字版信息架构。VibeBlog 的页面不算多但这六个页面的信息组织方式是重构的地基。首页:信息流文章卡片列表强化智能推荐的入口文章详情页:正文 左侧目录 右侧 Agent 对话区标签聚合页:标签要作为“主题”来呈现而不仅是标记关于页:个人介绍与开源项目的时间线Agent 面板:对话式交互全局可唤起不限于文章页设置页:主题切换、字体大小、阅读偏好信息架构之外的另一个关键产出是用户路径分析。AI 识别出三类核心用户并给出不同的行动路径。第一次来的读者路径是:信息流 → 一篇文章 → 随文对话 → 订阅或继续浏览。重度研究者路径是:信息流 → 文章详情 → 多文章对比 → 生成主题报告。开源贡献者路径是:首页 → GitHub 入口 → 项目文档。这三条路径直接影响导航设计——不能让“关于我”和“开源地址”这种低频链路占用主要视觉位置。3.2 第二步:构建设计 Tokens 与基础视觉规范信息架构确定后进入视觉规范阶段。我把 ui-ux-pro-max 的设计要求集中到两个维度:产品气质与可读性。VibeBlog 的核心气质是“锐利、清晰、冷静”不要拟物不要过度装饰要有工具感。可读性方面技术博客需要覆盖代码块、表格、引用块、行内代码排版密度要精准控制。颜色系统方面我决定从“品牌色 中性色 语义色”三层建立 token。品牌色选了一个偏冷的蓝紫色象征 AI 的智能感与专注感。语义色主要是成功、警告、错误三种状态用于 Agent 的各种反馈提示。暗色模式不是简单反色而要重新推导背景与前景的层级关系。亮色模式下正文主体采用深灰而非纯黑因为纯黑与纯白对比度过高长时间阅读会疲劳。字号系统我按 6 级设定从 caption 到 display正文设置为 16px行高 1.75保证中文排版的透气感。间距系统采用 4px 基数所有间距都是基数倍率。这些 tokens 最终写入 Tailwind 配置。下面是色彩 Tokens 的关键设定示例:// tailwind.config.ts 中抽取的关键颜色 token // 品牌色,主体为蓝紫,亮色模式主用 600,暗色模式主用 400 brand: { 50: #f0f2fe, 100: #dde0fc, 200: #c2c5f9, 300: #9d9ef4, 400: #7c7bed, 500: #645ced, 600: #5547e3, 700: #4939c8, 800: #3b30a3, 900: #2f2980, }, // 中性色,底色从浅到深,保证阅读对比度 ink: { 50: #f8fafc, 100: #f1f5f9, 200: #e2e8f0, 700: #334155, 800: #1e293b, 900: #0f172a, }, // 语义色,用于 Agent 状态反馈 success: #10b981, warning: #f59e0b, danger: #ef4444,字体与间距同样走 token 化。字体变量设计为font-sans、font-mono两套前者用于常规文本与标题后者用于代码、Agent 的“思考中”提示等场景。字号按 12、14、16、18、24、32 六级分布间距按 4、8、12、16、24、32、48、64 八级分布。整个过程要求 AI 每一步给出“选择依据”例如为什么正文用 16px因为主流阅读平台与中文排版实践均围绕 16px 优化低于 14px 会明显影响长文阅读体验。就是这样把审美问题转成可讨论的参数问题。3.3 第三步:四个核心页面的视觉重构实战规范就绪后进入具体的页面重设计。这一步我最满意的是文章详情页。桌面端采用三栏布局左侧目录最多 240px中间正文区域最大宽度 720px右侧是 Agent 对话区宽度 320px。移动端通过断点隐藏目录和常驻对话区改为浮动按钮唤起。这样既保住了阅读的沉浸感又让 Agent 功能始终在前台可见。首页的信息流卡片也做了大量减法。旧版卡片有封面图、摘要、标签、时间、阅读时长、作者头像六种信息太拥挤。我最终精简为“标题 摘要 标签 阅读时长”其中摘要由 Agent 自动生成最多两行超过截断。卡片点击区域是整个卡身而不是标题链接这符合移动端的点击习惯也减少了误触。标签聚合页则从“标签云”改成了“主题列表”每个标签附带 Agent 推荐的关联文章簇让标签从“分类标识”变成“探索入口”。Agent 对话面板是这次重构中改动最大的模块。老版本对话是独立页面切走之后上下文就丢了。新版本采用右侧滑出面板在任何一个页面都能唤出并保持会话上下文。为了实现流式输出我用fetchReadableStream读取 Agent 的 SSE 数据流配合状态库管理输出内容实时追加渲染。下面是核心的流式渲染代码片段去掉业务细节后是这个思路:// 流式读取 Agent 输出,逐段追加到对话区 const readStream async (stream: ReadableStreamUint8Array) { const reader stream.getReader() const decoder new TextDecoder() let buffer while (true) { const { done, value } await reader.read() if (done) break buffer decoder.decode(value, { stream: true }) // 每拿到一个完整数据块就追加渲染 const lines buffer.split(\n) buffer lines.pop() ?? for (const line of lines) { if (line.startsWith(data:)) { const data line.slice(5).trim() if (!data || data [DONE]) continue appendChunk(JSON.parse(data)) } } } }这一版设计对我的交互习惯改变很大。以前我写博客时会刻意忽略对话功能现在 Agent 区就摆在正文旁边写完一段就能顺手问它:“这段的论证逻辑完整吗”这种“边写边对话”的模式只有在视觉上把 Agent 提到一级位置后才真正成立。3.4 第四步:从设计到代码的落地机制设计 Tokens 与页面结构确认后最关键的问题是怎么把它们稳定地落到代码里。我先重写了tailwind.config把颜色、字体、间距全部映射成配置变量然后按组件而非页面来组织代码仓库。组件拆分遵循一个朴素的规则:一个组件只做一个事并通过 props 控制状态。比如文章卡片就是一个组件,接受article对象,内部根据有无摘要、有无标签自动渲染。这样重构过程中复杂页面本质上是“搭积木”而不是“写长 HTML”。重构过程中为了保证交互一致性我建立了三个文档:components 清单、states 清单、motion 规范。components 清单列出每个组件的全部状态比如按钮有 default、hover、active、disabled、loading 五种状态。states 清单规范空态、加载态、错误态的表现形式。motion 规范则写明动效使用原则比如面板滑出时长 200ms避免过度动画干扰阅读。有了这三个文档AI 生成的组件代码就能保持可持续维护的一致性。我大胆尝试了一个新体验:让 Agent 直接参与代码评审。重启前端后把自己当用户完成操作而 Agent 侧会在后台记录一些界面的渲染状态和交互热区自动提出“这一栏折叠后是否会被用户忽略”之类的问题。虽然这个环节还处在实验阶段但方向是对的——前端重构不只是静态页面转换它能为 Agent 提供更多交互上下文反过来让 Agent 更理解用户行为。4. 重构过程遇到的坑与排查思路4.1 AI 生成的方案“好看但不可用”怎么办重构中最容易出现的一类问题是:AI 输出的设计图在美学上特别统一但实际场景里根本站不住。典型例子是它最初给首页设计了 5 列的瀑布流卡片每张卡片只露出 200px 高度视觉上非常轻盈。但技术博客的标题本来就长5 列布局下标题每行只剩几个字,换行非常严重扫读效率极低。排查逻辑是这样的:先确认这是视觉问题还是信息架构问题。通过用户任务分析发现首页的核心任务是快速找文章不是看封面图因此卡片应该保持“标题优先 摘要辅助”的纵向密度。最终方案是把 5 列改成 3 列同时压缩装饰性元素让标题在一行内完整露出。这轮问题告诉我们:AI 可以给方向但信息权重必须由产品目标来定不能把设计稿当“答案”直接用。类似的坑还有“玻璃拟态滥用”。AI 在 Agent 面板设计上用了大量毛玻璃效果美观但会导致滚动阅读时底层的文字透上来造成严重视觉噪点。我最后的处理是保留玻璃拟态但大幅降低透明度并且在面板激活时给背景增加一层遮罩。这个案例里的经验是:面对 AI 的“装饰性冲动”要引入实际使用场景来检测而不是一眼看着漂亮就收下。4.2 风格一致性与组件复用问题重新设计过程中最痛苦的是组件状态不一致。同样一个“标签”首页卡片上是纯文本标签文章详情页变成了可点击的链接标签Agent 对话区里又变成了话题标签。三种标签长得完全不像用户会以为它们是三种东西。我通过 ui-ux-pro-max 的“组件清单”环节做了统一收口:全站只保留Tag一个组件用size和variant控制不同场景并且规定同场景下不得出现两种以上变体。组件统一带来的额外好处是主题切换变得非常简单——所有颜色都从 token 读取亮暗模式就是换一组 CSS 变量的事。我实测重构后全站组件数从原先的 47 个下降到 21 个视觉一致性提升的同时维护成本反而在降低。组件不必追求越少越好但要确保每个组件都有明确职责而不是新页面堆新文件。4.3 暗色模式的对比度与代码块可读性暗色模式是博客的前端标配但做的时候才发现最难的不是“反转颜色”而是兼顾对比度与可读性。我第一次测试暗色模式发现代码块区域特别刺眼:背景是深灰代码文字是高亮粉色和蓝色撞在一起根本分不清层次。后来分析发现我用的是亮色模式下的代码高亮配色没有单独给暗色模式设计一套 token。解决方式是为代码高亮单独建立一套暗色映射表在 CSS 变量中区分code-bg、code-keyword、code-string、code-comment。同时把正文的最小对比度锁定在 WCAG AA 标准。这里花时间最多的是调整代码注释颜色。太亮了抢正文风头太暗了又看不清,我最终选择了带一点灰绿色调的 comment 色,比正文暗两个层级但依然清晰可读。如果你也在做暗色模式,建议不要靠肉眼调色,直接用对比度计算工具验证每个文本层级的数值会让整个配色体系可靠很多。4.4 流式输出与渲染性能的取舍Agent 对话区改成流式渲染后性能问题也跟着来了。早期方案是每收到一个数据块就setState整体更新消息数组小文本没问题但当回答超过几百字时,页面明显卡顿。优化思路是“分块渲染 局部更新”:每次追加数据只更新当前正在输出的消息节点而不是重绘整个消息列表。这里有一个经验值得分享。React 的useState更新是异步且整体快照的如果频繁更新大数组会把渲染主线卡住。我把消息列表拆成了“已完成消息”和“流式消息”两部分已完成消息用普通 state 维护流式消息单独用一个 ref 指向真实 DOM 节点做追加写入性能直接上升一个量级。除此之外代码块的高亮处理也做了懒加载——只有当内容滚动到可视区时才做语法高亮避免了打开页面时大量同步计算导致的卡顿。前端重构往往不是设计完就结束性能调优才是真正让设计“立住”的关键一步。5. Agent 与前端边界重构:开源项目未来的想象力5.1 经历过这轮重构我如何看待“AI Agent 前端”的定位这轮重构做下来我对 VueBlog 的 Agent 定位有了一个新认识:Agent 不应该再寄生在页面某个角落它应该成为页面的一种“新的信息维度”。以往的前端偏重信息展示引入 Agent 后界面还承担了“帮助用户消化信息”的任务。所以 Agent 面板不是一个附加功能而是与正文信息平级的核心界面。基于这个理解在 Agent 对话区增加了一个“联想上下文”区域——它展示 Agent 当前正在阅读的文章线索以及它打算从哪些角度回答你的问题。这有点把 Agent 的“思考过程”给视觉化了用户反馈说这个设计让对话结果更有信任感。5.2 开源路线的下一步:让每个人都能“设计自己的 Agent 博客”这次重构还有一个未完成的目标就是主题可配置化。虽然我已经把颜色、字体、间距全部 token 化但主题切换目前只能通过改配置文件实现普通用户没法在博客后台可视化地定制。计划里下一步会做一套“可视化主题编辑器”把品牌色、字体、布局密度做成滑杆控件让用户像配置自己的博客主题一样配置 Agent 的视觉人格。这一环做完之后VibeBlog 作为“Agent 时代的个人博客框架”的定位才算完整。一个用户应该既能拥有强大的 Agent 写作助手也能通过简单的设置定制出属于自己的视觉风格。接下来的计划还包括:将这次重构沉淀的 ui-ux-pro-max 工作流整理成一份更通用的文档让其他开源作者也能用这套方法为自己的项目重设计前端;补充前端交互的自动化测试尤其是流式输出与可访问性相关部分;组件测试会引入 Playwright 做关键路径回归。5.3 对同样在重构前端的开发者说几句如果你也在做一个开源项目正在纠结要不要重构前端我的建议是:先把数据指标、用户问题和信息架构写清楚再让 AI 帮你设计而不是先截图给 AI 说“帮我做个更好看的”。ai-ux-pro-max 这套方法最大的价值在于它逼着你用产品思维来重新审视前端而不是被视觉带节奏。重构过程中我反复使用的动作是“问为什么”:为什么这个按钮要出现在这里为什么这个页面要三栏而不是两栏为什么这个卡片需要封面图这些问题看起来基础但一旦你把它们都回答清楚设计的高下就分出来了。AI 可以帮你生成一百种方案但它不会替你做产品判断。判断力仍然要长在项目负责人自己身上。这轮重新设计是我个人非常喜欢的一次“对抗失控”的过程。ui-ux-pro-max 没有让 AI 变成全自动的美工而是让我在一个可控的框架里把它变成了一位随时能出方案、但最终仍由我来拍板的设计师。VibeBlog 在功能上一直是 Agent 驱动现在它的视觉也配得上这个定位了。如果你在开源项目里也在尝试类似的 AI 参与设计的路线欢迎来 VibeBlog 仓库一起交流——前端重构只是开始Agent 与界面的深度协作还有很多值得往下挖的东西。