大厂 Vibe Coding 网站生产级落地
封面图
这不是一个常规的 UX 设计案例。它是我第一次以「设计师写代码」的方式完整交付一个线上产品——AlphaClaw Hub Skill 广场,从设计到 Vibe Coding 到发布,两三天落地,并摸索出了一套在 AI 辅助开发中保持设计语言一致性的方法。
#1
项目背景
工作中需要快速交付一个 SkillHub 社区网站。但社区页面多、再画稿子的周期又长——加上 Hub 类社区已经有很多参考,这件事非常适合用 AI 来做。
Hub 类网站结构标准
社区类页面结构相对固定,AI 可以根据设计规范直接生成,无需大量手动排版。
没有历史包袱
从 0 开始,不用对齐旧组件和旧样式,Vibe Coding 的风险和成本都是最低的。
上线快,迭代也快
有新功能时可直接改代码,不需要再走「画稿 → 评审 → 实现」的完整流程。
工作流采用三人协作链路:产品经理提供原型 → 设计师接手代码进行 Vibe Coding → 前端发布上线。
1-1
#2
产品的原型有什么问题?
PM 给到的是一个完整可运行的 React demo,信息架构和功能模块已包含其中。但作为设计师,我还看到三个问题:
视觉语言不统一
浅色 shadcn 主题+Inter 英文字体,与 AlphaClaw 暗色品牌体系不符,用户切换到社区站点时产生明显断裂感
交互逻辑待优化
发布入口隐藏在右下角浮动按钮;探索页分类粒度过粗,核心功能曝光不足
信息层级不清晰
Hero 区数据、文案、命令行平均分配视觉权重,用户进入页面时无清晰行动指引
1-2
#3
VibeDesign — 基于设计视角的优化
我的工作不是「从零设计」,而是把一个「能用的原型」改成「符合品牌、符合交互规范、可以对外的产品」。
问题:Vibe Coding 过程中,AI 每次生成的样式可能不一致,怎么保证整个网站的设计语言统一?
方案:网站这类内容其实不太需要完整的组件库,我的做法是把设计规范直接给 AI 生成一个 Skill 文件,这样每次 Vibe 时 attach 上去,设计出来基本就能和现有产品保持统一的设计语言。
3-1
最近发现这其实和 Stitch 的 DESIGN.md 思路是一致的——谷歌官方也给了 DESIGN.md 的示例格式,可以根据这个参考使用。
3-2
为什么这样做有效:
- · 规范文件是文字格式,AI 可以直接读取和遵循
- · 一次沉淀,多次复用:每次 Vibe 新页面都 attach 这个 Skill,设计语言就能保持稳定
- · 本质上是把「设计师脑子里的规范」外化成了 AI 可以理解的格式
突出社区核心价值,引导用户加入
让用户第一眼看出这是个活跃的 AI 技能社区,并清晰知道如何快速接入
Hero 内容平铺,无视觉重心
PM demo 将 Hero 文案、数字统计、命令行三块内容平均排列,数字以纯文本呈现,用户进入页面时缺乏明确的行动指引
重构 Hero 视觉层级,强化行动点
命令行「Quick Connect」作为右侧主视觉;数字统计改为独立灰色卡片;文案、数据、接入三块形成清晰视觉层级
让用户快速识别技能类型与质量
浏览效率决定社区的内容消费深度,需要明确的信息层级帮助用户快速判断技能是否值得点开
卡片信息层级混乱,分类维度粗糙
官方认证标签和技能类型标签样式接近,视觉优先级不清晰;探索页分类只有 4 个大类,无法精准匹配用户真实意图
规范 badge 层级 + 细化分类标签
统一 badge 排列顺序(类型 tag → 官方认证 → 版本号);将探索页分类细化为 8 个场景标签,贴近用户真实使用场景
降低开发者发布技能的门槛
社区内容生产者的体验直接影响内容数量,发布流程需要足够顺滑
发布入口隐蔽,表单字段不完整
「发布我的技能」是右下角浮动按钮,仅滚动时出现;表单缺少版本号、GitHub 链接等开发者关键字段,且只支持 Web 表单一种方式
发布入口上移 + 重设计发布页面
发布入口移至导航栏常驻;左侧增加发布方式导航(Web 表单 / CLI);表单改为两列布局,新增版本号和 GitHub 仓库链接字段
#4
如何迭代新功能
首版上线后,需求迭代链路变成:PM 提需求 → 设计师拉代码分支 → 设计新内容 → 发到发布分支。
4-1
真实踩坑:看着流程很简单,真实上手了很久——要开通一个又一个的权限,差点放弃;层层流程下来到最后能拉到分支,实在不容易,让我真正理解了设计和开发之间「信息差」从何而来。
#5
最终成果
AlphaClaw Hub Skill 广场已上线,作为电商 AI 技能社区平台,用户可以发布、沉淀、管理和扩展各类业务场景下的 Skills,支持官方精选与社区开放投稿,Agent 可通过命令行一键安装。
5-1
点击访问线上网站