蛛网之上 Above the Web
源仓库 ↗

方法论与洞察

长期更新展示站:两层结构 + 无头卡片量产

入档:2026-06-19 来源:给《目标是成为 Prompt 大师》学员站(GitHub Pages)加第 2 期时的结构升级 性质:可迁移的内容站架构律 + 卡片量产技术

一句话

任何「长期一期一期往里加」的展示型站点(作品集 / 教程系列 / 案例库),首页都不要顺序罗列全文——改成「分类封面墙 + 详情」两层,数据驱动;配图卡用「HTML 复用站点 CSS → Chrome 无头截图」量产,不依赖图像生成或手绘。

背景:顺序罗列的必然崩坏

第 1 期时,index.html 把整期内容(封面卡 + 拆解卡 + 原图 + 操作区)平铺在一页里。一期没问题,但这是会持续更新的系列:到第 10、20 期,首页会变成一条几十屏的长卷,读者要找某一期得一路滚,首页也越来越重。

判据:只要内容是「单调增长」的,顺序罗列就是一颗定时炸弹。第一期就该按「将来有 50 期」来设计结构。

律一 · 两层数据驱动结构

把单页拆成两个视图,中间用 URL hash 路由切换:

  1. 首页 = 封面墙(catalog):一格一期,只放封面卡缩图 + 期号 + 分类标签。紧凑、恒定高度,不随期数变长。顶部一排分类筛选 chip,按主题筛(本例:抽象词破题 / 物件与尺度)。
  2. 详情页(detail):点封面进入 #ep02,才渲染该期的完整内容(双卡 + 原图 + 一键复制 + 笔记弹窗 + 点赞)。一次只加载一期,互不干扰。

关键:数据驱动,不是手抄 HTML。 把每期抽成一个 JS 清单数组(manifest)里的一条对象:

var EPISODES = [
  { id:"ep02", no:"第 2 期", title:"《童话镇里的纸飞机》", cat:"object",
    sub:"...", folder:"02_纸飞机",
    cover:"...封面卡.png", breakdown:"...拆解卡.png", original:"...原图.png",
    note:"...笔记.md", xhs:"https://...", prompt:"..." }
];

封面墙、详情页、筛选、路由全部由这个数组渲染。于是「新增一期 = 建一个文件夹放资产 + 在数组里加一条对象」——再不用复制粘贴一大块 <article> HTML,也不会漏改 id / data-target / 计数 key 这类唯一标识(旧的「复制 <article> 区块」做法每次都得手动改 5 处占位,极易出错)。

反直觉点:很多人升级时第一反应是「拆成多个 HTML 页面」。但静态站(GitHub Pages、无构建)下,单文件 + 数据数组 + hash 路由维护成本最低:公共的灯箱 / 弹窗 / 脚本只留一份,新增期零改动公共逻辑。

技术二 · 无头卡片量产(HTML → Chrome 截图)

系列每期要两张 3:4 卡(封面卡 + prompt 四层拆解卡),用作站内展示 + 小红书发布。产出方式:

  1. 用站点同一套 CSS 变量(四色系统、字体、留白)写一个卡片 HTML,html,body 固定成目标尺寸(如 600×800),overflow:hidden。
  2. Chrome 无头截图导出 PNG:
chrome --headless --disable-gpu --hide-scrollbars \
  --force-device-scale-factor=2 --window-size=600,800 \
  --screenshot="封面卡.png" "file:///绝对路径/card.html"

--window-size 决定版面尺寸,--force-device-scale-factor=2 出 2 倍高清(600×800 → 实际 1200×1600)。截图尺寸 = window-size × scale,所以让 body 尺寸严丝合缝等于 window-size,就能得到精确比例、无白边、无滚动条的卡。

为什么用它而不是 Pillow 逐像素画 / 图像生成模型:

(系列原有的 make_cards.py(Pillow)仍可用;HTML→无头 是同等有效、改版式更快的替代路径,二选一。)

踩过的坑(可迁移)

适用边界

关联文档

类型/协作工具链