企业官网建设流程全解析

• AI 技能
• AI 插件
• 前端

Broadside 是 frontend-slides 技能（bold-template-pack 模板库，共 34 款）中一款"抗议海报式"编辑排版模板。本文以模板库中的 preview.md 预览卡为绝对主线，讲解它在模板筛选阶段的定位、其"墨与火"设计系统快照（近黑画布 + 单一火焰橙、Barlow 巨幅小写字标、IBM Plex Mono 专用于 chrome）、中英双语 CJK 适配规则，以及从一张预览标题页到最终整副 deck 生成的完整衔接流程，并对照selection-index.json、design.md与deck-stage.js给出仓库内的源码级依据，帮助你完整理解并正确使用这套模板。

一、preview.md 在"渐进式披露"选型流程中的角色

frontend-slides的核心原则之一是渐进式披露（Progressive Disclosure）：先读取轻量级风格索引，用户做出选择后再加载完整设计文档，避免一次性灌输 34 套模板的design.md。SKILL.md的 Core Principles 第 4 条明确写道："For bold templates, use small preview cards for style previews and load the fulldesign.mdonly after the user picks that template."

在这个流程中，preview.md 是一张轻量风格卡（preview card），它开篇第一句就自我声明了职责边界：

Use this small file for title-slide previews only. For final deck generation, read the full design doc listed below.

即：preview.md只用于生成标题页预览；最终生成整副 deck 时，必须读取同目录下的完整 design.md。这份"预览 → 完整设计"的层级契约，在 bold-template-pack/README.md 的 Implementation Contract 中同样被反复强调。

1.1 与选型工作流的对应关系

按照 SKILL.md 的 Phase 2（Style Discovery）与 selection-index.json 的 usage 说明，模板进入实际渲染的完整顺序是：

1. 先读selection-index.json：只依据元数据字段（mood、tone、best_for、avoid_for、formality、density、scheme）圈定候选，绝不提前读任何design.md；
2. 对圈定的候选，只读其preview.md：预览卡只承载标题页信息，用于生成 3 份风格预览（1 个安全预设 + 至少 1 款 bold 模板 + 1 个通配项）；
3. 用户选定后，才读取恰好那一款模板的完整design.md，并按其字体、调色板、装饰词汇、间距节奏和组件语法生成整副 deck；
4. 全程不得批量读取templates/*/design.md，也不得在预览阶段读取template.html（仅当所选design.md缺失关键实现细节时才允许作最后手段参考）。

因此，preview.md 是整个 bold-template-pack 流程中"成本最低、决策最快"的一层信息载体——读者读完本文后，应能根据预览卡字段快速判断某场演讲是否适配 Broadside，并知道何时切换到完整设计文档。

二、选择元数据：用 8 个字段判断模板是否匹配

preview.md 的 "Selection Metadata" 小节提供了结构化匹配依据，selection-index.json中的 Broadside 条目（slug: broadside）与之一致。这些字段正是 bold-template-pack/README.md 要求"先从元数据短名单"时使用的：

选型建议：best_for只是软信号，判断核心是"内容是否该落地成一张 protest-poster / 报纸大标题"。如果演讲本身就是宣言式的（一句话就是整个构图），Broadside 高度适配；如果目标是沉稳的季度汇报或面向传统机构的材料，则应回避。

三、设计系统快照：墨与火（"ink on fire"）

preview.md 的 "Visual Snapshot" 与 "Preview Ingredients" 两节，把 Broadside 的视觉世界观压缩成一段可执行的预览配方：

一个基于巨幅 Barlow 字型与单一火焰橙环境色的 protest-poster 编辑系统。美学主张是"墨上之火"（ink on fire）——深色幻灯片用于记录（documentation），橙色幻灯片用于宣言（declaration）。展示级字型高达 13vw（1440 宽度下约 187px）、字重 900、小写，把文字当作图形元素而非阅读文案。文化参照是 broadside 印刷品、SPACE10 报告，以及用"一个响亮的颜色 + 零装饰"重新诠释的 Wim Crouwel 网格。

核心设计前提：字号大到让文字停止充当文本、开始充当图形基元（graphic primitive）。13vw 的 display 字级让视线先扫描字形、后阅读语义——这是该系统最主要的表达乐器。

3.1 预览调色板

橙色页上不存在第三个颜色，强调一律通过"深墨色在 75%/55%/40%/20% 四种透明度下"实现（rgba(17,17,17,0.75)等 ink-on-orange 覆盖层），这是 design.md 对预览配方在完整色板上的延伸。

3.2 字型栈与五个 Signature Moves

• 字型栈：Barlow（承载从 display 到 body 的全部文本角色）+IBM Plex Mono（仅用于 chrome：页码、kicker、标签、图注、列表斜杠标记）+Noto Sans SC（每个 font-family 栈中的 CJK 回退）。
• Signature move 1：Barlow 展示字重 900、小写——展示元素从不使用大写。
• Signature move 2：双色域——深色页配米白文字，或橙色页配深墨文字；不存在奶油/白色页面。
• Signature move 3：fire-orange在深色页是强调色、在橙色页是整个环境——永远thecolor，绝不当次要色。
• Signature move 4：单一字型体系（Barlow）+ 仅供 chrome 的 IBM Plex Mono；无衬线伴侣、无手写体、无第三字体。
• Signature move 5：1px 发丝分隔线提供全部层级结构（深色页#282826，橙色页rgba(17,17,17,0.2)）。

四、从预览卡到完整设计系统：design.md 的纵深补充

preview.md 明确指出："For final deck generation, read the full design doc listed below." 完整设计文档 design.md 在预览配方基础上提供了可生成整套 deck 的规格。下面是与预览主题直接相关的关键延伸。

4.1 双色域与默认值规则

系统运行在二元表面体系上：每个幻灯片要么深色、要么橙色。默认分配为——内容页默认深色底（ink-black），封面 / 章节 / 宣言收束 / 章节分隔页默认橙色底。颜色默认值一览（均来自 design.md "Defaults"）：

• 深色面：标题与正文用cream；强调色用fire-orange（kicker、强调数字、子弹标记、图表首条、引号标记）；分隔线用border-dark。
• 橙色面：标题与正文用ink-black；强调色就是深墨本身；正文用rgba(17,17,17,0.75)；分隔线用rgba(17,17,17,0.2)。
• .light类在源码中被有意别名为深色（源码注释确认"there are no cream/white slides"），因此不存在第三个表面色域。

4.2 完整字型刻度（Typography Scale）

预览卡只给出了字型与角色约定，design.md 给出 13 个可落地的字号令牌。下表是生成任意 Broadside 页面时可直接引用的刻度：

行高在刻度顶端被刻意压缩：display0.88、h10.9、h21.1，到lead才展开到 1.5+——顶部的压缩让展示字型产生"整体成型"的观感。

4.3 布局、深度与装饰词汇

• 内边距刻意比通用编辑系统更紧：pad-x5.5vw、pad-y5.5vh，巨幅字型应当"逼近画框边缘"；间距档位gap-lg3.5vh /gap-md2vh /gap-sm1vh。
• chrome 框架：顶部slide-chrome（左章节标签、右页码）与底部slide-foot两条 1px 发丝线；在封面、章节、宣言、引言、结尾等声明性页面完全隐藏，让字型独占全场。独立的broadside-num等宽目录编号常锚定在橙色封面左上角。
• 绝对扁平：无投影、无圆角（除 50% 的导航圆点）、无渐变；层级只靠字重/字号、1px 发丝线、颜色对比和负空间构建。
• 装饰元素清单：36×2px 火焰橙 stub 短标尺；等宽目录编号；仅上边框的 stat card；左右 1px 分隔的 compare 面板对（右侧可整块填充火焰橙作"after"面）；border-left竖向条形图（每图一条.accent火焰橙）；SPACE10 式 fadelist（1.0/0.5/0.22 三级透明度堆叠词）；火焰橙巨型引号 + 78% 列宽的引文；1px 描边框的等宽 mono 标签。
• 九个规范版式 + 三个扩展：cover、chapter、statement、split、stats、quote、list、compare、end，外加 fadelist、chart、diagram 扩展。迭代指南规定：内容页必须"kicker → h2 标题"开场；声明页必须用橙色色域；列表最多 3 项、用/斜杠标记；图表每图只许一根火焰橙强调条。

4.4 关键 Do's 与 Don'ts

Do：展示字一律 sentence case（小写展示是 Broadside 最具辨识度的单一决定）；chrome 一律 IBM Plex Mono 大写 + ≥0.1em 字距；火焰橙做深色页的唯一点缀；封面/章节页把橙色当整页环境；列表封顶 3 项；展示字全部负字距（-0.04em 起步、h2 至少 -0.02em）；所有结构划分只用 1px 发丝线。

Don't：展示字绝不大写（13vw 的大写 Barlow 会读成另一套设计语言）；绝不引入第二种强调色；绝不用投影/圆角/渐变；橙色页绝不用米白文字（"ink on fire" 是绝对律令）；绝不配衬线伴侣；一页绝不堆叠超过一个 display 时刻；chrome 绝不用 Barlow 渲染。

五、CJK 与中英双语内容适配

preview.md 的 "International / CJK Preview Note" 给出预览阶段的三个硬约束：CJK 字距保持 0、放宽行高、对 CJK 字串禁用 uppercase 变换。由于中文没有大小写，preview.md 还要求"选定后在完整 design.md 的 CJK 章节中取用精确字体配对"。

design.md 的 CJK 章节提供了完整配对方案（全部经 CDN 加载、无需安装）：

混排策略（Strategy A）：每个角色使用单一 CJK 字族，字族自带拉丁字形——Noto Serif SC 900 覆盖全部展示/标题角色、LXGW WenKai 400 覆盖正文、Noto Sans SC 500 覆盖 chrome。在<head>中加入：

<link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> <link href="https://fonts.googleapis.com/css2?family=Noto+Serif+SC:wght@400;500;700;900&family=Noto+Sans+SC:wght@400;500&family=LXGW+WenKai+TC&display=swap" rel="stylesheet">

通用 CJK 调整：行高比拉丁规格提升约 15–25%（body 1.75–1.85，display 至少 1.0，quote-mark 的 0.6 压缩行高在 CJK 下会重叠必须放开）；所有 CJK 字串字距置 0（负字距会叠笔画、正字距在方块字上显得松散）；移除全部text-transform: uppercase；使用全角中文标点（，。：；！？「」（））；展示级标题不加句尾"。；遵守"盘古之白"——中文与相邻拉丁字符/数字之间插入 ASCII 空格；一句话内保持单一字族，避免浏览器在中英文混排时中途回退到 Barlow。

已知缺口：CDN 上没有能完全复刻"Barlow 巨幅小写 + 900 字重"身份的简体中文展示字（中文没有大小写这个表达杠杆），系统会用"重型宋体宣言体"替代"小写抗议式呐喊"；/斜杠标记在中文语境下仍可保留，它是图形记号而非语言元素；霞鹜文楷在受限网络下可能加载失败，必须把'Noto Serif SC', serif留在 body 字栈作回退。

六、预览生成规则：怎样才算一张合格的预览标题页

preview.md 的 "Preview Rules" 小节定义了预览渲染的可验证标准，与 SKILL.md Phase 2 的 Preview authenticity rules（NON-NEGOTIABLE）完全一致：

1. 在固定舞台（fixed-stage）模型内构建恰好一张 1920×1080 标题页；
2. 保留前述调色板、字型角色、表面节奏与装饰词汇；
3. 使用用户的真实标题/副标题/上下文，不得复制演示用示例内容；
4. 渲染结果必须看起来像真实的第一页幻灯片，而非"模板选择卡"；
5. 页面上绝不出现内部工作流文本：preview、generated from、preview.md、template、preset、style option、Option A/B/C、文件名、路径或源文档标签；
6. 绝不把模板名或 slug 画在幻灯片上——只能在对话消息中提及；
7. 绝不把用户需求备注（期望氛围、受众、内部使用标签）直接当作幻灯片内容，除非用户明确要求原词出现在 deck 中；
8. 可见 chrome 只能使用真实 deck 内容：deck 标题、真实章节标题、日期、作者、公司、页码，或用户材料中的真实语句；
9. 预览阶段不得读取template.html，不得读取其他模板的design.md；
10. 用户选定该模板后，先读取完整design.md再生成最终幻灯片。

这组规则的价值在于保证"Show, Don't Tell"的体验不被内部元数据污染——预览页必须让用户看到的是"自己 deck 的第一页"，而不是"一张介绍模板的卡片"。

七、与固定 16:9 舞台政策的衔接

design.md 的 frontmatter 之后第一条就是Frontend Slides Fixed-Stage Policy，且明确声明其优先级高于源模板自身的响应式行为：当该模板被frontend-slides技能使用时，最终 deck 必须是一个固定 1920×1080 舞台，整体均匀缩放到浏览器视口；在包括手机在内的任何屏幕上保持 16:9，允许信箱/柱箱留边，但绝不为移动端重排内容。

这意味着 design.md 中一切vw/vh/clamp()值（如 13vw、5.5vw、0.72vw）都必须被当作"设计比例"翻译成 1920×1080 舞台坐标，而不是在最终 deck 里作为实时响应式规则保留。落地手段有两个：

• 使用deck-stage.js或等价的行内舞台缩放器：deck-stage.js 是一个<deck-stage>自定义元素（默认设计尺寸 1920×1080），内部以transform: scale()将画布整体缩放并 letterbox；幻灯片以visibility: hidden+opacity: 0隐藏而非卸载，以保留视频/iframe 状态；键盘支持←/→、PgUp/PgDn、Space、Home/End、R（回到第一页）与数字键；移动端提供左/右 1/3 点击热区；每次切换派发slidechangeCustomEvent；@media print按设计尺寸每页一张输出 PDF；noscale属性供 PPTX 导出器读取未缩放几何。
• 或在每个演示中完整内联 viewport-base.css：这是 SKILL.md 规定"必须完整包含"的固定舞台基础样式，负责锁定视口（html, body100% 且overflow: hidden）、.deck-viewport全窗容器、1920×1080 的.deck-stage画布、.slide的 visibility/opacity 切换（禁止用display:none切换幻灯片，否则后续布局类会把所有幻灯片同时显示出来）、打印规则以及prefers-reduced-motion支持。

生成最终 deck 后，必须在浏览器截图中同时校验文本溢出与面板重叠（scrollHeight检查不足以发现网格面板互相遮挡），并保持单文件自包含 HTML 输出。导出 PDF 可调用 scripts/export-pdf.sh，它会以 1920×1080 逐页截图合并输出（--compact可用 1280×720 压缩体积）。

八、相关文件索引

• 预览卡（本文主体）：preview.md
• 完整设计文档（选型后必读）：design.md
• 模板短名单元数据：selection-index.json
• 模板包读取契约：bold-template-pack/README.md
• 技能主流程：SKILL.md
• 固定舞台组件（1920×1080 缩放与导航）：deck-stage.js
• 强制内联的基础样式：viewport-base.css
• 配套支持文档：html-template.md、animation-patterns.md、STYLE_PRESETS.md

一句话总结：preview.md 把 Broadside 压缩成"双色域 + 巨幅小写 Barlow + 火焰橙唯一强调 + 1px 发丝线"的可执行预览配方，并通过一套严格的预览规则守住"真实第一页"的体验底线；当你选定它之后，再切换到一个完整、可生成整套 deck 的design.md规格，并在 fixed 1920×1080 舞台政策下落地为最终 HTML 演示。

• AI 技能
• AI 插件
• 前端