—— 「网页美学评论实习生」笔试小作业复盘
题目
这段时间投了某 AI 公司的网页美学评论实习生，收到的笔试题只有三句话：
The attached file is my business plan. Please generate a landing page for me, featuring a product demo. It should perfectly match the visual style outlined in the business plan.
附件是一份 16 页的 PDF：Notion 在 2013 年 3 月写给投资人 Elad Gil 的种子轮 BP。
题目短，一开始想这着实简单，我用我的工具链找个风格相似的页面拆个组件库，然后再对着微调组件库细节就好。一开始我也确实是这么做的，也实现了一个差不多风格的demo：
但思来想去总是觉得不太对，于是又对着笔试题逐字逐句想了半天，发现这里可能有两个小坑：
- "perfectly match the visual style"——风格还原的颗粒度要做到多细？
- "featuring a product demo"——翻遍 16 页，第 6 页 demo 页只有一行 "Notion demo"，是空白的。当年的 demo 是创始人当面演示的，也就是说：demo 不存在于材料里，得自己设计开发。
为什么组件库这条路走不通
我一直以来的前端研究方向是"组件库优先"：能够稳定复刻已知视觉效果、功能结构合理的网页，是优先的研究目标。这套思路里我也踩过实际的工程坑——组件库的数据结构和人类语义理解之间存在偏差，所以我针对组件库的开发范式做过基于组件库的数据归一化管理，让人类用户能用语义有效指导 AI 基于组件库做进一步的前端开发。
但这次，我的组件库一顿操作下来，产出和笔试题的要求相去甚远。我盯着那个"差不多风格"的 demo 想了很久，发现问题出在方法论本身：
组件库作为"强约束"范式，有一个致命弱点：组件库导致收敛。所有输出都拼同一批零件 = 风格同质化 = 这恰恰是 AI slop 的成因本身。而这道题要的能力正好相反——评价标准的任务是在任意风格内部区分好坏，而不是把"好"定义成某一种风格，否则训练出来的模型只会一种风格。
所以准确说，不是组件库没有语义，而是判断不存在于组件里，存在于"组件 × 情境 × 目的"的关系里。同一批零件，换个语境就是另一种判决。
这让我突然想起早期研究前端时做的一个实验：同一个 UI，在 tree / schema / browser / VLM / human 等不同评估层下，valid、survival、preference 状态可以完全不同，而且这种分歧一定程度上可以被系统测量。当时这个实验说明的是"在哪一层评估"会改变结论；放到这道题里，它说的是同一件事——"好不好"从来不是 UI 的内在属性，而是评估层和语境的函数。既然判断是关系的产物，那标准的质量就取决于一件事：写下这些判断的人，判断本身有多可靠。
顺着这个思路，我又找了几篇前沿论文大致读了一下，结论可以压成一句话：评价模型的上限 = 人类判断数据的质量上限。模型评得准不准，取决于喂给它的判断本身写得有多好。
于是问题转换成了：如何从一份 artifact（这份 BP）里提取标准 → 再按标准产出（landing page）。
先搞清楚："判断"和"评价标准"是什么关系
"可复用"指的是模型训练流水线能直接消费。脑子里"这个好看"是私人感受，训练用不了；必须走完这条链：
直觉判断 → 语义化（说出为什么）→ 结构化（维度、锚点、示例）→ 机器可消费的三种形态
三种形态对应训练的不同环节：
- 偏好对（A 优于 B + 理由）→ 喂给 reward model，或直接做偏好优化
- rubric + 分档评语→ 变成 judge 模型的 prompt 和 SFT 数据，让模型学会"自己评"
- 缺陷规则/反例→ 变成推理时的拒绝采样过滤器（best-of-n 里把 slop 剔掉）
还有一个隐含约束很关键：一致性。标准存在的意义，是让不同的人、或同一个人两次评价同一个页面，得出相同的判决。
先别写代码：把 BP 读成一份"设计标准"
如果直接开写，结果通常是"大概有点像"（组件库生成也是如此）。所以我的做法是：先把 PDF 当成一份待提取的评价标准，落成一份结构化文档，之后所有生成和验收都对这份文档负责，不再回查原 PDF。
这份文档的维度不绑定具体材料——换成任何一份视觉输入（BP、官网、设计稿），同一张表都能填：
- 语境：这是什么、给谁看、在什么场景被消费、要达成什么目的。判断永远先于风格——同一张卡片网格，在 SaaS 官网是平庸，在后台系统是合适。
- 结构：信息如何组织与展开——叙事线 / 浏览动线、信息层级、节奏（哪里停顿、哪里对比、哪里收尾）。
- 语言：可量化的视觉参数——配色（色值 × 用途 × 比例）、字体（字族 / 字重 / 字号阶梯 / 特殊字形）、版式（对齐轴、留白节奏、密度）、图形（图表、图标、插画的构造规格）。
- 规则：参数背后的使用逻辑——何时用什么（正向规则），以及绝不能出现什么（反模式清单）。规则让标准能迁移到原材料没有覆盖的新页面。
- 验收：把以上落成二元可勾的检查清单，并标注易错点（定量事实、映射关系、文本层细节）。
前三项回答"它是什么"，第四项回答"它为什么是这样、如何延续它"，第五项回答"怎么验证做对了"——对应判断的三段：是什么、为什么、怎么办。
落到这份 BP 上，这张表填出来是：语境——2013 年 3 月、写给投资人 Elad Gil 的种子轮 deck；结构——背景 → 使命 → 问题 → 方案（五层架构）→ demo → 三组市场的 "Today vs Notion" 成对对比 → 时机 → 路线图；语言、规则与验收的具体内容，见下面三节。
提取环节靠视觉模型初读，人工负责校对。那下一个问题就是：校对到底要校对什么？
校对这一关，眼睛大抵信不过
视觉模型（和人眼）在定量事实上都不可靠。这次我全部用像素采样和文本提取复核，抓到不少东西。
这份 deck 有三种红。 标题是珊瑚红 #FE6150；isotype 人形图标的红更饱和，#FB3A43；Markets 页的注释文字偏橙，#FF4012。只用"一个红色"，风格就先输一半。
市场数字的映射比看起来容易错。 第 7 页的文本提取出来是乱序的（"Office/Docs、Enterprise/SaaS、$22b+、$120B+/$14B、New"），初版生成时就映射错过。渲染原页才看清：Office/Docs 是 $22b+，Enterprise/SaaS 是 $120B+/$14B，Software Marketplace 没有数字，写的是 "New"。而且 Web Hosting 和 Office/Docs 两个市场名是灰色的——deck 在悄悄表达"这两个只是顺带的市场"。
文本层会暴露眼睛看不到的东西。 第 4 页金句的原文是 "sending Word documents arounds"——原稿有笔误。要不要在网页里复刻笔误？我的判断：题目要求匹配视觉风格，不匹配笔误，改回 around，并把这个取舍记进文档。又比如章节标签：文本层是小写、渲染层是小号大写（small caps）——text-transform: uppercase 和 small caps 是两回事。
不过校验也不只抓错，偶尔也有惊喜。 两个冷门颜色——Marketplace 页的浅青 #E3FCFF、Roadmap 页 Series A 节点的绿 #77BB41——采样后与初稿文档里的记录分毫不差，说明初读阶段是认真取过色的。
三个存在挑战的部分
一、demo 页是空白的，需要自己设计交互。
不能抄今天的 Notion（那是 2016 年之后的产品），只能从 BP 自己的愿景往外推：Visual Editor + Structured Content + LEGO for Software。最后做了一个可以在浏览器里直接玩的积木编辑器：从左侧加块、拖拽排序、点任何文字直接改、勾选待办——"软件是拼出来的，不是装出来的。"
二、isotype 图不是装饰，是产品叙事论证。
第 2 页 Background 用三组人形图标论证杠杆：2 个红色开发者 vs 80 个黑色知识工作者（4×20 方阵）vs 一片向右逐渐隐去的灰色网民（"200+"，多到画不下）。第 3 页 Mission 把整张图以极低透明度垫在 "Democratize Software" 下面，当作回声。
这个"低透明度"是多少？采样发现：黑色图标变成了 #B4B4B4，红色文字变成了 #FFD0CC——恰好都等于白底上 30% 的不透明度。于是 CSS 里一行 opacity: 0.3 精确复现，不用猜。
这里还有个教训。初版我把第 2、3 页整个漏掉了，还自己发明了一排 "80M / 2M / 200M+" 的红色大数字来代替。对照原文复盘才发现：原版的信息本来就由图标图承载，我加的数字条有点画蛇添足了。
三、设计约束部分。
这份 deck 的美学全部来自单一色相、超大留白、左对齐的编辑式排版。任何"顺手加上"的现代元素——圆角卡片、渐变、投影、居中 hero——都会瞬间破功。所以验收文档里专门有一节反模式清单：无渐变、无卡片、无投影、不加 BP 里没有的元素。
验收：把"我觉得像"变成 checklist
最后一步是对照结构化文档逐条验收。每条都是二元判断——"Mission 副标题为红色、无衬线、无句号：是 / 否"——成品与 BP 并排截图逐节对比，再过一遍移动端（手机上 isotype 的两组改成上下堆叠，4×20 与 4×12 的阵形保持不变）。
复盘
这份作业表面考前端，实际考的是把审美判断外化成标准的能力：先读懂一份材料的风格 DNA，写成可校验的文档，再让生成和验收都对文档负责。
组件库给的是"答案"，评价标准给的是"判据"。前者让你抄得像一次，后者让你在任何风格里都分得清好坏——这次用的是后者。
本页是这篇文章的静态镜像。在互动版中打开，可使用附件下载、作者署名与目录导航。