关于这个模板
这是 CoreOS 的首屏，连同生成它的那份需求简报一起发布，而不是只给一张截图。配色是黑色 #2E3233 打底。交付形式是 React 和 Tailwind CSS，收录于 1468x1080，所以画幅在任何一行代码写下去之前就已经定好。动效预算就是0.5s 的过渡、一段循环视频打底。这份参考是给这样的工业企业用的：希望首屏在动手构建之前就已经定下来。收录的提示词记录于 1468x1080，所以这一页引用的每个数值都能追回到它。下面引用的每一项都是那份简报里的数值，从 1468x1080 的画幅一直到最小的间距档。
适合谁
- 如果这个首屏有三个人要改，就给内容负责人固定 62px 的标题字号、14px 间距，而不是一张截图。
- 产品市场的人需要首屏在背后有4.9s 的循环视频时依然好读。
- 给正在做工业企业首屏、背后还没有设计系统的独立创始人用。
包含哪些内容
- 导航是刻意做细的. 导航只有一行，下面没有二级。到了平板断点以下，改由移动端浮层接管。导航条悬在 1468x1080 的构图上，自己没有底色，素材因此从它下面通到两边。
- 间距档位是写明的. 需求简报里的每个尺寸都是能反测量回去的数值：固定 62px 的标题字号、14px 间距、0.5s 的过渡。画幅比例和尺寸记在一起，重建时连比例也一起对。换字体、换文案可以，别换字阶。
- 一条会主动让开的导航. 导航只有一行，下面没有二级。到了平板断点以下，改由移动端浮层接管。导航条悬在 1468x1080 的构图上，自己没有底色，素材因此从它下面通到两边。链接控制在四到五个，这一行的尺寸就是照这个定的。
- 通栏视频垫在文字后面. 氛围交给一段 1468x1080 的 4.9s 片段；需求简报定死了它的裁切方式，文字则原样叠在上面。按 1468x1080 或更宽的尺寸导出，cover 裁切就继续成立。按 1468x1080 或更宽的尺寸导出，裁切才不失真。
动效与交互
是循环，不是时间轴
环境动感是一段 1468x1080 下的 4.9s 片段，在文案后面安静循环，不响应指针。因为是静音的，循环可以在文案下面跑，不抢声音，也不抢注意力。
状态变化也有时长
悬停、按下和聚焦都在 0.5s 内完成，界面因此显得即时。缓动和时长写在一起（0.5s），复刻时没法悄悄换成另一种手感。
在 CoreOS 里先改什么
代价是辨识度。 CoreOS 的东西留得太多，页面读起来就是别人的；保住数字、换掉内容，它就是你的。保住素材的裁切；它和字体承担的工作一样多。这份参考在 1468x1080 下收录。
CoreOS 怎么安排第一次阅读的顺序
这份需求简报有 5,790 个字符，把阅读顺序明写出来：导航、背景片段，中间用固定 62px 的标题字号、14px 间距隔开。工业读者先看到主张，再看到选项。
把 CoreOS 当规格书读
这份参考之所以能反复使用，原因就在这里：固定 62px 的标题字号、14px 间距、0.5s 的过渡。页面里没有任何一处交给默认值，所以替换之后只要保住这些数字，整套构图就跟着保住了。这个首屏里没有任何一处依赖默认值。
常见问题
这条 CoreOS 条目是怎么组织的？
页面上引用的内容全部出自收录的 5,790 字符简报，而不是事后补写的说明。数字和文字能对得上，原因就在这里。
CoreOS 背后那份需求简报里到底有什么？
它是构建简报，不是感觉描述：写明 1468x1080 的构图、间距和动效数值。全文没有一处把渲染画面当作事实依据。
重建 CoreOS 必须用 React 和 Tailwind CSS 吗？
CoreOS 是用 React 和 Tailwind CSS 构建的，条目标注只是说明出处。简报写的是位置、尺寸和时长，所以任何能设字体、能摆元素的前端框架都能重建。
