一、问题背景与分析
1.1 能力积累现状
Han Design 设计系统截至本次升级前已具备以下核心能力：
主题体系（20+ 套）：
- 历史文化主题：秦汉、魏晋、唐、宋、元、明、清
- 风格化主题：水墨、青绿山水、青花瓷、敦煌、武侠、茶空间、朱砂、青瓷
- 当代配色主题：松麦 pine-wheat、藤紫 plum-blush、海兰 ocean-orchid、焦糖 caramel-cream、薄荷 mint-lavender、莓果 berry-butter
组件体系（10+ 类）：
印章按钮、卷轴卡片、窗棂组件、屏风布局、册页组件、题签组件、纹样组件、图标集、动效组件、深色模式、局部主题隔离（data-han-scope）、无障碍检查
1.2 核心问题：能力越强，使用门槛越高
尽管系统能力丰富，但在真实用户使用场景中，暴露了严重的使用门槛问题。典型场景如下：
用户输入一句普通需求：「帮我把这个页面做得好看一点」
Agent 端会产生以下犹豫链：
- 是否需要询问用户选择什么主题？
- 是否需要询问用户偏好的历史朝代/文化范围？
- 是否需要确认前端技术栈（React/Vue/原生）？
- 是否需要确认视觉强度/装饰浓度偏好？
最终结果：Agent 向用户抛出一排（8~10 个）配置性问题，用户无法快速回答，体验断崖式下降。
1.3 问题根因分析
经过对使用文档和 Skill 行为的复盘，定位问题根源在于设计哲学层面：
设计系统一直在「增加能力」，却把「使用能力的决策成本」直接转嫁给了最终用户。
该问题可类比为：制造商造了一辆性能很强的汽车，但用户上车后，制造商不是直接提供驾驶操作，而是递出一本厚厚的说明书，要求用户先自行调整悬挂参数、点火提前角和变速箱逻辑——而用户的目标仅仅是「开车回家」。
由此确立本次升级的核心目标：
为 Han Design 补上一个「设计总监」角色——一个站在用户与系统能力之间，替用户看项目、做判断、选方向、组织内容、检查效果并交付成品的中间决策层。
本次升级代号：Han Design 「自动驾驶」升级。
二、改造方案一：取消用户问题轰炸，引入「内部设计简报」机制
2.1 改造前流程
用户自然语言需求 → Agent 识别信息缺口 → 生成多维度配置问题列表 → 用户回答 → Agent 基于回答生成页面
问题：信息缺口被转嫁给用户，用户需要成为「半个设计专家」才能回答
2.2 改造后流程
用户自然语言需求 → Agent主动扫描项目上下文→ 内部生成「设计简报」→ 基于简报直接生成页面
2.3 上下文扫描维度
Agent 在生成设计简报前自动扫描以下项目信息：
- 当前项目类型与文件结构
- 已有页面内容与路由结构
- 已使用的组件与布局模式
- 图片与静态资源情况
- 现有品牌语言（已存在的配色、字体、文案风格）
2.4 设计简报示例
设计简报是 Agent 的内部决策约束，不展示给用户，典型结构如下：
面向小型设计团队的产品落地页，核心动作是申请体验， 使用海兰主题 ocean-orchid，视觉强度 1（克制档）， 保留现有 React 表单结构， 避免千篇一律的霓虹 AI 视觉风格。2.5 决策触发阈值规则
仅当缺失信息确实会改变业务目标时，才向用户发起询问。
以下情况属于「用户不需要操心」的决策范畴，Agent 自行判断：
- 主题选择
- 字体方案
- 卡片/容器外观
- 是否使用印章/卷轴等装饰性组件
- 装饰性元素浓度
以下情况属于「应确认用户」的决策范畴：
- 核心 CTA（主要行动按钮）指向缺失
- 关键业务数据缺失且无法合理补位
- 品牌标识/合规要求缺失
三、改造方案二：四档视觉强度体系（装饰预算机制）
3.1 设计动机
用户无法准确理解技术化组件名称（如「卷轴卡片」「窗棂组件」「.han-frame-window 类」），但用户能够准确表达「想要轻一点」或「想要浓一点」的风格偏好。
3.2 四档视觉强度定义
| 档位 | 档位名称 | 装饰行为 | 适用业务场景 |
|---|---|---|---|
| 0 档 | 令牌层（Token Only） | 仅修改颜色变量、文字样式、间距、边框和交互状态，零装饰性结构 | Dashboard 后台、企业应用、管理系统、数据密集型页面 |
| 1 档 | 克制（Restrained） | 允许出现 1 处安静的编辑性装饰，不干扰信息阅读 | 产品官网、SaaS 落地页、个人作品集、B端产品介绍页 |
| 2 档 | 鲜明（Distinctive） | 可使用一组标志性文化结构作为页面特征 | 茶品牌、工艺品牌、服装品牌、文化机构、生活方式品牌站 |
| 3 档 | 戏剧化（Dramatic） | 全部装饰能力开放，追求最大视觉冲击力 | 节庆活动页、游戏官方站、展览专题页、娱乐营销活动页 |
3.3 档位自动映射规则
Agent 在无用户明确指示时，按以下规则自动选择档位：
- Dashboard 类页面 → 默认 0 档
- 产品/SaaS 类落地页 → 默认 1 档
- 品牌/文化/生活方式类 → 默认 2 档
- 节庆/游戏/娱乐/营销类 → 默认 3 档
3.4 机制核心价值
Agent 首次拥有了「装饰预算」概念：不是仓库里有什么就全部往上堆，而是按预算额度合理使用设计能力。
该机制有效避免了「设计翻车」的常见成因——每个能力都急于证明自身存在，导致过度装饰。
四、改造方案三：6 套完整页面 Starter 体系
4.1 改造动机
此前 Agent 从「零散组件库」直接构建完整页面，难度极高，结果往往呈现「东拼西凑」感。根本原因在于：页面体验的核心决定因素并非单个组件的视觉质量，而是整体结构。
页面体验的核心决定因素：
- 首屏比例（Hero 区域高度与内容密度）
- 内容密度（信息与留白的平衡）
- 章节节奏（信息块的排布顺序与节奏感）
- 卡片多样性（是否出现「卡片墙」同质化问题）
- 图片位置（视觉动线引导）
- 收尾动作（页面底部是否提供清晰的下一步操作入口）
4.2 6 套 Starter 详情
| Starter 编号 | Starter 名称 | 结构组成 | 适用场景 |
|---|---|---|---|
| S1 | 品牌落地页 | 导航栏 + Hero 首屏 + 品牌主张区 + 产品卡片矩阵 + 特性列表 + CTA 行动区 + 页脚 + 完整移动端结构 | 品牌官网、产品官网、服务介绍页 |
| S2 | 产品发布页 | 版本导航 + 发布亮点 + 特性对比表 + 变更日志（Changelog）+ 下载/接入引导 + 兼容性说明 | 产品版本发布、更新公告、升级介绍 |
| S3 | Dashboard | 侧边导航 + KPI 指标卡 + 数据表格（含响应式处理）+ 状态标签 + 风险提示区 + 空状态处理 | 管理后台、数据看板、运营平台 |
| S4 | 展览页 | 展品元数据卡片 + 时间地点信息 + 展品网格（含筛选）+ 来源/作者说明 + 参观预约入口 | 艺术展览、博物馆专题、产品陈列、线上展厅 |
| S5 | 节庆活动页 | 倒计时组件 + 权益/奖品卡片矩阵 + 营销区块 + 互动入口 + 规则说明 + 即时行动区 | 节日营销、活动运营、游戏专题、品牌周年庆 |
| S6 | 长文编辑页 | 文章标题区 + 目录导航 + 正文组件（引用/代码/图片/表格）+ 相关推荐 + 作者信息 + 互动区 | 博客文章、产品文档、教程专栏、深度内容 |
每套 Starter 均包含：真实可编辑文案、图片占位结构、响应式断点处理、移动端布局优化。
4.3 与此前模式的本质差异
| 维度 | 此前模式（组件库模式） | Starter 模式 |
|---|---|---|
| Agent 起点 | 拿到一堆「零件」 | 拿到一套「靠谱房型」 |
| 工作方式 | 从零拼装所有结构 | 基于房型做局部改造：拆墙、换材料、重新布置 |
| 结果可靠性 | 结构质量波动极大 | 底线质量有保证，上限取决于改造深度 |
| 失败率 | 高（易出现结构不合理） | 低（Starter 已验证结构合理性） |
五、改造方案四：内容草稿自动补位机制
5.1 设计动机
空内容做不出好设计。
若页面仅填充「品牌标题、产品一、产品二、了解更多」等通用占位文字，即使 CSS 设计再精良，最终呈现也只是一个「精致的空壳」。
5.2 补位内容规则
Han Design 根据页面类型自动补充可编辑的真实草稿内容，内容规则如下：
| 页面类型 | 自动补充的内容结构 |
|---|---|
| 茶品牌类页面 | 品牌主张（品牌故事）+ 产品系列（3~4 款产品卡）+ 产地介绍 + 工艺说明 + 冲泡/使用方式 + 购买入口 |
| 展览类页面 | 展览时间 + 展览地点 + 展品元数据（名称/年代/来源/规格）+ 展品背景说明 + 参观须知 + 预约入口 |
| Dashboard 类 | 真实标签命名（如「进行中/已完成/高风险」）+ 合理数据值 + 状态语义（如「正常/告警/异常」）+ 风险提示文案 + 空状态引导文案 |
5.3 事实红线（不可逾越）
内容补位机制严格遵守以下红线：
- ❌禁止编造奖项、认证、排名
- ❌禁止编造销量、用户数、营收等业务数据
- ❌禁止编造专家背书、名人推荐、媒体报道
- ❌禁止编造历史故事、品牌渊源、人物经历
原则：缺什么可以补结构框架，绝不能把 AI 想象包装成客观事实。
六、改造方案五：浏览器自审自改机制（视觉回看 + 迭代修复）
6.1 改造前流程
页面代码生成 → 静态语法检查（Lint）→ 标记为「完成」
问题：大量视觉问题（响应式溢出、对比度不足、信息隐藏）无法通过静态检查发现
6.2 改造后流程
页面代码生成 → 静态语法检查 →真实浏览器渲染（桌面端 + 移动端）→视觉回看规则检查→自动修复问题→ 重新渲染 → 再次检查 → 所有检查通过或遇到不可抗阻塞 → 标记为「完成」
6.3 视觉回看规则清单（9 项）
| 检查项 | 检查说明 | 判定标准 |
|---|---|---|
| 层级检查 | 标题/正文/辅助文字/注释的字号层级是否清晰 | 至少 3 级可辨识字号差 |
| 节奏检查 | 页面区块之间的间距节奏是否一致 | 不出现忽大忽小的异常留白 |
| 间距检查 | 元素内边距外边距是否遵循设计规范 | 对齐网格、无杂乱间距 |
| 字体检查 | 中英文混排、字号、字重是否合理 | 标题字重≥正文、字号不跳变 |
| 颜色检查 | 正文对比度、链接可见性、状态色语义 | 正文对比度≥4.5:1（WCAG AA） |
| 装饰检查 | 装饰性元素是否喧宾夺主 | CTA 按钮视觉权重必须高于装饰 |
| 图片检查 | 图片比例、占位、alt 属性是否规范 | 无拉伸变形、占位符统一 |
| 响应式检查 | 375px 宽度下是否溢出、布局是否为移动优化 | 无横向滚动、信息不被隐藏 |
| 交互检查 | 悬停/按下/禁用/聚焦状态是否完整 | 按钮/链接/输入框均具备四态 |
6.4 实际发现问题案例（来自 Starter 自检）
在本次升级中，该机制成功识别了「人工审查遗漏」的 3 个问题：
问题 1：对比度不足
- 场景：松麦主题下 12px 辅助文字
- 测量值：对比度 3.22:1
- 标准要求：≥4.5:1（WCAG AA 级）
- 修复方式：加深文字色值至对比度 4.8:1
问题 2：移动端水平溢出
- 场景：Dashboard 表格组件在 375px 宽度
- 测量值：页面横向溢出 359px
- 修复方式：增加表格横向滚动容器
问题 3：信息隐藏（二次发现）
- 场景：修复溢出后，「负责人/状态/截止日期」列进入横向滚动盲区
- 用户问题：无法直观感知「后面还有信息」
- 最终修复：移动端改为「逐行字段卡片式布局」，所有字段直接可见，无需横向滚动
七、改造方案六：工作流式默认提示词
7.1 改造前提示词
请做一个克制、可访问、有文化语境的中国风页面。问题诊断：方向性正确但完全不可执行。Agent 读完后不知道「先做什么、后做什么、做到什么程度算完成」。
7.2 改造后提示词（工作流式）
你是 Han Design 的设计总监。按以下工作流执行用户需求： 【第 1 步：项目诊断】 扫描当前项目上下文，判断页面类型、目标用户、核心 CTA。 【第 2 步：决策定档】 自动选择主题 + 视觉强度档位 + 最合适的 Starter 页面模板。 决策依据：第三节「四档视觉强度规则」+ 第四节「Starter 适用场景表」。 【第 3 步：内容补位】 按第五节「内容补位规则」，为页面补充真实可编辑草稿结构。 严格遵守事实红线：绝不编造奖项/销量/背书/历史。 【第 4 步：生成响应式页面】 基于选定 Starter 进行定制化改造，输出完整响应式代码。 桌面端断点 ≥1024px，平板 768px~1023px，移动端 ≤767px。 【第 5 步：浏览器真实检查】 打开浏览器，分别查看桌面端 + 移动端（375px 宽度）效果。 按第六节 9 项视觉回看规则逐项检查。 【第 6 步：迭代修复】 发现问题不算完成。必须：修复问题 → 重新渲染 → 重新执行失败的检查项。 循环直至：所有检查通过，或明确遇到权限/素材/业务信息缺失（需明确告知阻塞原因）。 最终交付质量标准：可直接上线的生产级页面。八、独立验证测试
8.1 测试设计
测试目的：验证「自动驾驶」机制是否在零上下文暗示的全新 Agent 实例中依然生效。
测试配置：
- 启动一个全新的独立 Agent 实例（无历史对话、无项目缓存）
- 仅输入一句普通需求（无任何主题/组件/参数提示）
测试输入（与用户实际使用场景一致）：
给一个年轻茶品牌做移动优先落地页，风格安静一点， 有产品卡片、产地故事和一个主 CTA，其他设计你自己决定。8.2 Agent 自主决策结果（正确）
| 决策维度 | Agent 自主选择 | 是否符合预期 |
|---|---|---|
| Starter 模板 | 品牌落地页（S1） | ✅ 正确 |
| 主题选择 | 松麦 pine-wheat | ✅ 正确，安静的自然绿匹配年轻茶品牌 |
| 视觉强度 | 2 档（鲜明） | ✅ 正确，品牌站适用 2 档 |
| 内容补位 | 3 张产品卡 + 产地故事 + 冲泡方式 + 价格 + CTA | ✅ 正确，符合茶品牌内容规范 |
8.3 异常发现与二次修正
Agent 按工作流执行至浏览器检查阶段，正确发现了以下问题：
- 发现 1 个严重对比度问题
- 发现 20px 移动端水平溢出
但出现了规则理解偏差：Agent 仅「报告」了发现的问题，未执行「修复 → 重渲染 → 重检查」的迭代流程，直接进入结束状态。
8.4 测试价值与规则修正
该测试的核心价值在于：
静态文档中看似明确的规则（「至少修改一轮」），在真实 Agent 执行中被理解为「发现问题并报告 = 完成复盘」。
基于测试结果，对第六步「迭代修复」规则进行了语义收紧：
修正前（模糊）：
检查完成后至少修改一轮。
修正后（明确）：
发现问题不视为完成。必须执行以下循环：
- 实际修改代码
- 重新渲染页面
- 重新运行之前失败的检查项
循环终止条件：
- ✅ 全部检查通过
- ❌ 或遇到「权限不足/素材缺失/业务信息缺失」的真实阻塞（需明确列出阻塞项）
同时在 Eval 自动化评估指标中新增checksPassed字段。评估标准由「声称检查过」升级为「检查问题均已修复」。
九、升级验证统计
本次升级完成后执行的全量测试清单：
| 测试类别 | 执行数量 | 覆盖范围 |
|---|---|---|
| 路由 + 自动驾驶用例 | 14 个 | 覆盖常见页面类型 + 边界场景 |
| Starter 静态检查 | 6 套 | S1~S6 全量 Starter 各一套完整检查 |
| 浏览器真实渲染测试 | 6 组 | 桌面端 + 移动端 375px 双端验证 |
| Skill 格式校验 | 1 套 | Prompt 格式、语法、参数引用正确性 |
| 示例站点校验 | 1 套 | 官方展示站点全页面回归测试 |
| 发布包复验 | 1 套 | NPM 发布包文件完整性、版本号、依赖关系 |
数字本身不是重点，重点是 Han Design 的产品评判标准发生了根本性迁移。
| 评判维度 | 升级前（旧标准） | 升级后（新标准） |
|---|---|---|
| 主题维度 | 主题数量有多少？ | 不懂主题的用户说「好看一点」，系统能否正确选择？ |
| 组件维度 | 组件种类有多少？ | Agent 能否自行判断组件的使用场景与用量？ |
| 能力维度 | 能不能做出中国风效果？ | 能不能把页面做完整、做合理？ |
| 自检维度 | （无自检机制） | 能不能「看见」自己的问题并修复？ |
| 交付维度 | （代码静态无误即可） | 能不能修到可直接交付的状态？ |
十、设计哲学总结与产品拐点思考
10.1 产品能力增长的两个阶段
大多数技术产品都会经历同一个拐点：
第一阶段：能力堆积期
- 核心策略：疯狂增加功能/主题/组件/模型/参数
- 增长逻辑：能力可量化、可截图、可展示、可直接宣传
- 用户感知：「产品越来越强大」
第二阶段：选择消化期
- 核心策略：替用户做决策、做判断、消化复杂度
- 增长逻辑：用户能否「少费脑子」完成目标任务
- 用户感知：「产品越来越好用」
用户最终不关心你的产品有多少能力，只关心他要做的那件事能不能少费一点脑子。
10.2 Skill 产品的本质：知识 + 决策
一个真正可用的 AI Skill（能力插件），不只是向 Agent 注入更多知识，更重要的是：
替用户消化选择——在正确的时机做正确的动作。
具体包括以下决策能力：
- 什么时候该问用户（信息缺失会影响业务）
- 什么时候自己判断（信息可从上下文推断）
- 什么时候必须克制（装饰预算不超支）
- 什么时候可以下重手（节庆/戏剧化场景）
- 什么时候必须回去重做（质量未达交付线）
这些看不见的「决策逻辑」，才是 Skill 中真正的产品价值。
10.3 Han Design 的新定位
本次「自动驾驶」升级后，Han Design 的产品定位发生迁移：
| 维度 | 升级前定位 | 升级后定位 |
|---|---|---|
| 产品性质 | 中国文化设计语言 + CSS 资产集合 | 可独立工作的设计总监 Agent |
| 用户交互 | 用户配置主题 + 选择组件 + 拼装页面 | 用户说一句话需求 → 系统交付完整页面 |
| 质量保障 | 依赖用户审美与技术判断 | 内置规则 + 浏览器自审 + 迭代修复 |
| 最终目标 | 提供设计素材 | 提供设计交付结果 |
当前系统仍不完美，距成熟的设计 Agent 还有较长的路要走。但本次升级完成了一个关键的体验拐点：
用户坐进车里，不再需要先学会调悬挂。
他只需要说去哪里。
Han Design 负责把车开起来。
资源获取
Han Design 「自动驾驶」升级版本代码、6 套 Starter 页面模板、视觉回看规则清单、示例站点均已随项目版本发布，可前往项目仓库查阅。
https://github.com/you-want/han-design
