ARMOR 详情页面首屏体验研究与设计原则
1. 文档目的
本文档总结 ARMOR 官网在详情页面，尤其是文章详情页首屏体验方面的研究结论，用于后续新会话继续讨论、设计和开发。
本阶段的核心不是追求高度定制化的视觉设计，而是先建立一套稳定、清晰、可复用的首屏设计原则：
首屏空间极其宝贵，必须优先展示对用户和 ARMOR 都最有价值的信息，并尽可能降低用户开始阅读、理解和行动的成本。
当前项目仍处于基础开发阶段，因此实现策略必须优先复用 ARMOR 当前能力、AstroWind upstream 组件和 Astro 原生能力，避免过早造轮子。
2. 为什么首屏如此重要
首屏是用户进入详情页后无需滚动即可看到的区域。
它承担两个同时存在的任务：
- 帮助用户快速确认“这个页面是不是我想看的”
- 帮助 ARMOR 在不干扰用户主要任务的前提下，展示最重要的商业信息
对于文章详情页，用户进入页面后的第一目标是阅读，而不是欣赏页面结构，也不是先完成商业转化。
因此首屏设计必须优先回答：
- 这篇文章讲什么？
- 这是不是我需要的内容？
- 谁发布的 / 什么时候发布的？
- 阅读成本大概是多少？
- 我能不能马上开始阅读？
- 如果文章较长，网站能否帮助我快速找到需要的章节？
如果这些问题不能在很短时间内得到答案，用户就会产生浏览成本。
3. 当前 ARMOR 文章详情页暴露出的核心问题
此前 ARMOR 文章详情页在多轮调整后出现了明显的“结构叠加”问题。
典型流程接近：
Article Header → Breadcrumb → Category → Title → Excerpt → Meta → Tags → 巨大的 Featured Image → TOC → Article Body → Related Product Collections → Latest Articles → Inquiry → Related Articles
这导致几个严重问题。
3.1 Time to Content 过高
用户进入文章后，需要滚动很长距离才能看到真正的正文。
在当前某些页面中，甚至需要滚动接近两个屏幕，才开始看到文章文字内容。
这意味着用户在真正消费内容之前，先被迫经历大量“页面结构”。
这与文章详情页的核心任务相冲突。
3.2 Featured Image 变成了进入正文前的一座“大山”
文章配图本应帮助用户理解内容。
但当前 Featured Image：
- 尺寸过大
- 占据大量垂直空间
- 与正文视觉上脱离
- 更像一个独立 Hero Section
- 把文章正文继续向下推
问题不是“文章不能有大图”。优秀的网站同样会使用大图。
真正的问题是：
图片是否属于文章阅读流，还是成为用户开始阅读之前必须跨越的障碍。
3.3 页面被拆成多个互不关联的 Section
当前文章页面视觉上更像：
Header Section + Image Section + TOC Section + Article Section + Discovery Section + Inquiry Section
而不是：
一篇完整、连续、稳定的文章。
用户阅读时缺少明确、稳定的阅读轴。
3.4 宽度体系混乱
此前页面同时存在多套宽度逻辑，例如：
- Header / Hero 使用一套 max-width
- 阅读外层使用另一套 max-width
- 正文内部 p / ul / ol / blockquote 再单独使用 max-w-prose
- 文章结束后重新建立第二套 Grid
结果是：
- 正文过窄
- 删除右侧 Sidebar 后，空间仍未真正交给正文
- 右侧出现大量无意义空白
- 图片、标题、正文、TOC 缺少统一几何关系
- 页面看起来“每个模块都在自己找位置”
4. 从优秀文章详情页得到的核心启发
我们参考了 QTL 等成熟网站的文章详情页。
真正值得学习的不是具体配色、尺寸或组件样式，而是它们对首屏信息优先级的处理。
优秀页面打开后，第一屏通常已经包含：
- 配图
- 标题
- 作者 / 时间
- 阅读时长
- 摘要或价值说明
- 正文开头
同时，品牌希望展示的信息也可以出现，例如：
- Products Featured in This Post
- Subscribe to Our Newsletter
关键点是：
商业内容与阅读内容并行出现，而不是排在阅读内容前面。
用户不需要先通过一堆商业模块，才能开始阅读。
5. 首屏设计的核心原则
5.1 First Fold Reading Rule
文章详情页应建立一个硬性验收规则：
正常桌面环境打开文章后，用户应该在第一屏就看到正文开头，或者至少已经非常接近正文。
建议重点验收：
- 1440 × 900
- 1536 × 864
- 1920 × 1080
理想状态：
不滚动页面，就已经能够开始阅读正文。
最低要求：
不允许再出现滚动一个甚至两个完整屏幕后才看到正文的情况。
5.2 首屏不是展示区，而是阅读起点
文章详情页不应把首屏当成企业宣传 Hero。
首页和产品落地页可以更强调品牌和转化。
文章详情页则应优先进入内容消费。
因此首屏最重要的目标是：
降低用户从“进入页面”到“开始阅读”的成本。
5.3 用户主任务优先，ARMOR 商业任务并行
首屏需要同时考虑两类价值。
用户想看到的：
- 文章主题
- 标题
- 摘要 / Deck
- 发布 / 更新时间
- 作者
- 阅读时长
- 相关配图
- 正文开始
ARMOR 想展示的：
- 与文章真正相关的产品系列
- 品牌专业能力
- 合理的下一步路径
但 ARMOR 的商业内容不能堵住阅读入口。
原则：
先满足用户来的目的，再考虑 ARMOR 希望用户做什么。
6. 首屏元素的价值排序
以后每一个想进入首屏的元素，都应该接受一个问题：
它凭什么占据第一屏？
高优先级
Article Title
必须存在。用户需要立刻确认文章主题。
Short Deck / Excerpt
只在真正有价值时保留。
作用是快速告诉用户：这篇文章能解决什么问题。
应控制在 1–2 行为主。如果 excerpt 只是重复正文第一段，则不应该占据大量首屏空间。
Publish / Update Date
有价值。
Reading Time
有价值，可以帮助用户判断阅读成本。
Featured Image
可以存在，但尺寸必须受到控制。
图片应服务主题理解，而不是成为视觉障碍。
Article Body Start
这是首屏最高优先级之一。
正文应尽可能早出现。
中等优先级
Author
可以存在。但如果所有文章统一使用 Armor Team，则无需成为强视觉元素。
Breadcrumb
有导航价值，但应该很轻。
Category
可以保留，但不应占据大量空间。
TOC
有价值，但它是“阅读帮助”，不是“进入阅读之前的门槛”。
低优先级 / 不应占据首屏
Tags
适合放在文章结尾，不需要顶部和底部重复出现。
Inquiry CTA
不应该堵在正文前，应在用户已经获得内容价值之后出现。
Latest Articles
不需要占据首屏。
Explore Topics
更适合 Blog 首页 / Category / Tag 页面。
Newsletter
只有在 ARMOR 真正建立成熟 Newsletter 业务体系后再考虑。当前阶段不要为了模仿其它网站而新增。
7. Featured Image 的正确角色
7.1 图片属于文章，不属于文章外部 Hero
重要结论：
Featured Image 应该成为 Article Reading Area 的一部分。
推荐关系：
TOC | Main Article Column
Main Article Column 内部：
Featured Image → Article Body → Section → Content Image → More Content
这样图片、正文和后续内容形成一个整体。
7.2 图片不能决定首屏高度
不能因为某篇文章上传了一张高比例图片，就导致首屏失控。
应使用现有 Tailwind / Image 能力控制：
- width
- max-width
- aspect-ratio
- max-height
- responsive sizing
普通摄影图在确认主体不会被破坏的情况下，可以合理使用 object-cover。
但以下图片不得盲目裁切：
- Technical Drawing
- 尺寸图
- 参数图
- 结构图
- 安装示意图
7.3 图片必须和正文保持稳定对齐
文章图片不应该：
- 随机变宽
- 随机居中
- 随意超出正文
- 左右交错
- 每张图使用不同宽度体系
当前开发阶段优先保证：
图片与 Main Article Column 规整对齐。
7.4 不要默认把所有图片做成 Card
prose-img:shadow-lg 之类的统一大阴影效果，应谨慎使用。
文章图片首先是内容，而不是 UI Card。
工业产品摄影、应用图、技术图本身已经具有信息价值。
不需要通过大阴影、大圆角、浮动效果制造所谓“设计感”。
8. TOC 的角色
TOC 是当前研究中一个明确值得保留的人性化 UX 能力。
它的意义是：
帮助用户操作和使用已有内容，而不是继续增加更多内容。
对于 B2B 用户尤其重要，因为采购、工程师、设计师经常是带着具体问题进入页面：
- 参数在哪里？
- Installation 在哪里？
- Drawing 在哪里？
- FAQ 在哪里？
TOC 应帮助用户快速定位。
8.1 TOC 不应阻碍阅读
TOC 是阅读过程中的辅助系统，不是阅读前必须经过的模块。
桌面可以使用左侧 sticky TOC。
移动端 / 平板继续使用可折叠 On this page。
8.2 TOC 与正文形成 Reading Grid
当前推荐的大屏结构：
TOC | Main Article
例如：
12rem TOC + 合理 Gap + Main Article Column
但 Main Article Column 必须真正使用获得的空间。
不能再在内部给 p / ul / ol / blockquote 分别套 max-w-prose，导致正文继续过窄。
9. 文章宽度原则
正确原则：
父级 Main Article Column 负责阅读宽度，正文内部元素正常使用父级空间。
不要继续维护多层宽度体系。
开发阶段应简化为：
Reading Grid → Main Article Column → prose max-w-none
Main Article Column 使用 Tailwind 已有尺寸，例如：
- max-w-3xl
- max-w-4xl
最终选择应通过真实页面视觉验收，而不是 arbitrary pixel。
不要写 max-w-[790px]、width: 820px、max-w-[900px] 这类任意值，除非存在无法避免的明确技术原因。
10. 文章结束后的信息架构
文章正文结束以后，才进入下一阶段：
用户读完了，现在给他下一步。
推荐顺序：
Article Body → Topics / Share → Related Product Collections → Inquiry → Related Articles → Footer
10.1 Related Product Collections
应该保留。
它完成的是：
Article Knowledge → Relevant ARMOR Product Range
当前 ARMOR 已经有 ArticleProductCollections 以及相关产品集合推荐逻辑。
不需要重新创建 Products Featured in This Post 系统。
10.2 Latest Articles 应退出 Article Detail
文章详情页已经有 Related Articles。
Related Articles 的任务是：
读完这篇以后，你还可能需要什么？
相比之下 Latest Articles 只是：
网站最近发布了什么？
在文章详情页，Related Articles 的价值更高。
因此不需要同时存在 Latest Articles + Related Articles。
10.3 Inquiry 应在用户获得内容价值以后出现
文章页的顺序应该是：
先阅读 → 获得价值 → 如果用户正在做相关项目，再提供联系 ARMOR 的机会。
11. 关于 QTL 首屏商业信息的研究结论
QTL 首屏除了用户想看的文章信息，还放置：
- Products Featured in This Post
- Subscribe to Our Newsletter
这里值得学习的不是具体模块，而是：
品牌商业信息可以与阅读主任务并行，但不能阻塞阅读。
对于 ARMOR：
Products Featured in This Post
这个思路值得保留。
但 ARMOR 已经有 ArticleProductCollections。
因此优先复用现有能力，不创建重复系统。
Newsletter
当前不实现。
原因是要真正实现 Newsletter，后续需要 Subscribe UI、Email API、数据存储、Consent、Privacy、Unsubscribe、Email Delivery、Campaign / Content Operation 等完整能力。
当前项目仍处于基础开发阶段，没有必要为了模仿优秀网站而提前造整套 Newsletter 系统。
12. AstroWind-first 工程原则
本阶段必须坚持：
AstroWind-native Article Detail + Minimal ARMOR Extensions
优先组合：
AstroWind SinglePost + ARMOR ContentTableOfContents + ARMOR ArticleProductCollections + ARMOR Inquiry + AstroWind RelatedPosts
而不是创建一个新的 ARMOR Editorial Framework。
13. 已确认可复用的现有能力
AstroWind 已有
- SinglePost.astro
- Image.astro
- prose typography
- Tags.astro
- RelatedPosts.astro
- BlogHighlightedPosts.astro
ARMOR 已有
- ContentTableOfContents.astro
- ArticleProductCollections.astro
- InquiryForm
- SocialShare
- 现有 Blog / Content Collections infrastructure
因此当前文章详情页的大多数需求都不需要新造组件。
14. 当前开发阶段不应该做的事情
暂时不要：
- 创建新的 ArticleHero
- 创建新的 EditorialImage
- 创建新的 ArticleReadingLayout
- 创建新的 Newsletter 系统
- 创建新的推荐算法
- 创建新的 Sidebar framework
- 引入新的 CSS framework
- 引入 React / Vue / Svelte
- 为 Scroll Spy 引入 client JS
- 为了视觉创意大改 AstroWind
现阶段目标是：
先把网站做正确、好用、稳定、规整。
等整个网站开发完成以后，再进入真正的设计改造阶段。
15. 推荐的 Article Detail 用户旅程
最终应围绕以下路径设计：
进入文章 → 快速确认主题 → 看到阅读成本 → 马上开始阅读 → TOC 帮助快速导航 → 图片帮助理解内容 → 读完整篇文章 → 查看相关产品 → 需要项目支持时联系 ARMOR → 继续阅读相关内容
核心表达：
Navigate → Read → Understand → Discover → Act
而不是：
Navigate + Promote + Discover + CTA + Read
16. 首屏设计验收清单
以后审阅任何 Article Detail 首屏，都应该逐项检查：
- 第一屏能否看到正文开头？
- 是否存在不必要的大面积空白？
- Featured Image 是否把正文推得太远？
- Title 是否清晰？
- Excerpt 是否简短、有价值？
- Metadata 是否轻量？
- Tags 是否错误占据首屏？
- TOC 是否提供帮助而不是增加负担？
- 图片是否和正文形成同一个视觉整体？
- 商业内容是否与阅读并行，而不是堵在正文前？
- 是否存在重复 CTA？
- 是否存在重复的 Latest / Related 内容发现模块？
- 是否存在不必要的自定义组件？
- AstroWind / ARMOR 是否已经有现成能力可复用？
17. 一句话结论
ARMOR 文章详情页首屏的设计目标不是“展示更多”，而是：
用最短路径让用户确认文章价值，并立即开始阅读；同时让 ARMOR 的产品和商业信息以辅助方式出现，而不是成为阅读前的障碍。
首屏不是展示区。
首屏是阅读体验的起点。