独立站点async.cat最近贴出一个总大小956字节的示例网页,同时上线了1kb.club,专门收录体积低于1KB的作品。作者的说法很直接:AI能免费批量产出网站之后,页面做得精不精致已经证明不了作者水平,唯一还没被模型学走的是取舍——敢不敢把一个字节都删不动。

这个判断值得琢磨,但它更像一份审美宣言,不是被验证过的行业结论。体积达标和作者有没有品味、是不是纯手工完成,是两件不能互相证明的事。

956字节是怎么算出来的,又漏掉了什么

原文没有说清956字节到底是页面源码、还是gzip压缩后的体积,更没说是否包含外部字体、图标这类资源。这三种口径差得可能不止一倍,直接套用会误导。

它也不等于用户实际加载时消耗的带宽——请求头、TLS握手、DNS解析这些成本不会体现在网页本体大小里。

从技能免费到字节签名 技能免费 AI批量产出代码 品味失焦 作品不再证明作者 硬约束倒逼 字节不能浪费 字节即签名 取舍变成可验证信号

956字节和常见的产品网页,本来就不是同一种"网页"。

维度956字节示例页常见产品落地页
目标秀极限压缩完成产品功能
依赖手写HTML/CSS,几乎零框架框架+图片+动效+懒加载
典型体积1KB以内普遍以数百KB起步,图片字体常占大头
安全校验/无障碍支持大概率精简或缺失通常是硬需求

两者谁也替代不了谁,拿其中一个的标准去套另一个,本身就是个错误比较。

体积达标证明不了品味,也证明不了纯人工

作者给了一个检验方法:删掉页面里任意一个字节,如果页面照样能用,说明之前留的是冗余;如果意义跟着一起消失,才说明这段是真被抠出来的。

删除测试:小而空 vs 小而密 小而空 字节数一样 内容大多是空白 删掉一段,页面照样活 =之前留的是冗余 小而密 字节数一样 每个字节都在承重 删掉一段,意义跟着消失 =这一段真被抠出来了 检验方法:删掉一个字节,看意义是否还在

这个检验方法能区分冗余和克制,但区分不了作者是谁。模型确实更擅长按常见套路生成偏冗长的实现,这一点没错。

但开发者完全可以让模型出草稿,再用压缩工具、反复测试把体积压到1KB以下。工具没有拒绝参与压缩,只是不会主动往这个方向走。"LLM做不出1KB网页"这句话站不住脚。

所以956字节达标,能证明的只是工程耐心,证明不了作者的审美,更证明不了这是纯手工完成的。

独立开发者和产品负责人该怎么看

对独立开发者和网页设计师,极简站点更像一份能拿出来验证审美和耐心的作品集。放进1kb.club,比简历上写"熟练CSS"更有说服力。

对产品负责人,这套标准不该拿来当前端性能红线。现代应用要背的安全校验、交互反馈、兼容性和无障碍支持,天然会撑大代码量。为了凑体积砍掉这些,砍掉的不是冗余,是可用性。

更实际的用法,是把它当成评估AI编程工具的一个侧面测试——看模型能不能配合人完成极限压缩,而不是把它当成下一代前端的性能标准。

接下来最该盯的变量,是1kb.club会不会补一套验证提交者是否人工完成的机制。如果没有,这场"字节竞赛"迟早会被同样擅长压缩的AI工具卷进来,身份信号也就跟着失效。