概览

何时使用

每个产品或主要产品区域一个概览——即其侧边栏分组打开时的首个页面。范围说明： 本指南覆盖产品区域概览。跨多个区域的文档站点首页是更轻量的变体：同样的导航规范，但定向段落缩减为一句话标语，可用性/行动号召插槽通常不适用。概览不是：

• 概念页面。 概览说明产品做什么；概念页面解释如何运作以及为什么。如果一个段落开始解释架构或权衡取舍，将其移到概念页面并添加链接。
• 纯目录。 没有引导的链接列表只是侧边栏的重复。
• 营销页面。 读者已经点击进入了文档。说明它做什么、为谁服务；跳过说服。如果营销内容必须存在于文档附近，用栅栏隔离而非混入其中。

需要保持的平衡：足够的文字来引导（一段话），然后纯导航。

标题和描述

• 标题：产品或区域名称，作为名词。 “Hookline” 或 “Endpoints”——永远不要写 “Hookline documentation”，不要用动名词，不要写 “Introduction”。
• 描述公式： “它是什么 — 它为谁做什么。”——例如 “Hookline 为你投递应用程序的 webhook——带签名、可重试、可观测。”

搭建此页面

安装指南——你的编码智能体会读取完整的骨架和清单，并将其适配到你的产品：

npx @cloudflare/nimbus-docs add content-overview

yarn dlx @cloudflare/nimbus-docs add content-overview

pnpm dlx @cloudflare/nimbus-docs add content-overview

bunx @cloudflare/nimbus-docs add content-overview

组件指导

• Cards / CardGrid 是标志性组件——这是唯一一种卡片作为正文内容的类型，因为导航就是正文。卡片文字保持在名称加一行说明；有解释内容的卡片就是装在盒子里的概念段落。在 .md 版本中，卡片会展平为链接加描述的列表——编写单行说明时要确保两种形式都适用。
• 链接列表优于卡片的场景：当网格迫使填充冗余文案时，或者当一个分组确实需要超过约 5 个链接上限时——散文列表在大量条目时更易扫读。
• 不适用： Steps（这里没有操作步骤）、代码块（这里不查阅任何内容——引导行中的行内代码可以）、折叠面板（有隐藏内容的概览是在隐藏自己的地图）。

结尾

当相邻区域确实容易与本区域混淆时，以相关部分结尾——每个条目用一行进行消歧。当没有需要消歧的内容时，最后一个功能分组结束页面。无论哪种方式，都没有“下一步”章节：整个页面就是下一步。

阈值

• 引导文字 ≤ 1 段（加上可选的结果要点）。更长意味着解释内容渗入了。
• 3–5 个功能分组，每组 ≤ ~5 个链接——这使整个页面大约两到三屏。超出此范围时，产品区域需要子概览（导航页面模式），而不是更长的概览。
• 按读者的任务分组（“发送事件”、“安全防护”），而不是按内部团队或功能标志名称。

链接和新鲜度

本页面上的每个链接都至关重要——此处链接失效或过时会让读者在门口迷路。当新页面在此区域发布时，将其添加到这里（或决定不添加）是发布的一部分。在 frontmatter 中记录最近一次完整路由检查（lastUpdated 或 lastVerified 注释），使过时状态可见而非事后发现。

智能体备注

• 此页面是作用域 llms.txt 的人类可读对应物——相同的职能，相同的结构：名称、一行摘要、分节的带描述链接。编写卡片单行说明时要确保它们在 Markdown 版本中也能作为链接描述使用；智能体根据这些描述来决定获取什么内容。
• 引导段落是智能体在被问及“Hookline 是什么”时引用的内容——确保它自成一体且准确。

清单

建议性——供作者或智能体自查，不是构建门禁：

• 标题是产品/区域名称，名词形式，不含 “documentation”
• 一段引导文字（加上可选的结果要点）；迷路的读者能在此意识到
• 如果可用性因计划/地区/阶段而异，需说明
• 快速入门行动号召排在链接首位
• 分组按读者任务命名；卡片用于导航，不做解释
• 当存在易混淆的相邻区域时，提供相关部分并附消歧说明
• 每个链接可访问；此区域的新页面已收录（或明确不收录）
• 无步骤、无代码块、无隐藏在折叠面板中的内容