我们的 vibe coding 站点为何看起来像设计师做的

提到 vibe coding 出来的网站，你脑子里大概会浮现出这种东西： 示例用途的假网站（但它看起来很像一大堆并非示例用途的真网站） 不过，你现在看的这个网站也是我 vibe coding 出来的，而它长这样： 说实话，我自己觉得说它像设计师做的有点抬举了，但确实有人这么跟我讲！不少人跑来问我这网站是怎么做的，甚至问我跟谁合作的。 被问得多了，我就想挑战一下这个不可能的任务：把 Railcode 网站的创作过程完整讲一遍。 不是因为我自认多了不起，也不是觉得设计师没必要（恰恰相反），而是因为——大家聊来聊去都是 LLM 生成的设计垃圾，而我发现自己有了 coding agent 帮忙之后，对设计反而更来劲了。以前我束手无策，现在我能把脑子里的创意真正做出来。 所以我的目标是说明：你可以借助 coding agent 做出有品味的设计（有品味＝你自己喜欢），而且你完全应该放手去做。 为了写这篇文章，我把每一个原型连同生成它的原始 prompt 都整理进了一个索引页，这样我才能真正回溯自己的过程，让文章有据可依

一大堆过山车

Railcode 这个名字来自「code on rails」的想法。Railcode 里的应用和 agent 就是代码，我们负责基础设施和护栏（也就是那些 rails），让它们能快速部署到安全的环境里。 决定做网站的前一周，我意识到自己在 Railcode 里给自己搭东西搭得特别开心（我是活跃用户），问了问客户，他们说自己玩得也挺开心。 Rails + fun = rollercoaster，所以我决定网站上要有一辆过山车。 可我不是设计师，从零开始构思概念对我来说太难了。这意味着我得依赖案例和灵感。为此我有两个办法：

1. 在网上翻我喜欢的各种设计
2. 让 agent 把同一个东西用不同风格生成一大堆设计 目的是打开思路，看看有哪些可能性。大多数时候我会从好几个地方各取一点，拼起来，然后反复迭代到满意为止。大多数时候都是死路一条。 这次，最早的过山车设计长这样： ASCII 风格的那两个（上面两个）灵感来自我当周早些时候看到的朋友的网站。其余几个我交给 Fable 自由发挥。它们的作用是作为灵感的种子。 这里面有几个因素帮到了我：

• 强度分级： 我会让 agent 拿一个概念／想法，生成一批落在强度／复杂度光谱不同位置上的设计。这样我既能判断这个概念整体上是否有意思（如果光谱上没有一个我喜欢，那多半是我选错了光谱），也能判断自己是不是想把这个概念做得更极简，或者还有空间往更疯的方向走。
• 放飞自我： 试一个概念时，我通常会向 agent 要至少 4 个版本，有时甚至 10 个。其中至少一半我会给出一定程度的指引，剩下的就让 agent 自由发挥。大多数时候这些版本烂得彻底，但它们能擦出火花，催生新想法。 你大概能看出来，那个又疯又丑的霓虹设计就属于「放飞自我」的部分，我永远不会真的用它，但它把我从 ASCII 的思路里拽了出来，转向了更有野心的东西。

Rollercoaster Tycoon

我小时候常玩一款叫 Rollercoaster Tycoon 的游戏。目标（至少对我来说）是造出最酷的游乐园。就像你在上面看到的，你可以造出特别✨有美感✨的园区。

看着 Claude 造出的那坨霓虹怪物，我想起了这款游戏，于是我知道，我的网站要致敬它。

所以一开始，我让 Fable 给我搭了个迷你版游戏：

“做一个类似 Rollercoaster Tycoon 的自包含组件，让我能在 html 里直接玩——其实做两个并行的版本。其中一个要有透明背景”

这挺酷的，有那么一瞬间我以为我的网站里真会塞进一个游戏，但玩了一会儿之后我意识到，这有点过头了。

于是我回到原点，决定只挑一个我真正喜欢的过山车。试了足够多次之后，终于有了这个：

定下它的时候，我以为完事了。甚至直接把过山车往模板上一贴，一度觉得就这样吧。

这确实挺酷，但一个过山车杵在网站正中间算怎么回事？格格不入。

显然，我们需要一整个园区。

脱轨

决定要一个园区之后，我莫名觉得它得放在 hero 的底部。我确信这是受了以前见过的某些网站影响，但一个都想不起来。

于是就有了这条横带：

“加一条大概 200px 高的细横带，放一堆游乐园设施，风格和过山车一致”

到这里你能看出雏形了，但放到网站上还是很难看：

注意，此时我已经在并行推进，想清楚了要加 coding agents 板块，正在做那部分的组件

在此基础上继续迭代，就得到了这个：

走到这一步，我的做法是：把素材设计锚定在之前那个过山车上，逐个挑选并打磨每一段动画，并且认定这条条带不该独立存在，而应该是通向下一个区块的颜色过渡。最后这一点，我确信是从某些网站上看到的，但一个都想不起来是哪几个。

分叉之上再分叉

定下最后那版设计时，我特别满意，还马上拿给一个朋友看了。但总觉得哪里不对，于是就有了这些分叉。 做网站时，我会一直只用一个 HTML 文件，直到基本可以上线，才把它拆成 React，分成各种组件，让 agent 并行去改。 这样做的好处是，复制一份设计、改一两处、并排对比，速度非常快。

我还会搭所谓的“playground”，用来试颜色和其他变量。 这次我先把手头的草地颜色从蓝色改成绿色（草是绿的，废话），但调出来的绿并不是我想要的那种。于是我让 Claude 搭了一个 playground，可以在里面试不同的强调色、文字色、草地色、背景色等等，最后才定下我想要的那种草色。 （我甚至有点想做个开源小工具，专门用来管这些分叉和 playground。等有空了也许试试。） 草地搞定之后，我开始抠细节。 在转向过山车这个方向之前，我其实是先让 Fable 做了“一个开发者工具网站的有趣 mockup”，由此开启的整个流程。那些 mockup 基本都是垃圾，但在琢磨 CTA 怎么设计更好时，我想起自己见过一个很合适的东西：

这就是为什么要在流程早期多看设计，哪怕它们很糟糕。后面说不定就能从一堆草稿里翻出个宝贝。 另外，白色背景让网站显得不好玩（而我想要的是好玩），所以我把它改成了天蓝色，又加了几朵云烘托气氛：

从白到蓝，效果天差地别

剩下的就顺理成章了。首屏定调，整个网站跟着走。 Railcode 产品 现在的强调色是蓝色，但网站上的绿色来得太自然，我干脆顺势接受，没有硬掰回去。于是就有了浅绿和深绿两个区块，最后连页脚的土壤也这么来的。这么一来，产品本身的设计可能也得重新看看了…… 网站其余部分还是改了很多轮，但风格大致定型之后，做新图标和素材时就能随时参照。先把调性定下来很重要，因为这样才有明确的方向感。 不过细节永远抠不完。最后一个例子是导航栏：固定的颜色总觉得不对劲，于是我让它根据当前所在区块，渐变到对应的背景色。在我看来差别巨大！

白色、浅蓝、浅绿、深绿我都试过固定版本，最后发现最好的方案就是全都要

灵感

前面说过，作为非设计师，从现成的作品里找灵感是我创作流程中必不可少的一环。而清晰的范例，也是给 coding agent 指方向的最好方式。 有时候你会做出跟参考对象非常接近的东西，比如这个浅色区块转深色，本身是挺常见的模式，但我经常参考的是 Contextual AI：

左边是 contextual.ai，右边是 Railcode 网站

但有时候灵感来源没那么明确。比如 Railcode 的这个区块，其实是受 Clay 启发：

左边是 clay.com，右边是 Railcode 网站

我也一直在大量浏览各种网站，即使最后没有用到其中任何具体的东西，它们依然对我有影响。Railcode 的网站和 Sentry 完全不像，但我一直看他们的网站，去感受那种与内容契合的插画风格。

午夜过了 30 分钟：“more”

还有很多可以说的，但我觉得这篇已经太长了。所以如果要总结我认为自己流程中最关键的部分，就是：

• 做设计时我只用 Anthropic 的模型。我发现 OpenAI 的模型即使给了具体方向也很难做好。Fable 是最好的。
• 在满意设计、准备处理文案之类的东西之前，我把所有内容都放在一个 HTML 文件里。
• 我看 大量 网站找灵感。我会经常回看自己喜欢的网站，也不断寻找新的。如果特别喜欢某个组件，我会把它作为基础，在上面继续搭建。
• 一开始我让 Claude 生成大量不同的网站，最后 99% 都扔掉，但偶尔会从里面拿一个组件出来，或者只是得到一个可以试试的新想法。
• 我经常让 coding agent 对几个设计“放开手脚”，也会让它们从一个想法的种子出发，做出一系列从极简 -> 夸张的多个版本。
• 我喜欢让自己的过程留下容易查看的痕迹，所以我会不断“fork”一个设计，改几处，再和原版对比。之后我可能继续在 fork 上做，也可能回到原版，但从不删掉任何 fork。
• 我会搭 playground，在里面轻松试颜色、字体和位置，实时看到结果，而不是走让 agent 改东西那种缓慢的迭代流程。
• 我迭代，迭代，再迭代。大多数迭代都是死路。

最重要的是，我在这个过程中玩得很开心 :)

POV：Fable 挑大梁时的我