堆了 20 套主题、10+ 组件,用户还是用不出来?我给设计 Skill 加了「自动驾驶」

最近我一直在折腾 Han Design

它原本是一个给 AI Agent 用的中国风网页设计 Skill,里面有主题、颜色、字体、组件、纹样、排版规则,也有 han.csshan-scoped.css 这样的 CSS 资产。

东西其实不少。

但我越用越觉得不对劲。

能力越多,用户反而越容易不会用。

这就很尴尬了。

用户只是想要「好看一点」

场景特别简单。

用户对 Agent 说:

text 复制代码
帮我把这个页面做得好看一点。

然后 Agent 开始反问:

  • 要不要宋韵?
  • 要不要唐风?
  • 要不要水墨?
  • 视觉强度选 0、1、2 还是 3?
  • 要不要卷轴卡片?
  • 你现在用的是 React 还是 Vue?
  • 要不要局部主题隔离?

问题一个接一个。

不是哥们,人家只是想把页面改漂亮一点,怎么还得先考一个东方美学产品经理证书?

我后来想明白了,问题不在于 Han Design 能力少,而在于:

我一直在增加能力,却把使用能力的决策成本全丢给用户了。

主题多,用户自己选。

组件多,用户自己拼。

文化规则多,用户自己定。

接入方式多,用户还得先解释技术栈。

这就像你造了一辆性能很强的车,用户刚坐进去,你递给他一本说明书:

请先调悬挂、点火提前角和变速箱逻辑。

但用户只是想回家。

所以这次我停下了继续加组件的手,开始给 Han Design 补「自动驾驶」。

这次到底改了什么

这次一共动了 6 个地方。

改造 解决的问题
去掉问题轰炸,内部生成设计简报 用户不用回答一长串配置题
加入 0~3 档视觉强度 用「轻一点、浓一点」代替组件名
增加 6 套完整页面 Starter 不再从零散零件开始拼页面
内容草稿自动补位 页面不再只有几个空标题
浏览器自审自改 真打开页面看,发现问题就修
把默认提示词改成工作流 从一句口号变成一套执行流程

看上去像是在改 Skill 文档,实际上改的是产品体验。

第一刀,别再让用户填配置表

以前的流程是这样:

text 复制代码
用户提需求
  ↓
Agent 找信息缺口
  ↓
Agent 生成一长串问题
  ↓
用户回答
  ↓
Agent 才开始做页面

现在换成:

text 复制代码
用户提需求
  ↓
Agent 扫描项目上下文
  ↓
内部生成设计简报
  ↓
直接开始做页面

Agent 会自己看这些东西:

  • 当前项目是什么类型
  • 已经有哪些页面和路由
  • 现成组件能不能复用
  • 项目里有没有图片
  • 现在的品牌语言是什么
  • 这个页面最重要的动作是什么

然后在内部形成一个很短的判断,例如:

text 复制代码
面向小型设计团队的产品落地页,
核心动作是申请体验,
使用海兰主题 ocean-orchid,
视觉强度 1,
保留现有 React 表单,
避免千篇一律的霓虹 AI 视觉。

这个简报是给 Agent 自己看的,不拿出来折腾用户。

只有一种情况需要追问,缺失的信息真的会改变业务目标

主题、字体、卡片长什么样、装饰放多少,这些不该变成用户的负担。

第二刀,把视觉强度变成「装饰预算」

用户不一定知道 .han-frame-window 是什么。

但用户一定能说清楚:

我想要轻一点。

我想要明显一点。

我想要有点戏剧感。

所以我给 Han Design 定了 0~3 四档装饰预算。

档位 名称 怎么用
0 令牌层 只调整颜色、文字、间距、边框和状态,适合 Dashboard、后台
1 克制 放一处安静的编辑性装饰,适合官网和 SaaS
2 鲜明 加一组文化结构,适合茶、服装、生活方式和品牌站
3 戏剧化 装饰全开,适合节庆、游戏、展览和营销页

这套东西最重要的地方,不是多了四个数字。

而是 Agent 终于有了「装饰预算」这个概念。

仓库里有灯笼、卷轴、印章、屏风,不代表它们都该出现在同一个页面里。

设计翻车,很多时候不是能力不够,而是手里的能力都想证明自己来过。

第三刀,从一堆零件变成 6 个靠谱房型

以前 Agent 要从零散组件直接拼完整页面。

这事儿比看起来难多了。

页面好不好看,不是看某一个按钮漂不漂亮,而是看整体结构:

  • 首屏比例对不对
  • 内容密度会不会太挤
  • 章节有没有节奏
  • 图片放在哪儿
  • 卡片是不是全长一个样
  • 最后有没有明确的行动入口

所以这次直接补了 6 套完整 Starter。

Starter 适合做什么
S1 品牌落地页 导航、Hero、品牌主张、产品矩阵、CTA
S2 产品发布页 版本导航、亮点、对比表、Changelog、接入引导
S3 Dashboard 侧边栏、KPI 卡、表格、状态、空状态
S4 展览页 展品信息、时间地点、展品网格、预约入口
S5 节庆活动页 倒计时、权益卡、营销区、规则和行动入口
S6 长文编辑页 标题、目录、正文组件、相关推荐

每套 Starter 里都放了真实文案结构、图片占位、响应式断点和移动端布局。

以前是把一堆木板、螺丝、门把手递给 Agent,让它自己造房子。

现在是先给它一个靠谱房型,再根据项目情况换材料。

这个难度完全不是一回事。

第四刀,内容不够的时候,先把结构补上

有个问题特别现实:

空内容,做不出好设计。

用户说「帮我做一个茶品牌官网」,如果页面里只有:

text 复制代码
品牌标题
产品一
产品二
了解更多

那再好的 CSS,也只能做出一个精致空壳。

所以现在会按页面类型补内容草稿。

茶品牌会先补:

  • 品牌主张
  • 产品系列
  • 产地
  • 工艺
  • 购买入口

展览页会先补:

  • 展览时间
  • 地点
  • 展品元数据
  • 参观信息

Dashboard 会先补:

  • 数据标签
  • 表格值
  • 状态
  • 空状态文案

但这里有一条红线,不能碰:

  • 不能编奖项、认证和排名
  • 不能编销量、用户数和营收
  • 不能编专家背书和名人推荐
  • 不能编历史故事和品牌渊源

缺信息,可以补结构。

缺事实,不能瞎编。

这条边界我觉得挺重要。设计可以先搭起来,但不能拿 AI 的想象冒充品牌资料。

第五刀,别只跑静态检查,真的打开浏览器看看

以前的流程比较像这样:

text 复制代码
生成代码
  ↓
跑静态检查
  ↓
报告没问题
  ↓
交付

问题是,很多视觉问题静态检查根本看不出来。

比如:

  • 字体颜色对比度不够
  • 移动端表格横向溢出
  • 首屏按钮被装饰抢了注意力
  • 内容虽然没丢,但滚动以后看不到
  • 桌面端好看,375px 手机上直接崩掉

现在流程换成:

text 复制代码
生成代码
  ↓
静态检查
  ↓
浏览器打开桌面端
  ↓
浏览器打开 375px 移动端
  ↓
按规则逐项回看
  ↓
发现问题就改
  ↓
重新渲染,再检查一遍

这次自己写 Starter 的时候,真的抓到了几个问题:

  1. 松麦主题的 12px 辅助文字对比度只有 3.22:1 ,后来加深到 4.8:1
  2. Dashboard 在 375px 下横向溢出 359 像素
  3. 表格虽然能滚动,但负责人、状态、截止日期都藏在右边,手机用户根本看不全
  4. 最后把移动端表格改成逐行字段卡片,让信息直接可见

这个过程我挺喜欢。

不是我拍胸脯说「新版更好」,而是页面真的打开以后,问题一个个自己浮出来。

第六刀,把提示词改成真正能执行的工作流

旧版默认提示词大概是:

text 复制代码
请做一个克制、可访问、有文化语境的中国风页面。

听着没错。

但 Agent 看完以后,还是不知道下一步先做什么。

所以现在把它改成 6 步:

text 复制代码
第1步,扫描项目上下文,判断页面类型、目标用户和核心 CTA
第2步,选择主题、视觉强度和 Starter
第3步,按页面类型补内容草稿,遵守事实红线
第4步,生成桌面端、平板端和移动端页面
第5步,用浏览器检查桌面端和 375px 移动端
第6步,发现问题后改代码、重新渲染、重新检查

交付标准也说得更直白:

text 复制代码
不是「我看过了」就算完成,
必须改完、重渲染、重跑检查,
直到全部通过,或者明确说明真正的阻塞原因。

我还专门做了一次独立测试

为了避免自嗨,我启动了一个全新的 Agent 实例。

它没有 Han Design 的上下文,只给一句需求:

text 复制代码
给一个年轻茶品牌做移动优先落地页,风格安静一点,
有产品卡片、产地故事和一个主 CTA,其他设计你自己决定。

它最后自己做了这些判断:

  • 选了品牌落地页 S1
  • 选了松麦主题 pine-wheat
  • 选了 2 档视觉强度
  • 补了 3 张产品卡、产地故事、冲泡方式、价格和 CTA

入口算是通了。

但也暴露了一个问题。

它在浏览器检查时发现了对比度和 20px 溢出,却报告完问题就停了,没有把修复动作跑完。

这个坑很典型。

文档里写「至少修改一轮」,人看得懂,Agent 可能把「发现问题」理解成「完成复盘」。

所以我把规则改成了更硬的一句:

发现问题,不等于完成。必须改代码、重渲染、重新检查,直到全部通过,或者明确列出权限、素材、信息等真实阻塞。

现在评估指标里也加了 checksPassed

不能只说看过了,得真的修完。

评判标准已经变了

以前我会关注:

以前关注什么 现在更关心什么
主题有多少套 不懂主题的人说「好看一点」,能不能接住
组件有多少类 Agent 能不能自己做合理判断
能不能做出中国风 能不能把完整页面交出来
有没有静态检查 能不能看见自己的问题并修完

很多产品都会经历这个拐点。

刚开始,大家疯狂加能力,因为好展示、好宣传。

做到后面才发现,用户根本不关心你有多少能力,他只关心自己要做的那件事,能不能少费一点脑子。

Han Design 也是一样。

一个真正好用的 Skill,不只是往 Agent 脑子里塞更多设计知识,更重要的是帮用户消化选择:

  • 什么时候该问
  • 什么时候自己判断就够了
  • 什么时候必须克制
  • 什么时候可以下重手
  • 什么时候发现问题以后必须回去重做

这些看不见的决策逻辑,才是 Skill 里真正的产品价值。

还不完美。

距离一个成熟的设计 Agent,还有不少路要走。

但至少现在,用户坐进车里以后,不需要先学调悬挂了。

他说去哪儿。

Han 负责把车开起来。


项目代码、6 套 Starter、视觉回看规则和示例站点,都已经随版本发布。

项目地址:

github.com/you-want/ha...

如果你也在做 AI Agent、设计系统或者前端工程,欢迎在评论区聊聊,你现在最想让 Agent 替你消化哪一类决策?

喜欢这类分享的话,欢迎点赞、收藏、评论三连,也可以顺手给项目点个 Star。

相关推荐
贾天佑忆月 迷失的昵1 小时前
.NET Web开发技术简单整理
前端·.net
sg_knight2 小时前
Codex CLI 安装全攻略:macOS / Linux / Windows(WSL2)三端实战
linux·windows·macos·openai·ai编程·coding·codex
Cobyte2 小时前
Vite & Rollup 插件开发实践
前端·javascript·vue.js
朝阳392 小时前
react19【系列实用教程】实用组件封装
开发语言·前端·javascript
IT_陈寒2 小时前
React的useEffect依赖数组把我坑惨了,原来这样写才靠谱
前端·人工智能·后端
恋猫de小郭2 小时前
Flutter hit,一个可以灵活控制溢出点击的第三方包
android·前端·flutter
古韵2 小时前
小程序上传进度条,还要自己监听 onProgressUpdate 吗?
前端·javascript·uni-app
古韵2 小时前
axios 已经跑得好好的,还要不要上 alova?
前端·javascript·axios