适用场景
每个产品或主要产品区域只写一个概览 —— 它就是侧边栏该分区打开时显示的页面。范围说明： 本配方针对产品区域概览。覆盖多个区域的文档站首页是更轻的变体：路由纪律相同，但定位段落缩为一句标语，可用性与 CTA 区块通常不适用。概览不是：
- 概念页。 概览说明产品做什么；概念页解释怎么做、为什么。如果某段话开始讲架构或取舍，把它移到概念页并链接过去。
- 裸目录。 只有链接列表、没有定位说明，等于把侧边栏复制成页面。
- 营销页。 读者已经点进文档了。说明它做什么、面向谁；跳过推销。如果文档附近必须有营销内容，把它与智能体隔离开，而不是混进来。
要把握的平衡：足够定位的一段话，然后纯路由。
标题与描述
- 标题：产品或区域名称，名词。 “Hookline” 或 “Endpoints” —— 不要 “Hookline 文档”，不要动名词，不要 “介绍”。
- 描述公式：“它是什么 —— 它为谁做什么”。例如 “Hookline 投递你应用的 webhook —— 带签名、可重试、可观测。”
脚手架生成本页
安装配方 —— 你的编码智能体会读取完整骨架和清单，并根据你的产品做调整：
npx @cloudflare/nimbus-docs add content-overview
yarn nimbus-docs add content-overview
pnpm nimbus-docs add content-overview
bunx @cloudflare/nimbus-docs add content-overview组件建议
- Card / CardGrid 是标志性组件；这是唯一一种路由就是正文的类型。卡片文字保持为名称加一行说明，并确保它作为普通列表也成立 —— 在
.md版本中卡片就是这样呈现的。 - 链接列表 优于卡片的情形：网格迫使文案被填充时，或某个分组确实需要超过约 5 个链接时 —— 成规模的散文列表更好扫读。
- 不适合： Steps（这里没有要执行的操作）、代码块（这里没有要查的值 —— 定位句中的行内代码没问题）、折叠面板（藏了内容的概览，就是在藏自己的地图）。
结尾
只有当相邻区域确实容易与本区域混淆时，才以 Related（相关）结尾 —— 每条给出一行区分说明。没有需要区分的内容时，最后一个能力分组就结束页面。无论哪种，都不要 “下一步” 区块：整页都是下一步。
阈值
- 定位说明 ≤ 1 段（加上可选的结果要点）。更长意味着解释内容渗了进来。
- 3–5 个能力分组，每组 ≤ 约 5 个链接 —— 整页约两到三屏。超过则需要子概览（导航页模式），而不是更长的概览。
- 按读者任务分组（“发送事件”“安全”），绝不要按内部团队名或功能开关名分组。
链接与时效
本页每个链接都承重 —— 这里断链或过期会让读者卡在门口。本区域发布新页面时，把它加到这里（或明确决定不加）属于发布工作的一部分。在 frontmatter 中记录最近一次完整路由检查（lastUpdated 或 lastVerified 备注），让过期可见，而不是被发现。
智能体说明
- 本页是与限定范围的
llms.txt对应的人类可读版本 —— 同样的任务、同样的形状：名称、一行摘要、带描述的分节链接。写好卡片的一行说明，使它们在 Markdown 版本中也能作为链接描述；智能体据此决定抓取什么。 - 定位段落是被问到 “什么是 Hookline” 时智能体引用的内容 —— 让它自成一体、单独看也准确。
检查清单
建议性 —— 供作者或智能体自检，永不作为构建闸门：
- 标题是产品/区域名称，名词，不含 “documentation”
- 一段定位说明（外加可选的结果要点）；走错门的读者能在这里意识到
- 如果可用性因套餐、区域或阶段而异，已说明
- 快速开始 CTA 排在链接最前
- 分组按读者任务命名；卡片只做路由，绝不做解释
- 存在易混淆的邻居时提供 Related，并附区分说明
- 每个链接都能解析；本区域的新页面已体现（或有意不体现）
- 没有步骤、没有代码块、没有藏进折叠面板的内容