企业官网建设流程全解析

• 后端
• 前端
• 企业应用
• 运维
• 网络安全

Fleet 的开源仓库中沉淀了一套完整的案例研究（case study）写作方法论：以「问题 → 选择 Fleet → 结果」的三幕式叙事为骨架，配合attribution-quote与checklist两种自定义 div 语法和一套构建强制的元数据（meta tag），最终由网站构建管线渲染成带侧边栏摘要与公司卡片的专用页面。本文基于 fleet-case-study-formatting 技能及其规范示例拆解文档，完整讲解这套结构的每个组成部分、语法细节、诚实性红线与工作流，读者可直接用于撰写或审校仓库articles/目录下的案例研究文章。

适用范围：何时使用这套格式

Fleet 的内容体系按category划分内容类型，各类型对应独立技能。案例研究格式只适用于<meta name="category" value="case study">的内容：以真实客户的真实话语讲述其采纳 Fleet 的故事，用三段式结构呈现（客户的问题、为何选择 Fleet、改变的结果），并由署名引用（attributed quotes）锚定。

以下内容类型不适用本格式：

• 文章（articles）：思想领导力、教程、对比类文章，使用 fleet-article-formatting；
• 指南（guides）：分步操作流程，使用 fleet-guide-formatting；
• 公告（announcements）：即便叙述客户体验也归为此类。仓库内 deputy-achieves-compliance-and-clarity-with-fleet.md 就是真实例子：它读起来像案例研究（含checklistdiv、Challenge/Solution/Results 结构），但被标记为announcements，且完全省略了案例研究专用的元数据标签。

因此在应用本格式之前，应先检查文章的<meta name="category" ...>值，或向作者确认文章归属的内容类型，避免把格式强加给不匹配的内容。

结构骨架：三幕式叙事

案例研究的正文遵循一条统一弧线，规范示例中的标题措辞各有不同，但骨架一致：

1. 问题（The problem）：客户此前使用的工具或流程，为何失效，以及代价（浪费时间、风险、具体事故、迟缓的厂商支持）。必须落到具体事实：真实的工具名、真实的设备数量、真实的事故（如 Thumbtack 误设 nudge 配置文件日期导致全公司立即强制升级）。
2. 选择 Fleet（Choosing Fleet）：他们拿什么做评估对比，为何 Fleet 胜出。每个理由都要对应一项真实能力，而非空泛背书：API-first 架构支撑 GitOps、开源代码支撑自托管与审计、跨平台覆盖、基于 Slack 的高响应支持。
3. 结果（The results）：量化、具体的产出：迁移速度与百分比、成本/许可节省、人力或工单量变化、解锁的新能力。这是checklistdiv 最常见的落点。

可选第四节「展望（Looking ahead / The future）」收尾展望下一步——平台覆盖扩张、伙伴关系加深、新用例。并非每篇都需要，多个规范示例把这一节并入了结果部分。

空白的可复制模板完整保留了上述骨架，可直接作为起草起点。

标题规范

标题使用句首大写（sentence case，公司名除外，保留其自身大小写）。要点是点出公司与结果，而非功能：

• "Fastly gains visibility into all endpoints and critical infrastructure worldwide"（fastly.md）
• "Stripe moved 10,000 Macs to Fleet, saving hundreds of thousands annually"（stripe.md）
• "Thumbtack migrates more than 90% of Macs with no IT intervention"（thumbtack.md）

当故事侧重机制时，"How [Company] ..." 句式同样成立："How Mollie manages endpoint compliance the same way it ships software"、"How Primo built an HR-driven IT platform, powered by Fleet"。

自定义 div 语法

案例研究专属两种自定义 div 块，构建管线与样式表依赖它们的精确写法，必须严格照抄：

attribution-quote：署名引用

正文中的拉引（pull quote），归属于具名发言人：

<div purpose="attribution-quote"> *斜体的逐字引用，与客户原话完全一致。* **发言人姓名** 职位，公司 </div>

• 引用行用斜体（*...*），姓名用粗体（**...**），职位/公司行为纯文本；三者之间必须有空行，Markdown 才能正确渲染；
• 职位与公司可合并为一行（如 "Sr Manager Systems Engineering, Fastly"），若公司从上下文已显而易见，也可只写职位；
• 每篇案例研究使用 2～4 处引用，散布在叙事中最具冲击力的位置——描述痛点之后、阐述"为何选择 Fleet"之后、结果部分各放一处，不要全部堆在开头。

各规范示例展示了多种用法：Fastly 三处引用来自两位不同发言人（一位经理与一位高级客户端平台工程师），证明引用不必全部出自同一人；Stripe 四处引用全部来自同一发言人（Staff Client Platform Engineer），其中一处仅一句话，证明短引用同样能撑起一节；Thumbtack 在"Why Fleet"一节连续密集放置三处引用，证明引用可以聚集在其最相关的章节，而非每节各放一处。

checklist：短条目清单

由样式表渲染为勾选清单的纯文本列表，条目之间用空行分隔，不要使用-或*项目符号（div 的 CSS 自带对勾样式）：

<div purpose="checklist"> 第一条——一条标准、一个功能或一项量化结果 第二条 第三条 </div>

checklist 有两种典型用途：

• 评估标准：如 faire.md 中列出的三条 MDM 选型优先级（API-first 架构、全面的 Apple 支持、可靠的供应商），这是用checklist承载决策标准而非结果的最清晰示例；
• 简明结果清单：如 foursquare.md 仅用两条结果（维护工作量降低 50%、支出降低 24%）就撑起一个 div，证明两条目也完全成立。

结果超过 4 条且需要更多解释时，也可以退化为结果部分的普通 Markdown 项目符号列表——thumbtack.md 与 primo.md 的 "With Fleet, [Company] has:" 列表就是合法替代，两种写法按故事可读性择优。

章节编排：七篇规范示例的差异化应用

canonical-examples.md 逐篇拆解了七篇参考案例如何在同一骨架下做变体，写作时应"选贴合故事的小节标题"，而非照抄某一篇的措辞：

语音与诚实性红线：比文章更严格

案例研究的风险高于普通文章：每一个论断都归于真实公司中的真实个人，发布前后会由该公司核实。因此：

• 引用必须逐字准确，绝不改写或虚构。若故事需要的时刻缺少客户的原文，就围绕它写叙事而不放引用，或提示作者补充真实引用。严禁编造听上去合理的引用并归于具名个人。
• 数字必须来自客户，而非作者推断。迁移百分比、设备数量、成本节省、时间线都必须能追溯到客户或与其协作的 Fleet 团队的原始表述。任何推断的数字都要明确标记，而非当作已证实事实。
• 对 Fleet 自身团队成员的贡献（如 CSM 在迁移中的角色）须如实命名，且仅当这属于客户的叙述，不得虚构润色。
• 其余规则沿用 content-style 的完整要求：标题句首大写、禁 em dash、禁夸张词（"revolutionary"、"seamless"、"game-changing"）、牛津逗号、主动语态。案例研究的叙事口吻比指南更偏叙述性、更接近文章，但仍保持克制——让客户的引用承载热情，叙述者之音保持有据、客观。

结尾元数据：构建强制的案例研究标签

在标准文章结尾元数据（articleTitle、description、publishedOn、authorFullName、authorGitHubUsername、category）之外，网站的 Markdown 构建脚本 website/scripts/build-static-content.js 对category: case study页面要求额外标签，缺失即构建失败：

• summaryChallenge、summarySolution、summaryKeyResults：必填。它们填充案例研究页侧边栏的 "Challenge / Solution / Key results" 摘要框（website/views/pages/articles/case-study.ejs）。其中summaryKeyResults必须是分号分隔的列表（"Result one; Result two; Result three"），单句无分号会导致构建报错——这是源码层面强制校验的规则；
• companyLogoFilename：若存在，必须引用website/assets/images/中实际存在的文件，构建脚本会校验并在文件缺失时报错；
• quoteContent（页面顶部的 hero 拉引）：若存在，必须同时提供quoteAuthorName、quoteAuthorJobTitle、quoteAuthorImageFilename，且图片文件必须存在于website/assets/images/；
• companyName、companyInfo（及可选的companyInfoLineTwo）：驱动 "About [Company]" 侧边栏/移动端信息块。虽然非构建强制，但模板期待这些字段，应包含。

companyInfoLineTwo的用法很灵活：Faire 用它补充地理范围、员工数与设备构成（约 1,000 名员工，macOS 为主，另管理 300 台用于 Zoom Rooms 的 iPad），Foursquare 用它补充公司定位——按故事中最重要的第二个事实选择即可。

图片资产是硬依赖，而非该技能能自行产出的部分。构建成功前，需要有人按网站命名约定（{descriptor}-{css-width}x{css-height}@2x.{ext}，如fastly-logo-104x40@2x.png、dan-jackson-120x120@2x.png）把真实 logo 与头像文件放入website/assets/images/。若这些文件尚不存在，应明说，而不是写指向虚无的<meta>标签——那是一次静默构建破坏。

存在一个逃生舱：<meta name="useBasicArticleTemplate" value="true">可让案例研究改用普通文章模板渲染（此时要求cardTitleForCustomersPage而非摘要/引用/公司标签）。此情况罕见，仅在作者明确不要侧边栏模板时使用。

可选后续步骤：testimonials.yml

许多（并非全部）已发布案例研究还会把其拉引作为条目加入 handbook/company/testimonials.yml，该文件驱动网站各处的<scrollable-tweets>轮播（如/customers页）。这是锦上添花、非构建强制，且超出本技能的核心职责——应向作者作为后续事项提及，而非主动代做，因为它涉及营销团队共享维护的公共文件。

写作工作流

1. 确认有真实素材：客户的逐字引用（署名）与具体数字（设备数、迁移时间线、成本数据）。若基于原始访谈笔记或通话记录，先抽取引用与事实再起草，不要把真实引用润色成不同的措辞；
2. 识别本故事的三幕形状：什么坏了、为何选 Fleet、什么变了。选贴合故事的小节标题（参考规范示例），而非逐字复用某一篇的标题；
3. 起草正文：问题 → 决策 → 结果，在冲击点穿插 2～4 处attribution-quotediv；若故事有天然短清单，用checklistdiv 承载评估标准和/或核心结果；
4. 写标题（句首大写、点出公司与结果）；
5. 写完整结尾元数据块：标准文章标签后接案例研究专用的摘要/引用/公司标签。summaryChallenge/summarySolution从正文前两幕精炼转写，summaryKeyResults从结果节派生并分号分隔；
6. 确认图片资产（companyLogoFilename、quoteAuthorImageFilename）存在于website/assets/images/，否则标记仍需补充；
7. 运行 content-style 技能审校语音、句首大写、em dash、赘词与 Fleet 术语；
8. 运行下述自检。

审校工作流

1. 确认文章标记为category: case study；若它是叙述客户故事的announcements文章（如 Deputy 示例），不要强行套用此结构，而是指出不匹配；
2. 通读全文，确认三幕结构完整：问题、决策、结果，每幕都落到具体事实而非泛泛褒奖；
3. 检查每处引用是否像真人会说的话（具体、偶尔不够圆润的措辞）——过于顺滑往往是改写而非转写的迹象，存疑时提示作者对照原始来源核实；
4. 检查attribution-quote与checklistdiv 语法正确（引用/姓名/职位间有空行，checklist内无多余 Markdown 符号）；
5. 核实结尾元数据含全部案例研究必需标签，且summaryKeyResults分号分隔；
6. 核实引用的图片文件（companyLogoFilename、quoteAuthorImageFilename）真实存在于website/assets/images/；
7. 对正文运行 content-style；
8. 运行下述自检，随后总结改动并标记任何无法核实之处（数字、引用、缺失图片资产）。

完成前的自检清单

• 标题句首大写、点出公司、陈述结果而非功能；
• 正文遵循问题 → 选择 Fleet → 结果的弧线，小节标题贴合本故事；
• 2～4 处attribution-quotediv，格式正确（斜体引用、空行、粗体姓名、空行、职位/公司），散布于叙事而非聚集；
• 每处引用逐字准确、归于真实的具名个人，无虚构引用；
• 每个数字（迁移百分比、时间线、成本、设备数）可追溯到客户或 Fleet 团队，而非推断；
• 用checklistdiv（或普通列表）呈现核心结果；
• 结尾元数据包含summaryChallenge、summarySolution、summaryKeyResults（分号分隔）及公司/引用标签——或使用useBasicArticleTemplate时提供cardTitleForCustomersPage；
• companyLogoFilename与quoteAuthorImageFilename引用的图片存在于website/assets/images/，或已告知作者需要补充；
• 正文不含 "osquery"（改用 "Fleet's agent" 或 "fleetd"）；标题句首大写；无 em dash、赘词或夸张；
• 已对正文运行 content-style 技能。

边界案例：一个不算案例研究的客户故事

deputy-achieves-compliance-and-clarity-with-fleet.md 是一个真实的反例：它使用checklistdiv、具有 Challenge/Solution/Results 形态、讲述客户使用 Fleet 的体验，但被标记为<meta name="category" value="announcements">，且没有任何案例研究专用元标签（summaryChallenge、summarySolution、summaryKeyResults、companyName、quoteContent等），正文还使用了行内 Markdown 链接与短小的大写风格标题（"## Challenge"、"## Solution"），而非当前模式使用的更完整的句首大写标题。

这正是 SKILL.md 作用域一节所点名的边界情况：一篇以公告而非完整案例研究发布的客户叙事，很可能是因为它缺少案例研究模板要求的专属 logo/头像图片资产与更完整的摘要内容。若有人想把这类文章"修复"成案例研究格式，正确做法是询问作者是否愿意投入补齐缺失资产与摘要元标签以升级为真正的案例研究，而不是悄悄加上category: case study而不做相应投入。

• 后端
• 前端
• 企业应用
• 运维
• 网络安全