--- title: "快速开始" description: "让读者在几分钟内看到一次真实结果，且全程无需做任何选择。" --- > Documentation Index > Fetch the complete documentation index at: https://nimbus.ndjp.net/llms.txt > Use this file to discover all available pages before exploring further. # 快速开始 > **需求** > > 处于学习阶段、正在行动 —— 但目标是测试，而不是学习。读者正在评估产品或刚刚注册，想看到它能工作的证据：一次真实结果，越快越好。他们的第一个问题：*“多快能看到它做点什么？”* 指标是首次成功所需时间，而且它有代价：更长的快速开始会显著流失读者。 ## 适用场景 每个产品在每条主要路径上恰好有一个快速开始（例如 API 一个、控制台一个）。它不是： - **教程。** 没有学习目标，除了一句 “刚才发生了什么” 之外没有解释。读者不是在学，而是在测。 - **操作指南。** 操作指南服务的是正在工作中、有明确目标的读者。快速开始的唯一目标是*首次*成功，而且它替读者选择了这个目标。 定义性约束：**作者替读者做每一个选择。** 一种语言（其余用标签页），一种安装方式，处处使用默认值。当某个选择确实无法通过默认值消除时（区域、组织类型），替读者选推荐项，并用一句末尾说明提示替代方案 —— 绝不在步骤中间制造分叉。 **Get started 变体。** 有些产品不经过真实配置就无法达成一次诚实的首次成功，例如 DNS 或租户设置。对这类产品，把这个配方写成 **“Get started”（开始使用）** 页面： - 标题固定为 “Get started”。 - 预算放宽到最通用场景的*最小可用配置*。 - 前置条件可以包含真实决策，但每个决策都压缩为一个推荐默认值，并用一行说明何时选择其他方案。 下文其余内容原样适用。有快速路径的产品两者都发布：快速开始用来证明它能工作，Get started 用来正确完成配置。 ## 标题与描述 - **标题：** 只有一个时用 “Quickstart”；按框架或入口路径分别提供时用 “Quickstart: *路径或技术栈*”（“Quickstart: Next.js”“Quickstart: Dashboard”）。Get started 变体的标题永远是 “Get started”。 - **描述公式：**“*结果*，在*时间上限*内。” —— 例如 “五分钟内发出你的第一个 webhook。” 只承诺你亲眼看着陌生人达成过的时间。 ## 脚手架生成本页 安装配方 —— 你的编码智能体会读取完整骨架和清单，并根据你的产品做调整： ```sh npx @cloudflare/nimbus-docs add content-quickstart yarn nimbus-docs add content-quickstart pnpm nimbus-docs add content-quickstart bunx @cloudflare/nimbus-docs add content-quickstart ``` “你应该看到”（You should see）与 “下一步”（Next step）是契约性固定标题 —— 读者（和智能体）会学着直接跳到它们。 ## 组件建议 - **Steps** 和**带可见输出的代码块**就是整页。 “你应该看到” 区块是最重要的单一元素 —— 它是证据。 - **Tabs** 只用于语言/技术栈这一维度，且仅当示例真正平行时使用。其他任何选择：由作者决定。 - **不适合：** 卡片、折叠面板、关于边缘情况的提示框、步骤中间的链接。不在最短路径上的内容，就属于别的页面。 ## 结尾 固定页脚：**你应该看到**（预期输出 + 一句 “刚才发生了什么”）→ **下一步**，恰好一个主链接。有意识地使用下一步位置 —— 指向能加深采用的功能，而不是通用文档首页；最好的站点把快速开始的结尾当作旅程路由。 ## 阈值 - **≤ 约 600 词，≤ 6 步，一个功能。** 词数预算适用于**一条渲染路径** —— 一次标签页选择 —— 而不是多语言页面的源码总量。 - **当自然集成超出预算时，缩小首次成功** —— 一个托管页面、一次 CLI 触发的循环、一次调用 —— 而不是给快速开始注水，或把责任推给产品。完整集成属于 Get started 页面或操作指南。 - **不要错误处理、不要选项、不要生产加固。** 结尾可以用一句诚实的话说明跳过了什么，就像安静的 “测试模式” 标签那样。 - **每一步都必须每次都成功。** 快速开始借用教程的可靠性规则：陌生人的最初五分钟，不是 “结果因人而异” 该出现的地方。 ## 链接与时效 页脚之前几乎不要有链接 —— 首次成功之前的每个链接都是出口。这类页面在全部类型中腐化最快（安装命令、CLI 输出、注册流程）：在每个触及该路径的版本上完整重跑一遍，并在 frontmatter 中盖上 `lastVerified`。 ## 智能体说明 - 智能体会逐字执行快速开始；本页实际上是一份脚本外加周围说明。每条命令都必须可直接复制运行 —— 占位符写在尖括号里（`hl_test_`），绝不要在命令中使用裸省略号。 - 把会变化的输出字段（耗时、生成的 ID）标为占位符（`ms`），这样智能体把自己的输出与你的一比对时，不会把正常波动当成失败。输出块中其余内容保持原文。 - 在 `.md` 版本中，语言标签页会摊平成带标签的顺序块 —— 预期输出必须在每条路径上各出现一次，不能只出现在默认标签页里。 - 前置条件写成可核对的事实（“Node 20+”），不要写成感觉（“较新的 Node”）。 ## 检查清单 建议性 —— 供作者或智能体自检，永不作为构建闸门： - [ ] 描述中包含时间上限，并经过冷启动验证 - [ ] 读者零决策（标签页只用于语言/技术栈；无法默认的选择已替其决定，并附一行替代方案） - [ ] 每条渲染路径 ≤ 约 600 词、≤ 6 步、一个功能 —— 否则就缩小首次成功直到放得下 - [ ] 模拟了测试模式凭据；占位符放在尖括号中，命令里没有省略号 - [ ] 存在 “你应该看到” 标题；除会变化的字段用占位符外，输出保持原文 - [ ] “刚才发生了什么” ≤ 2 句 - [ ] 结尾恰好一个主下一步 - [ ] 已针对当前版本端到端验证；已盖上 `lastVerified` Source: https://nimbus.ndjp.net/style-guide/quickstart/index.mdx