揭秘现代 AI / SaaS 公司的内容布局公式
浏览：0
巴克励步
如果你打开一家成熟 AI 或 SaaS 公司的 DNS 记录，往往会看到一串看似「杂乱」的二级域名：`www`、`docs`、`api`、`status`、`chat`、`trust`……它们不是采购清单上的域名凑数，而是行业在多年实践中沉淀出的内容布局公式。 本研究对 Perplexity、Anthropic、OpenAI、Cursor、Intercom、Mintlify 等多家 SaaS/AI 公司二级域名样本聚合后发现：成熟…
如果你打开一家成熟 AI 或 SaaS 公司的 DNS 记录，往往会看到一串看似「杂乱」的二级域名：
www、docs、api、status、chat、trust……它们不是采购清单上的域名凑数，而是行业在多年实践中沉淀出的内容布局公式。本研究对 Perplexity、Anthropic、OpenAI、Cursor、Intercom、Mintlify 等多家 SaaS/AI 公司二级域名样本聚合后发现：成熟企业的对外数字体验，可以归纳为一条清晰结构——一个品牌主域 + 骨干四件套 + 五族群扩展。
公式第一层：一个品牌主域
所有对外叙事都有一个「锚点」：
openai.com、anthropic.com、intercom.com。主域承担三件事：- 品牌可信度与第一触点（通常落在
www） - 组织级合规与信任材料（
trust、legal、privacy） - 与其他子域的语义关联（用户知道「这还是同一家公司」）
OpenAI 的特例在于双根域：
chatgpt.com 贴近终端对话链路，openai.com 承载开发者平台与企业合规叙述。公式不变，只是受众矩阵决定了材料挂在哪条根域下。公式第二层：骨干四件套
跨企业计次后，过滤噪声（仅出现 1 次的标签）保留 26 个高频前缀，Top 4 合计分值 57，约占有效信号 46.7%：
| 排名 | 前缀 | 跨企业计次 | 本质 |
|---|---|---|---|
| 1 | www | 20 | 品牌叙事、产品概览 |
| 2 | api | 15 | 接口参考、集成入口 |
| 3 | docs | 12 | 产品文档、开发者参考 |
| 4 | status | 10 | 可用性公告、事故沟通 |
这四类构成 MVP 阶段最常见的内容骨干：让潜客看懂、让用户能查、让集成方能调、让事故可通报。再小的团队（如 Mintlify 平台方自身仅 4 个
*.mintlify.com 主机）也会优先保留 api + status + 门脸。公式表达：
品牌主域
├── www. 门脸与价值主张
├── docs. 产品是什么、怎么用
├── api. 机器可读的事实与集成
└── status. 服务是否健康、事故怎么说
公式第三层：五族群十八场景
在骨干四件套之上，行业常将体验归纳为 5 大族群、18 类场景（本仓库对照 Baklib 场景模板与调研样本）：
- 对外品牌与获客：www、products、blog、events
- 客户服务与支持：docs、help、chat、feedback
- 开发者与生态：developers、api、resources
- 组织、人才与合规：intranet、jobs、legal
- 内容与社区：podcasts、videos、community、partners
扩展场景还包括
trust、status、academy、brand 等——在采购与安全评审中权重往往很高。中腰高频标签（各 4～5 次计分）体现产品化 + 自助化双轨：
chat、platform 对应登录后用产品；help、blog、community 对应未登录先自助或获客。案例：公式在三家 AI 公司的变体
Anthropic：
www + docs + api + console + legal——开发者路径与合规披露分离清晰，采购常见问题有固定入口。Perplexity：
www、docs、api 之外还有 labs、blog、podcast——检索产品、实验叙事、内容营销各走专域，材料不混写在同一信息架构里。OpenAI：在骨干之上叠加
chat、platform、help、trust、research、cookbook 等，呈现双根域 × 多受众的完整矩阵。不是门牌越多越好，而是每种关键受众都有对的门。六层架构：公式在「楼层」上的展开
若把公式画成竖切面，可与六层体验架构一一对应——便于和研发排期、运营分工对齐：
| 楼层 | 公式中的位置 | 典型前缀 |
|---|---|---|
| 门脸 | 主域叙事锚点 | www, brand |
| 自助认知 | 四件套延伸 | help, blog |
| 产品应用 | AI 时代增量 | chat, app, platform |
| 开发者 | 四件套核心 | api, docs, developers |
| 信任韧性 | 四件套 + 合规 | status, trust, privacy |
| 身份商业 | 治理边界 | auth, admin, pay |
公式不是平面清单，而是有优先级的楼层：先齐 1、4、5 层骨干，再补 2、3 层获客与产品化，最后才考虑 6 层与生态长尾。Cursor 样本体量相对精简，却仍有 www、api、trust——说明楼层可以少，但开发者与信任两层不宜长期空缺。
公式的三个实操启示
1. 先画内容，再挂门牌
子域数量（MVP 约 4、成熟约 10～20）是内容就位后的技术侧面，不是规划起点。从受众与场景反推该写什么，惯例前缀只是落地时的常见选择。
子域数量（MVP 约 4、成熟约 10～20）是内容就位后的技术侧面，不是规划起点。从受众与场景反推该写什么，惯例前缀只是落地时的常见选择。
2. 命名即体验承诺
用户已形成路径预期：找文档去
用户已形成路径预期：找文档去
docs，找接口去 api。随意 renamed 会增加认知成本，也会让 AI 检索（GEO）抓取路径不稳定。3. 统一事实源，避免多副本地狱
公式里的每一扇门背后都应有明确维护人与更新节奏。品牌话术、SLA、数据驻留说明 ideally 只维护一份源，多场景分发——否则「改一处改三处」会成为常态。
公式里的每一扇门背后都应有明确维护人与更新节奏。品牌话术、SLA、数据驻留说明 ideally 只维护一份源，多场景分发——否则「改一处改三处」会成为常态。
你可以立刻做的自检
花 30 分钟，把公司对外 URL 按「主域 → 骨干四件套 → 五族群」贴标签：
- 骨干四件套是否齐全？缺
docs或status往往最先暴露痛点。 - 同一产品描述是否在 www、blog、help 三处口径一致？
trust/legal是否有可分享给采购的固定链接？
公式不是教条，而是行业惯例的压缩包。你的公司可以走路径（
/docs）而非子域，但内容分工的逻辑不会因此消失。与 Stripe、GitHub 的常识对照
虽未纳入本仓库实测样本，Stripe、GitHub 等公开产品的布局与公式高度同构：开发者文档与 API 参考独立于营销主站，状态页面向集成方开放订阅。它们进一步印证：用户并不期待「所有材料都在首页找」——公式体现的是协作惯例，而非某一家公司的特殊癖好。
下一步读什么？
关于 Baklib
现代 AI / SaaS 公司的内容布局公式，本质上是在回答：一套企业内容资产，如何服务多受众、多场景？ Baklib 定位下一代企业数字内容基础设施——用统一内容源驱动品牌站、文档站、帮助中心、信任中心等多类门户，避免「每个场景买一个工具、各维护各的副本」。
当你按公式规划
www + docs + help + trust 等场景时，Baklib 提供与行业 18 类体验场景对齐的模板与 Headless 分发能力：写一次品牌话术与 API 说明，多站点一致呈现；发版流程可挂钩合规页巡检。若你正在从「几个散落的 SaaS」走向可扩展的内容矩阵，可在 www.baklib.com 了解场景化建站与内容中台思路，用 POC 验证是否匹配自家公式落地节奏。数据说明：本文 Top4 占比、跨企业计次均来自本研究对多家 SaaS/AI 公司二级域名样本聚合（
subdomain_score.json），非全球统计。
