# 我让AI设计一个工具网站，结果让我重新思考UI

URL: https://caijiao.org/posts/182
Source: docs/posts/182.md
Description: AI 交出的第一版是顶部导航加 hero 加三栏特性卡加 CTA，标准得无从反驳，但把工具站当成品牌站设计就错了。Omni Calculator 把计算器抽象成配置、页面由模板生成，单个页面能吃到月流量 61086。

我把需求写得很具体："一个在线工具网站，要有首页、工具列表、单个工具页、定价页，视觉简洁现代。"

十几秒后拿到的是一个我形容不出毛病的东西：顶部通栏 logo 加六个导航项，hero 区一句 slogan 加一个渐变背景的 CTA 按钮，往下三栏特性卡各配一个图标，底部四列页脚。

挑不出毛病，问题恰恰在这——**它设计的是"一个网站"，而我真正要做的不是一个网站。**

## 工具站的单位不是网站，是入口

这批设计里最贵的错误是"首页 → 列表 → 详情页"这条路径。它假设用户会先认识你，再挑选功能。

工具站的用户不做这件事。他是带着一个具体的麻烦从搜索结果里点进来的，**他和这个站的第一次接触就是某一张工具页**。首页在他这次会话里根本不存在。

这对我手里这份设计意味着：那个三级结构里，**用户只会落在第三级**。前两级对他来说是隧道，每多一层就多一次放弃的机会。

而 AI 不知道这件事。它接受的是"设计一个网站"，于是它按完整的网站来交付。

Omni Calculator 把这个想得很透。它 2026 年 6 月的估算访问约 1429 万，覆盖 30 多种语言，而它内部真正的做法不是为每个计算器写页面，而是**把计算器本身抽象成一份配置——输入项、公式、单位、说明文案——然后由一个模板批量渲染出页面**。

![Omni Calculator 官网首页截图](/images/2026-09/omnicalculator.com.png)

*Omni Calculator 首页的分类卡直接标着数量：Conversion 329 个，Everyday life 393 个。*

这条路子反过来规定了 UI：既然页面是模板生成的，单个页面的布局就必须高度受限、可预测、不需要人工微调。

这份副产品其实是白捡的：页面之间的一致性由模板保证，等于把"视觉系统性"这个问题顺手解决了，不需要每个页面单独审美，只要把模板那一页做对。

## 一个页面能吃到的量，和"页面好不好看"没关系

页面上有一组数据很能说明问题：Omni Calculator 的 `/other/test-grade` 这一页，主关键词月搜索量 5900，带来的月流量是 61086。一个评分计算器。

一个单月六万的页面，UI 上大概只有几个输入框、一组选项、一个结果区。它的价值不在视觉，在**它精确对应了一个被搜的句子**。

想让这类页面被稳定收进来，页面的 HTML 必须在服务端或构建期就生成好，而不是靠浏览器跑脚本拼出来。工具页面上用 [JavaScript](/javascript/) 做计算和校验当然没问题，但骨架必须是直出的静态 HTML——这一点决定了技术选型，不是决定了 UI。

一致性高还有第三个好处：用户第二次来的时候不需要重新学习怎么用。TinyWow 挂了 250 多个工具、约 47% 的访问是直接访问（2026 年上半年第三方估算），而它的工具页长得几乎一样——对用户是熟悉感，对站长只是模板的副产品。

## 三栏特性卡是个特别糟糕的默认

这不是审美问题，是它占掉了本该给主操作的位置。工具页首屏的价值极高——用户点进来那一刻，注意力集中在"这件事能不能做"上，而三栏特性卡回答的是"这个站好不好"。

顺序完全反了。正确顺序是**先让人把手上的活干完，再考虑让他知道你还有什么**。

## AI 那版设计里唯一值得留下来的东西

从这个角度说，工具站在 UI 上真正要做的决策是**把可变的部分弄清楚，把不可变的部分一次做到位**。它顺手给了一个"结果区域 + 复制按钮"的结构。这个是我在几个站上验证过的：工具页的交互终点应该是**一个能被带走的结果**，而不是"点到第三步才能看到的东西"。

这个控件值得多说两句，因为有三处坑它生成时全漏了：复制成功之后要给可见反馈，静默复制用户不确定自己成功没有；在非安全上下文里 `navigator.clipboard` 不可用，必须留 fallback；移动端输入法弹出时，结果区经常被键盘挡住。这三处我是逐个设备试出来的。

## 重新想清楚的两条

第一条，工具页面的重心是"等待"。用户上传文件到出图之间那几秒，才是这个页面真正的界面：有没有真实的进度、失败了会不会留下可诊断的信息、大文件会不会让页面失去响应。图片重编码这类活挪到浏览器侧用 [WebAssembly](/webassembly/) 跑，等待时间能压到几乎为零，界面上连进度条都不必存在——这才是工具站该追求的 UI：**把等待消掉，而不是把等待设计好看**。

还有一个连带细节：只有把等待压到很短，"不需要上传"这条承诺才有意义。用户真正关心的从来不是数据存在哪里，而是**这个页面能不能立刻给我结果**。客户端处理最大的价值不在隐私，在省掉那一趟来回。

第二条，别设计一个"应用"，设计一组能各自独立存在的页面。工具集合的组织方式在[在线工具集合](/tool/)里有更完整的拆解，核心一句话是：每个工具自己就是一个完整的产品，删掉其他所有页面它照样能用。

通读一遍之后只剩一个结论：我把 hero、特性卡、FAQ 这三件套从提示词里删掉了，改成"每个页面只允许有一个主操作，且它必须在首屏可见"。生成的东西立刻变得不那么像模板。

---

*Omni Calculator 访问量、语言覆盖与单页流量数据来自 2026 年 6 月第三方估算与其公开案例。*